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_ evil
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
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
them
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/share
Mike Frysinger 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
«Always good to prejudge everything someone says based on how
they interact with
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 into
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
string, eg.
On Thu, Apr 26, 2012 at 2:16 PM, Greg Wooledge wool...@eeg.ccf.org 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()
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 the
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
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 *while* statement runs in
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
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 creating a
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.
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 and applied
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
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 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
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 debug
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,
however
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 ; done
You do not
On Wed, Apr 25, 2012 at 1:36 PM, Ted Okuzumi tedokuz...@gmail.com 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
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
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 what
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 see two
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
involving
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
hi
cyclops:/var/tmp/bash/bash-4.2$ ./bash -c 'shopt -s lastpipe; echo hi | read
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
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'
-DCONF_OSTYPE='linux-gnu'
On Wed, Apr 25, 2012 at 07:21, Ted Okuzumi tedokuz...@gmail.com 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'
30 matches
Mail list logo
