Hide Forgot
Consider the following commands: # ttt=ggg # ggg="asd'ddd'g" # echo "'${!ttt//\'/'\''}'" > ^C # echo "'${!ttt//\'/\'\\\'\'}'" 'asd\'\\'\'ddd\'\\'\'g' The first echo command does not complete waiting for additional input. It seems like the single quotes inside the brackets need to be escaped and in this case some are not escaped. When single quotes are escaped though, the escape character appears in the output which is wrong. I would expect output to be: 'asd'\''ddd'\''g' What I was trying to achieve is replace single quote (') with '\''. I found a workaround though: sss=\'\\\'\' echo "'${!ttt//\'/$sss}'" This works. But I think the operation should be possible without using an intermediate variable. Regards.
${var//\'/\\\'} ' needs to be escaped as well as \ Anyway, isn't printf "%q\s" "${var}" what are you looking for?
> Anyway, isn't printf "%q\s" "${var}" what are you looking for? printf "%q\n"
Dear Roman, 1. printf "%q\n" does not produce posix compliant output that can feed dash for example (set -o posix does NOT help) 2. when NOT quoting the ${} expression there is no problem, but I need it quoted with double quotes because it may contain white spaces, new lines, tabs, etc. 3. The fact is that there is something broken with quoting and the ${parameter/pattern/string} expression. Please provide me with a command that would replace single quote with '\'' without using an intermediate variable and always expanding to a single word if you think I'm wrong. Regards.
btw if set -o posix affects printf %q, that would also be useful but %q by itself is not posix compliant therefore I guess can be rejected upstream.
Asked upstream. It's possible to substitute to \' (literally), but not to ' (literally) without variable and when you don't want to perform word splitting. "'${var//\'/\'}'" it will substitute to \' (literally). Is dash posix compliant? Right, I don't test any shell but bash.
Roman, did upstream confirm the bug or just consider it an expected behavior? wrt posix I don't know to what extend is dash compliant but it is used by RHEL init system and it does NOT understand $'something' expressions what %q produces. You can try the following in bash: set set -o posix set You can see that in posix mode $'somehitng' expressions are NOT produced. I am producing a file that will be sourced by an init script thus I need the output compliant with dash.
There is (or was) discussion on upstream ML: http://lists.gnu.org/archive/html/bug-bash/2012-02/msg00109.html Interesting post is http://lists.gnu.org/archive/html/bug-bash/2012-02/msg00120.html Looks like you have to use temporary variable.
(In reply to comment #6) > Roman, did upstream confirm the bug or just consider it an expected behavior? > > wrt posix I don't know to what extend is dash compliant but it is used by RHEL > init system and it does NOT understand $'something' expressions what %q > produces. You can try the following in bash: > set > set -o posix > set > > You can see that in posix mode $'somehitng' expressions are NOT produced. I am > producing a file that will be sourced by an init script thus I need the output > compliant with dash. POSIX will be standardizing $'' in the future (http://austingroupbugs.net/view.php?id=249), but you are correct that it is not required by POSIX 2008. Requesting a new bug against dash to get it in early can't hurt, though. But as long as you are talking about it, ${var//pat/sub} is also not required by POSIX, and is not supported by dash, so you are trading one extension for another.
Thank you for replying Eric! I'll file a bug with dash about this extension. My goal is/was to generate posix compliant input for a non-bash shell so I can't agree that I'm just "trading one extension for another". I use extensions only on the bash part of the project. Anyways this behavior is certainly not blocking my work. All the explanations were just to point out a valid use case for the feature. The fact is bash is doing something weird parsing quoting vs parameter expansion. The existing workarounds do not change that fact. I believe the bash project will be better if the bug is fixed. At least it needs to be documented in the man pages so hopefully other people don't lose too much time figuring out what's wrong. I understand old versions of bash cannot accept this syntax but this is the same with any new functionality added to bash (or any other project). Everybody trying to write portable scripts has to test the targeted implementations anyways. That's why I don't see a reason for a fix to be rejected on that grounds. That said, I'm leaving it up to your considerations how to handle the bug further. Regards, Aleksandar
Proposed patch was sent upstream [1], but without any reaction. It's better to do such change in future version rather than in this stable. Also, POSIX does not specify this behaviour. [1] http://lists.gnu.org/archive/html/bug-bash/2012-11/msg00039.html