On Mon, 11 Feb 2019, Denys Vlasenko wrote: > On Sat, Feb 9, 2019 at 5:10 PM Cristian Ionescu-Idbohrn > <[email protected]> wrote: > > > > On Sat, 9 Feb 2019, Denys Vlasenko wrote: > > > On Wed, Jan 30, 2019 at 2:09 PM Cristian Ionescu-Idbohrn > > > <[email protected]> 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 _______________________________________________ busybox mailing list [email protected] http://lists.busybox.net/mailman/listinfo/busybox
