bug-coreutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Replacements for regular shell builtins


From: Eric Blake
Subject: Re: Replacements for regular shell builtins
Date: Thu, 24 Feb 2005 06:37:01 -0700
User-agent: Mozilla Thunderbird 1.0 (Windows/20041206)

-----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             address@hidden

-----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-----




reply via email to

[Prev in Thread] Current Thread [Next in Thread]