From: Denis Osterland-Heim <denis.osterland@diehl.com>
To: "barebox@lists.infradead.org" <barebox@lists.infradead.org>
Subject: Re: Not successful if statements returning error code
Date: Wed, 28 Jul 2021 09:38:55 +0000 [thread overview]
Message-ID: <eb2c7cc52d5a68cccaa64642ca909acf7cf25c94.camel@diehl.com> (raw)
In-Reply-To: <2c7807b2-e709-8042-1945-bf4d06f77f28@pengutronix.de>
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@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/
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
next prev parent reply other threads:[~2021-07-28 9:40 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-07-23 10:18 Andrej Picej
2021-07-27 5:20 ` Andrej Picej
2021-07-28 8:56 ` Ahmad Fatoum
2021-07-28 9:38 ` Denis Osterland-Heim [this message]
2021-07-29 9:22 ` Ahmad Fatoum
2021-07-29 9:48 ` Denis Osterland-Heim
2021-08-09 10:54 ` Ahmad Fatoum
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=eb2c7cc52d5a68cccaa64642ca909acf7cf25c94.camel@diehl.com \
--to=denis.osterland@diehl.com \
--cc=barebox@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox