ash builtin function `read' called without arguments...

Cristian Ionescu-Idbohrn cristian.ionescu-idbohrn at axis.com
Sat Feb 9 16:10:26 UTC 2019


On Sat, 9 Feb 2019, Denys Vlasenko wrote:
> On Wed, Jan 30, 2019 at 2:09 PM Cristian Ionescu-Idbohrn <cristian.ionescu-idbohrn at axis.com> wrote:
> > ...sets implicit variable REPLY, even though ASH_BASH_COMPAT is not
> > set.
> >
> > That was introduced in 2010-01-12 with commit
> > 045f4ad92c07434625e168bc8c37aa0e89f6e58e.  The comment is still
> > present in the code:
> >
> > +               /* $IFS splitting. NOT done if we run "read"
> > +                * without variable names (bash compat).
> > +                * Thus, "read" and "read REPLY" are not the same.
> > +                */
> >
> > Still, this is a bashism and should be tested with IF_ASH_BASH_COMPAT.
> >
> > Dash does not support that:
> >
> > $ read
> > dash: 1: read: arg count
> >
> > and The Open Group Base Specifications Issue 6 does not document that
> > behaviour.
> >
> > Yes, I suspect the "feature" may be already abused.
> >
> > What do you think?
> 
> Correctly testing for ASH_BASH_COMPAT *and* HUSH_BASH_COMPAT
> is tricky. I can think on of disabling "bashism" behavior
> in case both options are off.
> But is it worth the trouble?

IMO, yes.  There might be other opinions.  RFC.  Let's wait.

In my case (at work), I have to watch and prevent people from doing 
unportable things.  For me, that's a burden.


Cheers,

-- 
Cristian


More information about the busybox mailing list