`timeout`: refuses to run a command when an argument is not valid UTF-8, unlike GNU coreutils

[ottok]

Current timeout behavior

Notices on Ubuntu 26.10 "Resolute" devel version that timeout validates its whole argument vector as UTF-8 and aborts instead of executing the command:

$ dpkg -l | grep coreutils
ii  coreutils                        9.5-1ubuntu2+0.0.0~ubuntu24        all          coreutils meta package
ii  coreutils-from-uutils            0.0.0~ubuntu24                     all          coreutils from the uutils project
ii  gnu-coreutils                    9.7-3ubuntu1                       amd64        GNU core utilities
ii  rust-coreutils                   0.10.0-1ubuntu2~26.04.1            amd64        Universal coreutils utils, written in Rust

$ printf 'x\377\n' > arg
$ timeout 10 true "$(cat arg)"
error: invalid UTF-8 was detected in one or more arguments

For more information, try '--help'.
$ echo $?
125

The same happens with a filename that is not valid UTF-8, which is a perfectly
ordinary thing on Linux:

$ touch "$(printf 'bad\377name')"
$ timeout 1 ls -l "$(printf 'bad\377name')"
error: invalid UTF-8 was detected in one or more arguments
$ echo $?
125

Expected behavior

timeout should pass the argument vector to the command byte for byte, exactly like GNU coreutils, and report only the command's own exit status:

$  dpkg -l | grep coreutils
ii  coreutils                          9.10-1                           amd64          GNU core utilities
$ printf 'x\377\n' > arg
$ timeout 10 true "$(cat arg)"; echo $?
0
$ timeout 1 sleep 0.02 "$(cat arg)"; echo $?
0

Why this matters

Non-UTF-8 filenames are common on Linux, so timeout cannot be used with them at all. In our case it broke the test suite of Debian/Ubuntu's grep (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1149338). The tests/fgrep-infloop and tests/invalid-multibyte-infloop pass a deliberately invalid UTF-8 pattern through timeout, and since grep never runs they only ever see exit status 125, which those tests do not accept. We have had to work around it in our packaging (a byte-transparent timeout on PATH, https://salsa.debian.org/debian/grep/-/merge_requests/21) rather than treat it as a grep bug, because the incompatibility is on the timeout side.

[xtqqczze]

@ottok Thanks for the report. Since this also relates to an Ubuntu package, you may wish to consider reporting the issue downstream as well: https://bugs.launchpad.net/ubuntu/+source/rust-coreutils.

[SichenLiang]

On current main, nice and nohup reject a command argument containing invalid UTF-8 before starting the command:

$ nice echo "$(printf 'a\377b')"
error: invalid UTF-8 was detected in one or more arguments

For more information, try '--help'.
$ echo $?
125

$ nohup echo "$(printf 'a\377b')" < /dev/null
error: invalid UTF-8 was detected in one or more arguments

For more information, try '--help'.
$ echo $?
125

Neither command runs echo.
GNU coreutils 9.12 passes the argument through in both cases. echo writes the byte sequence 61 ff 62 0a (a, \377, b, newline), and both commands exit 0.
The problem is in argument parsing. timeout, nice, and nohup parse COMMAND and its arguments with clap’s default String parser, so parsing fails before the command is executed if any argument is not valid UTF-8. env, stdbuf, chroot, and runcon already use OsString for command arguments.
Fixes are prepared for timeout, nice, and nohup. Each changes the command and its arguments to OsString and adds regression tests.