The following issue has been SUBMITTED. 
====================================================================== 
https://www.austingroupbugs.net/view.php?id=1771 
====================================================================== 
Reported By:                calestyo
Assigned To:                
====================================================================== 
Project:                    Issue 8 drafts
Issue ID:                   1771
Category:                   Shell and Utilities
Type:                       Enhancement Request
Severity:                   Editorial
Priority:                   normal
Status:                     New
Name:                       Christoph Anton Mitterer 
Organization:                
User Reference:              
Section:                    Utilities / printf 
Page Number:                3269 
Line Number:                111019 
Final Accepted Text:         
====================================================================== 
Date Submitted:             2023-08-07 19:22 UTC
Last Modified:              2023-08-07 19:22 UTC
====================================================================== 
Summary:                    support or reserve %q as printf-utility format
specifier
Description: 
Hey.

Hope that hasn't been asked for before and rejected, at least I couldn't
find anything about it.

I propose considering to either support (in the sense of: conforming
implementations must support it) or reserve (in the sense of: *if* a
conforming implementation uses that format specifier, *then* it must be for
the given purpose) the %q format specifier for the printf-utility as used
e.g. by GNU printf or bash.

bash specifies it as:
> %q     causes printf to output the corresponding argument in a
>        format that can be reused as shell input.

GNU printf as:
> %q     ARGUMENT is printed in a format that can be reused as shell 
in‐
>        put,  escaping  non-printable characters with the proposed POSIX
>        $’’ syntax.

I'm afraid I don't have access to that many other shells like from BSDs or
so, but from what I saw after looking at some manpages, %q seems not to be
generally supported, although not used for other purposes either.
(There are experts around here, who can probably tell much better about
this.)


I'm also not sure how exactly it should be implemented:

1) One way would be to allow any quoting that is understood by the given
shell,... this would for example allow $'...' quotes to be used, even now
where they're (not yet) supported by POSIX. And of course any other custom
quoting styles used by a shell might then be produced by that.

I guess it's obvious that (1) would be rather bad with respect to
interoperability.


2) The better way would IMO be to allow only any quoting styles supported
by POSIX.
An open question, to which I have no proper answer, would be whether any
preference should be given or perhaps even any obligations should be made
(like newline needed to being given as $'\n' or the like, but not
literally).


The motivation for supporting %q is that it's IMO generally useful to have
an out-of-the-box mechanism to safely quote input so that it may be reused
as shell input.
Desired Action: 
see above
====================================================================== 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2023-08-07 19:22 calestyo       New Issue                                    
2023-08-07 19:22 calestyo       Name                      => Christoph Anton
Mitterer
2023-08-07 19:22 calestyo       Section                   => Utilities / printf
2023-08-07 19:22 calestyo       Page Number               => 3269            
2023-08-07 19:22 calestyo       Line Number               => 111019          
======================================================================


  • [Issue 8 dra... Austin Group Bug Tracker via austin-group-l at The Open Group
    • [Issue ... Austin Group Bug Tracker via austin-group-l at The Open Group
    • [Issue ... Austin Group Bug Tracker via austin-group-l at The Open Group
    • [Issue ... Austin Group Bug Tracker via austin-group-l at The Open Group
    • [Issue ... Austin Group Bug Tracker via austin-group-l at The Open Group
    • [Issue ... Austin Group Bug Tracker via austin-group-l at The Open Group
    • [Issue ... Austin Group Bug Tracker via austin-group-l at The Open Group
    • [Issue ... Austin Group Bug Tracker via austin-group-l at The Open Group
    • [Issue ... Austin Group Bug Tracker via austin-group-l at The Open Group
    • [Issue ... Austin Group Bug Tracker via austin-group-l at The Open Group
    • [Issue ... Austin Group Bug Tracker via austin-group-l at The Open Group

Reply via email to