[prev in list] [next in list] [prev in thread] [next in thread] 

List:       busybox
Subject:    Re: [RFC] Busybox ash built-in commands fail on unavailable console
From:       Ariel D'Alessandro <ariel.dalessandro () collabora ! com>
Date:       2022-07-21 13:27:59
Message-ID: 2b104cc6-83a8-4822-9888-8d7dc3db7e5b () collabora ! com
[Download RAW message or body]

Hi Laurent,

Thanks a lot for your quick feedback.

On 7/20/22 14:02, Laurent Bercot wrote:
>> Busybox's ash built-in commands -e.g. echo, printf, cd- returns an error
>> if the stdout/stderr device is not available. In particular, I reached
>> this behavior while debugging a Debian initramfs, where ash built-in
>> commands are run during boot, before the console is available.
> 
>  POSIX mandates that these functions return a nonzero code when an error
> occurs. This includes not being able to write to stdout. So the commands
> are conforming, it's definitely not a bug.
> 
> 
>> _log_msg()
>> {
>>    if [ "${quiet?}" = "y" ]; then return; fi
>>    # shellcheck disable=SC2059
>>    printf "$@"
>>    return 0 # Prevents error carry over in case of unavailable console
>> }
> 
>  That is valid.
>  Another way of proceeding is enforcing set +e at the beginning of
> the script, and explicitly exiting on command failures that are deemed
> fatal.
> 
> 
>> * As I'm not sure if this is really a bug or not, I'm sending this as an
>> RFC. So, the question of this RFC is: should this be considered a bug
>> and get fixed properly?
> 
>  Not a bug. What needs to be fixed is the scripts that assume cd, echo
> and printf always succeed. Adding "||:" after a command that must always
> succeed is easy enough - but hindsight is 20/20 :)
> 
> 
>> From Busybox ash source code, it can be seen that the *lone-dash* case
>> `cd -` tries to print to stdout. The other cd cases with the target
>> directory explicitly set don't fail as they don't try to open the output
>> device, which is unavailable at that point.
> 
>  Working as intended: "cd -" is specified to be equivalent to
> 'cd "$OLDPWD" && pwd', and it's the only case where cd writes to stdout.
> 
>  I'm afraid cd - >/dev/null is the best workaround you can get.
> Shell scripting is fraught with peril, and stdout being unavailable is
> a common pitfall.

Understood, makes sense. Thanks again for confirming this is not a bug
and commands are conforming to the standard.

Regards,
Ariel
_______________________________________________
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

[prev in list] [next in list] [prev in thread] [next in thread]