gmane.comp.shells.dash

candidatul fara studii

2012-05-24T12:37:09

http://www.altphel.ro/2012/05/dobre-arata-ne-diploma/
 To unsubscribe please send email to unsubscribe< at >cc.psd-prahova.ro
--
To unsubscribe from this list: send the line "unsubscribe dash" in
the body of a message to majordomo< at >vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

candidatul fara studii

2012-05-24T11:23:59

http://www.altphel.ro/2012/05/dobre-arata-ne-diploma/
 To unsubscribe please send email to unsubscribe< at >cc.psd-prahova.ro
--
To unsubscribe from this list: send the line "unsubscribe dash" in
the body of a message to majordomo< at >vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] avoid overflow for very long variable name

Jim Meyering — 2012-05-23T20:37:48

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  0x00000000

Spital nou de pediatrie

2012-05-02T13:14:47

http://www.youtube.com/watch?feature=player_embedded&v=phjGxHn3uKU
 To unsubscribe please send email to unsubscribe< at >cc.psd-prahova.ro
--
To unsubscribe from this list: send the line "unsubscribe dash" in
the body of a message to majordomo< at >vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

- Important Email

mark payneec — 2012-04-30T19:41:23

Good Morning,

we are currently generating top quality leads & 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 & I will forward you our pricing and volumes.

let's jump on quick call & I'll show you how to take your business to
next level & 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< at >vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[BUG] dash doesn't report syntax error when it should on stray "fi"

Stefano Lattarini — 2012-04-23T16:53:27

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&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< at >vger.kernel.org
More majordomo info at  http://vger.kernel.org/majord

wait and ctrl+Z

Marc Glisse — 2012-04-20T11:31:39

Hello,

I noticed a strange behavior of "wait" when I suspend and resume a script.

$ cat a.sh
#!/bin/dash
(sleep 7; echo blah) &
(sleep 7; echo bloh) &
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 "&&" and do the same suspend+resume, 
"coucou" is never printed.

I am using dash version 0.5.7-3 in debian testing.

local var=$(cat) only reads one line

Jim Pryor — 2012-04-08T22:09:06

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 <%s>\n" "$IN"
}

test2() {
    local IN="$(cat)"
    printf "test2 <%s>\n" "$IN"
}

test3() {
    IN=$(cat)
    printf "test3 <%s>\n" "$IN"
}

test4() {
    IN=$(cat)
    printf "test4 <%s>\n" "$IN"
}

MSG=$(printf "abc\ndef\nghi")

printf "%s" "$MS

8k9l0O

Xlpt — 2012-03-25T11:04:23

i8k9n0O1Q1SgUhVj9l9n0O1Q1SgUhVj9l0N0P1RfThUi8k9m0O0PfTgUi8k9ThVj8l9m0O0P1RfTgUi8k9m9N0P1RfTgUi8k9m0N0P1RfTgUhVj9m0hUi8l9n0O1Q1SgUhVj9l9n0O1Q1SgUhVj9l9n0O1Q1SgUhVj9l9n0P1RfThSfTh8k9m9N0P1RfSfSgUhVj9l9n0O0P1RfSfSgUiVj8k9m0O0Q1Q1Vj9l9N0P1RfTgUi8k9m0N0P1RfTgUi8k9m0N0P1RfThUi8k9m0N0P1RiWk9m0O0Q1RfThViWk9l9m0O0P1Q1SfThVj8l9m0O0Q1RfTgUiVj9l9n0N0PVj9l0O0P1RfThVi8k9m0O0P1RfThVj8k9m0O0P1RfThVj8k9m0O0Q1RSgUh8k9m0O0P1RfThUi8k9m0O0P1R1SgUhVj8k9m0O0P1RfTgUhVjQ1SfUi8k9l9N0P1RfSgUi8k9m9N0P1RfSgUi8k9m9N0P1RfTgUi8k9m0P1Q1SgUiWk9l9n0P1Q1SgUiWk9l9m0O0P1RfSgUi8k9l9N1SgUiWj9l9n0P1Q1SgUiWj9l9n0P1Q1SgUiWj9l9n0P1Q1SgUiWk9m0O0QThVj9l9n0O1Q1SgUhVj9l9n0O1Q1SgUhVj9l9n0O1Q1SgUhVj9l9O0SfThVj8l9m0O0Q1SfThVj8l9m0O0Q1SfThVj8l9N0P1RfSgUi8k9m9l9N0Q1SfThVj8l9m0O0Q1SfThVj8l9m0O0Q1SfThVj8l9m0O0Q1SgTh9n0P1RfThVj8k9m0O0Q1RfThVj8k9m0O0Q1RfThVj8k9m0O0Q1RfUiWkO1Q1TgUi8k9m0N0P1RfThUi8k9m0O0P1RfThUi8k9m0O0P1RfThV

-------------------------------------------------------------------------------------------------------------------------------------------

[PATCH] var.c: check for valid variable name before printing in "export -p"

2012-02-14T10:48:48

From: Harald Hoyer <harald< at >redhat.com>

"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
< at >< at > -409,12 +409,15 < at >< at > showvars(const char *prefix, int on, int off)
 for (; ep < epend; ep++) {
 const char *p;
 const char *q;
-
+const char *r;
+r = endofname(*ep);
 p =

bug in handling of ignored traps

Eric Blake — 2012-02-08T17:27:29

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 -- '' SIGPI

OpenWebmail Upgrade!!

OpenWebmail Upgrade Team — 2012-02-01T20:53:20

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< at >vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

OpenWebmail Upgrade!!

OpenWebmail Upgrade Team — 2012-02-01T21:01:27

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< at >vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[BUG] apache CustomLog pipe to a python script with sys.stdin.read() behaves weirdly with dash as system shell

steve — 2012-01-30T21:34:45

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:
        <do something with line>

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

/bin/dash -c != /bin/bash -c with pgrep

Richard Retanubun — 2012-01-24T15:51:38

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...

Question about job control in non-interactive shells

Michael Welsh Duggan — 2012-01-09T16:17:03

I am trying to determine why:

  dash -c "sleep 5 & kill %1"

results in:

  dash: 1: kill: No such process

whereas from an interactive dash

  sleep 5 & kill %1

seems to do exactly what it should.  Any hints?

Question about job control in non-interactive shells

Michael Welsh Duggan — 2012-01-09T16:17:03

I am trying to determine why:

  dash -c "sleep 5 & kill %1"

results in:

  dash: 1: kill: No such process

whereas from an interactive dash

  sleep 5 & kill %1

seems to do exactly what it should.  Any hints?

Dashhh

Heiko Gerstung — 2011-11-17T16:17:27

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

[PATCH] echo: fix octal escaping with \1...\7

Mike Frysinger — 2011-10-25T21:58:04

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 <vapier< at >gentoo.org>
---
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

evaluation of env variables in DASH

Dima Sorkin — 2011-10-19T21:24:50

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< at >vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

群发软件+买家搜索机+最新广交会买家、海关数据,B2B询盘买家500万。

仅10元每天。 — 2011-10-19T06:29:57

群发软件+109届广交会买家、海关数据、搜索引擎买家,B2B询盘买家共500万,仅10元每天。 
群发软件+109届广交会买家、海关数据、搜索引擎买家,B2B询盘买家共500万,仅10元每天。 
保证每天都有买家回复。
保证每天都有买家回复。
保证每天都有买家回复。

1、群发软件： 操作简单，功能强大，模仿人工操作模式，到达率高，日发送5万封以上。 
2、500万买家资源： 赠送的500万买家资源库，更新 (可以按照您的产品提取出来，更精准开发)。 
3、超级海外买家Email搜索机： 内置了600万行业关键词，根据长尾词搜索，结果更精确匹配；每天能搜索1-2万以上买家真实EMAIL，成单率高。 
 

要的抓紧联系QQ: 1339625218   或者立即回复邮箱: 1339625218< at >qq.com
要的抓紧联系QQ: 1339625218   或者立即回复邮箱: 1339625218< at >qq.com
要的抓紧联系QQ: 1339625218   或者立即回复邮箱: 1339625218< at >qq.com