| Age | Commit message (Collapse) | Author |
|---|
|
It turns out that there is lots of code in the wild, including in the
U-Boot tree itself, which used to rely on
test -n $somevar
to yield false when $somevar is not defined or empty. See for example
all the occurrences of 'test -n $fdtfile'. That was really only a
quirk of the implementation that refused calls with argc < 3, and not
because it was interpreted as
test -n "$somevar"
which is how this should be spelled.
While not exactly conforming to POSIX, we can accomodate such scripts
by special-casing a single argument "-n" to be interpreted as if it
comes from code as above with empty $somevar.
Since we only just added the ability to test a string for emptiness
using the single-argument form, it is very unlikely that there is code
doing
test "$str"
which would now fail if $str happens to be exactly "-n"; such a test
should really always be spelled
test -n "$str"
Fixes: 8b0619579b2 ("cmd: test: fix handling of single-argument form of test")
Reported-by: Franz Schnyder <[email protected]>
Signed-off-by: Rasmus Villemoes <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
|
|
POSIX states that
0 arguments:
Exit false (1).
1 argument:
Exit true (0) if $1 is not null; otherwise, exit false.
and at least bash and busybox sh behave that way.
The current 'argc < 3' does the right thing for a non-existing or
empty argv[1], but not for a non-empty argv[1]. Fix that and add
corresponding test cases.
Signed-off-by: Rasmus Villemoes <[email protected]>
Tested-by: Anshul Dalal <[email protected]>
|
|
Duplicate a few of the existing test cases, using the [ spelling, and
also ensure that the presence of a matching ] as a separate and last
argument is enforced.
Signed-off-by: Rasmus Villemoes <[email protected]>
Tested-by: Anshul Dalal <[email protected]>
|
|
The include file <command.h> does not need anything from <env.h>.
Furthermore, include/env.h itself includes other headers which can lead
to longer indirect inclusion paths. To prepare to remove <env.h> from
<command.h> fix all of the places which had relied on this indirect
inclusion to instead include <env.h> directly.
Reviewed-by: Mattijs Korpershoek <[email protected]> # android, bcb
Reviewed-by: Jerome Forissier <[email protected]> # spawn
Signed-off-by: Tom Rini <[email protected]>
|
|
Francis Laniel <[email protected]> says:
During 2021 summer, Sean Anderson wrote a contribution to add a new shell, based
on LIL, to U-Boot [1, 2].
While one of the goals of this contribution was to address the fact actual
U-Boot shell, which is based on Busybox hush, is old there was a discussion
about adding a new shell versus updating the actual one [3, 4].
So, in this series, with Harald Seiler, we updated the actual U-Boot shell to
reflect what is currently in Busybox source code.
Basically, this contribution is about taking a snapshot of Busybox shell/hush.c
file (as it exists in commit 37460f5da) and adapt it to suit U-Boot needs.
This contribution was written to be as backward-compatible as possible to avoid
breaking the existing.
So, the modern hush flavor offers the same as the actual, that is to say:
1. Variable expansion.
2. Instruction lists (;, && and ||).
3. If, then and else.
4. Loops (for, while and until).
No new features offered by Busybox hush were implemented (e.g. functions).
It is possible to change the parser at runtime using the "cli" command:
=> cli print
old
=> cli set modern
=> cli print
modern
=> cli set old
The default parser is the old one.
Note that to use both parser, you would need to set both
CONFIG_HUSH_MODERN_PARSER and CONFIG_HUSH_OLD_PARSER.
In terms of testing, new unit tests were added to ut to ensure the new behavior
is the same as the old one and it does not add regression.
Nonetheless, if old behavior was buggy and fixed upstream, the fix is then added
to U-Boot [5].
In sandbox, all of these tests pass smoothly:
=> printenv board
board=sandbox
=> ut hush
Running 20 hush tests
...
Failures: 0
=> cli set modern
=> ut hush
Running 20 hush tests
...
Failures: 0
Thanks to the effort of Harald Seiler, I was successful booting a board:
=> printenv fdtfile
fdtfile=amlogic/meson-gxl-s905x-libretech-cc.dtb
=> cli get
old
=> boot
...
root@lepotato:~#
root@lepotato:~# reboot
...
=> cli set modern
=> cli get
modern
=> printenv fdtfile
fdtfile=amlogic/meson-gxl-s905x-libretech-cc.dtb
=> boot
...
root@lepotato:~#
This contribution indeed adds a lot of code and there were concern about its
size [6, 7].
With regard to the amount of code added, the cli_hush_upstream.c is 13030 lines
long but it seems a smaller subset is really used:
gcc -D__U_BOOT__ -E common/cli_hush_upstream.c | wc -l
2870
Despite this, it is better to still have the whole upstream code for the sake of
easing maintenance.
With regard to memory size, I conducted some experiments for version 8 of this
series and for a subset of arm64 boards and found the worst case to be 4K [8].
Tom Rini conducted more research on this and also found the increase to be
acceptable [9].
If you want to review it - your review will really be appreciated - here are
some information regarding the commits:
* commits marked as "test:" deal with unit tests.
* commit "cli: Add Busybox upstream hush.c file." copies Busybox shell/hush.c
into U-Boot tree, this explain why this commit contains around 12000 additions.
* commit "cli: Port Busybox 2021 hush to U-Boot." modifies previously added file
to permit us to use this as new shell.
The really good idea of #include'ing Busybox code into a wrapper file to define
some particular functions while minimizing modifications to upstream code comes
from Harald Seiler.
* commit "cmd: Add new parser command" adds a new command which permits
selecting parser at runtime.
I am not really satisfied with the fact it calls cli_init() and cli_loop() each
time the parser is set, so your reviews would be welcomed.
* Other commits focus on enabling features we need (e.g. if).
|
|
As asked in commit 9c6bf1715f6a ("test/py: hush_if_test: Add tests to cover
octal/hex values"), this commit translates test_hush_if_test.py to a C test.
Signed-off-by: Francis Laniel <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
|
