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 <franz.schnyder@toradex.com>
Signed-off-by: Rasmus Villemoes <ravi@prevas.dk>
Reviewed-by: Simon Glass <sjg@chromium.org>

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 <ravi@prevas.dk>
Tested-by: Anshul Dalal <anshuld@ti.com>

I often find myself writing something like

  if [ "$somevar" = 123 ] ; then ...

only to realize that that syntax doesn't work in U-Boot shell, and
must be spelled

  if test "$somevar" = 123 ; then

It only takes a few lines of code to support this POSIX-standardized
alias for test, and helps developers focus on their actual problems
instead of dealing with such unexpected quirks of the shell.

Signed-off-by: Rasmus Villemoes <ravi@prevas.dk>
Tested-by: Anshul Dalal <anshuld@ti.com>

Tom Rini <trini@konsulko.com> says:

Given Simon's series at [1] I started looking in to what brings in
<env.h> when not strictly required and in turn has some unintended
implicit includes. This series takes care of the places where, commonly,
<linux/string.h> or <env.h> itself were required along with a few other
less common cases. This sets aside for the moment what to do about
net-common.h and env_get_ip() as I'm not entirely sure what's best
there.

[1]: https://patchwork.ozlabs.org/project/uboot/list/?series=454939&state=*
Link: https://lore.kernel.org/r/20250514225002.15361-1-trini@konsulko.com

In a number of cases we have C files which rely on a chain of indirect
include paths to get <linux/string.h> to be included via <command.h>. To
facilitate cleaning up <command.h> make this code directly include
<linux/string.h>.

Signed-off-by: Tom Rini <trini@konsulko.com>

Currently, the only way to make use of regex matching in the shell is
by using "setexpr [g]sub" command. That's rather awkward for asking
whether a string matches a regex. At the very least, it requires
providing setexpr with a dummy target variable, but also, the return
value of setexpr doesn't say whether any substitutions were done, so
one would have to do some roundabout thing like

  env set dummy "${string_to_test}"
  setexpr sub dummy '<some regex>' ''
  if test "${dummy}" != "${string_to_test}" ; then ...

When CONFIG_REGEX is set, teach the test command a new operator, =~,
which will allow one to more naturally write

  if test "${string_to_test}" =~ '<some regex>' ; then ...

The =~ operator with similar functionality is also supported in bash
when using its "extended" test operator [[ ]].

Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
Signed-off-by: Rasmus Villemoes <ravi@prevas.dk>

As part of bringing the master branch back in to next, we need to allow
for all of these changes to exist here.

Reported-by: Jonas Karlman <jonas@kwiboo.se>
Signed-off-by: Tom Rini <trini@konsulko.com>

When bringing in the series 'arm: dts: am62-beagleplay: Fix Beagleplay
Ethernet"' I failed to notice that b4 noticed it was based on next and
so took that as the base commit and merged that part of next to master.

This reverts commit c8ffd1356d42223cbb8c86280a083cc3c93e6426, reversing
changes made to 2ee6f3a5f7550de3599faef9704e166e5dcace35.

Reported-by: Jonas Karlman <jonas@kwiboo.se>
Signed-off-by: Tom Rini <trini@konsulko.com>

Remove <common.h> from all "cmd/" files and when needed add
missing include files directly.

Signed-off-by: Tom Rini <trini@konsulko.com>

Move this header out of the common header.

Signed-off-by: Simon Glass <sjg@chromium.org>