Add a New Comment (Rich Markup)
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.
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.
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. :-)
(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
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.
Please enter the title of George Orwell's famous dystopian book (it's a date):
Copyright © 2023 Free Software Foundation, Inc. Verbatim copying and distribution of this entire article is permitted in any medium, provided this notice is preserved. The Levitating, Meditating, Flute-playing Gnu logo is a GNU GPL'ed image provided by the Nevrax Design Team. Source Code
Powered by Savane 3.11