bug-findutils
[Top][All Lists]
Advanced

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

[bug #64100] wish/request: please reserve -printf "%V %v %E %R %r %B %e


From: raf
Subject: [bug #64100] wish/request: please reserve -printf "%V %v %E %R %r %B %e %J %I %z %x %X %j"
Date: Tue, 25 Apr 2023 01:35:03 -0400 (EDT)

Follow-up Comment #3, bug #64100 (project findutils):

[comment #1 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.


    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?64100>

_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/




reply via email to

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