Maarten Billemont wrote:
This mail has gone slightly off-topic. Hit mark as read if you don't
care for that sort of thing.
I don't care if you like evil in your sexual play or in your vendettas.
When you write code, evil is nothing worth liking. In programming,
evil is defined as so
This mail has gone slightly off-topic. Hit mark as read if you don't care for
that sort of thing.
On 27 Apr 2012, at 21:02, Linda Walsh wrote:
> Greg Wooledge wrote:
>
>> NEVER use eval plus a brace expansion to generate a list. That's just
>> freakin' evil. And unsafe:
>
> But I _like_ evi
Greg Wooledge wrote:
NEVER use eval plus a brace expansion to generate a list. That's just
freakin' evil. And unsafe:
===
But I _like_ evil sometimes! >:->
imadev:~$ a=(lib tmp bin share '`date`')
imadev:~$ (export IFS=,;eval "echo /usr/{${a[*]}}")
/usr/lib /usr/tmp /usr/bin /usr/shar
On Thu, Apr 26, 2012 at 08:47:39PM -0700, Linda Walsh wrote:
> Obviously, they were not complete beginners to bash -- to be
> reading
> arrays in from vars holding multi-line text? I would assume they'd have
> the
> intelligence to know when to use * or @ and I wouldn't have to talk down to
>
On Thursday 26 April 2012 23:47:39 Linda Walsh wrote:
> Anything else you wanna tell me NEVER/ALWAYS to do?
try ALWAYS being polite. but i guess that'll NEVER happen.
oh well, thankfully kmail can auto-mute based on sender.
-mike
signature.asc
Description: This is a digitally signed message pa
Maarten Billemont wrote:
On 26 Apr 2012, at 01:18, Linda Walsh wrote:
Ishtar:> echo "${b[*]}"
Please note that expanding array elements using [*] is usually NOT what anyone
wants.
---
It was exactly what I wanted for my example to work. Please don't suggest
non-working solutions to th
On Thu, Apr 26, 2012 at 2:16 PM, Greg Wooledge wrote:
> If the goal is to see the contents of an array, I'd use one of these,
> depending on how much detail I need:
>
> printf '<%s> ' "${array[@]}"; echo
>
> declare -p array
>
Or i'd use the args function Greg has shown before:
args() { printf
On Thu, Apr 26, 2012 at 05:54:27PM +0200, Maarten Billemont wrote:
> On 26 Apr 2012, at 01:18, Linda Walsh wrote:
> >
> > Ishtar:> echo "${b[*]}"
>
> You should always recommend the "${b[@]}" variant. "${b[*]}" is rarely
> useful in the event that your intent is to merge the array into a single
On 26 Apr 2012, at 01:18, Linda Walsh wrote:
>
> Ishtar:> echo "${b[*]}"
Please note that expanding array elements using [*] is usually NOT what anyone
wants. Be careful about recommending it to anyone.
"${b[*]}" # This throws away any usefulness of the array by merging all the
array elements
Ted Okuzumi wrote:
I am writing this e-mai to report to report a bug in bash
Description:
Cannot redirect into an array from multiline variable
Does not work:
echo "$mydata" | while read line; do myarray+=( "$line" ); done
Have you tried this?
Ishtar:> a='this
is
a
tes
Thank you for that detailed information. I really appreciate the 2
workarounds you provided.
I can confirm by adding in this line to my script:
shopt -s lastpipe
fixes the problem, confirming that it was indeed a subshell issue.
Best regards,
Ted
On Wed, Apr 25, 2012 at 10:50 AM, DJ Mills wr
On Wed, Apr 25, 2012 at 04:05:15PM -0400, Chet Ramey wrote:
> OK. Now make the call move_to_high_fd(0, 1, -1) and see if that fixes it.
cyclops:/var/tmp/bash/bash-4.2$ ./bash ~/foo
cyclops:/var/tmp/bash/bash-4.2$ ./bash -c 'shopt -s lastpipe; echo hi | read
f
On 4/25/12 3:09 PM, Greg Wooledge wrote:
> On Wed, Apr 25, 2012 at 02:54:07PM -0400, Chet Ramey wrote:
>> On 4/25/12 2:04 PM, Greg Wooledge wrote:
>>
>>> Maybe it only works on boxes with a very large "open files" resource
>>> limit. Perhaps the hard-coded 255 should be replaced with something
>>>
On Wed, Apr 25, 2012 at 02:54:07PM -0400, Chet Ramey wrote:
> On 4/25/12 2:04 PM, Greg Wooledge wrote:
>
> > Maybe it only works on boxes with a very large "open files" resource
> > limit. Perhaps the hard-coded 255 should be replaced with something
> > involving getrlimit() or similar?
>
> I se
On 4/25/12 2:04 PM, Greg Wooledge wrote:
> Maybe it only works on boxes with a very large "open files" resource
> limit. Perhaps the hard-coded 255 should be replaced with something
> involving getrlimit() or similar?
I see two potential fixes here. First, try changing the 255 to -1 and
see wha
On Wed, Apr 25, 2012 at 01:31:11PM -0400, Chet Ramey wrote:
> OK. Maybe someone with OpenBSD can debug the appropriate code in
> execute_cmd.c:execute_pipeline. Maybe the call to move_to_high_fd
> fails.
Breakpoint 1 at 0x41d5fc: file execute_cmd.c, line 2107.
Breakpoint 2 at 0x414aa3: file gene
On Wed, Apr 25, 2012 at 1:36 PM, Ted Okuzumi wrote:
> Please note that if I use a different command in the while loop it works.
>
> So instead of
> echo "$mydata" | while read -r line; do myarray+=( "$line" ); done
>
> if I say:
> echo "$mydata" | while read -r line; do echo "$line" ; done
>
> The
On Wed, Apr 25, 2012 at 10:36:53AM -0700, Ted Okuzumi wrote:
> Please note that if I use a different command in the while loop it works.
>
> So instead of
> echo "$mydata" | while read -r line; do myarray+=( "$line" ); done
>
> if I say:
> echo "$mydata" | while read -r line; do echo "$line" ; do
Please note that if I use a different command in the while loop it works.
So instead of
echo "$mydata" | while read -r line; do myarray+=( "$line" ); done
if I say:
echo "$mydata" | while read -r line; do echo "$line" ; done
Then it works. To pipe output into a while statement works, normally,
On 4/25/12 1:10 PM, Greg Wooledge wrote:
> On Wed, Apr 25, 2012 at 12:55:06PM -0400, Greg Wooledge wrote:
>> It also fails on OpenBSD 5.0 using bash 4.2.10 from ports.
>
> And it also fails on OpenBSD 5.0 using bash 4.2.24 straight from the
> original sources.
OK. Maybe someone with OpenBSD can
On Wed, Apr 25, 2012 at 12:55:06PM -0400, Greg Wooledge wrote:
> It also fails on OpenBSD 5.0 using bash 4.2.10 from ports.
And it also fails on OpenBSD 5.0 using bash 4.2.24 straight from the
original sources.
cyclops:/var/tmp/bash/bash-4.2$ ./bash -c 'echo $BASH_VERSION'
4.2.24(1)-release
cyclo
On Wed, Apr 25, 2012 at 06:26:18PM +0200, Roman Rakus wrote:
> On 04/25/2012 06:15 PM, Chet Ramey wrote:
> >OK. I get the same working behavior on Mac OS X, Solaris 8/10, RHEL 5,
> >BSD/OS (old), and Fedora 15. I'm not sure what to tell you.
> On Fedora 16 it works as expected.
> $ rpm -q bash
>
On 04/25/2012 06:15 PM, Chet Ramey wrote:
On 4/25/12 11:27 AM, Greg Wooledge wrote:
On Wed, Apr 25, 2012 at 11:07:57AM -0400, Chet Ramey wrote:
z4.local(1)$ ../bash-4.2-patched/bash -c 'echo $BASH_VERSION'
4.2.24(9)-release
z4.local(1)$ ../bash-4.2-patched/bash ./x3
foo
z4.local(1)$ ./x3
foo
I
On 4/25/12 11:27 AM, Greg Wooledge wrote:
> On Wed, Apr 25, 2012 at 11:07:57AM -0400, Chet Ramey wrote:
>> z4.local(1)$ ../bash-4.2-patched/bash -c 'echo $BASH_VERSION'
>> 4.2.24(9)-release
>> z4.local(1)$ ../bash-4.2-patched/bash ./x3
>> foo
>> z4.local(1)$ ./x3
>> foo
>
> I grabbed patches 21-24
On Wed, Apr 25, 2012 at 11:07:57AM -0400, Chet Ramey wrote:
> z4.local(1)$ ../bash-4.2-patched/bash -c 'echo $BASH_VERSION'
> 4.2.24(9)-release
> z4.local(1)$ ../bash-4.2-patched/bash ./x3
> foo
> z4.local(1)$ ./x3
> foo
I grabbed patches 21-24 and applied them. No change.
imadev:/var/tmp/bash/b
On 4/25/12 10:55 AM, Greg Wooledge wrote:
> On Wed, Apr 25, 2012 at 08:40:11AM -0400, Chet Ramey wrote:
>> Since you're using bash-4.2, you can experiment with the `lastpipe' shopt
>> option. If that's enabled, bash runs the last element of a pipeline in
>> the parent shell context without creatin
On Wed, Apr 25, 2012 at 08:40:11AM -0400, Chet Ramey wrote:
> Since you're using bash-4.2, you can experiment with the `lastpipe' shopt
> option. If that's enabled, bash runs the last element of a pipeline in
> the parent shell context without creating a subshell.
I actually started writing a res
On 4/25/12 1:23 AM, Clark Wang wrote:
>> Bash Version: 4.2
>> Patch Level: 0
>> Release Status: release
>>
>> Description:
>>Cannot redirect into an array from multiline variable
>>
>> Does not work:
>> echo "$mydata" | while read line; do myarray+=( "$line" ); done
>>
>
> Here the whole
On Wed, Apr 25, 2012 at 07:21, Ted Okuzumi wrote:
> I am writing this e-mai to report to report a bug in bash.
>
> Configuration Information [Automatically generated, do not change]:
> Machine: x86_64
> OS: linux-gnu
> Compiler: gcc
> Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64'
29 matches
Mail list logo
