> Codify what, please? I personally use which, since it is > provided by am essential package, and I can live with it eing an > external program, and missing aliases. People can also use POSIX type
You don't have that with zsh, since which is a builtin. > (umm, does zsh have type?). Why does this have to be codified? When zsh has type as a builtin, though it isn't POSIX either. > do we want to stop codifying every little thing? When there are no more problems? There are numerous #!/bin/sh scripts in Debian that are not POSIX-compliant. One might get the idea, if one were to read Debian's policy documents, that these scripts violate Policy. One might also get the idea, if one were to read the same section, that one could install a POSIX-compliant shell as /bin/sh on one's Debian system, and that one would experience no difficulties in doing so. Of course, this is a fallacy. What is the "common sense" thing to do? I would say that it's to have bash as /bin/sh, since that's what most maintainers are using, and that's what's most likely to work with the most scripts. I, on the other hand, would rather have ash as /bin/sh. What makes this possible? That policy has codified the requirement for /bin/sh scripts to be POSIX-compliant, and ash, for the most part, does a good job executing POSIX-compliant scripts. If this were not codified, and we were still living in the dark ages when someone would be lynched for using ash as /bin/sh and having the gall to expect sympathy, then well, lynching would be the least of problems. > I would possibly classify hard coded paths a bug in the > package, since I may well be experimenting with PATH's. But hard > coding paths is just asking for breakage, in case the FHS or the LSB > or someone decrees the binary move. Since there is no need for such > hard coded paths, doing so is bad design. And not doing so invites unexpected behaviors. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
