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
_______________________________________________
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
