bug-findutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

re: findutils bug 10609 (find needs fix re format strings)


From: Chris Chittleborough
Subject: re: findutils bug 10609 (find needs fix re format strings)
Date: Sun, 10 Oct 2004 20:45:50 +0930
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113

I've attached a code-only patch to the savannah page for this item
(https://savannah.gnu.org/bugs/index.php?func=detailitem&item_id=10609).

I've also added the following text as a followup comment. (This message will probably be easier to read, because I somehow managed to lose the indentation of the lines from my comment. Do-oh. I recommend a monospaced font.)
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
I've been thinking about how find's format codes *should* work in an ideal world, and came up with the following proposal. The lines beginning with two plus signs describe changes to find's current behaviour.

  CODE  STYLE   MEANING
   a    string  last access time in ctime() format
   A<K>   string  last access time using strftime() code <K>
   b    integer size in 512-byte blocks, rounded up
   c    string  status change time in ctime() format
   C<K>   string  status change time using strftime() code <K>
   d    integer depth
   f    string  file name (= basename(%p))
   F    string  filesystem type (a string)
   g    string  group name (or number)
   G    integer group number
   h    string  directory (= dirname(%p))
   H    string  command-line arg under which file was found
   i    integer inode number in decimal
   k    integer size in 1K blocks, rounded up
   l    string  target of symlink; "" for non-symlinks
   m    special modes (really permissions) in octal
++ M    string  mode in string format (eg., "drwxr-xr-x")
   n    integer number of hard links
   p    string  file's path
   P    string  file's path with command-line arg (=%H) removed
   s    integer size in bytes
++ S    string  size in human-friendly notation (like df -h)
   t    string  last modification time in ctime() format
   T<K>   string  last modification using strftime() code <K>
   u    string  user name (or number)
   U    integer user number

 String-style conversions are of the form
   "%" {<str-flag>} [<min-width>] ["."<max-length>] <code>
 where <str-flag> can be
        "-" for left-justification (iff <width> specified),
++   or "#" for Unix-style (backslashed) quoting.
 This could be implemented by using a "%[-][<width>][.<max-length>]s"
 format with fprintf().  (If "#" is specified, a backslash-escaped
 string is used instead of the original string.  Note that the -ls
 predicate performs backslash-escaping of pathnames.)

 Number-style conversions are of the form
   "%" {<num-flag>} [<min-width>] ["."<min-digits>] <code>
 where <num-flag> can be
        "-" for left-justification (ignored unless <width> specified),
++      "0" to pad with leading 0s (ignored if "-" used),
++      "+" to output a plus sign before the digits,
++      " " to output a space before the digits (ignored if "+" used),
++   or "'" to group digits in a locale-specific way.
 Possible implementation: use a "%{<num-flag>}[<width>][.<min-digits>]u"
 format with fprintf(), modulo type modifiers.
 Notes:
++      * I suspect that most find users would expect the "0", "+" and
++        " " flags and the ".<min-digits>" specifier to be supported
++        for numeric conversions; certainly *I* was suprised to find
++        they weren't.
++      * I think the "'" flag would be a useful addition to find.
++      * if "'" is used and the local fprintf() does not support "'"
++        itself, we have to insert the grouping separators (and pad the
++        result) ourselves.
          (Version 2 of the Single UNIX Specification, which dates back
          to 1997, requires support for the "'" flag.)

 The %m format is of the form
   "%" {<m-flag>} [<min-width>] ["."<min-digits>] "m"
 where <m-flag> can be
        "-" for left-justification (iff <width> specified),
++   or "#" to force a leading zero.
 This can be implemented using a "%{<m-flag>}<min-width>.<min-digits>o"
 format with fprintf().
 Notes:
++      * We always specify both <min-width> and <min-digits>.
++      * <min-digits> defaults to 3, to match most people's
++        expectations.
++      * <min-width> probably should default to 5.

ASIDE
Even with the above changes, it is not possible to write a printf format which is equivalent to -ls. With three more changes, it would be possible:
  * Let %s with a "#" flag behave differently with block and character
    devices: instead of printing a meaningless number, print the major
    and minor device numbers in "%3u, %3u" format.
  * Add a %L code, which generates "-> %l" for symbolic links and zero
    characters for everything else.
  * Add a time format code, possibly "-", which uses the strftime()
    formats "%a %b %d %H:%M" (for timestamps in the previous six months)
    or "%a %b %d  %y" (for all other timestamps).
Then -ls would be identical to
        -printf '%6i %4k %M %3n %0-8.8u %-8.8g %#8s %T- %p%L\n'
except that -ls uses %4b instead of %4k in POSIXLY_CORRECT mode.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]