On Wednesday, January 30, 2013 11:35:55 AM Chet Ramey wrote:
> On 1/30/13 2:47 AM, Dan Douglas wrote:
>
> > No, $* always expands to a single word. If multiple words result, those
> > are
> > the result of field-splitting, not an intrinsic multi-word expansion as in
> > the
> > case of $@. Thoug
> a simple patch to workaround/fix the issue by Yuta SATOH:
> --- bash-4.2/redir.c
> +++ bash-4.2/redir.c
> @@ -632,7 +632,9 @@
> }
>else
> {
> - fd = open (filename, flags, mode);
> + do {
> + fd = open (filename, flags, mode);
> + } while ((fd < 0) && (errno == EI
On 1/30/13 2:47 AM, Dan Douglas wrote:
> No, $* always expands to a single word. If multiple words result, those are
> the result of field-splitting, not an intrinsic multi-word expansion as in
> the
> case of $@. Though POSIX says very little about the unquoted cases.
I haven't looked at the
On 1/30/13 12:16 AM, Dan Douglas wrote:
>>> 3. Another IFS oddity via "command"
>>>
>>> IFS can be given "two values at once" through the environment of a
>>> redirection.
>>
>> I have to look at this one. It's clear that the temporary environment
>> given to `command' is like the temp environm
On 1/30/13 4:15 AM, Pádraig Brady wrote:
> Happens on x86_64 with 4.2.10(1) and 4.2.42(2) at least
>
> The following (done in a subshell to avoid killing the current shell)
> demonstrates it:
>
> $ ($((-2**63/-1)))
> Floating point exception (core dumped)
Thanks for the report. This was fixed s
Happens on x86_64 with 4.2.10(1) and 4.2.42(2) at least
The following (done in a subshell to avoid killing the current shell)
demonstrates it:
$ ($((-2**63/-1)))
Floating point exception (core dumped)
thanks,
Pádraig.
Information transmitted by this e-mail is proprietary to MphasiS, its
associated companies and/ or its customers and is intended
for use only by the individual or entity to which it is addressed, and may
contain information that is privileged, confidential or
exempt from disclosure under ap
On 18 January 2013 13:55, Chet Ramey wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 1/18/13 1:30 AM, Mike Frysinger wrote:
>> this is somewhat a continuation of this thread:
>> http://lists.gnu.org/archive/html/bug-bash/2008-10/msg00091.html
>>
>> i've gotten more or less the same
On 01/30/2013 10:06 AM, Roman Rakus wrote:
There is similar problem with ioctl() syscall in read.
Consider following script:
#!/bin/bash
( while :; do kill -CHLD $$ 2>&- || break; done ) &
while :; do
read -p 1 -t 0.01 -d ' '
done
On my Fedora it is reporting many
/tmp/test.sh: line 4:
On 01/29/2013 10:59 PM, Chet Ramey wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 1/18/13 1:30 AM, Mike Frysinger wrote:
this is somewhat a continuation of this thread:
http://lists.gnu.org/archive/html/bug-bash/2008-10/msg00091.html
i've gotten more or less the same report in Gentoo:
"Chris F.A. Johnson" writes:
> On Wed, 30 Jan 2013, Andreas Schwab wrote:
>
>> "Chris F.A. Johnson" writes:
>>
var=${a[*]} ... one two three four # bad
>>>
>>>Looks good to me. It expands to multiple words, just as an unquoted
>>>$* would do.
>>
>> But no field splitting is p
On Wed, 30 Jan 2013, Andreas Schwab wrote:
"Chris F.A. Johnson" writes:
var=${a[*]} ... one two three four # bad
Looks good to me. It expands to multiple words, just as an unquoted
$* would do.
But no field splitting is performed on the expansion, so why are the
colons lost?
"Chris F.A. Johnson" writes:
>> var=${a[*]} ... one two three four # bad
>
>Looks good to me. It expands to multiple words, just as an unquoted
>$* would do.
But no field splitting is performed on the expansion, so why are the
colons lost?
Andreas.
--
Andreas Schwab, sch...@lin
13 matches
Mail list logo
