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

[Paul E Condon]

On 20150222_1703+0000, James Youngman wrote:
> Update of bug #44221 (project findutils):
> 
>                 Severity:              3 - Normal => 2 - Minor              
>                   Status:                    None => Wont Fix               
>              Open/Closed:                    Open => Closed                 
> 
>     _______________________________________________________
> 
> Follow-up 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.

I am a plain user who joined this list in order to learn, but ...

An option to pre-scan the command line as submitted and rearrange it
to comply with the options-before-commands syntax could be implemented
*as an option*. Then this new 'option' could become the 'default', and
users who really want the current behavior, could continue the have it
by rejecting the default.  This is somewhat the behavior of many
utilities concerning strict POSSIX compliance. It is true that it is
inefficient to have two scans of the command line, but it maybe costs
less than a millisecond of computation in each invocation of find,
which over time, will probably never accumulate to the amount of time
that has already been wasted on this test of wills. Also, balance this
against the waste of cpu cycles for issuing the current warning message.

I lack the coding competence to actually do this, so this is just a
suggestion of a way to go.

-- 
Paul E Condon           
address@hidden