fascistic commit r084e2284c700 busybox/scripts/gen_build_files.sh

Denys Vlasenko vda.linux at googlemail.com
Sun May 23 00:03:54 UTC 2010


On Thursday 20 May 2010 05:34, Peter Tyser wrote:
> <snip>
> 
> > > Maybe some other shells happen to allow read without arguments, but its
> > > a crapshoot as its not a standard.
> > 
> > Which is why you say #!/bin/bash and then teach busybox's shells to understand 
> > the name "bash".  The name is a promise of an API beyond Posix.
> 
> That's fine by me, adding optional support for bashisms to busybox's
> shells seems like a good idea.

Yup. I spent last few days improving hush's ${var%...} expansion and such.
Bolted on ${var:EXPR:EXPR} substring bashism too.

> However, how does that relate to the 
> #!/bin/bash vs #!/bin/sh debate in build scripts we're having (or
> hopefully had?)?

Yes, gen_build_files.sh is dash-clean now (I suppose, I didn't test that).

> I'd guess the vast majority of developers don't use busybox's shell
> when building busybox itself.

I do. My /bin/sh is ash.

> Thus we are still left with the original debate of scripts using
> "bash+bashisms" or "sh + nobashisms".

My personal take is that we should get rid of blatant and not-needed
bashisms like "function", `<file` (which means `cat file`),
"export v=`echo a b`" (special-cased single-word expansion
in export and local builtins), maybe ((EXPR)), let EXPR and $[EXPR].

BUT, we (meaning not just busybox people, but wider community)
also should push for adoption by standard of those bashisms
which are very useful and not hard to implement:

* local builtin (even dash admits it's too useful to drop)
* $RANDOM
* ${var:N:M}   (doing it with `cat xxx` is SLOW)
* ${var/[/]search/replace}  (doing it with `sed s/xxx/` is SLOW)
* $PIPESTATUS  (it's notoriously hard to check pipe exitcodes without this)
* maybe brace expansion
* maybe read w/o param  (IFS='' read -r REPLY is *very non-obvious* thing)
* maybe abolish "special builtins" (why are they in standard at all??)
* situation with echo's options compat is a disaster

And in order to do it, we must make these work in shells we use.

That's why I am not too happy with removal of the bashisms
from this second list from the scripts I use.
If we remove them, we ease the pressure on the standards people
and other shells' developers and make it less likely
that they will give up and include them in the next iteration
of the standard.

That's why all the fuss about "read w/o param" has erupted -
I'd prefer to keep it. But I gave up on this one for now...

> Or am I missing something?  I thought we had reached the 
> consensus that we should strive to remove bashisms from the build
> scripts.  Is this still the case?

Now build system should be dash-clean. Please test...
-- 
vda


More information about the busybox mailing list