Geoff Clare <g...@opengroup.org> wrote:
> Joerg Schilling <joerg.schill...@fokus.fraunhofer.de> wrote, on 03 Jul 2019:
> > pax is not a shell and ls does not include own pattern matching.
> >
> > You thus cannot compare the behavior of these programs with each other or
> > with
> > a shell.
>
> Huh?
>
> find, pax, fnmatch() and glob() all do pattern matching as described in
> XCU 2.13. The shell is supposed to as well.
>
> I already said it has nothing to do with ls.
If you agree that this has nothing to do with ls, then you should also agree
that pax and find (that include pattern matching in contrary to ls) still
cannot be discussed together with shell behavior since pax/find do not have a
shell interpreter for strings inside their code.
As mentioned by Stephane, there is no support for find -name '"*".c' and the
content of the -name argument in find is typically controlled by the string
processing of the shell or by a prepared string from a program that calls
exec().
There is backslash processing by fnmatch() (in former times glob()) and there is
backslash processing in the shell string parsing and processing.
The backslash processing in the string processing of the shell is unchanged
since 42 years and if that was a problem, it had been discussed in the 1980s
already. If we like to keep compatibility, we cannot change the requirement for
somthing as important as that shell feature. If you like to have special
"escaping" for some characters to treat them literally, you can use [c] for
such a "c" and this is a method that has already been discussed in the 1980s in
the related Usenet groups.
Jörg
--
EMail:jo...@schily.net (home) Jörg Schilling D-13353 Berlin
joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.org/private/ http://sf.net/projects/schilytools/files/'
