Bug#854

[David Korn]

Bug #854: requirement for additional built-in utilities to be searched

for via $PATH was

not and is not existing practice OPEN
http://austingroupbugs.net/view.php?id=854
Action: Andrew to ask David Korn to comment on this bug and the previous

email

discussion of the issue (seq 21270).
Action repeated - a followup was sent to David.

I don't remember getting e-mail about this so maybe you sent it to my
research.att.com
address which I no longer have now that I am at Google, not AT&T.

Anyway, I learned early on that you create compatibility problems when you
make a standard utility built-in since there built-ins are run before doing
a PATH search. For example if grep is a builtin, but I want to use a much
faster version of grep that is in say /usr/fast/bin/grep, I can't do
PATH=/usr/fast/bin:$PATH to run the script and get the fast version of grep.

However, I like the idea of having built-in versions of standard utilities
so what I did in ksh is to allow a builtin to be associate with a path so
that I can have a built-in /bin/grep that will be invoked whenever a path
search would have found /bin/grep on PATH. This way, I have control
whether the built-in version is used or not and yet can have builtin
versions of utilities.

Doing it this way preserves compatibility.

[Bill Bogstad]

Post by David Korn

Bug #854: requirement for additional built-in utilities to be searched for
via $PATH was
not and is not existing practice OPEN
http://austingroupbugs.net/view.php?id=854
Action: Andrew to ask David Korn to comment on this bug and the previous
email
discussion of the issue (seq 21270).
Action repeated - a followup was sent to David.

I don't remember getting e-mail about this so maybe you sent it to my
research.att.com
address which I no longer have now that I am at Google, not AT&T.
Anyway, I learned early on that you create compatibility problems when you
make a standard utility built-in since there built-ins are run before doing
a PATH search. For example if grep is a builtin, but I want to use a much
faster version of grep that is in say /usr/fast/bin/grep, I can't do
PATH=/usr/fast/bin:$PATH to run the script and get the fast version of grep.
However, I like the idea of having built-in versions of standard utilities
so what I did in ksh is to allow a builtin to be associate with a path so
that I can have a built-in /bin/grep that will be invoked whenever a path
search would have found /bin/grep on PATH. This way, I have control whether
the built-in version is used or not and yet can have builtin versions of
utilities.

I like the idea, but I'm a little confused about the details. Are you saying:

If there is no "grep" in any directory specified in $PATH that the
built-in will be used. Otherwise, the first grep entry found by using
$PATH will be used.

You seem to be implying that there is something special about
/bin/grep and built-in commands. If there is a built-in grep AND
there also happens to be a executable called grep in the /bin
directory AND /bin is in the $PATH variable what happens?

Bill Bogstad

Post by David Korn
Doing it this way preserves compatibility.

[David Korn]

Yes, I am implying this.

The original Bourne shell did not have echo, test, and [] as built-ins.

When I created ksh in the early 1980's I made these built-ins. While this
made sense for performance reasons, it created compatibility problems. The
echo command on BSD was different then the echo command on System V.

Before I built in echo, the user could select the behavior they wanted by
setting their PATH. I think that the ability to do this selection by PATH
is important which is why I allow adding builtins to ksh93 with
builtin /bin/grep
to make /bin/grep run as a builtin (assuming that grep code is built-in or
loaded from a shared library).

Post by David Korn

Bug #854: requirement for additional built-in utilities to be searched

for

Post by David Korn

via $PATH was
not and is not existing practice OPEN
http://austingroupbugs.net/view.php?id=854
Action: Andrew to ask David Korn to comment on this bug and the previous
email
discussion of the issue (seq 21270).
Action repeated - a followup was sent to David.

I don't remember getting e-mail about this so maybe you sent it to my
research.att.com
address which I no longer have now that I am at Google, not AT&T.
Anyway, I learned early on that you create compatibility problems when

you

Post by David Korn
make a standard utility built-in since there built-ins are run before

doing

Post by David Korn
a PATH search. For example if grep is a builtin, but I want to use a

much

Post by David Korn
faster version of grep that is in say /usr/fast/bin/grep, I can't do
PATH=/usr/fast/bin:$PATH to run the script and get the fast version of

grep.

Post by David Korn
However, I like the idea of having built-in versions of standard

utilities

Post by David Korn
so what I did in ksh is to allow a builtin to be associate with a path so
that I can have a built-in /bin/grep that will be invoked whenever a path
search would have found /bin/grep on PATH. This way, I have control

whether

Post by David Korn
the built-in version is used or not and yet can have builtin versions of
utilities.

If there is no "grep" in any directory specified in $PATH that the
built-in will be used. Otherwise, the first grep entry found by using
$PATH will be used.
You seem to be implying that there is something special about
/bin/grep and built-in commands. If there is a built-in grep AND
there also happens to be a executable called grep in the /bin
directory AND /bin is in the $PATH variable what happens?
Bill Bogstad

Post by David Korn
Doing it this way preserves compatibility.

[David Korn]

What I was saying is that when you do a PATH search and at the point you
find the executable file /usr/bin/grep, you can run the built-in.

Post by David Korn
Yes, I am implying this.
The original Bourne shell did not have echo, test, and [] as built-ins.
When I created ksh in the early 1980's I made these built-ins. While this
made sense for performance reasons, it created compatibility problems. The
echo command on BSD was different then the echo command on System V.
Before I built in echo, the user could select the behavior they wanted by
setting their PATH. I think that the ability to do this selection by PATH
is important which is why I allow adding builtins to ksh93 with
builtin /bin/grep
to make /bin/grep run as a builtin (assuming that grep code is built-in or
loaded from a shared library).

Post by David Korn

Bug #854: requirement for additional built-in utilities to be searched

for

Post by David Korn

via $PATH was
not and is not existing practice OPEN
http://austingroupbugs.net/view.php?id=854
Action: Andrew to ask David Korn to comment on this bug and the

previous

Post by David Korn

email
discussion of the issue (seq 21270).
Action repeated - a followup was sent to David.

I don't remember getting e-mail about this so maybe you sent it to my
research.att.com
address which I no longer have now that I am at Google, not AT&T.
Anyway, I learned early on that you create compatibility problems when

you

Post by David Korn
make a standard utility built-in since there built-ins are run before

doing

Post by David Korn
a PATH search. For example if grep is a builtin, but I want to use a

much

Post by David Korn
faster version of grep that is in say /usr/fast/bin/grep, I can't do
PATH=/usr/fast/bin:$PATH to run the script and get the fast version of

grep.

Post by David Korn
However, I like the idea of having built-in versions of standard

utilities

Post by David Korn
so what I did in ksh is to allow a builtin to be associate with a path

so

Post by David Korn
that I can have a built-in /bin/grep that will be invoked whenever a

path

Post by David Korn
search would have found /bin/grep on PATH. This way, I have control

whether

Post by David Korn
the built-in version is used or not and yet can have builtin versions of
utilities.

If there is no "grep" in any directory specified in $PATH that the
built-in will be used. Otherwise, the first grep entry found by using
$PATH will be used.
You seem to be implying that there is something special about
/bin/grep and built-in commands. If there is a built-in grep AND
there also happens to be a executable called grep in the /bin
directory AND /bin is in the $PATH variable what happens?
Bill Bogstad

Post by David Korn
Doing it this way preserves compatibility.