Problem with ash redirection changing behaviour

Denys Vlasenko vda.linux at googlemail.com
Thu Jun 3 02:29:37 UTC 2010


On Thursday 03 June 2010 00:56, Richard Purdie wrote:
> On Wed, 2010-06-02 at 17:51 +0200, Denys Vlasenko wrote:
> > On Wed, Jun 2, 2010 at 11:56 AM, Richard Purdie <rpurdie at rpsys.net> wrote:
> > > Hi,
> > >
> > > I have an issue having recently upgraded busybox.
> > 
> > To which version do you upgrade?
> 
> 1.15.3. Not the latest I know but I did look at the ash source from git
> and did not see any significant change in the code paths that would
> alter this behaviour.

But can you test it anyway? Just to ensure we don't waste our time
fixing a but which does not exist anymore?


> > This would be the bug, but I can't reproduce it. Test script:
> > 
> > 
> > 
> > echo Hi there >b.tmp
> > 
> > exec 9>&0 <b.tmp
> > while read a b
> > do
> >        echo "$a $b"
> > done
> > exec 0>&9 9>&-
> > 
> > if test "$sourced"; then
> >     echo Returning from sourced file
> >     return
> > fi
> > sourced=1
> > echo Sourcing
> > . "$0"
> > echo Sourcing done
> > 
> > ls -l /proc/$$/fd
> > 
> > 
> > 
> > Running it:
> > 
> > # ./busybox ash b
> > Hi there
> > Sourcing
> > Hi there
> > Returning from sourced file
> > Sourcing done
> > total 0
> > lrwx------ 1 root root 64 2010-06-02 17:49 0 -> /dev/pts/0
> > lrwx------ 1 root root 64 2010-06-02 17:49 1 -> /dev/pts/0
> > lr-x------ 1 root root 64 2010-06-02 17:49 10 ->
> > /root/srcdevel/bbox/fix/busybox.t7/b
> > lrwx------ 1 root root 64 2010-06-02 17:49 2 -> /dev/pts/0
> 
> Running your script as above does not show the problem for me either,
> presumably as it didn't start with stdin as fd 0 when a script is
> specified.
> 
> I can make your script show the problem by doing:
> 
> $ ./ash
> $ . b
> /ash: b: line 3: 0: Bad file descriptor
> 
> (where ./ash is a symlink to busybox)

I reproduced it.
The problem occurs here:

exec 9>&0 <FILE

because at this point fd 0 is opened to the terminal and we were
taking commands from it. Thus, we cannot dup it to fd 9:
what if next command will be "echo BOO >&9" or "read v <&9" -
that would mean we are messing with the source fd of a script!??

OTOH in the case of stdin, it does make sense...

I updated the post 1.16.1 patch:

http://busybox.net/downloads/fixes-1.16.1/busybox-1.16.1-ash.patch

please try it and let me know if it still doesn't work.
-- 
vda


More information about the busybox mailing list