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" | {
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;
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:
> 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
>
Hello,
The ‘READ_SAMPLE_BUF’ macro in execute_cmd.c reads at most 80 bytes from
the hash-bang line. This is less than the already-small 128-byte limit
in the Linux kernel¹ and can quite easily be hit².
What about changing it to 128 bytes (as well as the ‘sample’ array) to
at least match Linux?
On Wed, Jan 13, 2016 at 11:25:03AM +0100, Ludovic Courtès wrote:
> Hello,
>
> The ???READ_SAMPLE_BUF??? macro in execute_cmd.c reads at most 80 bytes from
> the hash-bang line. This is less than the already-small 128-byte limit
> in the Linux kernel¹ and can quite easily be hit².
That's actually
Greg Wooledge skribis:
> On Wed, Jan 13, 2016 at 11:25:03AM +0100, Ludovic Courtès wrote:
>> Hello,
>>
>> The ???READ_SAMPLE_BUF??? macro in execute_cmd.c reads at most 80 bytes from
>> the hash-bang line. This is less than the already-small 128-byte limit
>> in the Linux kernel¹ and can quite
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
On Wed, Jan 13, 2016 at 02:52:08PM +0100, Ludovic Courtès wrote:
> Sure, but the fact that it???s smaller than that of the kernel Linux is
> problematic: when a hash-bang line > 127 chars is encountered, ???execve???
> fails with ENOENT, so Bash???s fallback code is executed, fails as well,
> but i
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 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 2:52 PM, Linda Walsh wrote:
>
>
> Chet Ramey wrote:
>> No. The shell doesn't perform any word expansions on the `name' when
>> executing a function definition command. Since the documentation doesn't
>> say it performs any expansions, why would you assume it does?
>>
> Because it
On 1/12/16 4:33 PM, Linda Walsh wrote:
>
>
> Greg Wooledge wrote:
>> On Tue, Jan 12, 2016 at 11:52:47AM -0800, Linda Walsh wrote:
>>
>>> Also, from a documentation standpoint, not all behaviors are documented
>>> in the manpage, like:
>>>
>>> echo $[1+2]
>>>
>>> as far as I can tell, isn't docu
On 1/13/16 5:25 AM, Ludovic Courtès wrote:
> Hello,
>
> The ‘READ_SAMPLE_BUF’ macro in execute_cmd.c reads at most 80 bytes from
> the hash-bang line. This is less than the already-small 128-byte limit
> in the Linux kernel¹ and can quite easily be hit².
That limit is huge compared to other Unix
On 1/13/16 8:52 AM, Ludovic Courtès wrote:
> Greg Wooledge skribis:
>
>> On Wed, Jan 13, 2016 at 11:25:03AM +0100, Ludovic Courtès wrote:
>>> Hello,
>>>
>>> The ???READ_SAMPLE_BUF??? macro in execute_cmd.c reads at most 80 bytes from
>>> the hash-bang line. This is less than the already-small 12
On 1/13/16 9:04 AM, Greg Wooledge wrote:
> On Wed, Jan 13, 2016 at 02:52:08PM +0100, Ludovic Courtès wrote:
>> Sure, but the fact that it???s smaller than that of the kernel Linux is
>> problematic: when a hash-bang line > 127 chars is encountered, ???execve???
>> fails with ENOENT, so Bash???s fal
On Wed, Jan 13, 2016 at 11:23:34AM -0500, Chet Ramey wrote:
> On 1/13/16 9:04 AM, Greg Wooledge wrote:
> > On Wed, Jan 13, 2016 at 02:52:08PM +0100, Ludovic Courtès wrote:
> >> Sure, but the fact that it???s smaller than that of the kernel Linux is
> >> problematic: when a hash-bang line > 127 char
Chet Ramey wrote:
On 1/12/16 4:33 PM, Linda Walsh wrote:
---
But why? It's less noisy than any alternative.
It's not as if I can type echo $(1+2) and expect it to work.
Because it only ever appeared in a Posix draft standard, and there's no
reason not to use the standard syntax.
Chet Ramey skribis:
> On 1/13/16 8:52 AM, Ludovic Courtès wrote:
>> Greg Wooledge skribis:
>>
>>> On Wed, Jan 13, 2016 at 11:25:03AM +0100, Ludovic Courtès wrote:
Hello,
The ???READ_SAMPLE_BUF??? macro in execute_cmd.c reads at most 80 bytes
from
the hash-bang line. T
On 1/13/16 1:25 PM, Alastair Hughes wrote:
> Thanks! Is this fix available in git yet?
Next push.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
On 1/13/16 12:20 PM, Linda Walsh wrote:
> It doesn't seem very consistent to choose (()) over [] -- why come up with
> a special longer operator for arith eval, when [] was already used for
> arith evaluation in array indexing?
http://pubs.opengroup.org/onlinepubs/9699919799/xrat/V4_xcu_chap02.ht
Thanks! Is this fix available in git yet?
Alastair Hughes
On 1/13/16 12:41 PM, Ludovic Courtès wrote:
>>> but it prints a misleading error message with an even more truncated
>>> hash-bang line.
>>
>> Again, it's only a cosmetic issue. I don't have a problem with increasing
>> the buffer size, but let's not pretend it's anything but that.
>
> Exactly.
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
24 matches
Mail list logo
