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://comments.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://comments.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://comments.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://comments.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://comments.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://comments.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://comments.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://comments.gmane.org/gmane.comp.shells.dash/712 <pre>Hi, I'm not a subscriber to this list and am not sure where's the best place to report this bug. A cursory search didn't find other reports of the same issue; but I can imagine there may well be such. If so, excuse the noise. I'm just trying to help. I notice the following issue in the version of dash that's bundled in a recent release of finnix (not sure which one, but the kernel version is 3.0.6, so it's probably finnix 103, released 23 October 2011). I also see it in the FreeBSD sh, from a FreeBSD-9 release candidate I compiled in January. I know that's not dash, but I understand the codebases are closely related. Neither of these are my active systems; hence the fuzzy details. Here is a testcase: #!/bin/dash test1() { local IN=$(cat) printf "test1 &lt;%s&gt;\n" "$IN" } test2() { local IN="$(cat)" printf "test2 &lt;%s&gt;\n" "$IN" } test3() { IN=$(cat) printf "test3 &lt;%s&gt;\n" "$IN" } test4() { IN=$(cat) printf "test4 &lt;%s&gt;\n" "$IN" } MSG=$(printf "abc\ndef\nghi") printf "%s" "$MSG" | test1 printf "%s" "$MSG" | test2 printf "%s" "$MSG" | test3 unset IN printf "%s" "$MSG" | test4 ####### The weird bit only shows up in test1: IN will only be assigned the first line of stdin. Hope this helps someone. </pre> Jim Pryor 2012-04-08T22:09:06 http://comments.gmane.org/gmane.comp.shells.dash/711 <pre>i8k9n0O1Q1SgUhVj9l9n0O1Q1SgUhVj9l0N0P1RfThUi8k9m0O0PfTgUi8k9ThVj8l9m0O0P1RfTgUi8k9m9N0P1RfTgUi8k9m0N0P1RfTgUhVj9m0hUi8l9n0O1Q1SgUhVj9l9n0O1Q1SgUhVj9l9n0O1Q1SgUhVj9l9n0P1RfThSfTh8k9m9N0P1RfSfSgUhVj9l9n0O0P1RfSfSgUiVj8k9m0O0Q1Q1Vj9l9N0P1RfTgUi8k9m0N0P1RfTgUi8k9m0N0P1RfThUi8k9m0N0P1RiWk9m0O0Q1RfThViWk9l9m0O0P1Q1SfThVj8l9m0O0Q1RfTgUiVj9l9n0N0PVj9l0O0P1RfThVi8k9m0O0P1RfThVj8k9m0O0P1RfThVj8k9m0O0Q1RSgUh8k9m0O0P1RfThUi8k9m0O0P1R1SgUhVj8k9m0O0P1RfTgUhVjQ1SfUi8k9l9N0P1RfSgUi8k9m9N0P1RfSgUi8k9m9N0P1RfTgUi8k9m0P1Q1SgUiWk9l9n0P1Q1SgUiWk9l9m0O0P1RfSgUi8k9l9N1SgUiWj9l9n0P1Q1SgUiWj9l9n0P1Q1SgUiWj9l9n0P1Q1SgUiWk9m0O0QThVj9l9n0O1Q1SgUhVj9l9n0O1Q1SgUhVj9l9n0O1Q1SgUhVj9l9O0SfThVj8l9m0O0Q1SfThVj8l9m0O0Q1SfThVj8l9N0P1RfSgUi8k9m9l9N0Q1SfThVj8l9m0O0Q1SfThVj8l9m0O0Q1SfThVj8l9m0O0Q1SgTh9n0P1RfThVj8k9m0O0Q1RfThVj8k9m0O0Q1RfThVj8k9m0O0Q1RfUiWkO1Q1TgUi8k9m0N0P1RfThUi8k9m0O0P1RfThUi8k9m0O0P1RfThV -------------------------------------------------------------------------------------------------------------------------------------------------------------------------- 办 （</pre> Xlpt 2012-03-25T11:04:23 http://comments.gmane.org/gmane.comp.shells.dash/704 <pre>From: Harald Hoyer &lt;harald&lt; at &gt;redhat.com&gt; "export -p" prints all environment variables, without checking if the environment variable is a valid dash variable name. IMHO, the only valid usecase for "export -p" is to eval the output. $ eval $(export -p); echo OK OK Without this patch the following test does error out with: test.py: import os os.environ["test-test"]="test" os.environ["test_test"]="test" os.execv("./dash", [ './dash', '-c', 'eval $(export -p); echo OK' ]) $ python test.py ./dash: 1: export: test-test: bad variable name Of course the results can be more evil, if the environment variable name is crafted, that it injects valid shell code. --- src/var.c | 9 ++++++--- 1 files changed, 6 insertions(+), 3 deletions(-) diff --git a/src/var.c b/src/var.c index 027beff..06771d3 100644 --- a/src/var.c +++ b/src/var.c &lt; at &gt;&lt; at &gt; -409,12 +409,15 &lt; at &gt;&lt; at &gt; showvars(const char *prefix, int on, int off) for (; ep &lt; epend; ep++) { const char *p; const char *q; - +const char *r; +r = endofname(*ep); p = strchrnul(*ep, '='); q = nullstr; -if (*p) +if (*p) { +if (p != r) +continue; q = single_quote(++p); </pre> harald< at >redhat.com 2012-02-14T10:48:48 http://comments.gmane.org/gmane.comp.shells.dash/702 <pre>Per POSIX requirements on trap, dash is properly refusing to let non-interactive scripts reset signal handlers via trap if the shell was started with an inherited ignored signal handler. However, dash lies to the user, making it impossible to tell if the user is invoking a shell in an environment where a signal was inherited as ignored. ksh and bash are nicer about things, and at least let the user query whether a shell is treating a particular signal as non-resettable. This is important for shell scripts that WANT to guarantee a particular behavior of SIGPIPE handling (such as this thread on writing a grep test for covering the behavior of grep both with and without SIGPIPE inherited as ignored: https://lists.gnu.org/archive/html/bug-grep/2012-02/msg00016.html). Bash behavior - you can learn about the ignored handler from the get-go: $ (trap '' PIPE; bash -c 'trap; echo 0; trap "echo 1" PIPE; trap; \ echo 2; kill -s PIPE $$; trap; echo 3') trap -- '' SIGPIPE 0 trap -- '' SIGPIPE 2 trap -- '' SIGPIPE 3 Ksh behavior - you can learn about the ignored handler, but only after trying to use something else: $ (trap '' PIPE; ksh -c 'trap; echo 0; trap "echo 1" PIPE; trap; \ echo 2; kill -s PIPE $$; trap; echo 3') 0 trap -- '' PIPE 2 trap -- '' PIPE 3 dash behavior - the trap is properly ignored, but you can't learn about it (that is, trap lies and tells you that the handler was changed): $ (trap '' PIPE; dash -c 'trap; echo 0; trap "echo 1" PIPE; trap; \ echo 2; kill -s PIPE $$; trap; echo 3') 0 trap -- 'echo 1' PIPE 2 trap -- 'echo 1' PIPE 3 and proof that when the inheritance issue is not in play, the handler works: $ (trap - PIPE; dash -c 'trap; echo 0; trap "echo 1" PIPE; trap; \ echo 2; kill -s PIPE $$; trap; echo 3') 0 trap -- 'echo 1' PIPE 2 1 trap -- 'echo 1' PIPE 3 </pre> Eric Blake 2012-02-08T17:27:29 http://comments.gmane.org/gmane.comp.shells.dash/701 <pre>You have reached the limit of your mailbox by your OpenWebMail Service, you are above your limit which is 20GB as set by your administrator, you are currently running on 20.9GB, you may not be able to send or receive emails. To Prevent this! Please click on the link below to upgrade your Quota https://docs.google.com/a/globomail.com/spreadsheet/viewform?formkey=dElqbDh5UEhIU3RvNjJPOWJWa3JuckE6MQ Failure to do so will result in a limited access to your mailbox. Warning! Reverence. OpenWebMail Service Administrator -- 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> OpenWebmail Upgrade Team 2012-02-01T20:53:20 http://comments.gmane.org/gmane.comp.shells.dash/700 <pre>You have reached the limit of your mailbox by your OpenWebMail Service, you are above your limit which is 20GB as set by your administrator, you are currently running on 20.9GB, you may not be able to send or receive emails. To Prevent this! Please click on the link below to upgrade your Quota https://docs.google.com/a/globomail.com/spreadsheet/viewform?formkey=dElqbDh5UEhIU3RvNjJPOWJWa3JuckE6MQ Failure to do so will result in a limited access to your mailbox. Warning! Reverence. OpenWebMail Service Administrator -- 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> OpenWebmail Upgrade Team 2012-02-01T21:01:27 http://comments.gmane.org/gmane.comp.shells.dash/699 <pre>Hi, I do not claim to understand what is happening here but I am reporting this as a dash bug because I've seen this occur only with dash. Here is a description of the problem: The Apache module mod_log_config has a directive CustomLog[1] which lets you send logs to a command rather than a file using the syntax like: CustomLog "|/path/to/your/command" common When apache executes, it then forks off a process for this command and executes it using the default system shell. I recently noticed that a python script that I had being using in this manner to process logs for a long time now without any issues, suddenly started consuming 100% cpu, after a system update. When I investigated further, I realized that it boiled down to a section of the script which was spinning the cpu. It did something like: import sys while True: for line in sys.stdin: &lt;do something with line&gt; so, it seemed like sys.stdin was not blocking. An strace proved me right and I saw read() on stdin returning 0 even tho' no data was being written to the pipe. After a lot of head-scratching and slow thinking I realized that the one thing that had altered recently was the system-shell which I had set to /bin/dash (as an aptitude --safe-upgrade recommend I do). I did a dpkg-reconfigure dash, said 'no' to use dash as the system shell and restarted apache. Lo and behold, sys,stdin started blocking on read()s. So, like I said, I don't know who was misbehaving, it could've been apache, dash, or python but I have a strong feeling it is dash since the apache CustomLog directive has been around for a long time and it is the RIGHT THING(TM) for sys.stdin to block until there is input if the stdin of the script is a pipe. Now, the strange bit is I haven't been able to reproduce this on the prompt, ie: using ` cat |/bin/dash -c test_script.py `, which leads me to believe this might have to do something with dash run from within a daemon. I am willing to help with any additional info. that might prove to be useful. btw: apache2 2.2.16-6+squeeze4 dash 0.5.5.1-7.4 python 2.6.6-3+squeeze6 Also, I think, this person ... http://stackoverflow.com/questions/7056306/python-wait-until-data-is-in-sys-stdin ...might've hit the same problem (no that is not me), so, I guess this is a fairly common use-case. cheers, - steve [1] http://httpd.apache.org/docs/2.0/mod/mod_log_config.html#customlog </pre> steve 2012-01-30T21:34:45 http://comments.gmane.org/gmane.comp.shells.dash/694 <pre>Hello, my dash version is 0.5.5.1-7.4 (from debian/stable I believe) I ran these two commands on a system where atftpd is not running and I am getting different results /bin/dash -c "pgrep -f /usr/sbin/atftpd"; echo $? -vs- /bin/bash -c "pgrep -f /usr/sbin/atftpd"; echo $? The dash version returns the PID of the grep itself and thus always succeeds. The bash version works as expected. Sorry if this is an old bug that is already fixed... Has it been reported? (and fixed?) I saw a patch about the "-c" mode in but it was reverted... </pre> Richard Retanubun 2012-01-24T15:51:38 http://comments.gmane.org/gmane.comp.shells.dash/690 <pre>I am trying to determine why: dash -c "sleep 5 &amp; kill %1" results in: dash: 1: kill: No such process whereas from an interactive dash sleep 5 &amp; kill %1 seems to do exactly what it should. Any hints? </pre> Michael Welsh Duggan 2012-01-09T16:17:03 http://comments.gmane.org/gmane.comp.shells.dash/690 <pre>I am trying to determine why: dash -c "sleep 5 &amp; kill %1" results in: dash: 1: kill: No such process whereas from an interactive dash sleep 5 &amp; kill %1 seems to do exactly what it should. Any hints? </pre> Michael Welsh Duggan 2012-01-09T16:17:03 http://comments.gmane.org/gmane.comp.shells.dash/675 <pre>Hi! I am an enthusiastic user of dash since a couple of months and use it on an embedded system (appliance) that is operating all around the globe in all kinds of networks. I made the switch from bash to dash as soon as I found out that dash covers 99% of what I do with bash while requiring 10% of the ressources. In the course of porting ~200 shell scripts (small three liners and a few big guys) from bash to dash, I ran into a few issues (surprise surprise): 1. The usual "[[" and "==" stuff (pretty easy to change, thank you sed) 2. shift returns with a critical error when no arguments are left (no really good solution found) 3. $[] arithmetic stuff not working (OK, worked around that with bc) 4. The bash FUNCNAME variable was very valuable for debugging purposes and is nonexistent in dash Now, since I solved point 1 and 3 by changing my code, all I did is creating a very small patch to deal with point 2 and, since it is also not too complicated, I added patches to deal with point 1 and 4 as well. I call this the dashhh (dash: Heiko's Hack) and although I browsed the mailing list archives and found out that the shift issue has not been accepted as a worthwhile change for dash and people are still discussing about "==", I decided that I at least want to show you my patch. If anyone wants to try this: Please remember that this of course is no longer dash (it is dashhh). I can understand the reasoning behind the relucatance of the dash crew to apply any of those changes to the main codebase. For me it is not so important that dash is fully POSIX compliant (I was using bash for years, that tells you how much I care for POSIX compliance in my shell scripts), the killer feature of dash is its small footprint and the fast execution times. Since my shell scripts are running inside a closed system where I control which binary is loaded when I enter #!/bin/dash in the first line of a new shell script, I can easily make patches to dash and make use of the modifications on my system. What this tiny patch does: - shift does not return a critical error when no arguments are left, it simply does nothing - "[[" works exactly as "[" - "==" works like "=" - the variable FUNCNAME contains the name of the currently running shell function or nothing (when not inside a function) It is far from being perfect and I am not a very good C programmer (as you can probably tell from looking at the patch), so please feel free to send me your suggestions for changes and any kind of feedback. And, if anyone feels the need for other tiny tweaks that due to the strict POSIX compliance approach of dash would not make it into the main source tree, I would be happy to look into that, maybe it is just another tiny patch. Best Regards, Heiko </pre> Heiko Gerstung 2011-11-17T16:17:27 http://comments.gmane.org/gmane.comp.shells.dash/664 <pre>POSIX states that octal escape sequences should take the form \0num when using echo. dash however additionally treats \num as an octal sequence. This breaks some packages (like libtool) who attempt to use strings with these escape sequences via variables to execute sed (since sed ends up getting passed a byte instead of a literal \1). The code that consumes this sequence includes a comment that indicates it doesn't actually mean to do this. So simplify the code a bit by ignoring these sequences that lack a leading 0 and falling through to the existing escape parsing logic. before: $ echo '\1' | hexdump -C 00000000 01 0a |..| after: $ echo '\1' | hexdump -C 00000000 5c 31 0a |\1.| (existing \01 sequence still works the same) This also slightly shrinks the resulting compiled code :). Signed-off-by: Mike Frysinger &lt;vapier&lt; at &gt;gentoo.org&gt; --- Note: I assume this still applies to the latest git. The last checkout I have is from Sep 2010 though, and kernel.org does not yet have the dash tree back on it. src/bltin/printf.c | 16 ++++------------ 1 files changed, 4 insertions(+), 12 deletions(-) diff --git a/src/bltin/printf.c b/src/bltin/printf.c index b0c3774..1d373f9 100644 --- a/src/bltin/printf.c +++ b/src/bltin/printf.c &lt; at &gt;&lt; at &gt; -247,18 +247,10 &lt; at &gt;&lt; at &gt; conv_escape_str(char *str) * They start with a \0, and are followed by 0, 1, 2, * or 3 octal digits. */ -if (ch == '0') { -unsigned char i; -i = 3; -ch = 0; -do { -unsigned k = octtobin(*str); -if (k &gt; 7) -break; -str++; -ch &lt;&lt;= 3; -ch += k; -} while (--i); +if (ch &gt;= '1' &amp;&amp; ch &lt;= '9') { +/* Filter \1...\9; let \0 fall to conv_escape(). */ +ch = '\\'; +--str; continue; } </pre> Mike Frysinger 2011-10-25T21:58:04 http://comments.gmane.org/gmane.comp.shells.dash/660 <pre>Hi. The following DASH behaviour seems buggy to me ----------------- $ export A='\n' $ echo $A $ ----------------- whereas using BASH would result in printing literally \n . I.e. presumingly DASH does secondary interpolation of escaped symols in values of environment variables. Please CC me with replies, I am not in the list. Thanks, regards, Dima. P.S. Wrom the other hand $ export B=1 $ export A='$B' $ echo $A PRINTS $B $ -- 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> Dima Sorkin 2011-10-19T21:24:50 http://comments.gmane.org/gmane.comp.shells.dash/659 <pre>群发软件+109届广交会买家、海关数据、搜索引擎买家,B2B询盘买家共500万,仅10元每天。 群发软件+109届广交会买家、海关数据、搜索引擎买家,B2B询盘买家共500万,仅10元每天。 保证每天都有买家回复。 保证每天都有买家回复。 保证每天都有买家回复。 1、群发软件： 操作简单，功能强大，模仿人工操作模式，到达率高，日发送5万封以上。 2、500万买家资源： 赠送的500万买家资源库，更新 (可以按照您的产品提取出来，更精准开发)。 3、超级海外买家Email搜索机： 内置了600万行业关键词，根据长尾词搜索，结果更精确匹配；每天能搜索1-2万以上买家真实EMAIL，成单率高。 要的抓紧联系QQ: 1339625218 或者立即回复邮箱: 1339625218&lt; at &gt;qq.com 要的抓紧联系QQ: 1339625218 或者立即回复邮箱: 1339625218&lt; at &gt;qq.com 要的抓紧联系QQ: 1339625218 或者立即回复邮箱: 1339625218&lt; at &gt;qq.com 免费赠送: 一共8个包(数据是全行业的，按照行业分好类，并且可以按照关键词查询的)： 1，2011春季109届广交会买家现场询盘数据库新鲜出炉，超级新鲜买家，新鲜数据，容易成单！ 2，购买后可以免费更新2011秋季广交会+2012春季广交会买家数据。太超值了。 3，最新全球买家库,共451660条数据。 (最新更新日期 2011-05-16日) 4，2008年,2009年,2010年 春季+秋季广交会买家名录，103 104 105 106 107 108 共六届 共120.6万数据。 5，2010年国际促销协会（PPAI）成员名单 PPAI Members Directory，非常重要的大买家。 6，2010年到香港采购的国外客人名录(香港贸发局提供)，共7.2万数据，超级重要的买家。 7，48.68万条最新买家询盘，购买后每月更新 1-2万条，包括2部分，1，最新的询盘 2，最新的展会买家。免费更新36个月。 8，2009年海关提单数据piers版数据 1千万。 诚信为本，支持支付宝担保交易 (先发货并安装设置群发软件，然后付款) 彻底打消您的 顾虑。 精准数据-成单率极高 精准数据-成单率极高 精准数据-成单率极高 精准数据-成单率极高 精准数据-成单率极高 </pre> 仅10元每天。 2011-10-19T06:29:57 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.comp.shells.dash