gmane.comp.shells.dash

NALÉHAVÉ UPOZORNĚNÍ!

Daniels Turlajs — 2013-05-16T07:34:09



Vašepoštovní schránka překročilalimit 2GBstanovenýwebmaster, klikněte prosímna odkazznovunastavitschránkuna nový server:  http://www.suemask.com/acc/admin/
Help DeskTeam--
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

Re: Crash on valid input

Harald van Dijk — 2013-04-09T21:20:52

It is not limited to 'set -x'. dash continues reading after the NULL 
value in argv, and usually that will be followed by another NULL if 'set 
-x' is not used, but not necessarily.

$ dash -c 'test ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! 
! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! !'
$ dash -c 'test ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! 
! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! !'
Segmentation fault
$ dash -c 'test ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! 
! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! !'
$

When [ ! ] is used, the ! is necessarily followed by two NULLs (one 
after the ], and one because the ] is replaced by NULL), so the problem 
is hidden.

dash should check whether ! is followed by an argument, like bash does, 
which would give an error message without a segmentation fault for all 
three forms above.

This seems to be easily possible by manually inlining primary() into 
nexpr(),

Re: Crash on valid input

Dan Kegel — 2013-04-09T03:44:27

Yeah, even valgrind doesn't see anything without -x.


On Mon, Apr 8, 2013 at 8:34 PM, Eric Blake <eblake< at >redhat.com> wrote:
--
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

Re: Crash on valid input

Eric Blake — 2013-04-09T03:34:42

If it helps, dash -cx '[ ! ]' does not crash.

Re: Crash on valid input

Eric Blake — 2013-04-09T03:27:28

The 'set -x' was indeed the key to reproducing the problem.  In fact,
this is the shortest I could make it:

dash -cx 'test !'

Re: Crash on valid input

Dan Kegel — 2013-04-09T03:12:31

Yes, my script was crap, I've fixed it.

Here's the reproducer.  Called with foo unset.  I think it doesn't
crash without -x.

#!/bin/dash
set -x
test ! $foo



On Mon, Apr 8, 2013 at 8:08 PM, Eric Blake <eblake< at >redhat.com> wrote:
--
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

Re: Crash on valid input

Eric Blake — 2013-04-09T03:08:16

You know, this is highly reliant on $foo expanding to either nothing (it
is empty, so you are really invoking the one-argument form 'test !'
which is true) or a single shell word (the two-argument form 'test !
nonempty' is false).  But if $foo has embedded whitespace, it expands to
more than one word after word-splitting, and you're hosed ('test ! one
two' can give interesting results, and probably not what you were
expecting).

You might want to fix your script to just use the safer:

! test "$foo"

which works even if $foo has embedded whitespace.  That said, you are
correct that dash should never crash.


and given this part of the stack trace, it looks like you were invoking
'test ! word'?  But I was unable to reproduce a crash when I tried
dash.git, so it would be helpful to know exactly what $foo was in your
reproducer.

Crash on valid input

Dan Kegel — 2013-04-09T02:43:36

If I check for an empty string like this:

+ test ! $foo

dash crashes.  This occurs both in the version shipped with ubuntu
10.04 and 12.04
as well as with dash from git.

Here's the stack:

Program received signal SIGSEGV, Segmentation fault.
__strcmp_sse4_2 () at ../sysdeps/i386/i686/multiarch/strcmp-sse4.S:221
221 ../sysdeps/i386/i686/multiarch/strcmp-sse4.S: No such file or directory.
(gdb) bt
#0  __strcmp_sse4_2 () at ../sysdeps/i386/i686/multiarch/strcmp-sse4.S:221
#1  0x0805938a in getop (s=0x202b <Address 0x202b out of bounds>) at
bltin/test.c:168
#2  0x08059c91 in t_lex (tp=0x806581c) at bltin/test.c:431
#3  0x080595cb in aexpr (n=UNOT) at bltin/test.c:260
#4  0x08059557 in oexpr (n=UNOT) at bltin/test.c:243
#5  0x080594ba in testcmd (argc=1, argv=0x8065814) at bltin/test.c:219
#6  0x0804c526 in evalbltin (cmd=0x805da1c, argc=2, argv=0x8065810,
flags=0) at eval.c:910
#7  0x0804c383 in evalcommand (cmd=0x80657cc, flags=0) at eval.c:850
#8  0x0804b4ab in evaltree (n=0x80657cc, flags=0) at eval.c:280

Offer to Attend Events for AMD

Phillip Williams — 2013-03-29T14:49:55

I would like to know if you would have any interest in covering some
events for us in your area?

There would be NO COST at all for admission, and it would not be
necessary for you to be an experienced reporter.

We are looking for members of the public to cover events such as Music
Concerts, Sporting Events, Restaurant Openings, Movies, Gallery
Openings, Shows, and others.

Since AMD has different pools relevant to experience (beginners up to
experienced working reporters) should you not be familiar with our
company, please take a moment to look into American Media Distribution
with any source you deem trusted.

Here is a link to the AMD BBB page for your convenience.

http://www.bbb.org/new-jersey/business-reviews/news-service/american-media-distribution-in-howell-nj-90096055

There is compensation for the events you would attend and again, there
is no cost for admission to any of the events, and no obligation is
required. 

We will be accepting only a few people from your area so let us know
if you are in

OPTIND

Chris F.A. Johnson — 2013-03-23T01:46:20

   According to both the dash man page and the POSIX spec, "When the
   shell is invoked, OPTIND is initialized to 1."

   However, it actually takes the value of the environment variable
   if it exists:

$ OPTIND=4 dash -c 'echo "$OPTIND"'
4
$ OPTIND=4 bash -c 'echo "$OPTIND"'
1
$ OPTIND=4 ksh -c 'echo "$OPTIND"'
1
$ OPTIND=4 ksh93 -c 'echo "$OPTIND"'
1

[PATCH] [DEBUG] Add newline when tracing in poplocalvars

Peter Rosin — 2013-03-12T13:22:11

Signed-off-by: Peter Rosin <peda< at >lysator.liu.se>
---
 ChangeLog |    4 ++++
 src/var.c |    2 +-
 2 files changed, 5 insertions(+), 1 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index d84d3b7..959dd07 100644
--- a/ChangeLog
+++ b/ChangeLog
< at >< at > -1,3 +1,7 < at >< at >
+2013-03-12  Peter Rosin  <peda< at >lysator.liu.se>
+
+* Add newline when tracing in poplocalvars.
+
 2012-06-09  Christoph Mathys <eraserix< at >gmail.com>
 
 * Add support for ulimit -r.
diff --git a/src/var.c b/src/var.c
index dc90249..c35e925 100644
--- a/src/var.c
+++ b/src/var.c
< at >< at > -547,7 +547,7 < at >< at > poplocalvars(int keep)
 while ((lvp = next) != NULL) {
 next = lvp->next;
 vp = lvp->vp;
-TRACE(("poplocalvar %s", vp ? vp->text : "-"));
+TRACE(("poplocalvar %s\n", vp ? vp->text : "-"));
 if (keep) {
 int bits = VSTRFIXED;

[PATCH] [DEBUG] Do not attempt to output a NULL message

Peter Rosin — 2013-03-10T21:58:38

Prevent future problems, as noone calls exverror with a NULL msg
at this time.

Signed-off-by: Peter Rosin <peda< at >lysator.liu.se>
---
 src/error.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

I stumbled on this when reading the code... Or is msg only ever
NULL when DEBUG is #defined?

Cheers,
Peter

diff --git a/src/error.c b/src/error.c
index 9d31989..5ab69c0 100644
--- a/src/error.c
+++ b/src/error.c
< at >< at > -151,8 +151,8 < at >< at > exverror(int cond, const char *msg, va_list ap)
 TRACE(("\") pid=%d\n", getpid()));
 } else
 TRACE(("exverror(%d, NULL) pid=%d\n", cond, getpid()));
-if (msg)
 #endif
+if (msg)
 exvwarning(-1, msg, ap);
 
 flushall();

From Mrs. Fundiswa Al Jamal(Very urgent).

Mr. Fundiswa Al Jamal. — 2013-02-28T17:12:34

Please open the attached file to read your message.

Parameter substitution bug

Mark Lentczner — 2013-01-21T21:36:07

Strangely I ran across this issue in the real world: A doubly nested
parameter substitution with an inner glob pattern (breath) fails /only
when in double quotes/! That is, these two expressions produce
different results:

${f%${f#?}}   --vs--  "${f%${f#?}}"

Strangely, that is the simplest case I get to fail.

The following script walks through the issue, and if run with bash,
ksh, or busybox exhibits those two expressions as producing the same
result.

- Mark
(Note: Not on mailing list, so please reply all to include me!)

Fwd: bug? Spawned childs always remain in zombie state

Sjon Hortensius — 2013-01-20T12:04:04

Hi. I'm trying to create a script which monitors a directory using
inotify and spawns a background process for all events. However I
found that all childs will remain in zombie state until the script
quits and I am unable to find a proper fix.

A minimal testcase:

#!/bin/dash
while true
do
    sleep 1 &
#    jobs >/dev/null
done

If you open a second terminal you'll see that all the 'sleep'
processes end up being defunct. I have tried playing with `set -ma`
but the only workaround I found is the commented 'jobs' line.
Uncommenting that line will result in expected behavior where childs
are properly reaped. Is this a bug, or is there an alternative
solution I'm missing?

Thanks,
Sjon
--
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

Re: Fwd: variable scope bug in while loop when using pipe

Seb — 2013-01-20T10:22:12

Hello,

It's not a bug, both are POSIX, placing a pipe member in the current
environment instead of in a subshell being an extension:

 Command substitution, commands that are grouped with parentheses, and
 asynchronous lists shall be executed in a subshell environment.
 Additionally, each command of a multi-command pipeline is in a
 subshell environment; as an extension, however, any or all commands
 in a pipeline may be executed in the current environment.

 http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_12

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

Fwd: variable scope bug in while loop when using pipe

z7z8th — 2013-01-20T08:07:20

---------- Forwarded message ----------
From: z7z8th <ybzhao1989< at >gmail.com>
Date: 2013/1/18
Subject: variable scope bug in while loop when using pipe
To: dash< at >vger.kernel.org

$ ls -l /bin/sh
lrwxrwxrwx 1 root root 4 Aug 21 08:11 /bin/sh -> dash*

The script did not work as what I wanted? Do you think it's a bug?

The output looks like below:

I think the last line should be abc=123

If the while loop is not after the pipe, it works as what I wanted.

the variable abc is 123 in the end.

Then I found this article talking about this problem.
http://www.kilala.nl/Sysadmin/index.php?id=741
It says that old bash has this problem.
But I found bash-4.2.37 and dash-0.5.7 has this problem too.

I'm using Debian testing.
Linux 3.2.0-4-amd64 #1 SMP Debian 3.2.35-2 x86_64 GNU/Linux
--
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

FROM MRS,GRACE MANDA; PLEASE OPEN THE ATTACHEMENT FILE AND GET BACK TO ME.

mrs grace manda — 2013-01-19T07:02:50

Re: (another) patch for dash

Jérémie Courrèges-Anglas — 2013-01-10T10:46:09

Hi,

with Aleksey we briefly discussed the mdoc compatibility of the manpage,
here's a patch that makes mandoc 1.12.1 happier and behaves correctly
against groff 1.21.  I want to include it in the staging dash-0.5.7
OpenBSD port.

Regards,

Re: patch for dash

Jérémie Courrèges-Anglas — 2013-01-06T17:37:34


Hi.  I'd like to submit this slightly different patch that uses awk
instead of nl.  This is useful for example on OpenBSD, which doesn't have
nl in the base system.

Regards,

patch for dash

Aleksey Cheusov — 2013-01-06T16:30:54

Hi. The following patch fixes dash build failure on Solaris
where /usr/bin/nl (which is in default PATH) is not POSIX compatible.
POSIX-ly correct version is in /usr/xpg4/bin but I think it's easier
to fix use of nl(1).

   [cheusov< at >pkgsrc-dev]$ /usr/bin/nl -ba -v0 <<< foo
     0  foo
   [cheusov< at >pkgsrc-dev]$ /usr/bin/nl -b a -v 0 <<< foo
   nl: a: No such file or directory
   [cheusov< at >pkgsrc-dev]$ uname -srm
   SunOS 5.11 i86pc
   [cheusov< at >pkgsrc-dev]$


--- src/mkbuiltins.orig2011-03-15 07:18:06.000000000 +0000
+++ src/mkbuiltins
< at >< at > -97,7 +97,7 < at >< at > cat <<\!
  */
 
 !
-sed 's/-[a-z]*//' $temp2 | nl -b a -v 0 | LC_COLLATE=C sort -u -k 3,3 |
+sed 's/-[a-z]*//' $temp2 | nl -ba -v0 | LC_COLLATE=C sort -u -k 3,3 |
 tr abcdefghijklmnopqrstuvwxyz ABCDEFGHIJKLMNOPQRSTUVWXYZ |
 awk '{printf "#define %s (builtincmd + %d)\n", $3, $1}'
 printf '\n#define NUMBUILTINS %d\n' $(wc -l < $temp2)