stat: %N fails with new line

[sylvestre]

touch $'/tmp/test\nnewline'

FORMAT='{"name":"%N"}'

# GNU stat (correct)
/usr/bin/stat -c "$FORMAT" $'/tmp/test\nnewline'
# Output: {"name":"'/tmp/test'$'\n''newline'"}

# uutils stat (broken)
./target/debug/coreutils stat -c "$FORMAT" $'/tmp/test\nnewline'
# Output: {"name":"'/tmp/test
# newline'"}

rm -f $'/tmp/test\nnewline'

{"name":"'/tmp/test'$'\n''newline'"}
{"name":"'/tmp/test
newline'"}

[egmontkob]

Looks to me ...

(purely by reading the code; I haven't tested the behavior because for some mysterious reason that I haven't tracked down, a clean build of git checkout main && git pull && git clean -dfx && cargo build --release && cargo install --path . --locked did not build the stat utility for me)

... that there are other problems as well, both prior to and after the proposed PR (hence I'm commenting here rather than to the PR).

"Simple" strings are enclosed between pairs of " if they don't contain ', and pairs of ' otherwise. So if a filename contains both ' and ", the quoting is broken.

If you escape a newline as \n, and leave everything else unescaped, you cannot distinguish this from a filename actually containing a \ followed by a n (assuming that there's a control char elsewhere, so that this non-shortcut branch is hit). The escaping character itself, i.e. \ in this case, always has to be escaped if you need unambiguous output.

You may open a $' and eventually close by another ', but in between you print other control chars (e.g. byte 0x01) as-is. The purpose of this kind of quoting is to produce human-readable output and thus produce literal $'\001' in this example. Also, as part of this game, avoid possibly emitting the terminal's escape character which could drive the terminal in uncontrolled ways.

Looking at the bigger picture:

There's already a shell escaping code in ls, parts of which are reused for printf %q, and are already somewhat buggy and being fixed under #9638. I think it would be desirable to only have one single, shared, extremely thorougly unit-tested implementation in the codebase. That is, please reuse what ls currently does, possibly depending on its work-in-progress fixes if required; rather than reinventing the wheel with a brand new nice set of bugs.