Not successful if statements returning error code

[Denis Osterland-Heim]

Hi,

Am Mittwoch, den 28.07.2021, 10:56 +0200 schrieb Ahmad Fatoum:
> Hello Andrej,
>
> On 23.07.21 12:18, Andrej Picej wrote:
> > Hi all,
> >
> > I have a question about Hush shell and the use of its conditional statements.
> > We have come upon an interesting behaviour with its return values.
> >
> > If the condition of the if statement is not true then the return value is 1 (error code), and if the condition is true the return value is 0 (success).
> >
> > Simple test:
> > > #!/bin/sh
> > > if [ 0 -gt 1 ]; then
> > >   echo "0 gt 1, Ret: $?"
> > > fi
> > > echo "Ret: $?"
> > >
> > > if [ 2 -gt 1 ]; then
> > >   echo "2 gt 1, Ret: $?"
> > > fi
> > > echo "Ret: $?"
> >
> > Output:
> > > Ret: 1
> > > 2 gt 1, Ret: 0
> > > Ret: 0
> >
> > This means that if, for example the first if statement (where condition is not met) would be at the end of a script the return value of that whole script would be 1 (error code).
> > I don't think this follows standard shell behaviour. If if statement condition is not met this doesn't mean that the return value should be an error code, right?
> > Using other shells (bash for example) we can see that the returned value in both cases is 0, which is expected (IMO).
> >
> > This behaviour is not new to the Hush or barebox as I could reproduce it on various previous barebox versions (2013.08.0, 2017.12.0 and 2019.11.0).
> >
> > Of course, this problem can be easily avoided if at the end of every script we use explicit exit 0. This is doable, but a little annoying.
> >
> > Although this is not a deal-breaker for us, I was wondering what is the reason behind this? How do you get around this and are there any plans to fix/modify this in the future so it follows the
> > behaviour of other shells?
>
> I talked with Sascha once before (off-list) about a similar issue. Missing error handling
> results in
>
>   [ x1 -eq x2 ] && echo yes || echo no
>
> printing yes.
>
> We agreed that it's ok to break scripts relying on clear hush bugs like this.
>
> I'd thus recommend you to send a patch to fix hush instead of working around it.
shellcheck says:

SC2015: Note that A && B || C is not if-then-else. C may run when A is true.

So I would think that B is maybe allowed to run before A, too.
But, I do not know if Hush specifies execution order here.

Regards, Denis

>
> Cheers,
> Ahmad
>
> >
> > Thank you for your answer.
> >
> > Best regards,
> > Andrej
> >
> > _______________________________________________
> > barebox mailing list
> > barebox at lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/barebox
> >
>
>
Diehl Connectivity Solutions GmbH
Geschäftsführung: Horst Leonberger
Sitz der Gesellschaft: Nürnberg - Registergericht: Amtsgericht
Nürnberg: HRB 32315

________________________________

Der Inhalt der vorstehenden E-Mail ist nicht rechtlich bindend. Diese E-Mail enthaelt vertrauliche und/oder rechtlich geschuetzte Informationen.
Informieren Sie uns bitte, wenn Sie diese E-Mail faelschlicherweise erhalten haben. Bitte loeschen Sie in diesem Fall die Nachricht.
Jede unerlaubte Form der Reproduktion, Bekanntgabe, Aenderung, Verteilung und/oder Publikation dieser E-Mail ist strengstens untersagt.

- Informationen zum Datenschutz, insbesondere zu Ihren Rechten, erhalten Sie unter:

https://www.diehl.com/group/de/transparenz-und-informationspflichten/

The contents of the above mentioned e-mail is not legally binding. This e-mail contains confidential and/or legally protected information. Please inform us if you have received this e-mail by
mistake and delete it in such a case. Each unauthorized reproduction, disclosure, alteration, distribution and/or publication of this e-mail is strictly prohibited.

- For general information on data protection and your respective rights please visit:

https://www.diehl.com/group/en/transparency-and-information-obligations/