-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 According to Paul Eggert on 2/23/2005 12:36 PM: >>On the bug-bash list, Chet Ramey pointed out to me that a POSIX shell is >>not required to implement those 17 utilities as built-ins; it only >>requires that the POSIX-compliant version those 17 utilities be >>successfully found without searching PATH, and that any side-effects to >>the current environment take place correctly. > > Sorry, I can't parse that. > And I can't find anything relevant after wading through the spam at > <http://lists.gnu.org/archive/html/bug-bash/2005-02/threads.html> > (perhaps because the discussion hasn't been archived yet). > Could you please elaborate a bit, perhaps with a URL or two?
Sorry about that. See the thread starting at: http://lists.gnu.org/archive/html/bug-bash/2005-02/msg00107.html In short, POSIX never says that those 17 utilities SHALL be builtins, only that they are frequently provided as builtins. The first SHALL requirement (in XCU 1.13) is that any utility provided as a regular builtin (whether those 17, or others) also be findable by the exec() family. The second SHALL requirement (in XCU 2.9.1 Command Search and Execution) is that those 17 utilities are guaranteed to be invoked without having to do a PATH search (ie. no trojan horse at the beginning of PATH can thwart the shell from invoking the POSIX-compliant version of the utility, whether the utility was builtin or not). However, many of those 17 utilities have further requirements on the utility itself, that when invoked in the same execution environment as the shell, they have side effects visible to that shell (cd sets PWD, OLDPWD, and changes the current directory; alias adds aliases to the current environment, etc) or require information about the environment that fork/exec does not preserve (kill can handle %jobid notation, etc). newgrp is odd, in that its justification for being provided as a shell builtin is not a hard requirement - it MAY, but not SHALL, replace the current shell with itself, or it may run as a subprocess. As I see it, newgrp, true, and false are the only 3 of the 17 that do not have requirements to affect the current environment and/or use knowledge of the current environment. > > But given that almost nobody uses coreutils "su", I'm not sure that > newgrp belongs in coreutils. They are related commands. It might > make more sense to decommission coreutils 'su'. > I agree with you there; the cygwin port of coreutils that I maintain is an example of a port where 'su' is useless, because cygwin cannot implement changing uid using Windows syscalls while still maintaining open file descriptors. - -- Life is short - so eat dessert first! Eric Blake [EMAIL PROTECTED] -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCHdh984KuGfSFAYARAq2hAKDS/kF7NVbKfoYjGUJmsesTRGLuVwCeP5+A lWMUaCqK4TIpTzp/mK5rHyk= =IYtD -----END PGP SIGNATURE----- _______________________________________________ Bug-coreutils mailing list [email protected] http://lists.gnu.org/mailman/listinfo/bug-coreutils
