Prev: Bash/Shell scripting practices/conventions
Next: Cron is sorting with ls differently
From: pk on 29 Mar 2008 07:50
Barry Margolin wrote:

> Which, of course, leads to the next question: why is there a
> /usr/bin/read command, if it doesn't work?

man read on my system (linux) says (slightly reformatted):

RATIONALE
The read utility historically has been a shell built-in. It was
separated off into its own utility to take advantage of the richer
description of functionality introduced by this volume of IEEE Std
1003.1-2001.

Since read affects the current shell execution environment, it is
generally provided as a shell regular built-in. If it is called in
a subshell or separate utility execution environment, such as one of
the following:

(read foo)
nohup read ...
find . -exec read ... \;

it does not affect the shell variables in the environment of the
caller.

So it would seem an external utility is not required (also according to
what's reported below).

> I believe the answer is that POSIX has a silly requirement that every
> shell built-in have a corresponding external command.

POSIX does say something, but not so strict.
If I read the standard correctly, there is a distinction between "special
built-ins" and "regular built-ins". It seems that "read" falls into the
latter category, for which the standard states that they "are not required
to be actually built into the shell on the implementation" (while special
built-ins, IIUC, are required to be truly "built-in").
On the other hand, although the standard defines them as "regular
built-ins", I've never seen a /bin/cd or a /bin/alias (which nonetheless
might exist in some implementations, although I can't imagine why an
implementation would provide such external commands).

--
All the commands are tested with bash and GNU tools, so they may use
nonstandard features. I try to mention when something is nonstandard (if
I'm aware of that), but I may miss something. Corrections are welcome.
From: Gary Johnson on 31 Mar 2008 16:04
Chris Mattern <syscjm(a)sumire.gwu.edu> wrote:
> On 2008-03-29, pk <pk(a)pk.invalid> wrote:
>> built-ins", I've never seen a /bin/cd or a /bin/alias (which nonetheless
>> might exist in some implementations, although I can't imagine why an
>> implementation would provide such external commands).
>>
> Both AIX and Solaris have /usr/bin/cd. I don't have an HP-UX system
> handy to check, but I bet they have one too.

$ uname -a
HP-UX cctrgt16 B.11.11 U 9000/800 1702987686 unlimited-user license
$ which cd
/usr/bin/cd
$ ll $(which cd)
-r-xr-xr-x 1 bin bin 146 Nov 14 2000 /usr/bin/cd

--
Gary Johnson
From: Janis Papanagnou on 29 Mar 2008 10:51
pk wrote:
> Barry Margolin wrote:
>
>
>>Which, of course, leads to the next question: why is there a
>>/usr/bin/read command, if it doesn't work?
>
>
> man read on my system (linux) says (slightly reformatted):
>
> RATIONALE
> The read utility historically has been a shell built-in. It was
> separated off into its own utility to take advantage of the richer
> description of functionality introduced by this volume of IEEE Std
> 1003.1-2001.
>
> Since read affects the current shell execution environment, it is
> generally provided as a shell regular built-in. If it is called in
> a subshell or separate utility execution environment, such as one of
> the following:
>
> (read foo)
> nohup read ...
> find . -exec read ... \;
>
> it does not affect the shell variables in the environment of the
> caller.
>
> So it would seem an external utility is not required (also according to
> what's reported below).

(Frankly, the above examples don't seem to explain much.)

>>I believe the answer is that POSIX has a silly requirement that every
>>shell built-in have a corresponding external command.
>
> POSIX does say something, but not so strict.
> If I read the standard correctly, there is a distinction between "special
> built-ins" and "regular built-ins". It seems that "read" falls into the
> latter category, for which the standard states that they "are not required
> to be actually built into the shell on the implementation" (while special
> built-ins, IIUC, are required to be truly "built-in").

It could be quite desastrous if you would be able to overwrite
special builtins like break, eval, exec, exit, export, return, etc.

> On the other hand, although the standard defines them as "regular
> built-ins", I've never seen a /bin/cd or a /bin/alias (which nonetheless
> might exist in some implementations, although I can't imagine why an
> implementation would provide such external commands).

You say that the standard defines 'alias' as a regular builtin?
That would be interesting since ksh has it in the special-builtin
list.

Janis
From: pk on 29 Mar 2008 11:16
Janis Papanagnou wrote:

> (Frankly, the above examples don't seem to explain much.)

I was replaying to Barry who said that having a corresponding external
utility for each built-in command was a POSIX requirement. The above does
not suggest that a "read" external utility is always required. In fact, if
I read the standard correctly, POSIX never requires that for any builtin.
It's true, however, that that does not explain why the OP's implementation
provides /usr/bin/read. My guess is: to avoid breaking scripts run under a
shell that does not have "read" as a built-in? It seems that would break
them anyway, only in a different way.

> It could be quite desastrous if you would be able to overwrite
> special builtins like break, eval, exec, exit, export, return, etc.

Agreed.

> You say that the standard defines 'alias' as a regular builtin?
> That would be interesting since ksh has it in the special-builtin
> list.

My interpretation is that "regular builtins" are those listed in section
2.9.1, paragraph "Command search and execution", letter c. "alias" is
listed among those. However I could be misinterpreting, of course
(corrections welcome).

--
All the commands are tested with bash and GNU tools, so they may use
nonstandard features. I try to mention when something is nonstandard (if
I'm aware of that), but I may miss something. Corrections are welcome.
From: Janis Papanagnou on 29 Mar 2008 11:18
pk wrote:
> Janis Papanagnou wrote:
>
>
>>(Frankly, the above examples don't seem to explain much.)
>
>
> I was replaying to Barry who said that having a corresponding external
> utility for each built-in command was a POSIX requirement. The above does
> not suggest that a "read" external utility is always required. In fact, if
> I read the standard correctly, POSIX never requires that for any builtin.
> It's true, however, that that does not explain why the OP's implementation

I was aiming at something different; because I can use the read
builtin in a special way where the side effects are irrelevant
(man page examples re-inserted)

(read foo)
nohup read ...
find . -exec read ... \;

would that be a sensible rationale to have an external program?
I think not.

> provides /usr/bin/read. My guess is: to avoid breaking scripts run under a
> shell that does not have "read" as a built-in? It seems that would break
> them anyway, only in a different way.
>
>
>>It could be quite desastrous if you would be able to overwrite
>>special builtins like break, eval, exec, exit, export, return, etc.
>
>
> Agreed.
>
>
>>You say that the standard defines 'alias' as a regular builtin?
>>That would be interesting since ksh has it in the special-builtin
>>list.
>
>
> My interpretation is that "regular builtins" are those listed in section
> 2.9.1, paragraph "Command search and execution", letter c. "alias" is
> listed among those. However I could be misinterpreting, of course
> (corrections welcome).
>

I haven't had a look into that document, rather I was just curious
because of the difference with the ksh document; and was wondering
whether the difference between regular builtin and special builtin
is just a somewhat "arbitrary" decision of the shell implementors.

Janis
 |  Next  |  Last
Pages: 1 2 3 4
Prev: Bash/Shell scripting practices/conventions
Next: Cron is sorting with ls differently