[Top][All Lists]

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

Re: avoid mkdir/selinux failure when mknod is a shell built-in

From: Ralf Wildenhues
Subject: Re: avoid mkdir/selinux failure when mknod is a shell built-in
Date: Wed, 16 Apr 2008 18:24:00 +0200
User-agent: Mutt/1.5.17 (2008-03-09)

Hi Eric,

* Eric Blake wrote on Wed, Apr 16, 2008 at 03:07:42PM CEST:
> According to Jim Meyering on 4/16/2008 6:57 AM:
> |   $ PATH=. /bin/sh -c 'exec mknod --version'|head -1
> |   /bin/sh: mknod: --: unknown option
> Ouch - this looks like a POSIX compliance bug in exec; I'm adding
> bug-autoconf to the distribution in case we want to document this corner
> case bug in the shell portability section.  POSIX states that exec is
> supposed to bypass shell builtins (and while special shell builtins, like
> 'exit', give undefined behavior when passed to exec, regular shell
> builtins, like 'fg', are required to exist in PATH even if they can't
> quite do as much work as their builtin counterpart).

Can you please point me to where POSIX specifies these things?  I cannot
find in the page describing exec, that it has to bypass built-ins.
Also, I cannot find at all that regular shell builtins have to exist as
independent programs in $PATH.  The only thing I found wrt. special
built-ins was

   The special built-in utilities in this section need not be provided
   in a manner accessible via the exec family of functions defined in
   the System Interfaces volume of IEEE Std 1003.1-2001.

which isn't a requirement on the implementation.
I'm looking at SUSv3, by the way.

* Eric Blake wrote on Wed, Apr 16, 2008 at 06:14:35PM CEST:
> Any comments before I check it in?

> address@hidden @command{exec}
> +Posix divides the set of shell built-ins into two groups.  Special
> +built-ins (such as @command{exit}) must impact the environment of the
> +current shell, and need not be available through @command{exec}.
> +Regular built-ins (such as @command{echo} or @command{cd}) must not
> +propogate variable assignments to the environment of the current shell,


> +On the other hand, @command{pdksh} 5.2.14 refuses to execute the
> +executable replacement, using the built-in no matter what:

OpenBSD's /bin/sh is heavily modified from pdksh.  While it seems that
both share this bug, in general one should not be quick to assume both
share all features.

> +This has the interest effect that @command{pdksh} can use @command{exec}


> +on special built-ins, even though Posix doesn't require it:


reply via email to

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