bugfindutils - Bugs: bug #32976, find has no option to ignore case...

 
 

bug #32976: find has no option to ignore case of starting directories

Submitted by:  Linda A. Walsh <law>
Submitted on:  Sat 02 Apr 2011 09:25:46 PM UTC  
 
Category: findSeverity: 1 - Wish
Item Group: NoneStatus: Need Info
Privacy: PublicAssigned to: None
Originator Name: Open/Closed: Open
Release: 4.4.0Fixed Release: None

Add a New Comment (Rich MarkupRich Markup):
   

You are not logged in

Please log in, so followups can be emailed to you.

 

Wed 25 Sep 2013 11:49:53 PM UTC, comment #4:

> 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.

Linda A. Walsh <law>
Wed 25 Sep 2013 09:13:43 PM UTC, comment #3:

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.

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.

These are, in my conception of things at least, different concepts.

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?).

On the other hand, if /foo/ is a case-sensitive file system, /foo/BAR and /foo/bar are distinct names; zero, one or both of these files may exist, and find will corrrectly treat these as distinct.

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.

Did I misunderstand something? Please correct me if I did.

James Youngman <jay>
Project Administrator
Sun 15 May 2011 10:49:51 PM UTC, comment #2:

A starting path is one given on the command line telling find where to start the search, i.e: the 'path' in:

find [-H] [-L] [-P] [-D debugopts] [-Olevel] [path...] [expression]

Ex:
/tmp$ touch a
/tmp$ find A
find: `A': No such file or directory
/tmp$ find -i A
find: unknown predicate `-i'

Note that while a -i form ignores case for all other path options, it doesn't work for the path telling find where to start the search.

Also, please note: ignoring case of paths was considered a necessary feature of find, but it doesn't work for starting paths. I would (and did) consider this to be a bug (even though it may have been forgotten during the design phase). I wouldn't consider consistent treatment for paths to be something that fell into the category of a 'wish'. However, given my experience with some paid products, recently, even being able to 'install' software is sometimes not something that some companies consider to be a supported feature. :-/ (sigh)...

Linda A. Walsh <law>
Sun 15 May 2011 08:50:28 PM UTC, comment #1:

If I understand what you're asking for, this is what -iname does.

/tmp$ touch x
/tmp$ find x -iname X
x

If this isn't what you are interested in, could you be more specific?

James Youngman <jay>
Project Administrator
Sat 02 Apr 2011 09:25:46 PM UTC, original submission:

While find has options to ignore case on the linkname, name and regex options, there is nothing that will allow it to ignore case for the starting path options.

I don't understand why case ignore was provided on 3 of the name match options (-name, -regex, -lname), but left off the 4th (starting name). Seems like a gaping design hole to do it in in 75% of the name match options, but leave it off the 4th.

The need to fix inconsistent user interface options, IMO, should have been a high-priority item as soon as it was decided to implement that feature for the other options.

However, given the rise in the use of linux servers for windows, it can only be that its priority would be even higher now.

Linda A. Walsh <law>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach File(s):
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by jay (Posted a comment)
  • -unavailable- added by law (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 2 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Sun 15 May 2011 08:50:28 PM UTCjaySeverity3 - Normal=>1 - Wish
      StatusNone=>Need Info

    Back to the top


    Powered by Savane 3.1-cleanup