bugfindutils - Bugs: bug #64100, wish/request: please reserve...

 
 

bug #64100: wish/request: please reserve -printf "%V %v %E %R %r %B %e %J %I %z %x %X %j"

Submitter:  raf <raf>
Submitted:  Sun 23 Apr 2023 11:57:45 PM UTC
   
 
Category:  find Severity:  3 - Normal
Item Group:  None Status:  None
Privacy:  Public Assigned to:  None
Originator Name:  raf Open/Closed:  Open
Release:  None Fixed Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Wed 26 Apr 2023 06:31:44 AM UTC, comment #6: 

comment #5:

> Regarding format specs like "left-justified in a column of width 20":
> I don't believe that it s find(1)s task to do formatting, and such features would
> add unnecessarily large code while subsequent and existing formatting tools, e.g. numfmt(1),
> can easily do that already.  One tool for one purpose.


find already does support printf(3)-style flags, field widths and precision specifiers. The behaviour isn't entirely consistent with printf(3) (some flags/precision specifiers behave differently for text and number conversions, but find treats most numbers as though they were text in this regard), but it's close.

> Regarding the requested formatting range:
> I don't believe that it's good for find to add too many features in the future,
> especially those which are specific to certain filesystems.
> That kind of information can be retrieved with or in combination with
> other existing tools already, so that would just be yet another way to
> achieve things.
> Hence it's unlikely that there'll be a "clash" with how rawhide interprets the
> formatting characters.


I thought that would probably be the case, but wanted to let you know just in case.

> But anyway, thanks for the heads-up, and we now have this as reference in the
> bug tracker.


Thanks.

raf <raf>
Tue 25 Apr 2023 06:33:57 AM UTC, comment #5: 

My first thought on this request was rather how are other well-known tools which are specified by POSIX doing this?
Hence I compared find's -printf percent formats to that for stat(1) from the GNU coreutils.
Unluckily, there's maybe only 30-40% of overlap.
Users have to know per tool.

Regarding format specs like "left-justified in a column of width 20":
I don't believe that it s find(1)s task to do formatting, and such features would
add unnecessarily large code while subsequent and existing formatting tools, e.g. numfmt(1),
can easily do that already.  One tool for one purpose.

Regarding the requested formatting range:
I don't believe that it's good for find to add too many features in the future,
especially those which are specific to certain filesystems.
That kind of information can be retrieved with or in combination with
other existing tools already, so that would just be yet another way to
achieve things.
Hence it's unlikely that there'll be a "clash" with how rawhide interprets the
formatting characters.

But anyway, thanks for the heads-up, and we now have this as reference in the
bug tracker.

Bernhard Voelker <berny>
Group administrator
Tue 25 Apr 2023 05:46:33 AM UTC, comment #4: 

comment #2:

> It might also be useful to allow the user to specify how the program should respond if a format specifier is
>
> (1) unknown to the implementation
> (2) known to the implementation but not supported on the platform
> (3) supported on the platform but not retrievable (example: AFS provides sufficiently granular permissions that you can have only some metadata accessible; similarly on Unix it can be possible to count the subdirectories a directory has but not the files).
>
> Possible responses might include (a) failing immediately, (b) printing spaces or (c) printing nothing and ensuring that the final exit status is nonzero.


I don't think that any user will want to have to think about this or make such decisions. The existing documentation states that any unknown format conversion specifiers results in undefined behaviour. I think it would have been much better for unknown format conversion specifiers to result in an error. That would prevent any users from being sloppy. That's the only way to ensure that adding new format conversion specifiers won't change the behaviour of any existing commands. But it's too late to fix that. But since the documentation has explained that the use of previously non-existent format conversion specifiers results in undefined behaviour, it is acceptable to replace that undefined behaviour with new defined behaviour.

raf <raf>
Tue 25 Apr 2023 05:35:03 AM UTC, comment #3: 

comment #1:

> This is quite a sizeable chunk of the available namespace. 


Yes, but currently unclaimed and therefore safe to claim (according to the existing documentation).

> I suggest instead we agree a compatible way to extend things while staying mostly out of each other's way. Here's a strawman:
>
> %{ns/ns/path:keyword:flags}


I'm glad that you present that as a strawman argument. They are intended to be torn down:

No offense intended, but that looks terrible. I can't imagine that any user would be happy with being required to use that notation, when a single-letter format conversion (such as %I) could have been possible instead.

> Here "flags" is the usual size and so on.


If such notation were implemented, I would reconmmend retaining the existing flag/fieldwidth/precision syntax inherited from printf(3). I don't think there's any good reason to modify the well-established overall syntax for format conversions. The only change should be that a single-letter format conversion, like %d, be expanded to %{...}. The flags, field width, and precision syntax doesn't also need to change.

So, the above should be: %[flags/width/precision spec]{...}

Not that I'm recommending that. I think it looks hideous. :-)

> ns/ns/path is just a namespace which serves to prevent collision and keyword describes the data to be formatted.   For example,
>
> %{gnu/find:version:-20}


That's far too many keystrokes. I can't believe that any user would be delighted with it.

> might print the version number of a file, left-justified in a column of width 20.   Other implementations of course would be welcome to implement formatting for gnu/find:version of course.
>
> We put the flags after ! instead of before the { so that we don't have to skip over flags to look at the keyword, and then have to go back to parse and understand the flags.
>
> I'm not sure that using : twice inside {} is a great idea because a different choice would probably make parsing easier.   Since my first choice was !, I changed my mind because of the need/difficulty of escaping ! on Unix systems.  So I fell back on : but maybe there's a better choice.


None of this is a great idea. It's too verbose for no reason. The above could be done with "%-20I".

> This idea, by the way, is why GNU find's documentation lists %{ as reserved for future use.


GNU find's documentation also states (unwisely in my opinion) that anything after % other than what has been defined results in undefined behaviour. It would have been wiser if unknown format conversion characters were documented (and implemented) as resulting in an error, rather than undefined behaviour. That would prevent anyone accidentally using them meaninglessly. But it is what it is. But it's still the case that there's no technical reason not to introduce new single-letter format conversion characters. The existing documentation allows for this. If anyone has used a -printf string containing %I for example, the format is undefined, and could therefore change to mean something specific and meaningful.


Anyway, rawhide (rh) has already started using the additional single-letter format conversions. I recommend that GNU find either use the same letters to mean the same things (if the additional functionality is ever added to GNU find), or that it not use them to mean anything else. Either is great. I won't be adding any %{...} notation to rawhide, because I don't think that it will delight the user.

raf <raf>
Mon 24 Apr 2023 05:27:07 PM UTC, comment #2: 

It might also be useful to allow the user to specify how the program should respond if a format specifier is

(1) unknown to the implementation
(2) known to the implementation but not supported on the platform
(3) supported on the platform but not retrievable (example: AFS provides sufficiently granular permissions that you can have only some metadata accessible; similarly on Unix it can be possible to count the subdirectories a directory has but not the files).

Possible responses might include (a) failing immediately, (b) printing spaces or (c) printing nothing and ensuring that the final exit status is nonzero.


James Youngman <jay>
Group administrator
Mon 24 Apr 2023 05:20:04 PM UTC, comment #1: 

This is quite a sizeable chunk of the available namespace. 

I suggest instead we agree a compatible way to extend things while staying mostly out of each other's way.   Here's a strawman:

%{ns/ns/path:keyword:flags}

Here "flags" is the usual size and so on.   ns/ns/path is just a namespace which serves to prevent collision and keyword describes the data to be formatted.   For example,

%{gnu/find:version:-20}

might print the version number of a file, left-justified in a column of width 20.   Other implementations of course would be welcome to implement formatting for gnu/find:version of course.

We put the flags after ! instead of before the { so that we don't have to skip over flags to look at the keyword, and then have to go back to parse and understand the flags.

I'm not sure that using : twice inside {} is a great idea because a different choice would probably make parsing easier.   Since my first choice was !, I changed my mind because of the need/difficulty of escaping ! on Unix systems.  So I fell back on : but maybe there's a better choice.

This idea, by the way, is why GNU find's documentation lists %{ as reserved for future use.


James Youngman <jay>
Group administrator
Sun 23 Apr 2023 11:57:45 PM UTC, original submission:  

Hi,

I've written a find-alternative called rawhide (rh) that does almost everything that GNU find can do (except file system type names), and can do a few additional things.

Rawhide's version of -printf (its -L option) has some extra %-notation things that I'm hoping you will consider reserving for potential future use in find:

    %V  The major device number of the device/filesystem that the file resides on (part of st_dev).

    %v  The minor device number of the device/filesystem that the file resides on (part of st_dev).

    %E  The device number of the file (st_rdev). This is only meaningful for character devices and block devices.
        See the related %R and %r format conversions (next) for the major and minor device numbers of the
        file.

    %R  The major device number of the file (part of st_rdev). This is only meaningful for character
        devices and block devices.

    %r  The minor device number of the file (part of st_rdev). This is only meaningful for character
        devices and block devices.

    %B  The preferred block size for efficient I/O on the file's filesystem (st_blksize). On some filesystems
        (e.g., zfs), this is specific to each file, rather than to the whole filesystem.

    %e  The ext2-style file attributes as a space-separated list of attribute names. This is available on
        Linux systems with libe2p. See chattr(1) and lsattr(1) for details. On other systems, this is the
        empty string.

        The possible ext2-style file attribute names are: secrm, unrm, compr, sync, immutable, append, nodump,
        noatime, dirty, comprblk, nocompr, encrypt, index, imagic, journal_data, notail, dirsync, topdir,
        huge_file, extents, verity, ea_inode, nocow, snapfile, dax, snapfile_deleted, snapfile_shrunk,
        inline_data, projinherit, and casefold.

    %J  The ext2-style project number. This is available on Linux systems with libe2p. See chattr(1) and
        lsattr(1) for details. On other systems, this is the empty string.

    %I  The ext2-style version/generation number. This is available on Linux systems with libe2p. See
        chattr(1) and lsattr(1) for details. On other systems, this is the empty string.

    %z  The access control list (ACL) as a comma-separated list of items. This is available on Linux, FreeBSD,
        macOS, Solaris, and Cygwin. On systems without supported ACLs, this is the empty string.

        FreeBSD and Solaris have NFSv4 ACLs with two forms of ACL text. By default, the compact form will be
        output. With the -v option, the non-compact form will be output. For "POSIX" ACLs (Linux and Cygwin)
        and macOS ACLs, the -v option has no effect.

        On Solaris, ACLs are always present by default, even if they are trivially identical to the file
        permission bits.

    %x  The extended attributes (EA) as a comma-separated list. This is available on Linux, FreeBSD, macOS,
        Solaris, and Cygwin. On systems without supported EAs, this is the empty string.

    %X  The access control list/extended attributes (ACL/EA) indicator (like in rh -l). When a (non-trivial)
        ACL is present, this is a plus sign ("+"). When any (interesting) EAs are present, this is an at sign
        ("@"). When both are present, this is an asterisk character ("*"). When neither is present, but there
        is an selinux(8) context, this is a dot character ("."). When none of the above are present, this is a
        space character (" ").

    %j  All of the file information in JSON format, representing an object with the following possible
        attributes:

            path (string) (same as %p)
            name (string) (same as %f)
            target (string) (same as %l) (only for symlinks)
            start (string) (same as %H)
            depth (integer) (same as %d)
            dev (integer) (same as %D)
            major (integer) (same as %V)
            minor (integer) (same as %v)
            ino (integer) (same as %i)
            mode (integer) (like %M, but in the underlying numeric form)
            modestr (string) (same as %M)
            type (string) (same as %y)
            perm (integer) (same as %m, but in decimal)
            nlink (integer) (same as %n)
            user (string) (same as %u) (only if a name is available)
            group (string) (same as %g) (only if a name is available)
            uid (integer) (same as %U)
            gid (integer) (same as %G)
            rdev (integer) (same as %E)
            rmajor (integer) (same as %R)
            rminor (integer) (same as %r)
            size (integer) (same as %s)
            blksize (integer) (same as %B)
            blocks (integer) (same as %b)
            atime (string) (like %a/%A@, but in ISO format)
            mtime (string) (like %t/%T@, but in ISO format)
            ctime (string) (like %c/%C@, but in ISO format)
            atime_unix (integer) (same as %A@)
            mtime_unix (integer) (same as %T@)
            ctime_unix (integer) (same as %C@)
            attributes (string) (same as %e) (only if available)
            project (integer) (same as %J) (only if available)
            generation (integer) (same as %I) (only if available)
            access_control_list (string) (like %z without the -v option, but not reformatted as a comma-separated list) (only if present)
            access_control_list_verbose (string) (like %z with the -v option, but not reformatted as a comma-
            separated list) (only if present)
            extended_attributes (string) (like %x, but not reformatted as a comma-separated list) (only if present)
            selinux_context (string) (same as %Z) (only if present)
            acl_ea_indicator (string) (same as %X)


I'm not asking for any of this functionality to be added to GNU find. But if any of it ever does get added, please consider using the above %-notation so that the two programs remain in sync. It would be nicer that way for any users of both programs.

Thanks.

raf <raf>

 

(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 berny (Posted a comment)
  • -email is unavailable- added by jay (Posted a comment)
  • -email is unavailable- added by raf (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.13-758e.
    Corresponding source code