Array Elements with Spaces
Group,
I have having a problem with spaces in individual elements of an array.
The space causes a single element to be seen as multiple elements.
Here is a sample run:
-
[EMAIL PROTECTED]:~/bin> ./arraywithspace.sh
3.1.17(1)-release
got 6 parms
parm: arg1
parm: arg2
parm: arg
parm: 3
parm: arg
parm: four
[EMAIL PROTECTED]:~/bin> cat ./arraywithspace.sh
#!/bin/bash
declare -a Arguments=("arg1" "arg2" "arg 3" "arg four")
function countparms
{
echo "got $# parms"
while (($# != 0 ))
do
echo "parm: $1"
shift
done
}
echo $BASH_VERSION
countparms ${Arguments[*]}
--
The real problem I am having is using the array as a list of arguments
to a command, maybe something like this:
grep -i mypattern ${FileList[*]}
--
potter
Re: Array Elements with Spaces
Thanks,
That fixed it.
For the benefit of others...
I ran my test program on a couple different versions of bash (including 2.x)
and It seems that this behavior (combination of quotes and * versus @)
changes based on the version of bash, and not just between 2.x and 3.x. I
did not do an exhaustive test because this solution will work for me.
--
potter
On Nov 10, 2007 12:27 PM, Andreas Schwab <[EMAIL PROTECTED]> wrote:
> "Michael Potter" <[EMAIL PROTECTED]> writes:
>
> > countparms ${Arguments[*]}
>
> Use "[EMAIL PROTECTED]" instead (including the quotes). See node Arrays
> in the Bash docs.
>
> Andreas.
>
> --
> Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
> SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
> PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
> "And now for something completely different."
>
Re: read output of process into a variable
It is not a bug in bash. it is just how it works. the while loop creates a subshell and changes to the variables are not visable outside of the subshell. if you put the while loop first, then it will not create the subshell. do this: result="" while read line; do extracteddata=`echo "$line" | sed -e 's/X/Y/'` result="$result $extracteddata" done < <(/usr/bin/output_generator) /usr/bin/another_tool "$result" the <() is syntax for a named pipes. it makes a command look like a file. Be aware that this may leave files in your /tmp directory. BTW: I would use $() syntax instead of the backtic syntax; just easier to see. -- potter On 30 Jan 2008 11:21:34 GMT, Stefan Palme <[EMAIL PROTECTED]> wrote: > Hi, > don't know if this is the right newsgroup, but it's the only one > I can find with "bash" in its name :-) > > I want to do something like this: > > result="" > /usr/bin/output_generator | while read line; do > extracteddata=`echo "$line" | sed -e 's/X/Y/'` > result="$result $extracteddata" > done > /usr/bin/another_tool "$result" > > In the last line is "result" as empty as at the start of the > whole thing - I guess because the inner "while" loop is executed > in a subshell, so that changing the value of "result" in this > loop does not affect the "outer result". > > How can I solve this? I have some very ugly solutions, but > I guess there must be something "nice" :-) > > (using bash-3.2.17(1)-release) > > Thanks and regards > -stefan- > > >
errexit does not exit script in subshells
Bash Bunch,
Not surprisingly, bash does not exit the script when an error is detected in
a subshell.
I am hopeful that someone has a solution to this (other than: be careful to
not use subshells).
Here is the test run:
---
./subshellnofail.sh
BEGIN
ERROR: ./subshellnofail.sh 10 <- would like the script to stop here.
ONE
ERROR: ./subshellnofail.sh 10
---
Here is the sample script:
--
#!/bin/bash
set -o errexit
set -o noclobber
set -o nounset
set -o pipefail# if you fail on this line, get a newer version of bash.
function traperr
{
echo "ERROR: ${BASH_SOURCE[0]} ${LINENO}"
# exit 1 # does not seem to affect the program.
# return 1 # does not seem to affect the program.
}
set -o errtrace
trap traperr ERR
echo "BEGIN"
cat /etc/passwd |while read aLine
do
# in a subshell
test=$(true | false | true |false);
done
echo "ONE"
while read aLine
do
# not in a subshell
test=$(true | false | true |false);
done
SOLUTION: errexit does not exit script in subshells
Bash Bunch,
Here is how I 'solved' the problem:
function traperr
{
echo "ERROR: ${BASH_SOURCE[0]} ${LINENO}"
# if BASH_SUBSHELL is 0, then script will exit anyway.
if (( $BASH_SUBSHELL >= 1 ))
then
kill $$
fi
}
I put solved in quotes because I do not really care for this solution.
I hope someone will comment with a graceful solution.
--
Michael Potter
On Jan 31, 2008 11:43 AM, Michael Potter <[EMAIL PROTECTED]> wrote:
> Bash Bunch,
>
> Not surprisingly, bash does not exit the script when an error is detected
> in a subshell.
>
> I am hopeful that someone has a solution to this (other than: be careful
> to not use subshells).
>
> Here is the test run:
> ---
> ./subshellnofail.sh
> BEGIN
> ERROR: ./subshellnofail.sh 10 <- would like the script to stop here.
> ONE
> ERROR: ./subshellnofail.sh 10
> ---
>
> Here is the sample script:
> --
> #!/bin/bash
>
> set -o errexit
> set -o noclobber
> set -o nounset
> set -o pipefail# if you fail on this line, get a newer version of
> bash.
>
> function traperr
> {
>echo "ERROR: ${BASH_SOURCE[0]} ${LINENO}"
># exit 1 # does not seem to affect the program.
># return 1 # does not seem to affect the program.
> }
>
> set -o errtrace
> trap traperr ERR
>
> echo "BEGIN"
>
> cat /etc/passwd |while read aLine
> do
># in a subshell
>test=$(true | false | true |false);
> done
>
> echo "ONE"
>
> while read aLine
> do
># not in a subshell
>test=$(true | false | true |false);
> done
> echo "TWO"
>
> test=$(true | false | true |false);
>
> echo "END"
>
> exit 0
> -
>
> echo $BASH_VERSION
> 3.2.17(1)-release
>
>
Re: errexit does not exit script in subshells
The root 'problem' is that errexit only exits the subshell, it does
not exit the script. I put that in quotes because under some
circumstances that is a feature.
I want the script to exit when an error is detected without any extra code.
see my other email with the "SOLUTION". Hopefully someone will point
out a more graceful solution.
--
potter
On Feb 1, 2008 1:56 PM, Linda Walsh <[EMAIL PROTECTED]> wrote:
>
>
> Michael Potter wrote:
> > Bash Bunch,
> >
> > Not surprisingly, bash does not exit the script when an error is detected in
> > a subshell.
> >
> > I am hopeful that someone has a solution to this (other than: be careful to
> > not use subshells).
>
> This seems to work unless I'm missing something...
>
> #!/bin/bash
>
> set -o errexit -o noclobber -o nounset -o pipefail
>
> function traperr
> {
> echo "TRAPERROR: ${BASH_SOURCE[0]} ${LINENO}"
> exit 1 # does not seem to affect the program.
> # return 1 # does not seem to affect the program.
> }
>
> set -o errtrace
> trap traperr ERR
>
> echo -n "Test one: "
> pipesave=$(set +o |grep pipefail)
> set +o pipefail
> cat /etc/passwd |while read aLine; do
> # note: ending following 'test=' line with a "|true" will
> # stop failure from occurring or being detected, if this is
> # what you want..., if not, then set -o pipefile and it
> # will 'fail' if any are false.
> test=$(true | false | true |false)
> done
> test "$?" != 0 && exit 47
> $pipesave # set pipesave back to original value
>
> echo -n "ONE Ok; Test two: "
>
> while read aLine; do
>
> test=$(true | false | true |false);
> done
> echo "TWO"
>
> test=$(true | false | true |false);
>
> echo "END"
>
> exit 0
>
broken pipe
Bash Bunch,
I googled a bit and it see this problem asked several times, but I
never really saw a slick solution:
given this:
set -o pipefail
find / -type f -print 2>&1 |head -20
echo ${PIPESTATUS[*]}
prints this:
141 0
find fails because it has a bunch of output, but head only will accept
the first n lines.
This is a problem for me because I have trap ERR & errexit & pipefail activated.
The solution I will use will be to write the find output to a file,
then run head on it.
I am hoping that someone on the group has a more graceful solution.
BTW: I am not using find in my real script. I just used that here so
anyone could reproduce the problem.
--
Michael Potter
