Taylor Venable wrote: > Micah Cowan <[EMAIL PROTECTED]> writes: > >> Is there a good reason not to simply follow symlinks when they are >> encountered, as this user obviously expected? > > If it did follow the symlink to /dev/null, and tried to read from that > device, it would fail. You can't (or at least, shouldn't) read from > /dev/null because it's a sink, not a source. What kind of behavior > would you expect, trying to read from /dev/null?
As Tony has indicated, /dev/null is indeed intended to be read as well as written. >> I realize that unsetting viminfo is preferable to linking .viminfo to >> /dev/null; but I believe we still have a responsibility to users who >> just happen to try a different route (perhaps being unaware of the >> "canonical" method), for which they have a reasonable expectation that >> it will DTRT. > > I think soft linking a file that is meant to be both read and written > to the bit bucket demonstrates that the user has just enough knowledge > to be dangerous but without knowing exactly how to get what they want. > As that kind of a user, I would expect an error message of some sort, > in this situation. You may think that. My own thoughts are that this is an extremely common Unix idiom, and should be handled accordingly. -- Micah J. Cowan Programmer, musician, typesetting enthusiast, gamer... http://micah.cowan.name/
signature.asc
Description: OpenPGP digital signature
