Subject: Re: /bin/sh `name=value command' anomaly
To: None <netbsd-users@NetBSD.ORG>
From: Jim Wight <J.K.Wight@newcastle.ac.uk>
List: netbsd-users
Date: 03/27/1995 14:33:16
I wrote:

> When I run a /bin/sh command of the form `name=value command' under i386
> NetBSD 1.0 it fails with the message 'Out of file descriptors'. It
> only works as expected if a semicolon is placed after the name=value
> part. This is not a requirement of any other /bin/sh that I am familar
> with, and shouldn't be necessary according to my interpretation of
> this extract from the man page:

The feedback I received indicated that my experience was not typical.
So I've delved further to try to pin down the circumstances under
which it happens. It turns out that it only occurs when the command is
"exec". The case that brought the problem to my attention involves a
script and an executable of the same name, the first calculating the
location of the second and exec'ing it via an amended search path.
Here is a stripped down version of the scenario.

The following script takes the place of the script above; assume it is
in the home directory:

    #!/bin/sh
    
    echo /home/script
    
    PATH=/tmp:$PATH exec script

The next script plays the role of the executable; assume it is in /tmp:

    #!/bin/sh
    
    echo /tmp/script

Assume that $HOME is in the shell search path.

When I run under SunOS 4.1.x I get this behaviour

$ echo $HOME
/home/blagdon/njkw
$ which script
/home/blagdon/njkw/script
$ script
/home/script
/tmp/script
$ 

In other words the PATH=/tmp:$PATH path in the first script is used to
locate the second script - in /tmp. This is the behaviour on all
systems where I've installed my software. However, under NetBSD the
temporary PATH appears not not to be used in locating the executable
(second script), with the result that the initial script keeps on
re-finding itself, and the system eventually runs out of file
descriptors.

A bug?

Jim

PS I didn't have the presence of mind to try simplified scripts like
   the ones presented here when I was doing my investigations under
   NetBSD at the weekend, so I don't actually have first hand experience
   of them failing in the way I describe. However, I believe that they
   do faithfully mirror the real case, which does fail that way.