On Mon, Aug 15, 2011 at 08:19:01PM -0700, Linda Walsh wrote:
> >>today_snaps="$('ls' -1 ${snap_prefix} 2>/dev/null |tr "\n" " " )"
> >
> >This one is so bad, I saved it for last. Ack! Pfffft! Wait, what? Why?
> >What the? Huh?
> ...
> What would you do to search for files w/wild cards and return the output
> in a list?
Maybe this?
today_snaps=( ${snap_prefix} )
e.g., given:
$ ls note*
note note-to-bob note-to-bob.txt
$ unset foo bar; bar=note\*; foo=($bar); echo ${foo[@]}; echo $foo
note note-to-bob note-to-bob.txt
note
This result is an array; if you really want a string,
$ unset foo bar; bar=note\*; foo="$bar"; echo ${foo[@]}; echo $foo
note note-to-bob note-to-bob.txt
note note-to-bob note-to-bob.txt
>From bash(1):
Pathname Expansion
After word splitting, unless the -f option has been set, bash
scans each word for the characters *, ?, and [. If one of these
characters appears, then the word is regarded as a pattern,
and replaced with an alphabetically sorted list of file names
matching the pattern. ...
I'm guessing the 'Ack!' was maybe for 'useless use of subshell'?
> I'm sorry if you feel you waisted your time, I usually don't stay stuck
> ...
I'm actually trying to follow along, but it's tough going.
It seems to me that there are real bugs in applying set -e that can only
be fixed by handling more special cases in the bash code, and those cases
may vary for different scripts. I've never used it, and do use a lot of
'|| exit' constructs, but I think the core of the matter is conflating
'non-zero exit value' with 'error'. set -e is not defined to trigger on
'errors', but rather on 'non-zero exit values'. The problem is that,
for set -e to be generally useful, bash has to somehow internally disable
it under some conditions, as described in the manual:
set ...
-e
...
The shell does not exit if the command that fails is part of the
command list immediately following a while or until keyword,
part of the test following the if or elif reserved words,
part of any command executed in a && or || list except the
command following the final && or ||, any command in a pipeline
but the last, or if the command's return value is being
inverted with !.
A constructive contribution might be made by seeing if you can add your
special cases to that list, even better if you can help by identifying
where it might be done in the code.
Ranting, inferring that people have 'little minds', aren't good
or skilled programmers, etc., does little to make things better.
Excessive verbosity, lingo, abbrevs, etc., don't help either. ;-)
Ken
