On Wed, 13 Jan 2016, Chet Ramey wrote:
> On 1/13/16 4:08 AM, Andreas Schwab wrote:
> > Martin Kealey writes:
> >
> >> What do other shells do? Ksh? Dash? Zsh?
> >
> > $ ksh -c 'printf "foo1\nfoo2\n" | { (read x; echo 1: $x) & (read x; echo 2:
> > $x) & }'
> > 1: foo1
> > 2: foo2
>
> I changed bas
On 1/13/16 4:08 AM, Andreas Schwab wrote:
> Martin Kealey writes:
>
>> What do other shells do? Ksh? Dash? Zsh?
>
> $ ksh -c 'printf "foo1\nfoo2\n" | { (read x; echo 1: $x) & (read x; echo 2:
> $x) & }'
> 1: foo1
> 2: foo2
I changed bash to behave like this, which I think is the most reasonabl
On 1/12/16 7:20 PM, Martin Kealey wrote:
>
>
> On Mon, 11 Jan 2016, Chet Ramey wrote:
>> "The standard input for an asynchronous list, before any explicit
>> redirections are performed, shall be considered to be assigned to a file
>> that has the same properties as /dev/null."
>
> I thought the
On Wed, 13 Jan 2016, Andreas Schwab wrote:
> What does "take them as read" mean?
Taking something as read means that the author thought we would understand
it without them actually writing it down.
Or more prosaically, it means to pretend that they're written there, even
though they're not, becau
Martin Kealey writes:
> On 13 Jan 2016 8:14 p.m., "Andreas Schwab" wrote:
>
>> I don't think so.
>>
> http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_07
>> doesn't mention pipelines.
>
> That was rather my point. Given that they aren't mentioned, one has to take
>
On 13 Jan 2016 8:14 p.m., "Andreas Schwab" wrote:
> I don't think so.
>
http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_07
> doesn't mention pipelines.
That was rather my point. Given that they aren't mentioned, one has to take
them as read, otherwise even ( ( foo
Martin Kealey writes:
> The standard is actually a bit vague; under "Compound Commands" it mentions
> that "Each redirection will apply to all the commands within the compound
> command that do not explicitly override that redirection" but it fails to
> mention that this applies to pipes as well;
Martin Kealey writes:
> What do other shells do? Ksh? Dash? Zsh?
$ ksh -c 'printf "foo1\nfoo2\n" | { (read x; echo 1: $x) & (read x; echo 2: $x)
& }'
1: foo1
2: foo2
$ dash -c 'printf "foo1\nfoo2\n" | { (read x; echo 1: $x) & (read x; echo 2:
$x) & }'
1:
2:
$ zsh -c 'printf "foo1\nfoo2\n" | {
On Mon, 11 Jan 2016, Chet Ramey wrote:
> "The standard input for an asynchronous list, before any explicit
> redirections are performed, shall be considered to be assigned to a file
> that has the same properties as /dev/null."
I thought the (only) point of that to avoid a background job reading
On 1/10/16 2:23 AM, Martin D Kealey wrote:
> Bash Version: 4.3
> Patch Level: 11
> Release Status: release
>
> Description:
> The first backgrounded element within a pipeline component has its
> stdin redirected to /dev/null; this does not apply to the second and
> subsequent ba
Surely a pipe counts as an explicit redirection?
And even if it didn't, the inconsistency between the first and subsequent
asynchronous elements is confusing.
On 12 Jan 2016 02:41, "Chet Ramey" wrote:
> On 1/10/16 12:54 PM, Piotr Grzybowski wrote:
> > hey,
> >
> > I am quite sure it happens her
On 1/11/16 3:37 PM, Chet Ramey wrote:
> On 1/11/16 3:29 PM, Martin Kealey wrote:
>> Surely a pipe counts as an explicit redirection?
>
> It doesn't.
I should be clear that this is according to what the standard says. The
existing code attempts to inhibit this implicit redirection in the
presence
On 1/11/16 3:29 PM, Martin Kealey wrote:
> Surely a pipe counts as an explicit redirection?
It doesn't.
> And even if it didn't, the inconsistency between the first and subsequent
> asynchronous elements is confusing.
Agreed.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
On 1/11/16 11:37 AM, Andreas Schwab wrote:
> Chet Ramey writes:
>
>> On 1/10/16 12:54 PM, Piotr Grzybowski wrote:
>>> hey,
>>>
>>> I am quite sure it happens here (devel branch, at
>>> 6f82653c5ef09aeeeba4376a1c65ce86c3605c00):
>>>
>>> execute_cmd.c +5115:
>>>if ((cmdflags & CMD_STDIN_REDIR)
Chet Ramey writes:
> On 1/10/16 12:54 PM, Piotr Grzybowski wrote:
>> hey,
>>
>> I am quite sure it happens here (devel branch, at
>> 6f82653c5ef09aeeeba4376a1c65ce86c3605c00):
>>
>> execute_cmd.c +5115:
>>if ((cmdflags & CMD_STDIN_REDIR) &&
>> pipe_in == NO_PIPE &&
>> (stdin_redirects
On 1/10/16 12:54 PM, Piotr Grzybowski wrote:
> hey,
>
> I am quite sure it happens here (devel branch, at
> 6f82653c5ef09aeeeba4376a1c65ce86c3605c00):
>
> execute_cmd.c +5115:
>if ((cmdflags & CMD_STDIN_REDIR) &&
> pipe_in == NO_PIPE &&
> (stdin_redirects (redirects) == 0))
> async_
hey,
I am quite sure it happens here (devel branch, at
6f82653c5ef09aeeeba4376a1c65ce86c3605c00):
execute_cmd.c +5115:
if ((cmdflags & CMD_STDIN_REDIR) &&
pipe_in == NO_PIPE &&
(stdin_redirects (redirects) == 0))
async_redirect_stdin ();
but after reading the comments some 3.5k lin
Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64'
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-pc-linux-gnu'
-DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKAG
18 matches
Mail list logo
