Bugs in defconfig /bin/sh

Rob Landley rob at landley.net
Thu Sep 30 21:29:48 UTC 2010


On Thursday 30 September 2010 15:49:24 Denys Vlasenko wrote:
> On Thursday 30 September 2010 21:46, Rob Landley wrote:
> > On Thursday 30 September 2010 13:14:37 Denys Vlasenko wrote:
> > > On Thursday 30 September 2010 02:49, Rob Landley wrote:
> > > > Bug #1: defconfig defaults to ash, but I thought hush was the future
> > > > bash replacement, recipient of future development work, and ash was a
> > > > dead end.
> > >
> > > No (at least not yet). ash is still the default shell.
> >
> > Understood, but I thought the strategy going forward was to expand hush
> > into both a viable bash replacement and the one true busybox shell, not
> > to try to scale ash up (or down) or to make it replace the other busybox
> > shells.
> >
> > Changing the default to "the one with a future" seems like a reasonable
> > first step.
>
> Only when hush has no significant missing features compared to ash.
> In 1.17.x, for example, it still has no history saving.
>
> > (Making {file,file} curly bracket support work would be darn nice too,
> > that's the biggest thing I miss.  You can't even follow the Linux From
> > Scratch build instructions without that...)
>
> This is not easy. Consider three commands:
>
> v='/bin/*'; echo $v
> v='/bin/{a,b}*'; echo $v
> echo /bin/{a,b}*
>
> In the first case, unquoted $v is globbed *after* $v value is substituted,
> and echo prints long list of filenames in /bin.
>
> In the second case, echo prints just "/bin/{a,b}*"
>
> In the third case, echo prints all filenames in /bin which start from a and
> b.

That's messed up, and it really sounds like the second case is a bug.

I just fired up an Aboriginal system image with bash 2.05b (the much less 
bloated version), and under that the third case _also_ prints "/bin/{a,b}*", 
so the behavior of this corner case changed between bash versions.  Most 
likely somebody reported the third case as a bug and they fixed the one defect 
report without fixing the general case, because they're the FSF and everything 
is a special case to them.

The _important_ test is just:

  v='/bin/*'; echo $v

Which answers the simple question of glob precedence: does it happen before or 
after the variable substitution?  And if the answer is "after" (which it is), 
then that's what we should do.  Perform globbing after substituting variables.  
{a,b} is part of globbing the same way * and ? and [x-y] and such are.

The fact that bash is a buggy pile of crap that can't even consistently 
implement its own extensions is not our problem.  We should do the simple 
thing and wait for the FSF to catch up.  (Specifically, wait for somebody 
replying on this _obvious_bug_ to complain, and then tell them to complain to 
the bash guys and make sure they don't _fix_ their inconsistency first.)

> This means that unquoted $v expansion should protect (prefix with
> backslash) brace expansion chars before they are fed into brace expansion
> machinery (otherwise case 2 will break), BUT should not prefix glob chars.

No it doesn't, it means bash is a buggy pile of crap and we have the 
opportunity to behave more consistently than they do.

> In other words, we cannot simply extend glob chars to include expansion
> chars and make corresponding changes to globbing logic.

Yes we can.

> these two steps
> (globbing and brace expansion) have inherently different rules.

But shouldn't.

Rob
-- 
GPLv3: as worthy a successor as The Phantom Menace, as timely as Duke Nukem 
Forever, and as welcome as New Coke.


More information about the busybox mailing list