[PATCH v2 1/3] doc: usage: Add general rule for `$?`

[Quentin Schulz]

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 <trini at konsulko.com>
>>> ---
>>> 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