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/