"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
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:
> 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 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:
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 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
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
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.
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
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 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
> 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 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
13 matches
Mail list logo
