Re: scripts stop running in bg in 4.0.35, and need to be toggled fg-bg to complete
It was sox who messed it up. The play command of sox. As soon as it is left out, all is well. Pls. loop up the Gentoo Forums for more: http://forums.gentoo.org/viewtopic-p-6162718.html This is NOT a bug in bash nor readline. Sorry!
Re: Passing variables to and from custom programs
On Sat, Feb 06, 2010 at 05:35:21PM -0800, DennisW wrote:
> On Feb 6, 5:37 pm, djackn wrote:
> > Result = myIpExec(${IPaddr1} ${IPaddr2} ${IPaddr3} ${IPaddr4})
> >
> > myIpExec is a c program that normally uses scanf to prompt the user
> > for the IP addresses and returns 0 or 1.
> > I plan to use the script to test the program for various inputs.
>
> It is more likely that this would work:
>
> Result=$(echo "{IPaddr1} ${IPaddr2} ${IPaddr3} ${IPaddr4}" | myIpExec)
>
> Note that there are no spaces around the equal sign.
If the result of 'myIpExec' is output to stdout then you could put that into
a shell variable with the syntax that DennisW showed you. But you may have a
problem with parsing it because any prompt for the IP addresses will be included
at the front of that variable.
If the result of 'myIpExec' is actually a return value from main() then you
would access that as the shell variable $? just after the program is run.
The bash 'here string' notation could be used as an alternative to the
echo pipeline notation. It is not as portable. But I like the way it looks
in shell script. It is used like this-
myIpExec <<< "{IPaddr1} ${IPaddr2} ${IPaddr3} ${IPaddr4}"
Result=$?
--
Mike Stroyan
Re: Passing variables to and from custom programs
On Sun, 7 Feb 2010, Mike Stroyan wrote:
> On Sat, Feb 06, 2010 at 05:35:21PM -0800, DennisW wrote:
> > On Feb 6, 5:37 pm, djackn wrote:
> > > Result = myIpExec(${IPaddr1} ${IPaddr2} ${IPaddr3} ${IPaddr4})
> > >
> > > myIpExec is a c program that normally uses scanf to prompt the user
> > > for the IP addresses and returns 0 or 1.
> > > I plan to use the script to test the program for various inputs.
> >
> > It is more likely that this would work:
> >
> > Result=$(echo "{IPaddr1} ${IPaddr2} ${IPaddr3} ${IPaddr4}" | myIpExec)
> >
> > Note that there are no spaces around the equal sign.
>
> If the result of 'myIpExec' is output to stdout then you could put that into
> a shell variable with the syntax that DennisW showed you. But you may have a
> problem with parsing it because any prompt for the IP addresses will be
> included
> at the front of that variable.
>
> If the result of 'myIpExec' is actually a return value from main() then you
> would access that as the shell variable $? just after the program is run.
>
> The bash 'here string' notation could be used as an alternative to the
> echo pipeline notation. It is not as portable. But I like the way it looks
> in shell script. It is used like this-
>
> myIpExec <<< "{IPaddr1} ${IPaddr2} ${IPaddr3} ${IPaddr4}"
> Result=$?
The portable equivalent is:
myIpExec
===
Author:
Shell Scripting Recipes: A Problem-Solution Approach (2005, Apress)
Pro Bash Programming: Scripting the GNU/Linux Shell (2009, Apress)
Bug with -o posix, local variables and assignment preceding builtins
We encountered a strange bug while working on bash-completion. I was
originally only able to reproduce this through a fairly elaborate setup
but Freddy Vulto found a tiny test case:
set -o posix
t() {
local x
BAR=a eval true
}
BAR=b; t; echo $BAR
Bash documentation claims the following (section 6.11 point 23):
""" Assignment statements preceding posix special builtins persist in
the shell environment after the builtin completes."""
The above example should always print "a" but with "#local x" commented
it prints "b". This is obviously wrong; the x variable is not even used.
This can be reproduced on all versions of bash since at least bash-3.0
(probably on bash-2 as well). I also checked Debian's dash as an
alternative posix-compliant shell and it always prints "a" as expected.
Re: Bug with -o posix, local variables and assignment preceding builtins
On Feb 7, 7:33 pm, Crestez Dan Leonard wrote:
> We encountered a strange bug while working on bash-completion. I was
> originally only able to reproduce this through a fairly elaborate setup
> but Freddy Vulto found a tiny test case:
>
> set -o posix
> t() {
> local x
> BAR=a eval true
> }
> BAR=b; t; echo $BAR
>
> Bash documentation claims the following (section 6.11 point 23):
>
> """ Assignment statements preceding posix special builtins persist in
> the shell environment after the builtin completes."""
>
> The above example should always print "a" but with "#local x" commented
> it prints "b". This is obviously wrong; the x variable is not even used.
>
> This can be reproduced on all versions of bash since at least bash-3.0
> (probably on bash-2 as well). I also checked Debian's dash as an
> alternative posix-compliant shell and it always prints "a" as expected.
For reference, ksh93, busybox ash and zsh (with setopt posixbuiltins)
print "a"
