bugfindutils - Bugs: bug #31943, Optional path component not...

 
 

bug #31943: Optional path component not documented as being a valid extension of POSIX

Submitter:  None
Submitted:  Tue 21 Dec 2010 04:18:36 PM UTC
   
 
Category:  find Severity:  3 - Normal
Item Group:  Wrong result Status:  Wont Fix
Privacy:  Public Assigned to:  ericb
Originator Name:  Chris Rees Originator Email:  -email is unavailable-
Open/Closed:  Closed Release:  None
Fixed Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Tue 21 Dec 2010 06:04:59 PM UTC, comment #3: 

Sounds great, thanks for the effort.

Chris

Chris Rees <cmjrees>
Tue 21 Dec 2010 05:01:28 PM UTC, comment #2: 

About the only thing we could do at this point is make more prominent mention in the info and man documentation that it is a non-portable GNU extension that allows one to omit a leading pathname.

That is, change the last sentence of:

The command line may begin with the `-H', `-L', `-P', `-D' and `-O' options.  These are followed by a list of files or directories that should be searched.  If no files to search are specified, the current directory (`.') is used.

to:

As a GNU extension, if no files to search are specified, the current directory (`.') is used.

Eric Blake <ericb>
Group administrator
Tue 21 Dec 2010 04:57:03 PM UTC, comment #1: 

POSIX 2008 was specifically modified to allow GNU find's behavior of an optional path component (but you are correct that it is a violation of POSIX 2001).

http://pubs.opengroup.org/onlinepubs/9699919799/utilities/find.html

"If the first operand starts with a '-' , or is a '!' or a '(' , the behavior is unspecified."

I'm considering closing this as WONTFIX - it is not worth our efforts to cater to older POSIX to require failure.  And the only other way to report failure is by the addition of extra parameters or by the presence of POSIXLY_CORRECT - which won't catch the non-portability aspect in the common case when you are not using these extra options.

Eric Blake <ericb>
Group administrator
Tue 21 Dec 2010 04:18:36 PM UTC, original submission:  

Most operating systems (FreeBSD [1], Solaris [2]) implement the correct behaviour when not give a path to search.

Example:

$ find -type d

should fail.

Find should require the first non-option to be a path, whereas this variant assumes '.' if not provided.

This means that people writing scripts often don't make them portable; for example the busybox project had some in their Makefiles until recently [3]

Perhaps now the damage is done, a warning could be given if this incorrect behaviour is relied upon?

I'll write a patch shortly if that sounds agreeable.

[1] http://nixdoc.net/man-pages/FreeBSD/find.1.html

[2] http://docs.sun.com/app/docs/doc/816-0210/6m6nb7m9j?l=en&a=view

[3] http://git.busybox.net/busybox/commit/?id=12caabfa2da59ef877ad7ccbe949164dcc6d69e4

Anonymous

 

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

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by jay (Updated the item)
  • -email is unavailable- added by cmjrees (Posted a comment)
  • -email is unavailable- added by ericb (Posted a comment)
  • -email is unavailable- added by None (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 4 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2011-04-02 jay Open/ClosedOpen Closed
    2010-12-21 ericb SummaryOptional path component violates POSIX Optional path component not documented as being a valid extension of POSIX
    2010-12-21 ericb StatusNone Wont Fix
        Assigned toNone ericb

    Back to the top

    Powered by Savane 3.13-758e.
    Corresponding source code