mail archive of the barebox mailing list
 help / color / mirror / Atom feed
* Not successful if statements returning error code
@ 2021-07-23 10:18 Andrej Picej
  2021-07-27  5:20 ` Andrej Picej
  2021-07-28  8:56 ` Ahmad Fatoum
  0 siblings, 2 replies; 7+ messages in thread
From: Andrej Picej @ 2021-07-23 10:18 UTC (permalink / raw)
  To: Barebox List

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?

Thank you for your answer.

Best regards,
Andrej

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox


^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Not successful if statements returning error code
  2021-07-23 10:18 Not successful if statements returning error code Andrej Picej
@ 2021-07-27  5:20 ` Andrej Picej
  2021-07-28  8:56 ` Ahmad Fatoum
  1 sibling, 0 replies; 7+ messages in thread
From: Andrej Picej @ 2021-07-27  5:20 UTC (permalink / raw)
  To: barebox

Just saw that I forgot to mention the main reason, why this is important.
We have a couple of boot scripts which end with if statements. If 
conditions of these if statements are not met then the boot script 
returns error code and the booting process is broken:

> Running script '/env/boot/mmc' failed: error -1
> Booting entry 'mmc' failed
> Nothing bootable found

BR,
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?
> 
> Thank you for your answer.
> 
> Best regards,
> Andrej
> 
> _______________________________________________
> barebox mailing list
> barebox@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/barebox

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Not successful if statements returning error code
  2021-07-23 10:18 Not successful if statements returning error code Andrej Picej
  2021-07-27  5:20 ` Andrej Picej
@ 2021-07-28  8:56 ` Ahmad Fatoum
  2021-07-28  9:38   ` Denis Osterland-Heim
  1 sibling, 1 reply; 7+ messages in thread
From: Ahmad Fatoum @ 2021-07-28  8:56 UTC (permalink / raw)
  To: Andrej Picej, Barebox List

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.

Cheers,
Ahmad

> 
> Thank you for your answer.
> 
> Best regards,
> Andrej
> 
> _______________________________________________
> barebox mailing list
> barebox@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/barebox
> 


-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Not successful if statements returning error code
  2021-07-28  8:56 ` Ahmad Fatoum
@ 2021-07-28  9:38   ` Denis Osterland-Heim
  2021-07-29  9:22     ` Ahmad Fatoum
  0 siblings, 1 reply; 7+ messages in thread
From: Denis Osterland-Heim @ 2021-07-28  9:38 UTC (permalink / raw)
  To: barebox

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

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Not successful if statements returning error code
  2021-07-28  9:38   ` Denis Osterland-Heim
@ 2021-07-29  9:22     ` Ahmad Fatoum
  2021-07-29  9:48       ` Denis Osterland-Heim
  0 siblings, 1 reply; 7+ messages in thread
From: Ahmad Fatoum @ 2021-07-29  9:22 UTC (permalink / raw)
  To: Denis Osterland-Heim, barebox

On 28.07.21 11:38, Denis Osterland-Heim wrote:
> Hi,
> 
> Am Mittwoch, den 28.07.2021, 10:56 +0200 schrieb Ahmad Fatoum:
>
>> 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.

An option-less barebox echo can't fail, so it should never
print both yes and no, but thanks for the reference. I'll keep
an eye on it in future shell code.

This wasn't what I meant to show though, I meant that x1 and x2
are both non-integers and -eq which compares integers returns
true when comparing them unlike what a POSIX shell does.

Cheers,
Ahmad
 

> 
> 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
> 


-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Not successful if statements returning error code
  2021-07-29  9:22     ` Ahmad Fatoum
@ 2021-07-29  9:48       ` Denis Osterland-Heim
  2021-08-09 10:54         ` Ahmad Fatoum
  0 siblings, 1 reply; 7+ messages in thread
From: Denis Osterland-Heim @ 2021-07-29  9:48 UTC (permalink / raw)
  To: a.fatoum, barebox

Hi,

Am Donnerstag, den 29.07.2021, 11:22 +0200 schrieb Ahmad Fatoum:
> On 28.07.21 11:38, Denis Osterland-Heim wrote:
> > Hi,
> >
> > Am Mittwoch, den 28.07.2021, 10:56 +0200 schrieb Ahmad Fatoum:
> >
> > > 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.
>
> An option-less barebox echo can't fail, so it should never
> print both yes and no, but thanks for the reference. I'll keep
> an eye on it in future shell code.
>
> This wasn't what I meant to show though, I meant that x1 and x2
> are both non-integers and -eq which compares integers returns
> true when comparing them unlike what a POSIX shell does.
Oh. Now I got your point ;-)

https://git.pengutronix.de/cgit/barebox/tree/commands/test.c#n182
error handling is missing here.
It is very likely that simple_strtol() returns the same value in case of error,
which results in a successfully compare.

Regards, Denis

>
> Cheers,
> Ahmad
>
>
> >
> > 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
> >
>
>
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

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Not successful if statements returning error code
  2021-07-29  9:48       ` Denis Osterland-Heim
@ 2021-08-09 10:54         ` Ahmad Fatoum
  0 siblings, 0 replies; 7+ messages in thread
From: Ahmad Fatoum @ 2021-08-09 10:54 UTC (permalink / raw)
  To: Denis Osterland-Heim, barebox

Hi,

On 29.07.21 11:48, Denis Osterland-Heim wrote:
> Hi,
> 
> Am Donnerstag, den 29.07.2021, 11:22 +0200 schrieb Ahmad Fatoum:
>> On 28.07.21 11:38, Denis Osterland-Heim wrote:
>>> Hi,
>>>
>>> Am Mittwoch, den 28.07.2021, 10:56 +0200 schrieb Ahmad Fatoum:
>>>
>>>> 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.
>>
>> An option-less barebox echo can't fail, so it should never
>> print both yes and no, but thanks for the reference. I'll keep
>> an eye on it in future shell code.
>>
>> This wasn't what I meant to show though, I meant that x1 and x2
>> are both non-integers and -eq which compares integers returns
>> true when comparing them unlike what a POSIX shell does.
> Oh. Now I got your point ;-)
> 
> https://git.pengutronix.de/cgit/barebox/tree/commands/test.c#n182
> error handling is missing here.
> It is very likely that simple_strtol() returns the same value in case of error,
> which results in a successfully compare.

Yes. I noted this because of the similarity to Andrej's problem:
A bug leads to clearly bogus shell behavior. It can be ok to fix such bugs
despite them not being 100% backwards compatible.

> 
> Regards, Denis
> 
>>
>> Cheers,
>> Ahmad
>>
>>
>>>
>>> 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
>>>
>>
>>
> 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/
> 
> 


-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2021-08-09 10:56 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-07-23 10:18 Not successful if statements returning error code Andrej Picej
2021-07-27  5:20 ` Andrej Picej
2021-07-28  8:56 ` Ahmad Fatoum
2021-07-28  9:38   ` Denis Osterland-Heim
2021-07-29  9:22     ` Ahmad Fatoum
2021-07-29  9:48       ` Denis Osterland-Heim
2021-08-09 10:54         ` Ahmad Fatoum

mail archive of the barebox mailing list

This inbox may be cloned and mirrored by anyone:

	git clone --mirror https://lore.barebox.org/barebox/0 barebox/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 barebox barebox/ https://lore.barebox.org/barebox \
		barebox@lists.infradead.org barebox@lists.infradead.org
	public-inbox-index barebox

Example config snippet for mirrors.


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git