Re: [PATCH] gen_build_files.sh: Remove bashisms
On Monday 17 May 2010 12:07:27 Cristian Ionescu-Idbohrn wrote:
Oh boy... But then you'll also have to imitate those many intentional
obscure bashisms in hush, will you not?
Yes.
This was always the plan. Adding support for things people actually _use_ to
busybox is what busybox does.
The busybox shell situation has sucked for years because there were several
divergent implementations and our most feature-rich one A) didn't scale down,
B) was a huge pile of messy code tacked on from an external source and never
fully understood by this development community.
Denys has spent several years cleaning up the result. He did so by removing
some of the less-used shells and picking one (hush) that was a reasonable base
to extend. Hush should someday replace ash in busybox as our full-featured
shell, and it should also be able to replace bash.
(Keep in mind dash doesn't even support thing/{one,two} syntax.
I know. But that would easily be made portable with a for loop, wouldn't
it?
You could rewrite it in cobol if you wanted to. That's irrelevant.
it's not hard to make the scripts smaller and simpler by filling them
with things dash can't cope with.)
True.
I'm warning you to drop this topic.
Threat. It was not my intention to get you irritated to that degree, but
now that I managed, I think I'll go on for a while longer :)
Feel free, but Denys asked me to keep the flames down to a dull roar, so I'm
going to stop reading here and add you to my spam filter.
Rob
--
Latency is more important than throughput. It's that simple. - Linus Torvalds
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH] gen_build_files.sh: Remove bashisms
On Monday 17 May 2010 06:23:30 Natanael Copa wrote: On Fri, May 14, 2010 at 10:41 PM, Rob Landley r...@landley.net wrote: On Thursday 13 May 2010 18:05:53 Peter Tyser wrote: Using 'read' without a variable is not supported in many shells. Lines such as 'while read; do' in gen_build_files.sh would result in build failures when using sh or dash as an interpreter: Simple fix: say #!/bin/bash at the top of all shell scripts, always. Please no. Please let it be possible to build busybox with the busybox tools. A) Teach busybox to understand that the name bash can redirect to hush. B) Teach hush to support the extended API. Busybox ash handles most shell scripts just fine. Ash is a mess that doesn't .config down to small sizes well. Hush scales and Denys has a good understanding of its implementation, so that's the one he's chosen to extend to become the full-fledged busybox bash replacement. (That's what he said at CELF, anyway.0 Please don't force us to install the slow bloaty bash to bootstrap a busybox system. Please. I agree this is an important design goal. The way to fix it is to extend hush. (Alas, I haven't got time to work on it this week. I'm trying to get a 1.0 release out of my build project, and working an unrelated day job. However, I hope to be able to help out here eventually.) Rob -- Latency is more important than throughput. It's that simple. - Linus Torvalds ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH] gen_build_files.sh: Remove bashisms
On Tuesday 18 May 2010 17:54:44 Denys Vlasenko wrote: Hey Rob, please do abstain from biting our contributors. :) Ok. Sorry. Rob -- Latency is more important than throughput. It's that simple. - Linus Torvalds ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH] gen_build_files.sh: Remove bashisms
On Mon, 17 May 2010, Paul Smith wrote: IMO if you want bash, get bash (and put #!/bin/bash at the top of your scripts). If you put #!/bin/sh at the top of your scripts, restrict yourself to POSIX shell features. On Mon, 2010-05-17 at 23:54 +0200, Cristian Ionescu-Idbohrn wrote: -local tempname=/tmp/temp.$$.$RANDOM +local tempname=/tmp/temp.$$ This isn't valid: there's no local keyword in POSIX shell. True. But all modern shells support it (with some diffrences in implementation). It helps decluttering the name space, saves a lot of 'unset' commands (which can't be used if you must 'return $variable' the caller), and makes it easier to avoid unintentionaly overwriting global variable values. I don't insist on using it. I guess it's one of those things that need to be discussed. wrong. It eats leading and trailing whitespace. I cannot find anything in the opengroup page you earlier referred to: http://www.opengroup.org/onlinepubs/009695399/utilities/read.html saying explicitely whitespace must me preserved. Yes, that's what Denys is saying. The rewrite is NOT equivalent to the bash version, because the bash version preserves leading/trailing whitespace, and the rewrite does not. And that's what I'm also saying :) Let me rephrase. Expecting 'read' to preserve leading and trailing whitespace is not POSIX. It's a bashism. Don't do that. Which makes the rewrite correct, IMO. Cheers, -- Cristian ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH] gen_build_files.sh: Remove bashisms
On Mon, May 17, 2010 at 9:12 PM, Cathey, Jim jcat...@ciena.com wrote: We have embedded systems that don't have room for bash. I don't think bash provides that much useful stuff in its extensions that warrant locking ourselves to it. But then, the whole trend away from portable coding doesn't sit well with me... If this would be only a portability argument... I have a feeling dash people might be using portability argument as a convenient excuse. What happened in reality, is that they try to acquire a place in the community which does not belong to them. We all know quite a few people who abuse their position in the community. glibc people. gcc people. I don't like their current attitudes towards their users, but *at least* they do (or did) something to earn that position in the first place. Ulrich Drepper _did_ code up a big part of glibc. You may not like glibc, but you cannot disregard the fact that glibc was used by Linux userspace for years and years, and it was doing its job (and continue to do it). dash, on the contrary, did not do even that. It wasn't a default Linux shell. It was not even a typically installed optional package. Now, suddenly, it becomes a default shell. It is *forced on us*. Why? It is based on a Kenneth Almquist's shell, but now it is maintained by other people. In other words, those people didn't even write it, they just patch it up. Comparing to glibc project: they did not maintain a project for a decade benefiting a large community, they did not even maintain it for a decade as a small project with limited user base - someone else did! And now, lo and behold, we _MUST_ bow down and accept it as our default shell? On what grounds?! How do we know that maintainers are sane and technically savvy? I do respect other people's ideas. However, I do not like one iota when other people's ideas are *forced on me*, instead of being *negotiated with me*. If they want me to, for example, write shell scripts in a more portable way, they need to talk to me and explain why is this good. Instead, they seem to think that by installing dash as /bin/sh, they will just force everyone to write portable scripts, *using dash maintainers' definition of what portable means*. For example, they decided to implement local builtin, but not, say, $RANDOM variable. Standards are not holy scriptures given by God, you know. *People* created them. People can change them, too. Instead of uglifying our scripts, maybe we should amend the standard and add $RANDOM variable? It shouldn't be that hard, especially since standard already defines a few other magic variables. And a way to get something into standard is to add support for it into actually deployed shells, making it a de-facto accepted feature. Conversely, diking out a widely used and simple feature because it is non-standard and then demanding everyone to work around resulting widespread breakage smells like a quasi-religious crusade to me. And finally. I ran busybox ash testsuite under dash. Filtered out bash compat failures and ended up with 11 failures on *standard-compatible* test scripts out of 41 test scripts total. ~25% failure rate. These people talk about standard compatibility?! Give me a break... -- vda ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH] gen_build_files.sh: Remove bashisms
On Tue, May 18, 2010 at 1:03 PM, Cristian Ionescu-Idbohrn cristian.ionescu-idbo...@axis.com wrote: wrong. It eats leading and trailing whitespace. I cannot find anything in the opengroup page you earlier referred to: http://www.opengroup.org/onlinepubs/009695399/utilities/read.html saying explicitely whitespace must me preserved. Yes, that's what Denys is saying. The rewrite is NOT equivalent to the bash version, because the bash version preserves leading/trailing whitespace, and the rewrite does not. And that's what I'm also saying :) Let me rephrase. Expecting 'read' to preserve leading and trailing whitespace is not POSIX. It's a bashism. Don't do that. Which makes the rewrite correct, IMO. Gosh. Rewrite should preserve the *functionality*, that is, it should *read entire line without mangling it* (ok, sans NUL bytes...) The proposed patch didn't do it, therefore *it is incorrect*. If standard shell can't do it, it does not mean I must sacrifice functionality. It means that standard shell sucks. If standard shell can do it, but requires extensive ugly hacks to achieve it, it means that standard shell sucks (just not as much as in the case it can't do it at all). For the record: standard shell can do it, with somewhat ugly hack. I bet a lot of people will not come up with this hack though... they will likely try to save/restore IFS around read, which is butt-ugly: while sv=$IFS; IFS=''; read -r line; IFS=$sv; do... Gaack... -- vda ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH] gen_build_files.sh: Remove bashisms
On Monday 17 May 2010 02:23, Rob Landley wrote:
On Saturday 15 May 2010 17:27:40 Cristian Ionescu-Idbohrn wrote:
I had a look through and found:
,[ individual ]
| possible bashism in individual line 15 (brace expansion):
He changed the start to #!/bin/bash and you're still looking for bashisms.
If you keep on with this, I'm going to go through and try to optimize every
shells cript in the project with as many intentional obscure bashisms as
possible. (Keep in mind dash doesn't even support thing/{one,two} syntax.
it's not hard to make the scripts smaller and simpler by filling them with
things dash can't cope with.)
OMG :D
I'm warning you to drop this topic. I don't have a stubborn streak, I have a
vindictive streak. It has a very high activation threshold, and most things
I
don't care enough to do anyhing about. But once the straw breaks the camel's
back you go in the Bruce Fucking Perens category and I remain 100% opposed to
your very existence years later.
Hey Rob, please do abstain from biting our contributors. :)
--
vda
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH] gen_build_files.sh: Remove bashisms
On Sun, 16 May 2010, Rob Landley wrote: On Saturday 15 May 2010 13:30:51 Cristian Ionescu-Idbohrn wrote: Yes. A performant shell it's crucial in the embedded world, as an important part of cross-building and also running the target system. On the target use a busybox shell. Or 'dash'. That's a separate issue from your build environment. Yes and no. The build system I use makes extensive use of the shell to generate Makefiles and make the source code available to 'make'. Makefiles use shell script snippets too. The performance boost of a fast shell _is_ important. Cheers, -- Cristian ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH] gen_build_files.sh: Remove bashisms
On Fri, May 14, 2010 at 10:41 PM, Rob Landley r...@landley.net wrote: On Thursday 13 May 2010 18:05:53 Peter Tyser wrote: Using 'read' without a variable is not supported in many shells. Lines such as 'while read; do' in gen_build_files.sh would result in build failures when using sh or dash as an interpreter: Simple fix: say #!/bin/bash at the top of all shell scripts, always. Please no. Please let it be possible to build busybox with the busybox tools. Busybox ash handles most shell scripts just fine. Please don't force us to install the slow bloaty bash to bootstrap a busybox system. Please. -- Natanael Copa ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH] gen_build_files.sh: Remove bashisms
On Sat, May 15, 2010 at 9:10 PM, Denys Vlasenko vda.li...@googlemail.com wrote: On Friday 14 May 2010 01:05, Peter Tyser wrote: -find -type d | while read; do - d=$REPLY - +find -type d | while read d; do I applied this part, and changed #!/bin/sh to bash. Please keep the #!/bin/sh and keep the scripts posix compliant. Busybox ash is more than good enough to build busybox. Please don't force us install the bloaty bash. Please! -- Natanael Copa ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH] gen_build_files.sh: Remove bashisms
On Mon, 2010-05-17 at 13:23 +0200, Natanael Copa wrote: On Fri, May 14, 2010 at 10:41 PM, Rob Landley r...@landley.net wrote: On Thursday 13 May 2010 18:05:53 Peter Tyser wrote: Using 'read' without a variable is not supported in many shells. Lines such as 'while read; do' in gen_build_files.sh would result in build failures when using sh or dash as an interpreter: Simple fix: say #!/bin/bash at the top of all shell scripts, always. Please no. Please let it be possible to build busybox with the busybox tools. It's (obviously) not possible now if bash isn't installed. So the above makes it at least work for Debian-esque people with a bash installed. Busybox ash handles most shell scripts just fine. Please don't force us to install the slow bloaty bash to bootstrap a busybox system. Please. Care to provide patches solving problems?! Bernd -- Bernd Petrovitsch Email : be...@petrovitsch.priv.at LUGA : http://www.luga.at ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH] gen_build_files.sh: Remove bashisms
On Fri, May 14, 2010 at 01:52:24PM -0700, Cristian Ionescu-Idbohrn wrote: On Fri, 14 May 2010, Rob Landley wrote: On Thursday 13 May 2010 18:05:53 Peter Tyser wrote: Using 'read' without a variable is not supported in many shells. Lines such as 'while read; do' in gen_build_files.sh would result in build failures when using sh or dash as an interpreter: Simple fix: say #!/bin/bash at the top of all shell scripts, always. Not surprisingly, I disagree :) dash is 5+ times faster than bash. If I'm *that* concerned about performance, *sh is not the answer... -- David N. Lombard, Intel, Irvine, CA I do not speak for Intel Corporation; all comments are strictly my own. ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH] gen_build_files.sh: Remove bashisms
On Sun, 16 May 2010, Rob Landley wrote:
On Saturday 15 May 2010 17:27:40 Cristian Ionescu-Idbohrn wrote:
Thank you.
I had a look through and found:
,[ individual ]
| possible bashism in individual line 15 (brace expansion):
He changed the start to #!/bin/bash and you're still looking for bashisms.
Yes, I do.
If you keep on with this, I'm going to go through and try to optimize
every shells cript in the project with as many intentional obscure
bashisms as possible.
Oh boy... But then you'll also have to imitate those many intentional
obscure bashisms in hush, will you not?
(Keep in mind dash doesn't even support thing/{one,two} syntax.
I know. But that would easily be made portable with a for loop, wouldn't
it?
it's not hard to make the scripts smaller and simpler by filling them
with things dash can't cope with.)
True.
I'm warning you to drop this topic.
Threat. It was not my intention to get you irritated to that degree, but
now that I managed, I think I'll go on for a while longer :)
I don't have a stubborn streak, I have a vindictive streak. It has a
very high activation threshold, and most things I don't care enough to
do anyhing about. But once the straw breaks the camel's back
English is not my mother tongue, but what you say sounds good :)
you go in the Bruce Fucking Perens category
You don't seem to like that man. I don't know him, never met, but I bet
Bruce won't be happy to find out about his new middle name, so I won't
Cc:.
I guess I'll have to be more careful here. I might get an additional
middle name(s) and be unhappy for the rest of life :)
and I remain 100% opposed to your very existence years later.
Sad thing :(
But, we could still have fun discussing how we go about making the scripts
as portable as possible and avoid breaking peoples builds, I presume.
And this is, IMO, the main point to this flamy exchange of ideas.
Take care Rob. And try to focus on the matter at hand, which should not
be which shell is best, but how to make the scripts portable.
Cheers,
--
Cristian
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH] gen_build_files.sh: Remove bashisms
But, we could still have fun discussing how we go about making the scripts as portable as possible and avoid breaking peoples builds, I presume. And this is, IMO, the main point to this flamy exchange of ideas. Take care Rob. And try to focus on the matter at hand, which should not be which shell is best, but how to make the scripts portable. I 100% agree. Participating in this discussion is like wrestling a greased pig:) I also echo your opinions about keeping the scripts portable. Best, Peter ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH] gen_build_files.sh: Remove bashisms
On Mon, May 17, 2010 at 7:28 PM, Peter Tyser pty...@xes-inc.com wrote: But, we could still have fun discussing how we go about making the scripts as portable as possible and avoid breaking peoples builds, I presume. And this is, IMO, the main point to this flamy exchange of ideas. Take care Rob. And try to focus on the matter at hand, which should not be which shell is best, but how to make the scripts portable. I 100% agree. Participating in this discussion is like wrestling a greased pig:) Because it's political discussion now. :) I also echo your opinions about keeping the scripts portable. I can sympathise with this point of view. However, I can see another point of view: Why, after years and years of happily using bash, everybody should be tortured now by being forced to work in a shell which: * does not have a single source release linked to its homepage (http://gondor.apana.org.au/~herbert/dash/) * does not support many (any?) bash extensions, even simple ones * does not have a testsuite Why? Who are those people and why I am forced to use their shell now? Why am I a hostage now to their whim on when, and *whether*, they will agree to fix bug foo or implement feature baz? bash didn't have bug foo and had feature baz, and I was happy. Now I'm not. -- vda ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH] gen_build_files.sh: Remove bashisms
I also echo your opinions about keeping the scripts portable. I can sympathise with this point of view. However, I can see another point of view: Why, after years and years of happily using bash, everybody should be tortured now by being forced to work in a shell which: * does not have a single source release linked to its homepage (http://gondor.apana.org.au/~herbert/dash/) * does not support many (any?) bash extensions, even simple ones * does not have a testsuite Why? Who are those people and why I am forced to use their shell now? Why am I a hostage now to their whim on when, and *whether*, they will agree to fix bug foo or implement feature baz? bash didn't have bug foo and had feature baz, and I was happy. Now I'm not. I definitely see your points. But I don't think this discussion should be centered on dash. To me its a debate about using portable POSIX compliant shell scripting vs using bash-specific shell scripting. If we use POSIX compliant code, dash, as well as most other shells should work without issue. If we use bash-specific shell scripting bash will work, and others *may* work. The 2 acceptable solutions to me would be (in order of preference): 1. Use POSIX compliant shell scripting, and using /bin/sh as the interpreter. 2. Use bash shell scripting, and use /bin/bash as the interpreter. Right now, we're using bash scripting, but using /bin/sh as the interpreter. This is what I think is broke. If we use /bin/sh as the interpreter, we shouldn't be using bashisms. If we use /bin/bash as the interpreter, than we're free to use bashisms as we please. So in any case, in my mind it comes down to using option #1 or #2 above - and I do see both sides of that argument. Either #1 or #2 would be an improvement in my opinion. Best, Peter ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
RE: [PATCH] gen_build_files.sh: Remove bashisms
We have embedded systems that don't have room for bash. I don't think bash provides that much useful stuff in its extensions that warrant locking ourselves to it. But then, the whole trend away from portable coding doesn't sit well with me... Portable !== Linux-du-jour! -- Jim -Original Message- From: busybox-boun...@busybox.net [mailto:busybox-boun...@busybox.net] On Behalf Of Peter Tyser Sent: Monday, May 17, 2010 12:03 PM To: Denys Vlasenko Cc: busybox@busybox.net Subject: Re: [PATCH] gen_build_files.sh: Remove bashisms I also echo your opinions about keeping the scripts portable. I can sympathise with this point of view. However, I can see another point of view: Why, after years and years of happily using bash, everybody should be tortured now by being forced to work in a shell which: * does not have a single source release linked to its homepage (http://gondor.apana.org.au/~herbert/dash/) * does not support many (any?) bash extensions, even simple ones * does not have a testsuite Why? Who are those people and why I am forced to use their shell now? Why am I a hostage now to their whim on when, and *whether*, they will agree to fix bug foo or implement feature baz? bash didn't have bug foo and had feature baz, and I was happy. Now I'm not. I definitely see your points. But I don't think this discussion should be centered on dash. To me its a debate about using portable POSIX compliant shell scripting vs using bash-specific shell scripting. If we use POSIX compliant code, dash, as well as most other shells should work without issue. If we use bash-specific shell scripting bash will work, and others *may* work. The 2 acceptable solutions to me would be (in order of preference): 1. Use POSIX compliant shell scripting, and using /bin/sh as the interpreter. 2. Use bash shell scripting, and use /bin/bash as the interpreter. Right now, we're using bash scripting, but using /bin/sh as the interpreter. This is what I think is broke. If we use /bin/sh as the interpreter, we shouldn't be using bashisms. If we use /bin/bash as the interpreter, than we're free to use bashisms as we please. So in any case, in my mind it comes down to using option #1 or #2 above - and I do see both sides of that argument. Either #1 or #2 would be an improvement in my opinion. Best, Peter ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH] gen_build_files.sh: Remove bashisms
Patches welcome? Here's mine. License: Public domain. --- gen_build_files.sh 2010-05-17 22:00:34.912406823 +0200 +++ gen_build_files_fixed.sh2010-05-17 22:03:33.893406743 +0200 @@ -1,5 +1,6 @@ #!/bin/sh -# bashism: +# bashism removed: +# lines 22 and 48 had # read -r without variable name reads line into $REPLY # without stripping whitespace. @@ -18,9 +19,9 @@ s=`sed -n 's...@^//kbuild:@@p' -- $srctree/$d/*.c` echo # DO NOT EDIT. This file is generated from Kbuild.src $dst.$$.tmp - while read -r; do - test x$REPLY = xINSERT REPLY=$s - printf %s\n $REPLY + while read -r reply; do + test x$reply = xINSERT reply=$s + printf %s\n $reply done $src $dst.$$.tmp if test -f $dst cmp -s $dst.$$.tmp $dst; then @@ -38,9 +39,9 @@ s=`sed -n 's...@^//config:@@p' -- $srctree/$d/*.c` echo # DO NOT EDIT. This file is generated from Config.src $dst.$$.tmp - while read -r; do - test x$REPLY = xINSERT REPLY=$s - printf %s\n $REPLY + while read -r reply; do + test x$reply = xINSERT reply=$s + printf %s\n $reply done $src $dst.$$.tmp if test -f $dst cmp -s $dst.$$.tmp $dst; then (also attached) It's easy, isn't it? ;) teh_patch_for_gen_build_files Description: Binary data ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH] gen_build_files.sh: Remove bashisms
On Monday 17 May 2010 22:10, Douglas Mencken wrote: Patches welcome? Here's mine. License: Public domain. - while read -r; do - test x$REPLY = xINSERT REPLY=$s - printf %s\n $REPLY + while read -r reply; do + test x$reply = xINSERT reply=$s + printf %s\n $reply done $src $dst.$$.tmp if test -f $dst cmp -s $dst.$$.tmp $dst; then (also attached) It's easy, isn't it? ;) Easy and wrong. It eats leading and trailing whitespace. -- vda ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH] gen_build_files.sh: Remove bashisms
On Sun, 16 May 2010, Cristian Ionescu-Idbohrn wrote:
On Sat, 15 May 2010, Denys Vlasenko wrote:
On Friday 14 May 2010 01:05, Peter Tyser wrote:
-find -type d | while read; do
- d=$REPLY
-
+find -type d | while read d; do
I applied this part, and changed #!/bin/sh to bash.
Thanks!
Thank you.
I had a look through and found:
under subdirectory scripts/, running 'file' on any of these scripts:
,[ individual ]
,[ mkdiff_obj ]
,[ randomtest.loop ]
,[ trylink ]
shows:
POSIX shell script text executable
But that's only what the shebang line indicates.
They are 'Bourne-Again shell script text executable'.
The effort to make them portable is trivial. Take 'trylink' for example.
This patch:
diff --git a/scripts/trylink b/scripts/trylink
index 8c88546..c6f307c 100755
--- a/scripts/trylink
+++ b/scripts/trylink
@@ -46,7 +46,11 @@ try() {
}
check_cc() {
-local tempname=/tmp/temp.$$.$RANDOM
+local tempname=/tmp/temp.$$
+
+tempname=$(mktemp $tempname.XX /dev/null) ||
+ tempname=$tempname.$(date +%s.%N) /dev/null
+
# Can use -o /dev/null, but older gcc tend to *unlink it* on failure! :(
# -xc: C language. /dev/null is an empty source file.
if $CC $1 -shared -xc /dev/null -o $tempname.o /dev/null 21; then
@@ -58,7 +62,11 @@ check_cc() {
}
check_libc_is_glibc() {
-local tempname=/tmp/temp.$$.$RANDOM
+local tempname=/tmp/temp.$$
+
+tempname=$(mktemp $tempname.XX /dev/null) ||
+ tempname=$tempname.$(date +%s.%N) /dev/null
+
echo \
#include stdlib.h
/* Apparently uclibc defines __GLIBC__ (compat trick?). Oh well. */
is what (I found) is needed to realy make it POSIX shell script text
executable.
Cheers,
--
Cristian
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH] gen_build_files.sh: Remove bashisms
On Monday 17 May 2010 21:03, Peter Tyser wrote: I also echo your opinions about keeping the scripts portable. I can sympathise with this point of view. However, I can see another point of view: Why, after years and years of happily using bash, everybody should be tortured now by being forced to work in a shell which: * does not have a single source release linked to its homepage (http://gondor.apana.org.au/~herbert/dash/) * does not support many (any?) bash extensions, even simple ones * does not have a testsuite Why? Who are those people and why I am forced to use their shell now? Why am I a hostage now to their whim on when, and *whether*, they will agree to fix bug foo or implement feature baz? bash didn't have bug foo and had feature baz, and I was happy. Now I'm not. I definitely see your points. But I don't think this discussion should be centered on dash. To me its a debate about using portable POSIX compliant shell scripting vs using bash-specific shell scripting. If we use POSIX compliant code, dash, as well as most other shells should work without issue. If we use bash-specific shell scripting bash will work, and others *may* work. The 2 acceptable solutions to me would be (in order of preference): 1. Use POSIX compliant shell scripting, and using /bin/sh as the interpreter. 2. Use bash shell scripting, and use /bin/bash as the interpreter. Right now, we're using bash scripting, but using /bin/sh as the interpreter. This is what I think is broke. If we use /bin/sh as the interpreter, we shouldn't be using bashisms. If we use /bin/bash as the interpreter, than we're free to use bashisms as we please. So in any case, in my mind it comes down to using option #1 or #2 above - and I do see both sides of that argument. Either #1 or #2 would be an improvement in my opinion. Ok, let's go for choice #1 -- vda ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH] gen_build_files.sh: Remove bashisms
On Mon, 17 May 2010, Denys Vlasenko wrote: On Monday 17 May 2010 22:10, Douglas Mencken wrote: Patches welcome? Here's mine. License: Public domain. - while read -r; do - test x$REPLY = xINSERT REPLY=$s - printf %s\n $REPLY + while read -r reply; do + test x$reply = xINSERT reply=$s + printf %s\n $reply done $src $dst.$$.tmp if test -f $dst cmp -s $dst.$$.tmp $dst; then (also attached) It's easy, isn't it? ;) Easy and arguably? wrong. It eats leading and trailing whitespace. I cannot find anything in the opengroup page you earlier referred to: http://www.opengroup.org/onlinepubs/009695399/utilities/read.html saying explicitely whitespace must me preserved. On the contrary, The line shall be split into fields as in the shell (see Field Splitting); the first field shall be assigned to the first variable var, the second field to the second variable var, and so on. Cheers, -- Cristian ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH] gen_build_files.sh: Remove bashisms
Definitely put me down in the camp that does NOT want to add a lot of bash-specific features to the default shell. The default shell should be POSIX, nothing more. Anything else runs the risk of introducing incompatibilities with standard POSIX scripts, resulting in failures! For example, what if I write a shell script that defines a shell function source; now that we support the bash source builtin that script, which works fine with any POSIX shell AND with (older, anyway) versions of dash, will fail. Etc. IMO if you want bash, get bash (and put #!/bin/bash at the top of your scripts). If you put #!/bin/sh at the top of your scripts, restrict yourself to POSIX shell features. On Mon, 2010-05-17 at 23:54 +0200, Cristian Ionescu-Idbohrn wrote: -local tempname=/tmp/temp.$$.$RANDOM +local tempname=/tmp/temp.$$ This isn't valid: there's no local keyword in POSIX shell. wrong. It eats leading and trailing whitespace. I cannot find anything in the opengroup page you earlier referred to: http://www.opengroup.org/onlinepubs/009695399/utilities/read.html saying explicitely whitespace must me preserved. Yes, that's what Denys is saying. The rewrite is NOT equivalent to the bash version, because the bash version preserves leading/trailing whitespace, and the rewrite does not. Not sure that matters in this case, but it's true nonetheless: ~$ cat /tmp/booar thisis a file ~$ read -r foo /tmp/booar ~$ echo |$foo| |thisis a file| ~$ read -r /tmp/booar ~$ echo |$REPLY| | thisis a file| ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH] gen_build_files.sh: Remove bashisms
On Saturday 15 May 2010 13:30:51 Cristian Ionescu-Idbohrn wrote: On Fri, 14 May 2010, Rob Landley wrote: And of course you program in shell for performance reasons. Yes. A performant shell it's crucial in the embedded world, as an important part of cross-building and also running the target system. On the target use a busybox shell. That's a separate issue from your build environment. I'm building under QEMU on a 3 year old laptop that was only midrange when I got it, and Bash is working fine for me. I'd prefer to move to a busybox shell, but that's to reduce the number of packages in my base system, not for performance reasons. Debian is sucking in bad design decisions from Ubuntu, yes. Which distribution sucks less, in your opinion? They all suck in different ways. I'm sniffing arond Gentoo these days and thinking of switching my laptop over to that when Ubuntu 9.04 becomes unsupported, but that's not the same as endorsing it for others to use. (Then again, I don't recommend Linux for other people anymore. The battle for the desktop is over and we lost, I just tell 'em to get a Mac...) Rob -- Latency is more important than throughput. It's that simple. - Linus Torvalds ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH] gen_build_files.sh: Remove bashisms
On Saturday 15 May 2010 13:10:08 Cristian Ionescu-Idbohrn wrote: On Fri, 14 May 2010, Rob Landley wrote: On Friday 14 May 2010 15:57:34 Cristian Ionescu-Idbohrn wrote: Yes. Horrid obfuscation. By the way, if you were making the argument this should work under busybox's own shells, I'd be all for it. You could even make a standards argment around SUSv4. I'll hold my breath :) But making the argument this should comply with Ubuntu's design mistakes, such as replacing the gcc binary with a perl wrapper (yes really, check Ubuntu 8.10)... No, I'm not making that argument. Aren't we diverging from the subject? Weren't you running an ubuntu (flawed desingn) box? Ubuntu installs bash by default. If you say #!/bin/bash at the top, you get bash. There's never been any plan to remove bash from the system, they're just adding more unnecessary glop on top. Their original rationale was to speed up init scripts. Yes really. They penalized the entire system because they hadn't yet thought of upstart, and then followed through because they'd never admit a mistake no matter how obvious. You are defending the single worst technical decision Ubuntu ever made. Rob -- Latency is more important than throughput. It's that simple. - Linus Torvalds ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH] gen_build_files.sh: Remove bashisms
On Saturday 15 May 2010 17:27:40 Cristian Ionescu-Idbohrn wrote:
On Sat, 15 May 2010, Denys Vlasenko wrote:
On Friday 14 May 2010 01:05, Peter Tyser wrote:
-find -type d | while read; do
- d=$REPLY
-
+find -type d | while read d; do
I applied this part, and changed #!/bin/sh to bash.
Thanks!
Thank you.
I had a look through and found:
,[ individual ]
| possible bashism in individual line 15 (brace expansion):
He changed the start to #!/bin/bash and you're still looking for bashisms.
If you keep on with this, I'm going to go through and try to optimize every
shells cript in the project with as many intentional obscure bashisms as
possible. (Keep in mind dash doesn't even support thing/{one,two} syntax.
it's not hard to make the scripts smaller and simpler by filling them with
things dash can't cope with.)
I'm warning you to drop this topic. I don't have a stubborn streak, I have a
vindictive streak. It has a very high activation threshold, and most things I
don't care enough to do anyhing about. But once the straw breaks the camel's
back you go in the Bruce Fucking Perens category and I remain 100% opposed to
your very existence years later.
Rob
--
Latency is more important than throughput. It's that simple. - Linus Torvalds
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH] gen_build_files.sh: Remove bashisms
On Friday 14 May 2010 22:52, Cristian Ionescu-Idbohrn wrote: On Fri, 14 May 2010, Rob Landley wrote: On Thursday 13 May 2010 18:05:53 Peter Tyser wrote: Using 'read' without a variable is not supported in many shells. Lines such as 'while read; do' in gen_build_files.sh would result in build failures when using sh or dash as an interpreter: Simple fix: say #!/bin/bash at the top of all shell scripts, always. Not surprisingly, I disagree :) dash is 5+ times faster than bash. I think adding bash compat in read builtin in dash wouldn't make it 5 times slower, while it will avoid problems for a lot of people by not making scripts break. This assumes that dash developers are not on a crusade to implement what standards say, and not an iota more. -- vda ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH] gen_build_files.sh: Remove bashisms
On Fri, 14 May 2010, Rob Landley wrote: On Friday 14 May 2010 15:57:34 Cristian Ionescu-Idbohrn wrote: Yes. Horrid obfuscation. By the way, if you were making the argument this should work under busybox's own shells, I'd be all for it. You could even make a standards argment around SUSv4. I'll hold my breath :) But making the argument this should comply with Ubuntu's design mistakes, such as replacing the gcc binary with a perl wrapper (yes really, check Ubuntu 8.10)... No, I'm not making that argument. Aren't we diverging from the subject? Weren't you running an ubuntu (flawed desingn) box? Cheers, -- Cristian ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH] gen_build_files.sh: Remove bashisms
On Sat, 15 May 2010, Denys Vlasenko wrote: On Friday 14 May 2010 22:52, Cristian Ionescu-Idbohrn wrote: On Fri, 14 May 2010, Rob Landley wrote: Simple fix: say #!/bin/bash at the top of all shell scripts, always. Not surprisingly, I disagree :) dash is 5+ times faster than bash. I think adding bash compat in read builtin in dash wouldn't make it 5 times slower, while it will avoid problems for a lot of people by not making scripts break. Sounds like a pragmatic approach to the problem. And as such, you may be right. This assumes that dash developers are not on a crusade to implement what standards say, and not an iota more. Plausible. Still, we're slowed down by scripts breaking because standards are not followed, or corrected when found confusing. Sad. Cheers, -- Cristian ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH] gen_build_files.sh: Remove bashisms
On Fri, 14 May 2010, Rob Landley wrote: And of course you program in shell for performance reasons. Yes. A performant shell it's crucial in the embedded world, as an important part of cross-building and also running the target system. Debian is sucking in bad design decisions from Ubuntu, yes. Which distribution sucks less, in your opinion? Cheers, -- Cristian ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH] gen_build_files.sh: Remove bashisms
On Friday 14 May 2010 22:52, Peter Tyser wrote:
On Fri, 2010-05-14 at 15:41 -0500, Rob Landley wrote:
On Thursday 13 May 2010 18:05:53 Peter Tyser wrote:
Using 'read' without a variable is not supported in many shells. Lines
such as 'while read; do' in gen_build_files.sh would result in build
failures when using sh or dash as an interpreter:
Simple fix: say #!/bin/bash at the top of all shell scripts, always.
With the exception of fix_ws.sh, all other shell scripts in scripts/
use /bin/sh. I had assumed this was intentional? Unless there is a
specific bashism that makes gen_build_files.sh much cleaner/better/etc,
read -r without argument does not strip leading whitespace from the read line.
read -r REPLY does.
This can be fought with with IFS tricks, which looks ugly (what if you
need to restore IFS? brrr):
$ (echo a \ b | { read -r; echo [$REPLY]; })
[ a \ b ]
$ (echo a \ b | { read -r REPLY; echo [$REPLY]; })
[a \ b]
$ (IFS=''; echo a \ b | { read -r REPLY; echo [$REPLY]; })
[ a \ b ]
why not keep it portable? I also personally prefer explicitly
specifying a variable for 'read' instead of using the magical REPLY
variable.
--
vda
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH] gen_build_files.sh: Remove bashisms
On Friday 14 May 2010 01:05, Peter Tyser wrote: -find -type d | while read; do - d=$REPLY - +find -type d | while read d; do I applied this part, and changed #!/bin/sh to bash. Thanks! -- vda ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH] gen_build_files.sh: Remove bashisms
On Sat, 15 May 2010, Denys Vlasenko wrote:
On Friday 14 May 2010 01:05, Peter Tyser wrote:
-find -type d | while read; do
- d=$REPLY
-
+find -type d | while read d; do
I applied this part, and changed #!/bin/sh to bash.
Thanks!
Thank you.
I had a look through and found:
,[ individual ]
| possible bashism in individual line 15 (brace expansion):
| make busybox.links include/bb_config.h
$(pwd)/{libbb/libbb.a,archival/libunarchive/libunarchive.a,coreutils/libcoreutils/libcoreutils.a,networking/libiproute/libiproute.a}
| possible bashism in individual line 31 ('function' is useless):
| function substithing()
| possible bashism in individual line 33 (${parm/?/pat[/str]}):
| if [ ${1/ $3 //} != $1 ]
| possible bashism in individual line 39 ('function' is useless):
| function extra_libraries()
| possible bashism in individual line 70 ('function' is useless):
| function bonkname()
| possible bashism in individual line 74 (should be 'b = a'):
| if [ $APPLET == $1 ]
| possible bashism in individual line 76 (${parm/?/pat[/str]}):
| APPFILT=${2/@*/}
| possible bashism in individual line 77 (should be 'b = a'):
| if [ ${APPFILT} == $2 ]
| possible bashism in individual line 81 (${parm/?/pat[/str]}):
| HELPNAME=${2/*@/}_full_usage
| possible bashism in individual line 92 ('function' is useless):
| function buildit ()
`
,[ mkdiff_obj ]
| possible bashism in mkdiff_obj line 5 ($'...' should be $(printf '...')):
| sed $'s/^\\(\t*\\)[ ]*[0-9a-f][0-9a-f]*:[ \t]*/\\1/' \
`
,[ randomtest.loop ]
| possible bashism in randomtest.loop line 16 ($RANDOM):
| dir=test.$$.$RANDOM
| possible bashism in randomtest.loop line 23 (let ...):
| let fail++
| possible bashism in randomtest.loop line 37 (let ...):
| let cnt++
`
,[ trylink ]
| possible bashism in trylink line 49 ($RANDOM):
| local tempname=/tmp/temp.$$.$RANDOM
| possible bashism in trylink line 61 ($RANDOM):
| local tempname=/tmp/temp.$$.$RANDOM
`
you might want to look into.
Cheers,
--
Cristian
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH] gen_build_files.sh: Remove bashisms
On Thursday 13 May 2010 18:05:53 Peter Tyser wrote: Using 'read' without a variable is not supported in many shells. Lines such as 'while read; do' in gen_build_files.sh would result in build failures when using sh or dash as an interpreter: Simple fix: say #!/bin/bash at the top of all shell scripts, always. Speaking of which, when hush gets close to being a reasonable bash replacement (about when we're ready to delete ash), we should teach it to be callable via a bash alias, since so many scripts do this becase the Defective Annoying Shell is such a horrid Ubuntu-ism. Rob -- Latency is more important than throughput. It's that simple. - Linus Torvalds ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH] gen_build_files.sh: Remove bashisms
On Fri, 14 May 2010, Rob Landley wrote: On Thursday 13 May 2010 18:05:53 Peter Tyser wrote: Using 'read' without a variable is not supported in many shells. Lines such as 'while read; do' in gen_build_files.sh would result in build failures when using sh or dash as an interpreter: Simple fix: say #!/bin/bash at the top of all shell scripts, always. Not surprisingly, I disagree :) dash is 5+ times faster than bash. Speaking of which, when hush gets close to being a reasonable bash replacement (about when we're ready to delete ash), we should teach it to be callable via a bash alias, since so many scripts do this becase the Defective Annoying Shell is such a horrid Ubuntu-ism. Not only. Soon to become an as horrid debian-ism and debian derivate-ism. Cheers, -- Cristian ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH] gen_build_files.sh: Remove bashisms
On Fri, 2010-05-14 at 15:41 -0500, Rob Landley wrote: On Thursday 13 May 2010 18:05:53 Peter Tyser wrote: Using 'read' without a variable is not supported in many shells. Lines such as 'while read; do' in gen_build_files.sh would result in build failures when using sh or dash as an interpreter: Simple fix: say #!/bin/bash at the top of all shell scripts, always. With the exception of fix_ws.sh, all other shell scripts in scripts/ use /bin/sh. I had assumed this was intentional? Unless there is a specific bashism that makes gen_build_files.sh much cleaner/better/etc, why not keep it portable? I also personally prefer explicitly specifying a variable for 'read' instead of using the magical REPLY variable. Best, Peter ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH] gen_build_files.sh: Remove bashisms
On Friday 14 May 2010 15:52:24 Cristian Ionescu-Idbohrn wrote: On Fri, 14 May 2010, Rob Landley wrote: On Thursday 13 May 2010 18:05:53 Peter Tyser wrote: Using 'read' without a variable is not supported in many shells. Lines such as 'while read; do' in gen_build_files.sh would result in build failures when using sh or dash as an interpreter: Simple fix: say #!/bin/bash at the top of all shell scripts, always. Not surprisingly, I disagree :) dash is 5+ times faster than bash. And of course you program in shell for performance reasons. Speaking of which, when hush gets close to being a reasonable bash replacement (about when we're ready to delete ash), we should teach it to be callable via a bash alias, since so many scripts do this becase the Defective Annoying Shell is such a horrid Ubuntu-ism. Not only. Soon to become an as horrid debian-ism and debian derivate-ism. Debian is sucking in bad design decisions from Ubuntu, yes. They're still bad design decisions. The rationale for the switch to dash was to speed up init scripts. Switching #!/bin/sh instead of having the init scripts start with #!/bin/dash was a stupid way to go about it. Then they implemented upstart and started rewriting the init logic in C, rendering it doubly moot. But as with all large bureaucracies, the bad decision has acquired momentum. It's like the itanium; no purpose to continue to exist but too much invested in it to stop... Cheers, Rob -- Latency is more important than throughput. It's that simple. - Linus Torvalds ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH] gen_build_files.sh: Remove bashisms
On Friday 14 May 2010 15:57:34 Cristian Ionescu-Idbohrn wrote: On Fri, 14 May 2010, Peter Tyser wrote: I also personally prefer explicitly specifying a variable for 'read' instead of using the magical REPLY variable. Yes. Horrid obfuscation. By the way, if you were making the argument this should work under busybox's own shells, I'd be all for it. You could even make a standards argment around SUSv4. But making the argument this should comply with Ubuntu's design mistakes, such as replacing the gcc binary with a perl wrapper (yes really, check Ubuntu 8.10)... That's not a compelling argument for an embedded toolset. Cheers, Rob -- Latency is more important than throughput. It's that simple. - Linus Torvalds ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
