Greg Wooledge:
> If you simply handle errors yourself by checking the return
> code from commands that actually matter, you won't have to worry about
> all these nasty little surprises.
How is this done?
CHK0="test $? == 0"
my_important_task; $CHK0 || exit 1
Chet:
> To do otherwise would have made expr much less useful. Idioms such as
>
> var=10
> while var=`expr $var - 1`
> do
> echo $var
> done
Mmh I'd use the C like for loop for this which is supported by bash as well.
Bob Proulx:
> Also I must mention grep too. The exit status of grep isn't just
> whether it exits without an error but instead returns an indication of
> whether the pattern matched or not. This makes idioms such as this
> possible:
>
> if grep -q PATTERN FILE; then
> ... do something ...
> fi
to sum up / clarify:
Touching while and if doesn't make sense. Because the exit status is used to
control the program flow. There is no easy way to catch segmentation faults or
such.
Can you come up with a useful use case where you want to ignore the result in
for i in ?
Sure.
for i in $(grep ...); do .. done
So mmh. I should stop using bash because bash can't destinguish a failure from
a return value.
It can. But you have to remember details all the time.
So the problem here is that grep is an external tool.
In other languages you can do
my_lines = file('foo').read.lines.filter( l : matches l 'some regex')
and you'll get an exception if the file isn't found.
So I have to learn those details or use another language.
Thank you for taking the time discussing this topic here. I learned a
lot.
Marc Weber
