Follow-up Comment #4, bug #32976 (project findutils):
> I don't really see these as being inconsistent; /some/path/some-basename is
a
> path name, and the named file either exists or it doesn't.
----
It either exists in "some case" or not (on a case sensitive file
system).
> The tests implemented by find (such as -iname) are essentially a query
> language allowing the user to specify which files they would like to see in
> the results.
----
Right -- and the initial directory list is a list of starting points
or subtrees where you would like the query to return results from. I.e.
the starting points are part of the query. With different starting
points, it is a query that returns a different result -- just like DNS.
If I query for "Eng.machine_a", I might get an answer if my DNS server
defaults to "ibm.com", vs. on the outside, it would likely return an
error.
> These are, in my conception of things at least, different concepts.
---
They can be viewed arbitrarily based on any persons definitions.
I don't see that as being of primary importance.
> If /foo/ is a case-insensitive file system, then surely "find /foo/BAR" and
> "find /foo/bar" should produce similar results. Identical in fact, apart
from
> the case of "BAR" in the output. I believe this should already be
happening
> (or am I wrong?).
----
I don't know. I made no mention of a case-insensitive file system.
That would be something outside the realm of find. I am only talking
about how find processes arguments given to it (on a command line or
in an argv array).
> TL;DR: Start points are treated case-insensitively if they exist on a
> case-insensitive file system, and case-sentively if they exist on a
> case-sensitive file system.
---
I'm referring to arguments given to 'find' -- not features of a file
system or OS that are outside of find. The "iname" option functions
independently of the the OS and file system. That is the only
functionality that I am saying is missing in the path processing on the
command line. Switches on find's command lines can say to process paths
or regex's in a case insensitive manner, but nothing allows for ignoring
the case of the "base" or "starting point[s]" of the query.
To use your filesystem argument as an example -- if a filesystem has
stored randomly "cased" filenames, because some people wanted "Home" and
"Doc" instead of "home" and "doc", find has no way of specifying that it
should ignore the starting path's case. If "ignoring case" of items to
search for was considered necessary enough to provide case-ignoring
options for path and regex (where it isn't really necessary anyway), it
seem that being able to ignore the case of the starting path would be
equally important.
TL;DR: Filesystem features are not part of a query that one can control.
It doesn't seem logical to divert a discussion of how find processes its
command line arguments to things outside the domain and control of find.
The point is how to tell find to process paths case insensitively and
how to include or access such functionality for the query start point.
_______________________________________________________
Reply to this item at:
<http://savannah.gnu.org/bugs/?32976>
_______________________________________________
Message sent via/by Savannah
http://savannah.gnu.org/
