Hi Tom,
On 10/24/25 6:55 PM, Tom Rini wrote:
On Fri, Oct 24, 2025 at 06:47:45PM +0200, Quentin Schulz wrote:
Hi Tom,
On 10/24/25 6:02 PM, Tom Rini wrote:
For nearly all commands in U-Boot the '?' variable is handled the same
way with 0 meaning success, 1 meaning any failure. Explain this in the
general rules section of the cmdline documentation (with a link to a
counter example) and then remove the redundant wording from most
commands. We retain a section about the return value in a number of
places where we are doing something such as always returning a specific
value or we have useful additional information to go along with the
normal return codes.
Signed-off-by: Tom Rini <[email protected]>
---
Changes in v2:
- Rewordings suggested by Quentin
- After confirming that invalid syntax also always returns 1 and not -1,
For example cmd/scmi.c do_scmi_set_proto() can return CMD_RET_USAGE which is
a -1 enum and the function returns an int, so I assume this would be
propagated properly?
I don't have time today to check the cmd function call stack to see if it
is, but this seems odd to me.
I spent a while Tuesday trying to dig in to this. We always pass
CMD_RET_USAGE internally, CMD_RET_USAGE is -1. I ended up getting stuck
on where we actually set the '?' environment variable. I don't know if
we have ever actually passed -1 to the shell. Testing things out in a
real shell, "2" is the value of invalid invalid syntax for a command
(e.g. /bin/bash --keyboardsmash;echo $?).
Curiosity got the better of me and I believe we probably set it from
get_dollar_var() in common/cli_hush.c where we do
sprintf(buf, "%u", (unsigned int)last_return_code);
which anyway is an unsigned int.
More things to add to the todo list for next week :)
But I did verify with askenv and indeed the shell reports 1 in $? while
the enum value is -1.
Cheers,
Quentin
