[RFC] Busybox ash built-in commands fail on unavailable console

[Laurent Bercot]

>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.

  Good luck,

--
  Laurent