bugfindutils - Bugs: bug #62230, Doc/behaviour mismatch for -printf...

 
 

bug #62230: Doc/behaviour mismatch for -printf %INVALID

Submitter:  raf <raf>
Submitted:  Tue 29 Mar 2022 09:17:07 AM UTC
   
 
Category:  find Severity:  3 - Normal
Item Group:  Wrong result Status:  None
Privacy:  Public Assigned to:  None
Originator Name:  raf Open/Closed:  Open
Release:  4.8.0 Fixed Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Wed 30 Mar 2022 02:55:06 AM UTC, comment #2: 

I suppose that's an alternative, but I don't think that making it explicitly unspecified is the best way to help users. It seems like a way to allow programmers to (unconsciously) shift blame onto any users who "do the wrong thing" and then encounter problems if/when a new conversion is added. It would be much better if programmers prevented such problems in the first place whenever possible.

A fatal error when given invalid instructions is the only/best(?) way to ensure that new conversions can be added without breaking anyone's existing use. But it's too late for that. It should have been done when -printf was added (no offense meant, I'm sure it seemed like a good idea at the time). Since it wasn't done then, the next best thing is to at least make the documentation accurately reflect the existing behaviour(?).

Perhaps a deprecation warning for a decade or so, eventually replaced with a fatal error would really be the next best thing.

The problem with trying to prevent assumptions by documenting that the behaviour is explicitly unspecified, is that users can make assumptions without reading the documentation (whatever it says). But you can't easily ignore fatal errors. :-)

Since % at the end of the format string is already documented as being undefined, and since it already results in a fatal error, its documentation could be changed now to clearly state that it's an error.

And since % followed by an invalid conversion specifier is (incorrectly) documented as doing something other than what it actually does, any deprecation would be for something that is technically (almost) undocumented behaviour. Perhaps a shorter deprecation period would be acceptable because of that. Not sure.

Anyway, it's something to think about.

raf <raf>
Tue 29 Mar 2022 05:49:21 PM UTC, comment #1: 

There is an argument for making the effect explicitly unspecified (i.e. possibly including a fatal error, or any kind of output) so that in the future new format specifiers can be introduced, and to that people using GNU find don't make assumptions about the behaviour of other implementations that also support -printf.

James Youngman <jay>
Group administrator
Tue 29 Mar 2022 09:17:07 AM UTC, original submission:  

The find(1) manual entry says (in relation to -printf):

  "A `%' character followed by any other character is discarded, but the other character is printed"

But that's not the case. find . -printf '%Q\n' prints "%Q" for each file. According to the documentation, it should print "Q".

While the behaviour described in the documentation is arguably better than the actual documentation (not as good as an error but still better), it would probably be best to change the documentation to match the current behaviour.


A separate (not technically incorrect) point:

It also says:

  "A `%' at the end of the format argument causes undefined behaviour since there is no following character.  In some locales, it  may  hide  your door keys, while in others it may remove the final page from the novel you are reading."

When in reality, it just detects the situation and terminates with this error:

  find: error: % at end of format string

While technically OK, the documentation could just tell the truth and say that it is an error. I'm assuming that there aren't any actual locales where it decides to not be an error. :-)

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 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