ash builtin function `read' called without arguments...
Cristian Ionescu-Idbohrn
cristian.ionescu-idbohrn at axis.com
Mon Feb 11 13:07:36 UTC 2019
On Mon, 11 Feb 2019, Denys Vlasenko wrote:
> On Sat, Feb 9, 2019 at 5:10 PM Cristian Ionescu-Idbohrn
> <cristian.ionescu-idbohrn at axis.com> wrote:
> >
> > 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.
>
> ash.c readcmd():
> params.argv = argptr;
>
> hush.c builtin_read(c):
> params.argv = argv;
>
> We can add a "params.argv[0] == NULL" test after these lines,
> emit error message if it is and bash compat is off.
That sounds like a good idea.
Cheers,
--
Cristian
More information about the busybox
mailing list