Re: which paradigms does bash support
Excerpts from Pierre Gaston's message of 2018-03-14 09:22:45 +0200: > > On 26/01/15 13:43, Greg Wooledge wrote: > > > On Sun, Jan 25, 2015 at 08:11:41PM -0800, garegi...@gmail.com wrote: > > >> As a programming language which paradigms does bash support. > > Declarative, procedural, imperative? Read code like 'topgit' and you'll understand that there is a reason why alternate programming languages do exist for complex programs. I'm not a shell export, but I don't know how to return a list in bash. You can get quit far with shell scripts depending on what you do. But seriously - why not just use Python/Perl/Ruby/... ? some paradigms * global functions/ vars / some global state (eg how glob patterns behave) * builtin background processing by using & leep 10 & sleep 10 & wait * propagate exit codes by false && true && true (only first will be run) * signal handlers and clreanup hooks * hashes, lists, but syntax is wired (IMHO) => can you return lists? ... -> so for anything complex use a real language, please. Marc Weber
Re: feature request: more complete set -e
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
Re: feature request: more complete set -e
On Thu, Jun 25, 2009 at 07:33:18PM -0400, Chet Ramey wrote: > Marc Weber wrote: > > > This is my point: I'd like to tell bash: Whenever running an executable > > assume that if it returns a non zero exit status that's a unforeseen > > exception. And in this case don't continue as usual but abort and return > > non zero exit status yourself. set -e comes close. > > You're talking about making bash exit when a command fails even when > not in a command execution context. The example above is a word > expansion context. `set -e' acts in a command execution context. > > Nor are you talking only about executables; you mean builtins too, > just to make that clear. > > Your proposal would have bash exit on > > echo `expr $var - 1` shrug. I didn't knew that either. I think that this is bad. expr should do some calculation. If the calculation fails (eg devision by zero) the return value should be non zero. But yeah. You've just given me another example why you need deep active knowledge to write good scripts Maybe I should rather just use perl, python, ruby or php instead of continuing this thread then Marc Weber
Re: feature request: more complete set -e
On Tue, Jun 23, 2009 at 09:00:10AM -0400, Chet Ramey wrote:
> Marc Weber wrote:
> > Hi,
> >
> > I stumbled about another bash problem today:
> >
> > for item in $(false);
> > echo $item
> > done || { echo for failed; }
> >
> > doesn't fail. I think it's bad that there is no
> > set -e
> >
> > like switch which really catches all failures of this kind.
>
> This isn't really about set -e or ||; the for loop doesn't fail.
>
> Posix.2 says, in part,
>
> "[T]he list of words following in shall be expanded to generate
>a list of items...If there are no items, the exit status shall
>be zero."
>
> http://www.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_09_04_03
This is my point: I'd like to tell bash: Whenever running an executable
assume that if it returns a non zero exit status that's a unforeseen
exception. And in this case don't continue as usual but abort and return
non zero exit status yourself. set -e comes close.
Maybe this is not posix compliant. But I think it would be useful to
have this kind of propagating error conditions in all cases.
Of course for i in $(echo ""); .. ; done should still result in exit
status 0. But if echo was an executable failing due to any reason (eg
segmentation fault) there should be a way to make the script fail
without having to remember that a dummy var has to be used like this:
dummy=$(fail)
for i in $dummy; do .. ; done
I'm only one user in the world and I can't say what all bash users want.
I'd like to see this feature making my script yell if there is an
exception.
I don't want to offend bash. I want to see it turning into a fool
proof direction because bash is not the only language I have to use
which makes it harder to remember all details.
Sincerly
Marc Weber
feature request: more complete set -e
Hi,
I stumbled about another bash problem today:
for item in $(false);
echo $item
done || { echo for failed; }
doesn't fail. I think it's bad that there is no
set -e
like switch which really catches all failures of this kind.
If you want to ignore non zero exit status you can always use || true.
Of course the workaround is obvious: use
dummy_var=$(false)
for item in $dummy_var;
echo $item
done || { echo for failed; }
However you have to remeber this pitfall.
I know that some scripts may depend on the current behaviour.
So what about adding a new switch beeing more strict?
Sincerly
Marc Weber
