With dash as /bin/sh, make headers_install doesn't create the __ASM_STUB_ header properly Result: #ifndef __ASM_STUB_ #define __ASM_STUB_ Expect: #ifndef __ASM_STUB_TYPES_H #define __ASM_STUB_TYPES_H
Created attachment 113929 [details, diff] Fix the issue Basically dash requires a semi colon here.
that doesnt sound right to me at all why would you require a semicolon in order to set a variable ? you only need whitespace which is what the makefile provides ...
Maybe it's because it's on the rhs of an assignment already - I'm guessing the value cmd_gen is interpreted by the shell rather than make. However whitespace-separated assignments are also valid for the shell: $ F=one G=two $ echo $F $G one two This works for me in bash, busybox - and dash-0.5.2.7, dash-0.5.3.7, so the Roy's analysis is incomplete. I had a quick look at the posix spec: http://www.opengroup.org/onlinepubs/009695399/utilities/xcu_chap02.html#tag_02_09_01 implies a command consisting of just a sequence of variables should work and will affect the environment. Roy; could you explain why you think the original makefile is broken? Maybe it's not dash causing the problem, but the version of make being used.
Created attachment 113954 [details] emerge --info I agree, and taking that code snippet by itself it does not need the semi colon. But the thing as a whole requires it. So something in the parsing is causing dash to barf here. What that something is I am not sure. Any insight into finding out the root cause would be nice :)
it's because dash does not export evaluated variables until the next statement the headers basically do something like: A=moo B="$A more" dash does not make $A available until the next statement, that's why inserting the semi-colon there "fixes" things so run this command chain to see the difference between bash and dash: unset A B; A="moo" B="$A more"; echo $A , $B
my reading of the spec says that dash is broken here ... ive also checked on the bash mailing list and they agree ... so time to bug the dash maintainers :P
busybox: $ bb ~ $ unset A B; A="moo" B="$A more"; echo $A , $B moo , more so busybox is doing the same as dash. It would be interesting to know what the Unix shells do (solaris, hpux etc) - given that the posix spec in this sort of area should be documenting the common denominator. I.e. if bash is the _only_ shell interpreting things this way, it's not likely that posix is intended to specify it (it is perhaps intended to leave it unspecified, to allow for variations in common sh implementations. If posix is intended to allow for the variation, then it would make sense to avoid depending on this behaviour, especially where it costs nothing.
FreeBSD sh does the same as dash and bb - not too suprising as they're all descended from ash.
Just tried OpenSolaris 5.11 (belenix) and it's sh (unsurprisingly) does the same as dash, bb.
tbh, i dont really thing it matters what shells do what in general ... if a shell's behavior differs from POSIX, then it's broken ... i'd say the same thing if we thought bash was doing the wrong thing
That's just it though - I'm coming to the conclusion that bash is doing the wrong thing in this case. We'll see how the thread develops on bug-bash.
(In reply to comment #10) > tbh, i dont really thing it matters what shells do what in general ... if a > shell's behavior differs from POSIX, then it's broken ... i'd say the same > thing if we thought bash was doing the wrong thing Where in the POSIX shell spec are you seeing a defined behaviour as I cannot find any reference to this. FWIW, C does not define a paramter evaluation order either - something that Cardoe found out. It's not right to left - it could be left to right or something else. So taking the above into account, which is true? unset A B; A="moo" B="$A, more" A="foo"; echo $A $B If this is the case then the only way to guarantee correct parameter evaluation is to separate them by statements. unset A B; A="moo"; B="$A, more"; A="foo"; echo $A $B Of course, I could be talking out of my ass and vapier will pull the POSIX page out explaining why I am wrong :)
Kevin already posted the link to the relevant section in the POSIX spec ... in there it states that evaluation happens "from the beginning of the command text to the end" i dont see how C's handling of , and ; is relevant here ... we're talking about POSIX shell
Got some more clarification from the bash maintainer. It does appear that bash is posix-compliant in this respect, and that it is dash that is non-compliant (along with pretty much all other shells). The other shells I mentioned aren't Posix shells and don't claim compliance. ksh93 (which makes a big thing about posix-compliance - didn't think to try it before) does the same as bash. Thread on bug-bash at: http://www.mail-archive.com/bug-bash%40gnu.org/msg02622.html http://lists.gnu.org/archive/html/bug-bash/2007-03/msg00075.html Summary - take it up with the dash maintainers, since NetBSD does care about Posix-compliance for its shell (according to http://netbsd.gw.com/cgi-bin/man-cgi?sh++NetBSD-current). Refer them to the above thread (better than paraphrasing what we've said here).
FFS can we just make a simple fix by adding a ; It's not like making this change will break bash or rape kittens. I have contacted dash upstream and CC'd everyone on this bug. When the time comes, you can pull out the ; and be happy to be ; free, but until then add the ;
Spanky: Are you not upstream for busybox? Can you file this bug with them or fix it?
i really dont think busybox is an issue at this time busybox shell is used at runtime on embedded systems, not on a development system i'm sure there's plenty of other things dash has fixed that have not made their way into busybox ... the shell situation in busybox is just all fucked anyways
If you won't add that little semi colon, could you at least put a test into linux-headers ebuild so that it won't install when /bin/sh isn't bash OR force the Makefile into using bash somehow? Just because you don't think busybox should be used as a shell on our boxes doesn't stop the fact that our users for all their sins might want to.
busybox's shell will fail a lot more POSIX tests than this one ... simply put, it is not supported as a development shell and only gets limited support as a runtime shell
Fine, can you just add a little semi-colon? That's all we want. You would have spent less time adding the semi-colon then trying to argue with us.
Note that adding the ';' means FNAME gets set in the environment rather than just for the one command. That means the maintainer would need to verify (and re-verify on every release) that FNAME isn't used elsewhere. I notice we're now talking about busybox, when the bug was originally about dash. Has dash been fixed?
Kevin: You were CC'd in my original e-mail to the DASH maintainer. I have not received an answer from him.
we're not talking about busybox, forget it was mentioned
Created attachment 119375 [details, diff] Use one var (In reply to comment #21) > Note that adding the ';' means FNAME gets set in the environment rather than > just for the one command. That means the maintainer would need to verify (and > re-verify on every release) that FNAME isn't used elsewhere. Valid point. This new patch addresses this concern. > I notice we're now talking about busybox, when the bug was originally about > dash. Has dash been fixed? No, but it applies to current busybox in portage as well, regardless of Mikes views about its suitability as /bin/sh for a Gentoo development system. Yes, dash is probably more POSIX compliant than busybox, but there's also no need to go out of our way to needlessly ignore it when patches are trivial.
the triviality of a patch is irrelevant when referring to its correctness
(In reply to comment #25) > the triviality of a patch is irrelevant when referring to its correctness What part of the patch is incorrect?
the part where it's needed
Is this bug still relevant? Seems like dash still behaves this way, but what packages are affected, if any?
packages that either have changed their syntax or changed their shebang
seems to work with dash-0.5.7
