Follow-up Comment #7, bug #64816 (project findutils):
> 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).
_______________________________________________________
Reply to this item at:
<https://savannah.gnu.org/bugs/?64816>
_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/
