Re: debian patches to exit with code 127 for nonexistent/directory scripts
On Tue, 8 Jun 2010, Herbert Xu wrote: Jilles Tjoelker jil...@stack.nl wrote: Debian's dash package has some local changes which cause an exit with code 127, as required by POSIX, if a script (passed with dash filename) cannot be opened or cannot be read because it is a directory. My interpretation of the above is that debian's patched dash is POSIX compliant WRT the named exit code. Please report this through Debian's bug tracking system. Why? There is nothing that I can do about this. Upstream dash is _not_ POSIX compliant WRT the named exit code, seems to be the meaning of the sentence. And you can certainly _do_ something about it. On the other hand, I may have got it all wrong (because of some language barrier), in which case please accept my apologies. Cheers, -- Cristian -- To unsubscribe from this list: send the line unsubscribe dash in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [EVAL] with set -e exit the shell if a subshell exits non-zero
On Mon, 28 Jun 2010, Herbert Xu wrote: On Mon, Jun 14, 2010 at 09:56:03AM +, Gerrit Pape wrote: Example: $ dash -c 'set -e; (false); echo here' here With this commit, dash exits 1 before echo. The bug was reported by Stefan Fritsch through http://bugs.debian.org/514863 Signed-off-by: Gerrit Pape p...@smarden.org I'm not convinced that this change is necessary. I've run some tests and bash/pdksh both behave like dash, while ksh93 behaves in the way you suggest. Has bash's behaviour changed recently (I'm using an ancient version)? bash 3.2.39 and 4.0.37 are behaving as dash without the suggested patch. Still. What is the correct behaviour? That should be the essential matter IMO, not what others do. So, why should this fail: $ dash -c 'set -e; false; echo here' and this succeed? $ dash -c 'set -e; (false); echo here' The subshell returns exit code 1, and errexit is set. Why does dash ignore that exit code in the later case? Cheers, -- Cristian -- To unsubscribe from this list: send the line unsubscribe dash in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: read() builtin doesnt read integer value /proc files (but bashs does)
Jonathan, On Wed, 15 Dec 2010, Jonathan Nieder wrote: Cristian Ionescu-Idbohrn wrote: On Sun, 28 Nov 2010, Herbert Xu wrote: I'm with Jilles on this. I also don't particularly feel like bloating dash just because of the borked /proc interface when there is a perfectly adequate work-around in cat. value=$(cat /proc/file) I wouldn't call that a perfectly adequate work-around, but a painful and unadequate work-around. This works in /proc because files in /proc are seekable. That said, I don't think borked /proc is a great reason to do this (it's a better reason to fix /proc). Speeding up the read builtin might be a good reason. Right. So, there are 2 options here. One is to to make dash work like bash on a proc filesystem, the other to fix the kernel. How many linux distributions depend on a working dash? Which alternative is the more realistic one? What are the ETAs odds? How do we proceed? Cheers, -- Cristian -- To unsubscribe from this list: send the line unsubscribe dash in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
