mail archive of the barebox mailing list
 help / color / mirror / Atom feed
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

  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