http://blog.gmane.org/gmane.comp.shells.dash hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://permalink.gmane.org/gmane.comp.shells.dash/733 <pre> http://www.altphel.ro/2012/05/dobre-arata-ne-diploma/ To unsubscribe please send email to unsubscribe&lt; at &gt;cc.psd-prahova.ro -- To unsubscribe from this list: send the line "unsubscribe dash" in the body of a message to majordomo&lt; at &gt;vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html </pre> cramer< at >cc.psd-prahova.ro 2012-05-24T12:37:09 http://permalink.gmane.org/gmane.comp.shells.dash/732 <pre> http://www.altphel.ro/2012/05/dobre-arata-ne-diploma/ To unsubscribe please send email to unsubscribe&lt; at &gt;cc.psd-prahova.ro -- To unsubscribe from this list: send the line "unsubscribe dash" in the body of a message to majordomo&lt; at &gt;vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html </pre> cramer< at >cc.psd-prahova.ro 2012-05-24T11:23:59 http://permalink.gmane.org/gmane.comp.shells.dash/731 <pre> Otherwise, this: $ perl -le 'print "v"x(2**31+1) ."=1"' | dash provokes integer overflow: (gdb) bt #0 doformat (dest=0x61d580, f=0x416a08 "%s: %d: %s: ", ap=0x7fffffffd308) at output.c:310 #1 0x00000000004128c1 in outfmt (file=0x61d580, fmt=0x416a08 "%s: %d: %s: ") at output.c:257 #2 0x000000000040382e in exvwarning2 (msg=0x417339 "Out of space", ap=0x7fffffffd468) at error.c:125 #3 0x000000000040387e in exverror (cond=1, msg=0x417339 "Out of space", ap=0x7fffffffd468) at error.c:156 #4 0x0000000000403938 in sh_error (msg=0x417339 "Out of space") at error.c:172 #5 0x000000000040c970 in ckmalloc (nbytes=18446744071562067984) at memalloc.c:57 #6 0x000000000040ca78 in stalloc (nbytes=18446744071562067972) at memalloc.c:132 #7 0x000000000040ece9 in grabstackblock (len=18446744071562067972) at memalloc.h:67 #8 0x00000000004106b5 in readtoken1 (firstc=118, syntax=0x419522 "", eofmark=0x0, striptabs=0) at parser.c:1040 #9 0x00000000004101a4 in xxreadtoken () at parser.c:826 #10 0x000000000040fe1d in readtoken () at parser.c:697 #11 0x000000000040edcc in parsecmd (interact=0) at parser.c:145 #12 0x000000000040c679 in cmdloop (top=1) at main.c:224 #13 0x000000000040c603 in main (argc=2, argv=0x7fffffffd9f8) at main.c:178 #8 0x00000000004106b5 in readtoken1 (firstc=118, syntax=0x419522 "", eofmark=0x0, striptabs=0) at parser.c:1040 1040 grabstackblock(len); (gdb) p len $30 = -2147483644 Signed-off-by: Jim Meyering &lt;meyering&lt; at &gt;redhat.com&gt; --- ChangeLog | 5 +++++ src/parser.c | 2 +- 2 files changed, 6 insertions(+), 1 deletion(-) diff --git a/ChangeLog b/ChangeLog index 8686332..c84aa7e 100644 --- a/ChangeLog +++ b/ChangeLog &lt; at &gt;&lt; at &gt; -1,3 +1,8 &lt; at &gt;&lt; at &gt; +2012-03-11 Jim Meyering &lt;meyering&lt; at &gt;redhat.com&gt; + +* Avoid overflow for very long variable name. +$ perl -le 'print "v"x(2**31+1) ."=1"' | dash + 2012-02-25 Herbert Xu &lt;herbert&lt; at &gt;gondor.apana.org.au&gt; * Sanitise environment variable names on entry. diff --git a/src/parser.c b/src/parser.c index 6de2762..572cbcd 100644 --- a/src/parser.c +++ b/src/parser.c &lt; at &gt;&lt; at &gt; -853,7 +853,7 &lt; at &gt;&lt; at &gt; readtoken1(int firstc, char const *syntax, char *eofmark, int striptabs) { int c = firstc; char *out; -int len; +size_t len; struct nodelist *bqlist; int quotef; int dblquote; -- 1.7.10.2.552.gaa3bb87 -- To unsubscribe from this list: send the line "unsubscribe dash" in the body of a message to majordomo&lt; at &gt;vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html </pre> Jim Meyering 2012-05-23T20:37:48 http://permalink.gmane.org/gmane.comp.shells.dash/730 <pre> This is not actually said in the XCU 'wait' page but in XCU 2.11 Signals and Error Handling. However, it says something subtly different: only a signal for which a trap has been set should cause 'wait' to return immediately with an exit status greater than 128. Because no trap has been set on SIGTSTP, 'wait' should not be interrupted here and the shell should continue waiting. Likewise, if the shell internally uses SIGCHLD to get notified about process termination, this does not interrupt 'wait'; dash implements that aspect properly. Only if you have set any traps that resume execution of the original script (i.e. do not exit the process). Otherwise, if 'wait' is being called without parameters, you can do something like until wait; do :; done If 'wait' is being called with parameters, the required loop is very complicated. </pre> Jilles Tjoelker 2012-05-03T22:46:38 http://permalink.gmane.org/gmane.comp.shells.dash/729 <pre> Hello, and thanks for you answer. I find that quite surprising. I re-read the posix description of wait, and my understanding is that the return value of wait should depend on what happened to the waited process (exit code, signal), not to wait itself. And other shells seem to agree. Are you suggesting that wait should always be used in a loop? With what check exactly? </pre> Marc Glisse 2012-05-03T22:28:17 http://permalink.gmane.org/gmane.comp.shells.dash/728 <pre> That's normal as wait was interrupted by a signal. If you want to wait even after an interruption, you should check the return value of wait. Cheers, </pre> Herbert Xu 2012-05-03T21:51:22 http://permalink.gmane.org/gmane.comp.shells.dash/727 <pre> http://www.youtube.com/watch?feature=player_embedded&amp;v=phjGxHn3uKU To unsubscribe please send email to unsubscribe&lt; at &gt;cc.psd-prahova.ro -- To unsubscribe from this list: send the line "unsubscribe dash" in the body of a message to majordomo&lt; at &gt;vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html </pre> cramer< at >cc.psd-prahova.ro 2012-05-02T13:14:47 http://permalink.gmane.org/gmane.comp.shells.dash/726 <pre>Good Morning, we are currently generating top quality leads &amp; data for several clients. if you are in market looking for quality leads or data, this is some thing you do not want to miss. drop me a line &amp; I will forward you our pricing and volumes. let's jump on quick call &amp; I'll show you how to take your business to next level &amp; lower your customer acquisition costs w no cheesy sales tactics. best, -Mark -- To unsubscribe from this list: send the line "unsubscribe dash" in the body of a message to majordomo&lt; at &gt;vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html </pre> mark payneec 2012-04-30T19:41:23 http://permalink.gmane.org/gmane.comp.shells.dash/725 <pre> In what way does a lone "fi" differ from constructions like the below, which do not match the POSIX grammar but are accepted by some subset of shells that attempt to comply to POSIX: case x in (esac) ;; esac for i; do echo "$i"; done for i; do echo "$i"; done for i { echo "$i"; } for ((i = 0; i &lt; 10; i += 1)) do echo "$i"; done f() : The only difference seems to be that the lone "fi" is somehow "wrong" while the above are not "wrong". That's too vague for a specification. Unfortunately, the XCU volume is very thin on constraints (as found, for example, in the C standard). Many ways to do things "wrong" are instead left open for implementation extensions. In practice, many such extensions exist. That said, rejecting the lone "fi" is still a quality of implementation issue, particularly because dash's current behaviour is poorly defined. I fixed it in FreeBSD a while ago (9.0 has the fix). In making this change, a testsuite is very useful to guard against bugs and to ensure no cases are missed, but latent bugs in shell scripts may still cause annoyance. If there is an error in a command substitution that is normally not executed, most shells (except ash derivatives) will not notice this. For example, FreeBSD 9.0's sh is one of the few shells that detects the error in: if false; then `fi`; fi </pre> Jilles Tjoelker 2012-04-24T22:47:03 http://permalink.gmane.org/gmane.comp.shells.dash/724 <pre> Yes, I think you're right. For some reason I thought that using reserved words in ways not permitted by the grammar produced undefined behavior, to support shells with extensions like the arithmetic "for". But now that I read more closely, it looks like "function", "[[", "]]", and "select" produce unspecified behavior but everything else is pretty well specified. Thanks for clarifying. -- To unsubscribe from this list: send the line "unsubscribe dash" in the body of a message to majordomo&lt; at &gt;vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html </pre> Jonathan Nieder 2012-04-23T19:54:58 http://permalink.gmane.org/gmane.comp.shells.dash/723 <pre>Hi Jonathan, Chet. On 04/23/2012 09:44 PM, Jonathan Nieder wrote: I have no patch, but a little more information that might help anyone who volunteers to write one: $ nl=$'\n' $ dash -c ":$nl fi" &amp;&amp; echo NOERR dash: Syntax error: "fi" unexpected $ dash -c ":;$nl fi" &amp;&amp; echo NOERR dash: Syntax error: "fi" unexpected $ dash -c ":&amp;$nl fi" &amp;&amp; echo NOERR dash: Syntax error: "fi" unexpected $ dash -c ": &amp;&amp; fi" &amp;&amp; echo NOERR dash: Syntax error: "fi" unexpected The problem seems to only be present when a stray "fi" comes after a '&amp;' or ';' -- see: $ dash -c ":; fi" &amp;&amp; echo NOERR NOERR dash -c ":&amp; fi" &amp;&amp; echo NOERR NOERR The same goes for other loops/conditionals terminators: $ dash -c ":; done" &amp;&amp; echo NOERR NOERR $ dash -c ":; esac" &amp;&amp; echo NOERR NOERR $ dash -c ":&amp; elif" &amp;&amp; echo NOERR NOERR HTH, Stefano -- To unsubscribe from this list: send the line "unsubscribe dash" in the body of a message to majordomo&lt; at &gt;vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html </pre> Stefano Lattarini 2012-04-23T19:53:21 http://permalink.gmane.org/gmane.comp.shells.dash/722 <pre> The way I read 2.10.2, Posix requires that the "fi" resolve to the reserved word `fi' in this case, since it's in a position where a command name is expected (Rule 1, [Command Name]). I would think that would make it a syntax error in any application, conforming or not. Chet </pre> Chet Ramey 2012-04-23T19:48:08 http://permalink.gmane.org/gmane.comp.shells.dash/721 <pre> I meant "conforming POSIX applications". A patch for this might even be welcome if it makes dash bigger, if that's what you're wondering. -- To unsubscribe from this list: send the line "unsubscribe dash" in the body of a message to majordomo&lt; at &gt;vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html </pre> Jonathan Nieder 2012-04-23T19:44:53 http://permalink.gmane.org/gmane.comp.shells.dash/720 <pre> What are `conforming scripts'? Scripts without syntax errors? </pre> Chet Ramey 2012-04-23T19:27:33 http://permalink.gmane.org/gmane.comp.shells.dash/719 <pre>Hi Jonathan, thanks for the quick reply. On 04/23/2012 07:03 PM, Jonathan Nieder wrote: True, it it makes "dash -n" less useful (not that I deeply care, just pointing it out). Thanks, Stefano -- To unsubscribe from this list: send the line "unsubscribe dash" in the body of a message to majordomo&lt; at &gt;vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html </pre> Stefano Lattarini 2012-04-23T17:09:40 http://permalink.gmane.org/gmane.comp.shells.dash/718 <pre>Hi Stefano, Stefano Lattarini wrote: Since this doesn't affect conforming scripts, I suspect it falls squarely within the "patches welcome as long as they don't make dash bigger" category. Thanks for finding it. Sincerely, Jonathan -- To unsubscribe from this list: send the line "unsubscribe dash" in the body of a message to majordomo&lt; at &gt;vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html </pre> Jonathan Nieder 2012-04-23T17:03:39 http://permalink.gmane.org/gmane.comp.shells.dash/717 <pre>How to reproduce: $ dash -c ':; fi'; echo stat = $? stat = 0 Behaviour of other shells: $ bash-4.1 -c ':; fi'; echo stat = $? # Bash 4.1.5 bash-4.1: -c: line 0: syntax error near unexpected token `fi' bash-4.1: -c: line 0: `:; fi' stat = 1 $ bash-3.2 -c ':; fi'; echo stat = $? # Bash 3.2.0 bash-3.2: -c: line 0: syntax error near unexpected token `fi' bash-3.2: -c: line 0: `:; fi' stat = 2 $ ksh -c ':; fi'; echo stat = $? # AT&amp;T Ksh ksh: syntax error at line 1: `fi' unexpected stat = 3 $ pdksh -c ':; fi'; echo stat = $? # Public Domain Ksh, version 5.2.14 pdksh: syntax error: `fi' unexpected stat = 1 $ zsh -c ':; fi'; echo stat = $? # Zsh 4.3.12 zsh:1: parse error near `fi' stat = 1 Version information: $ dpkg -l dash ii dash 0.5.5.1-7.4 POSIX-compliant shell Regards, Stefano -- To unsubscribe from this list: send the line "unsubscribe dash" in the body of a message to majordomo&lt; at &gt;vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html </pre> Stefano Lattarini 2012-04-23T16:53:27 http://permalink.gmane.org/gmane.comp.shells.dash/716 <pre>Hello, I noticed a strange behavior of "wait" when I suspend and resume a script. $ cat a.sh #!/bin/dash (sleep 7; echo blah) &amp; (sleep 7; echo bloh) &amp; wait ; echo coucou $ ./a.sh ^Z zsh: suspended ./a.sh $ fg [1] + continued ./a.sh coucou $ blah bloh As you can see, the instruction after "wait" was executed immediatly on resume, without waiting for the jobs. If I replace the ';' after "wait" by "&amp;&amp;" and do the same suspend+resume, "coucou" is never printed. I am using dash version 0.5.7-3 in debian testing. </pre> Marc Glisse 2012-04-20T11:31:39 http://permalink.gmane.org/gmane.comp.shells.dash/715 <pre>Hi Jilles, thanks for your reply. Indeed now I remember having read somewhere that you couldn't portably rely on assignments after "local" to suppress word expansion in the same way that ordinary assignments do. I had forgotten that. I hope shell implementations evolve towards more consistency about this. In the meantime, it's easy enough to get portable behavior if you remember the issue. On another note, I was reading in this mailing list about dash's treatment of: FOO=value shell_function $args printf "%s\n" "$FOO" # prints 'value' The other discussion points out that this surprising behavior is in fact mandated by POSIX. I notice however in the dash.1 manpage distributed with finnix 103, the following: When a shell function is executed, all of the shell positional parameters (except $0, which remains unchanged) are set to the arguments of the shell function. The variables which are explicitly placed in the envi- ronment of the command (by placing assignments to them before the func- tion name) ***are made local to the function and are set to the values given.*** Then the command given in the function definition is executed. The positional parameters are restored to their original values when the command completes. This all occurs within the current shell. Presumably this manpage should be updated to track the current behavior of dash. I'm not sure whether it comes from the dash source distro, or was added in by the finnix maintainers. </pre> Jim Pryor 2012-04-09T16:23:00 http://permalink.gmane.org/gmane.comp.shells.dash/714 <pre> The cause is that the local command expands to local IN=abc def ghi and therefore it sets IN to less than what you expect and also makes two more variables local. Now, local is not in POSIX, but export and readonly are and have exactly the same issue. Reading POSIX.1-2008 (and also older versions) literally, this way of splitting is correct. However, ksh93, bash and pdksh think differently, doing what your script expects. Also, the examples section of export has export PATH=/local/bin:$PATH which assumes that either the value will not contain IFS characters or metacharacters or it will not be split regardless. Dash had this behaviour for some time but it was dropped again because of inconsistencies between implementations. However, there appears to be some sort of agreement on how it should work now: http://austingroupbugs.net/view.php?id=351 (scroll down to note 0000943). </pre> Jilles Tjoelker 2012-04-09T15:34:24 http://permalink.gmane.org/gmane.comp.shells.dash/713 <pre> test4 was supposed to use quotes: "$(cat)". It works fine either way. This also works fine: test1a() { local IN IN=$(cat) printf "test1a &lt;%s&gt;\n" "$IN" } It's only this which fails: test1a() { local IN=$(cat) printf "test1 &lt;%s&gt;\n" "$IN" } I've also reported to FreeBSD: &lt;http://www.freebsd.org/cgi/query-pr.cgi?pr=166771&gt; </pre> Jim Pryor 2012-04-09T01:12:43 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.comp.shells.dash