* 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
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox