> well, you were asking for a GNU extension as well ...

Arguably, but at least in the GNU world, there is only one find implementation used (though there are other program like fd, which do something similar), while there are many different shells used.

Most notably, ash-based shells are used in many areas (e.g. Debian uses it as /bin/sh and thus for most scripts, busybox and klib-utils ship an ash-based sh).
And while bash does already support read -d '', ash-based shell's don't - and the POSIX revision that includes it isn't even out yet.

> we can suggest and add a lot of options and features,
> but to keep the code as compact as possible, we should
> encourage people to use what's there, i.e., use the GNU
> toolbox.  Therefore, before talking about what to add,
> let's take the time to talk about why to add it, and what
> kind of problem to solve with it.

Seems reasonable.

My main points for adding such feature would be:
1) Homogeneity with other GNU tools, especially coreutils whose ls provides already a way to quote the output like that.

find, as of now and not assuming -print0, uses various styles:
With -ls it seems to be a format that does quote, but is still different from what ls would do. e.g. find -ls':
./\360\221\231\243\360\221\231\244\360\221\231\246
./g\ h
vs ls':
𑙣𑙤𑙦
'g h'
etc.

I'd say it would make sense to align that to what ls does, which is IMO easier to read.


2) Usefulness of the printed data.

With -print and when connected to a terminal, it seems to do what ls did long ago (so called 'literal' style, despite it's not really literal) and use a ? instead of problematic characters.
Which is IMO quite useless, not only when there are multiple files which differ only in the non-printable character, but also when there's a file that would really use a ?.

If the default would change here, then sure, some people will complain (as they did with ls), but it should be only user human-readable output that changes - and if anyone fakes a terminal to be connected while still using the data in scripts... well... own fault.

With output not connected to a terminal output really seems to be literal, but that breaks as soon as files contains newlines, which - while uncommon - is still completely valid to have.

While I don't think the default should be changed in this case, it would still be nice to have a format that can be reused (which of course -print0 would also give).



3) Alternative to -print0
As said, right now it's not yet even possible to write a portable shell script which can read that. In command substitution NUL is not allowed (and would likely fail if there are more than one record) and read -d '' is so far not everywhere available.

Also using it sees more cumbersome to me than e.g. simply doing something like:
  ls $(find … --quoting-style=shell-escape)
(and yes it's clear that this particular example can also be made with -exec or xargs).

> [...] most of the POSIX shell and utilities have no support for printing or reading NUL delimited, it's only GNU extensions [...]

well, you were asking for a GNU extension as well ...

But back to the requirement.

Of course, we can suggest and add a lot of options and features, but to keep the code
as compact as possible, we should encourage people to use what's there,
i.e., use the GNU toolbox.  Therefore, before talking about what to add,
let's take the time to talk about why to add it, and what kind of problem to
solve with it.  Eventually, there are already several other existing solutions
out there, and this would be a strong argument against adding new things.

TBH I'd not consider the for-loop example in the original report as sufficient as an
argument to add something in find/xargs, because there are several ways to
do such processing safely and efficient already.

So what is the concrete problem to be solved (which cannot already be solved
in the one or the other way)?

>  [...] shells don't work very well with NULL delimited output.

I'm not sure I follow this statement.
Actually, NUL-terminated processing is the safest way of file name
processing with tools in shells, because the NUL character is the only one
(apart from a directory separator) which cannot be part of a file name.

Therefore, instead of going the route further down to use escaped strings
in find/xargs for further processing, the better way is IMO to give better
support of NUL-terminated in-/output to all tools.
The recent addition of the '-files0-from ...' option in find(1) was exactly
doing that.

The above is addressing the area of safely processing of file names in combination
with other tools via shell scripts/pipes, etc.

The discussion about 'find -ls' displaying information to the terminal and which
quoting style to be chosen best is a different one.
The point here is that the output should be safe no matter what malicious file
an attacker might have placed, i.e., it should not disturb the terminal settings.

Maybe it would also make sense to add the same functionality to xargs.

The idea is, that (POSIX compatible) shells don't work very well with NULL delimited output.

If some program produces such, it's output could be piped into xargs -0 ... and if that would now have an output mode that produces a string that is re-usable in the shell, one could rather easily get e.g. strings with trailing newlines into shell variables.

Something like:
eval "set -- $(  printf 'a\n\0b\nc\0d\n\n' | xargs -0 -- --quoting-style=shell-escape )"

where the printf simulates an arbitrary program that outputs byte strings NULL-delimited, which are then read by xargs and printed again but escaped for the shell to be re-used as input (without any command substitutions, etc. happening)... and in this example, set as the new positional parameters, which might be quite handy for e.g. shell functions.


[ Also notice, that this is not easily doable with shell command substitution ( $(... ) ) as that drops trailing newlines.
And yes I know, there are hacks around that (using sentinel values) but making the truly portable is something between tricky/fragile to not possible. ]


Just an idea though.