Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > gnu.bash.bug > #15725 > unrolled thread

Re: Not missing, but very hard to see (was Re: Backslash missing in brace expansion)

Back to article view | Back to gnu.bash.bug

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Not missing, but very hard to see (was Re: Backslash missing in brace expansion) Eli Schwartz <eschwartz@archlinux.org> - 2019-12-12 22:03 -0500

#15725 — Re: Not missing, but very hard to see (was Re: Backslash missing in brace expansion)

[Multipart message — attachments visible in raw view] — view raw

On 12/12/19 9:57 PM, L A Walsh wrote:
> 
> 
> On 2019/12/12 13:01, Ilkka Virta wrote:
>> On 12.12. 21:43, L A Walsh wrote:
>>  
>>> On 2019/12/06 14:14, Chet Ramey wrote:
>>>
>>> Seems very hard to print out that backquote though.  Closest I got
>>> was bash converting it to "''":
>>>     
>>
>> The backquote is in [6], and the backslash disappears, you just get
>> the pair of quotes in [2] because that's how printf %q outputs an
>> empty string.
>>   
> -----
> 
>    I'm sorry, but you are mistaken.

How so?

>    The characters from 'Z' (0x5A) through 'z' (0x61) are:
> 
> 0x5A 0x5B 0x5C 0x5D 0x5E 0x5F 0x60 0x61
> Z    [    \    ]     ^   _     `    a
> 
> the backslash comes between the two square brackets.
> 
> Position [6] is the "Grave Accent" (or backquote).
> 
> It is quoted properly.

But... that's exactly what was said.

> As for %q printing an empty string for 0x5C
> 
>         "%q" causes  printf to output the corresponding argument in a
>         format that can be reused as shell input.
> 
>    For that string to be empty would mean there is no character at hex
> value 0x5C (unicode U+005C), which isn't so.

But there isn't. An empty string was passed as an argument to printf,
because the backslash was *converted* via escaping, into an empty
string, *before* it was passed on the command line as an argv element to
the printf builtin.

Do you think that because printf is a builtin, and you didn't use
/bin/printf, that somehow means it is exempt from the usual rule of how
shells work, and gets to see its own argv before the parser reinterprets it?

>>  
>>>>  read -r -a a< <(printf "%q " {Z..a})
>>>>  my -p a
>>>>       
>>> declare -a a=([0]="Z" [1]="\\[" [2]="''" [3]="\\]" [4]="\\^" [5]="_"
>>> [6]="\\\`" [7]="a")
>>>     
>>
>>
>>   


-- 
Eli Schwartz
Bug Wrangler and Trusted User

[toc] | [standalone]

Back to top | Article view | gnu.bash.bug

csiph-web