From: Francis Laniel <francis.laniel@amarulasolutions.com>
To: u-boot@lists.denx.de
Cc: michael@amarulasolutions.com, "Marek Behún" <marek.behun@nic.cz>,
"Simon Glass" <sjg@chromium.org>, "Wolfgang Denk" <wd@denx.de>,
hws@denx.de
Subject: How should we deal with actual hush odd behavior?
Date: Fri, 20 Aug 2021 18:12:23 +0200 [thread overview]
Message-ID: <2787647.e9J7NaK4W3@pwmachine> (raw)
Hi.
I hope you are fine and the same for your family and friends.
In July, a proposal to add a new shell for U-Boot was posted on the mailing
list [1].
The community discussed a lot about this changes, some people did not agree
with it because the new shell is not compatible with the actual one (hush)
[2].
So, a proposal to update U-Boot actual hush to follow what they currently have
in Busybox was made [3].
Porting 2021 Busybox hush to U-Boot seems, for me, to be a good idea as we
would benefit from Busybox bug fixes as well as being compatible with actual
hush (in theory).
We could also add new features to U-Boot hush, like functions, as they were
added to Busybox.
Nonetheless, the idea of this port is to be compatible.
In practice, I noted some cases when this is actually not the case.
The first one can be related to how && and || operators were handled in hush.
So, the following: false && false || true
Returns 0 on Busybox 2021 hush and 1 on U-Boot.
The behavior of 2021 is coherent with the definition of these operators [4]:
> The return status of AND and OR lists is the exit
> status of the last command executed in the list.
An other example concerns variable expansion, where foo='bar "quux" is
expanded to bar quux in U-Boot and bar "quux in Busybox.
I do not have a real opinion on the second one, as I think local variable set
in U-Boot scripts are quite simple as people do not try to do: foo="bar \"quux
'quuz' \"\"\"corge".
The first one is maybe more problematic.
Grepping "if test" shows me that the more complex if condition seems to be
under the form:
if first_test_ AND/OR second_test
Here also, people seems to no try to write complex expression like: foo ||
bar; echo quux && quuz.
So, porting Busybox 2021 hush can solve bugs we have currently in U-Boot, but
what if fixing these bugs lead to a board script failing and so a device not
booting...
I would like to have the opinion of the community on this question.
Best regards.
---
[1] https://lists.denx.de/pipermail/u-boot/2021-July/453347.html
[2] https://lists.denx.de/pipermail/u-boot/2021-July/453790.html
[3] https://lists.denx.de/pipermail/u-boot/2021-July/453848.html
[4] https://linux.die.net/man/1/bash
next reply other threads:[~2021-08-20 16:12 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-08-20 16:12 Francis Laniel [this message]
2021-08-20 18:22 ` How should we deal with actual hush odd behavior? Simon Glass
2021-08-25 22:24 ` Tom Rini
2021-08-23 11:20 ` Wolfgang Denk
2021-08-31 9:32 ` Francis Laniel
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=2787647.e9J7NaK4W3@pwmachine \
--to=francis.laniel@amarulasolutions.com \
--cc=hws@denx.de \
--cc=marek.behun@nic.cz \
--cc=michael@amarulasolutions.com \
--cc=sjg@chromium.org \
--cc=u-boot@lists.denx.de \
--cc=wd@denx.de \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.