headers
Michael Welsh Duggan | 9 Jan 2012 17:17
Favicon

Question about job control in non-interactive shells

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?

--

-- 
Michael Welsh Duggan
(mwd <at> cert.org)
--
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
Permalink | Reply | 3 comments |
headers
Jonathan Nieder | 9 Jan 2012 17:37
Picon

Re: Question about job control in non-interactive shells

Hi Michael,

Michael Welsh Duggan wrote:

> I am trying to determine why:
>
>   dash -c "sleep 5 & kill %1"
>
> results in:
>
>   dash: 1: kill: No such process

You are probably looking for the -m option.

Thanks for writing, and hope that helps,
Jonathan
--
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
Permalink | Reply | 2 comments |
headers
Jilles Tjoelker | 13 Jan 2012 16:49
Picon
Favicon

Re: Question about job control in non-interactive shells

On Mon, Jan 09, 2012 at 10:37:45AM -0600, Jonathan Nieder wrote:
> Michael Welsh Duggan wrote:
> > I am trying to determine why:

> >   dash -c "sleep 5 & kill %1"

> > results in:

> >   dash: 1: kill: No such process

> You are probably looking for the -m option.

The cause is that the -m option ("job control") enables running commands
in separate process groups, and dash follows literally what POSIX says
about kill %job: a background process group should be signaled; however,
there is no background process group. Some shells signal one or more
processes they know are part of the job in this case, but dash calls
kill() on a process group that is guaranteed not to exist.

--

-- 
Jilles Tjoelker
--
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
Permalink | Reply | 1 comment |
headers
Herbert Xu | 15 Jan 2012 04:53
Picon
Picon

Re: Question about job control in non-interactive shells

Jilles Tjoelker <jilles <at> stack.nl> wrote:
> On Mon, Jan 09, 2012 at 10:37:45AM -0600, Jonathan Nieder wrote:
>> Michael Welsh Duggan wrote:
>> > I am trying to determine why:
> 
>> >   dash -c "sleep 5 & kill %1"
> 
>> > results in:
> 
>> >   dash: 1: kill: No such process
> 
>> You are probably looking for the -m option.
> 
> The cause is that the -m option ("job control") enables running commands
> in separate process groups, and dash follows literally what POSIX says
> about kill %job: a background process group should be signaled; however,
> there is no background process group. Some shells signal one or more
> processes they know are part of the job in this case, but dash calls
> kill() on a process group that is guaranteed not to exist.

Right.  And you don't even need %1:

	dash -c "sleep 5 & kill $!"

works just fine.

Cheers,
--

-- 
Email: Herbert Xu <herbert <at> gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
(Continue reading)

Permalink | Reply | 0 comments |
headers
Richard Retanubun | 24 Jan 2012 16:51
Favicon

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

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

--

-- 
Richard Retanubun
--
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
Permalink | Reply | 4 comments |
headers
Jonathan Nieder | 24 Jan 2012 20:43
Picon

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

Hi Richard,

Richard Retanubun wrote:

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

As the pgrep(1) manual explains, the running pgrep or pkill process
will never report itself as a match.  However, when running pgrep
through dash, it reports the process id of the shell executing pgrep,
while the bash version and recent dash versions optimize "sh -c
'single command'" to

	sh -c 'exec pgrep -f /usr/sbin/atftpd'

so there is no shell process left to report.

If that "exec" is specified explicitly, the result is the same in both
shells.

Hope that helps,
Jonathan
--
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
(Continue reading)

Permalink | Reply | 3 comments |
headers
Richard Retanubun | 24 Jan 2012 21:17
Favicon

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

On 24/01/12 02:43 PM, Jonathan Nieder wrote:
> Hi Richard,
>
> Richard Retanubun wrote:
>
>> /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.
>
> As the pgrep(1) manual explains, the running pgrep or pkill process
> will never report itself as a match.  However, when running pgrep
> through dash, it reports the process id of the shell executing pgrep,
> while the bash version and recent dash versions optimize "sh -c
> 'single command'" to
>
> 	sh -c 'exec pgrep -f /usr/sbin/atftpd'
>
> so there is no shell process left to report.
>
> If that "exec" is specified explicitly, the result is the same in both
> shells.
>
> Hope that helps,
> Jonathan
It sure does, thanks a lot Jonathan.

As an addendum, I find using "pgrep -x atftpd" in this case also yields the
(Continue reading)

Permalink | Reply | 2 comments |
headers
Richard Retanubun | 24 Jan 2012 21:53
Favicon

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

On 24/01/12 03:17 PM, Richard Retanubun wrote:
> On 24/01/12 02:43 PM, Jonathan Nieder wrote:
>> Hi Richard,
>>
>> Richard Retanubun wrote:
>>
>>> /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.
>>
>> As the pgrep(1) manual explains, the running pgrep or pkill process
>> will never report itself as a match.  However, when running pgrep
>> through dash, it reports the process id of the shell executing pgrep,
>> while the bash version and recent dash versions optimize "sh -c
>> 'single command'" to
>>
>> 	sh -c 'exec pgrep -f /usr/sbin/atftpd'
>>
>> so there is no shell process left to report.
>>
>> If that "exec" is specified explicitly, the result is the same in both
>> shells.
>>
>> Hope that helps,
>> Jonathan
> It sure does, thanks a lot Jonathan.
>
(Continue reading)

Permalink | Reply | 1 comment |
headers
Jonathan Nieder | 24 Jan 2012 22:03
Picon

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

Richard Retanubun wrote:

> Sorry, one more question to clarify, which "recent dash versions"
> have the optimization?

Upstream versions, or you can grab Debian packaging from the
proposed-experimental branch at [1].

Cheers,
Jonathan

[1] git://repo.or.cz/dash/debian/jrn.git
--
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
Permalink | Reply | 0 comments |
headers
steve | 30 Jan 2012 22:34
Gravatar

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

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 data was being written to the pipe.

After a lot of head-scratching and slow thinking I realized that the one thing
(Continue reading)

Permalink | Reply | 0 comments |

Gmane