Re: Question about variables and for loop
Paul Jarc schrieb am 18.03.2006 um 20:44:17 (-0500):
> Bob <[EMAIL PROTECTED]> wrote:
> > XXX='a "b c" d'
> > for x in $XXX ; do
> > echo $x
> > done
>
> XXX='a "b c" d'
> eval "set $XXX"
> for x in "$@" ; do
> echo $x
> done
>
> If the first element in XXX might start with "-", then it takes a
> little more work to ensure it isn't misinterpreted as an option to
> "set":
> eval "set x $XXX"
> shift
>
I would use arrays to complete this task, because it is quite hard to
escape a string for the eval-set construct. There is no need to, look at
this (simple?) solution:
x=("-" 0tt a x) # creating array
for t in "[EMAIL PROTECTED]"; do echo "$t"; done
# ^ iterating over all array elements
Because this command does not use eval it is faster and safer;
f.e. you can't add commands in the XXX string, like this:
XXX='a b ; ls -la' # ls -la is executed by eval.
To get rid of you "first element is '-' problem" you can switch off
the option parsing with a single dash or a double dash:
set -- -xxx
set - -xxx
In both cases "$1" would be "-xxx".
Alexander
___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash
Re: bash shell parser bug
laura fairhead wrote: > I just found a bug that affects a number of shells (pressumably the > code there is from the same roots) in the parser. > > The following code; > > l='eval "$l"' > eval "$l" > > Which sets off an infinite recursion on 'eval', should result in an > infinite loop to be terminated by INT (doesnt' work) or at least > end gracefully with an error "bash: out of memory". Instead the > system has to kill the shell process because of SEGV fault. I'm not sure why you are unable to kill the loop with SIGINT; I was able to do it on the systems I tried. You assume incorrectly that the code in the parser is at fault, and that it is "from the same roots". The infinite loop will eventually cause the stack size (most common) or data size (less common) resource limit to be exceeded, and cause the shell to be killed by the kernel. Playing with resource limits (setting the data size limit low enough and the stack size limit high enough), I was able to get malloc to fail and observe the behavior, which was bash exiting with an error message from xmalloc about an allocation failure. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ( ``Discere est Dolere'' -- chet ) Live Strong. No day but today. Chet Ramey, ITS, CWRU[EMAIL PROTECTED]http://cnswww.cns.cwru.edu/~chet/ ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: echo "enhancement" leads to confused legacy script tools...
Henrik Nordstrom <[EMAIL PROTECTED]> writes: > sön 2006-03-19 klockan 12:57 -0800 skrev Paul Eggert: > >> Autoconf deals with shells that do not conform to XSI, and where the >> results are implementation-defined if there's a backslash anywhere in >> the string, so to some extent this point is moot for Autoconf (though >> it's undeniably a portability problem, one that is documented in the >> Autoconf manual under "Limitations of Builtins"). > > I thought so too, but in this case it is a autoconf 2.57 output which is > failing, ending up with a lot of control characters instead of the > expected sed backreferences.. Autoconf 2.57 is pretty old. Do you have the same problem with 2.59? If not, then the problem's solved from the Autoconf point of view. Otherwise, I'd ask you to try it with CVS Autoconf (which has further fixes in this area). ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
