bugfindutils - Bugs: bug #56855, find -printf %h gives an empty...

 
 

bug #56855: find -printf %h gives an empty string for the root directory '/'

Submitter:  Tavian Barnes <tavianator>
Submitted:  Tue 03 Sep 2019 03:56:18 PM UTC
   
 
Category:  find Severity:  3 - Normal
Item Group:  None Status:  None
Privacy:  Public Assigned to:  None
Originator Name:  Open/Closed:  Open
Release:  4.7.0 Fixed Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Thu 27 Apr 2023 08:19:03 PM UTC, comment #3: 

POSIX is clear in https://pubs.opengroup.org/onlinepubs/9699919799/functions/dirname.html that the dirname(3) function returns a non-empty string for input of "/".  However, POSIX is also clear that the string composed by 'dirname(str)+"/"+basename(str)' need NOT refer to the same file as 'str'; case in point: when str is "//", POSIX says you could end up with any of "///", "////", or "/////" depending on choices made in basename and dirname, but all of those results are equivalent to to "/" while POSIX is explicit that "//" may be distinct from "/".

Similar arguments can be made about the behavior of the basename(1) utility.

However, since -printf is not defined by POSIX, there is no requirement that %h be defined by the POSIX functionality of basename(3) (the function), nor of basename(1) (the utility).  However, if we intend to return the empty string, it IS a bug if our documentation is not explicit that we intentionally differ in behavior from the POSIX functions, and give examples why we think that is the right thing to do.

Eric Blake <ericb>
Group administrator
Sun 23 Apr 2023 07:00:54 AM UTC, comment #2: 

I think that it's correct that "the dirname of the path" is the empty string when the directory is the root directory. The root directory has no name. The path separator ("/") is not a name. More importantly, this behaviour cannot change because it has been in place for decades. Changing it could only cause problems.

raf <raf>
Tue 03 Sep 2019 08:42:25 PM UTC, comment #1: 

There is also a case for having the empty string there. If it was the case for %f as well, that would mean that -printf %h/%f would always be equivalent to -printf %p

More importantly, in cases like:


find / -name foo -printf '%h/bar\0' |
  xargs -r0 cmd


that means you don't get an incorrect bar when foo is found in /.

Remember that foo is not guaranteed by POSIX to be the same as /foo (and in practice is not on some systems like cygwin).

The :h and :t history modifiers of tcsh and bash (not zsh) do return the empty string for /


Stephane Chazelas <stephanechazelas>
Tue 03 Sep 2019 03:56:18 PM UTC, original submission:  

This is just https://savannah.gnu.org/bugs/?50259#comment13, but I thought it deserved its own report.

https://git.savannah.gnu.org/cgit/findutils.git/commit/?id=855dbdadbf75ca1f08f3e1c7c6811670e952d906 even documents that %h should give the dirname of the path, but:


$ find / /tmp -maxdepth 0 -printf '[%h]\n'
[]
[]
$ dirname /
/
$ dirname /tmp
/


%h giving the empty string can be a problem if you are using -printf to output paths for processing by some other command, for example.

Tavian Barnes <tavianator>

 

(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 ericb (Posted a comment)
  • -email is unavailable- added by raf (Posted a comment)
  • -email is unavailable- added by stephanechazelas (Posted a comment)
  • -email is unavailable- added by tavianator (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.

     

    No changes have been made to this item

    Back to the top

    Powered by Savane 3.12