bugfindutils - Bugs: bug #44221, Spurious warning about non-option...


bug #44221: Spurious warning about non-option arguments is spurious

Submitted by:  None
Submitted on:  Tue 10 Feb 2015 01:45:22 PM UTC  
Category:  find Severity:  2 - Minor
Item Group:  Wrong result Status:  Wont Fix
Privacy:  Public Assigned to:  None
Originator Name:  Andrew McGill Originator Email:  -email is unavailable-
Open/Closed:  Closed Release:  4.4.2
Fixed Release:  None

Add a New Comment (Rich Markup)

You are not logged in

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


( Jump to the original submission)

Sun 22 Feb 2015 05:03:48 PM UTC, comment #8: 

Dale's most recent comment captures precisely the reason why I added this warning (see http://git.savannah.gnu.org/cgit/findutils.git/commit/?id=d4ed83819c9ced4a2453473851456177d6bb4857).

The initial bug report does limit the scope of the complaint to command-lines in which all tests are joined by AND conditions.   In those cases the warning is, perhaps, useless.   However, it's quite complex to implement an exception for that case accurately, since the options aren't propagated into the resulting expression tree.    Limiting the cases in which the warning is issued would likely require either leaving a placeholder for each global option or perhaps parsing the command line an extra time.

I don't believe the additional complexity of either approach is justified.  For that reason, and despite the fact that the complaint does have merit, I'm going to close this bug as working-as-intended (for which the nearest status code in the Savannah UI is "Won't Fix").

However, I'm willing for this not to be the end of the discussion.   If you think that "find" can be improved in this respect and at a very small complexity cost, please feel free to contribute (see README.hacking) a patch demonstrating your point.

James Youngman <jay>
Project Administrator
Mon 16 Feb 2015 08:06:32 PM UTC, comment #7: 

Given the existence of -o and !, it is not true that "everything after a dash is a filter that narrows down the scope of what find finds".  That is the fundamental reason users have to be made aware of the proper use of options -- they don't work like most users think they work.  Yes, if you aren't using -o or !, then the one obvious interpretation of a misused -maxdepth (move it to the beginning) is almost certainly what the user expects, but if there is a -o, the odds are quite good that the one obvious interpretation is not what the user expects.  (Indeed, there is no way to specify to find what the user is likely expecting.)

Dale Worley <worley>
Mon 16 Feb 2015 09:16:28 AM UTC, comment #6: 

To most users everything after a dash is a filter that narrows down the scope of what find finds.  For -maxdepth and -mindepth specifically this is a completely valid interpretation, and the distinction between options and tests is like the distinction between procedures and functions.

Andrew McGill <list2014>
Mon 16 Feb 2015 03:32:27 AM UTC, comment #5: 

My expectation is that the warning's purpose is to make the user aware that there are some things that look like tests but are in fact options, and the user has most likely gotten that wrong.  If the user writes "find -type f -mindepth 4 ...", he probably thinks that -mindepth is a test and the location that it is written can have some effect.

The reason not to use the one possible interpretation is that there is a high probably that the user's mental model doesn't match reality.  Don't try to DWIM when it's likely that what the user means can't possibly be right.

Dale Worley <worley>
Thu 12 Feb 2015 04:24:13 PM UTC, comment #4: 


find -type f -ls -a -mindepth 4 -delete

That's an odd example ... I'm really struggling to understand what possible interpretation -mindepth could have here other than the one it has .. maybe someone might want to list all files but delete only some of them?  Without the warning they may be unable to figure out why they did not list things below depth 4?  Is the problem not that an output action, "-ls" appears before -mindepth? 

Here is a restatement of the command with no opportunity for ambiguity, which nevertheless generates a warning:

  find -type f -mindepth 4 -ls -a -delete

Even this wildly incorrect invocation can only be understood in one way (and it is somehow allowed, when "find -type f -a" is not):

  find -type f -a -mindepth 2

While it is fun to educate users that they are misunderstanding the more subtle points of finding files, a 37 word warning lecture when there is no possible ambiguity or bug seems petulant rather than helpful. 

Andrew McGill <list2014>
Thu 12 Feb 2015 09:42:27 AM UTC, comment #3: 

That might be true in your simple case, but it does not hold in general.  What about the following command for instance?

find -type f -ls -a -mindepth 4 -delete

Kamil Dudka <kdudka>
Thu 12 Feb 2015 09:26:50 AM UTC, comment #2: 

Indeed, you do need to order options and non-options, but only because of this spurious warning that is printed when you do not do so. 

It looks like the warning is intended to cater for options which affect tests after them, namely:

  -follow (deprecated)
  -daystart (didn't know about this, looks interesting)
  -regextype (this also looks interesting)

All the other options are global in scope - they cannot be construed to apply differently based on their position in the command line.

The distinction between "options" and "tests" is almost completely artificial.  "-mindepth" is a test which excludes files below the required depth.  Everyone knows that "find" lists these files, and rejects them for failing the test.

Andrew McGill <list2014>
Tue 10 Feb 2015 02:06:47 PM UTC, comment #1: 

-mindepth and -maxdepth are options whereas -type is a test.  You need to specify options before non-optionos (tests and actions).

Kamil Dudka <kdudka>
Tue 10 Feb 2015 01:45:22 PM UTC, original submission:  

When you specify multiple options which must all apply (AND-logic) then for -maxdepth n and -mindepth n, find lately displays a warning, explaining that there are fine points of the order of operations at work -- as if find is using a special form of logic which is something less than boolean.  This warning makes no sense at all.  For a file to be 'found', ALL of the conditions have to apply.  Why would anyone care which one fails first?  Specifying multiple AND-conditions for find is the most common use case, and for this use case, without a single OR-condition, the warning is most rudely displayed.  Other GNU utilities allow arguments (additional conditions) to be added at the end of the command line, but find has this feature / regression by which it does not do so.

It seems that `find' is trying to warn the uer about the global nature of -maxdepth and -mindepth -- but this warning is entirely unnecessary when the entire find command consists of AND-conditions.  All conditions must apply, so none of them apply first. 

This spurious warning is a good and proper bug, as evidenced by the slew of bug reports in all sorts of projects since 2006

To reproduce this bug:

  find -type f -maxdepth 1 -mindepth 1

Expected behaviour:

  print a list of files in the current directory, without spurious warnings.

Incorrect behaviour:

Spurious warnings are printed.

find: warning: you have specified the -mindepth option after a non-option argument -type, but options are not positional (-mindepth affects tests specified before it as well as those specified after it).  Please specify options before other arguments.

find: warning: you have specified the -maxdepth option after a non-option argument -type, but options are not positional (-maxdepth affects tests specified before it as well as those specified after it).  Please specify options before other arguments.

Proposed fix 1:

  Only display this warning when it may indicate a logic bug, e.g. OR-logic is included.  (I can't improve this suggestion, since I don't understand circumstances where one would benefit from this warning.)

Proposed fix 2:

  Remove this warning as per attached patch :P

(How about this: no warning is showed for "find -maxdepth 1  -print  -type d" where "-type d" has no effect ... this is a real error ...  unless it was "-type d $ACTION" where $ACTION is null ...)



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

Attach Files:

Attached Files


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -email is unavailable- added by jay (Posted a comment)
  • -email is unavailable- added by jay (Bill Gradwohl previously reported this as #15360)
  • -email is unavailable- added by worley (Posted a comment)
  • -email is unavailable- added by list2014 (Posted a comment)
  • -email is unavailable- added by kdudka (Posted a comment)
  • -email is unavailable- added by None (Submitted the item)

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

    Only logged-in users can vote.




    Follow 5 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2015-02-22 jay Severity3 - Normal => 2 - Minor
        StatusNone => Wont Fix
        Open/ClosedOpen => Closed
    2015-02-22 jay Carbon-Copy- => Added bill@ycc.com
    2015-02-10 None Attached File- => Added findutils.positional-warnings-considered-harmful.diff, #33046

    Back to the top

    Powered by Savane 3.5