bug-bash
[Top][All Lists]
Advanced

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

Re: printf %q represents null argument as empty string.


From: Dan Douglas
Subject: Re: printf %q represents null argument as empty string.
Date: Fri, 11 Jan 2013 22:39:19 -0600
User-agent: KMail/4.8.3 (Linux/3.4.6-pf+; KDE/4.8.3; x86_64; ; )

On Saturday, January 12, 2013 02:35:34 AM John Kearney wrote:
> so there is always at least one word or one arg, just because its 
> "address@hidden"
> should not  affect this behavior.
...
> printf "%q" "address@hidden"
> becomes
> printf "%q" ""
> 
> which is correct as ''

No, "address@hidden" doesn't always become at least one word. "$@" can expand 
to zero or 
more words. It can become nothing, one word, or more, possibly concatenated 
with adjacent words. That's completely beside the point.

BTW, your wrappers won't work. A wrapper would need to implement format string 
parsing in order to determine which argument(s) correspond with %q so that 
they could be removed from the output if not given an argument. It also would 
have to work around handling -v, which can take up either 1 or 2 args, plus 
possibly --. It isn't feasible to wrap printf itself this way.

I just used "$@" as an example of something that can expand to zero words and 
preserves exactly the positional parameters present (possibly none). This is 
important because printf %q is often used to safely create a level of escaping 
that guarantees getting out exactly what you put in.

 $ ksh -c 'f() { cmd=$(printf "%q " "$@"); }; f; eval x=moo "$cmd"; echo "$x"'
moo

Bash yields a "command not found" error for obvious reasons, but it goes 
against the spirit of what %q is supposed to do IMHO. It's a minor detail. 
This isn't even a particularly good example.

See Chet's previous message for the actual explanation. The reason is to be 
consistent with the defaults for other format specifiers which act like they 
were given a null or zero argument if more formats than arguments are given. 
We already had pretty much this same discussion here:

http://lists.gnu.org/archive/html/bug-bash/2012-12/msg00083.html

It somehow slipped my mind.
-- 
Dan Douglas



reply via email to

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