Re: while /usr/bin/read

Sven Mascheck wrote:

> Barry Margolin wrote:
>
>> why is there a /usr/bin/read command, if it doesn't work?
>
> (Apart from other parts of this thread drifting away to yet
> another "/bin/cd is so silly")
>
> I wonder about possible reasons, too,
> 1) establish some sort of orthogonality?
> like in "find . -exec cd -exec [...]"
> 2) posix repeatedly is misunderstood for going
> along with existing practice; is there any prehistory?

The POSIX rationale says, in C.1.13 Built-In Utilities:


There were originally three justifications for allowing the omission
of exec-able versions:

1. It would require wasting space in the file system, at the expense
of very small systems. However, it has been pointed out that all
16 utilities in the table can be provided with 16 links to a
single-line shell script:

$0 "$@"

2. It is not logical to require invocation of utilities such as cd
because they have no value outside the shell environment or
cannot be useful in a child process. However, counter-examples
always seemed to be available for even the most unusual cases:

find . -type d -exec cd {} \; -exec foo {} \;
(which invokes "foo" on accessible directories)

ps ... | sed ... | xargs kill

find . -exec true \; -a ...
(where "true" is used for temporary debugging)

3. It is confusing to have a utility such as kill that can easily
be in the file system in the base standard, but that requires
built-in status for the User Portability Utilities option (for
the % job control job ID notation). It was decided that it was
more appropriate to describe the required functionality (rather
than the implementation) to the system implementors and let them
decide how to satisfy it.

On the other hand, it was realized that any distinction like this
between utilities was not useful to applications, and that the cost to
correct it was small. These arguments were ultimately the most effective.


--
Geoff Clare