I have an application which takes as an input attributes in double quotes embedded in single quotes. Take for example this right command:

command -p 'cluster="cl1"'

In order to automate it, I created a bash file using $CLUSTER as a variable. How should be my command? In other words, what should I put instead of cl1?

Please note that, If I modified the above command, it won't be accepted. For instance: command -p "cluster=cl1" is not accepted

  • 2
    CLUSTER='"cl1"'; command -p "cluster=$CLUSTER"
    – mikeserv
    Jan 9, 2015 at 23:39
  • Another possibility (if you prefer to store cli without quotes inside CLUSTER variable): CLUSTER='cl1'; command -p 'cluster="'"$CLUSTER"'"'
    – jimmij
    Jan 9, 2015 at 23:52
  • Finally, I found the right answer. Thanks @jimmij.
    – Newbie
    Jan 10, 2015 at 0:33

2 Answers 2


It looks like your command is maybe setting environment variables based on arguments given it on the command-line. It may be you can do:

CLUSTER=cl1; cluster=$CLUSTER command

...and set its environment for it at invocation.

Otherwise, shell quotes typically delimit arguments or escape other special shell characters from shell interpretation. You can contain (and therefore escape) different kinds of shell-quotes within other kinds based on various rules:

  • "''''" - a soft-quoted string can contain any number of hard-quotes.
  • "\"" - a \ backslash can escape a "soft-quote within a "soft-quoted string.
    • In this context a \\backslash also escapes itself, the \$expansion token, and \newlines as noted below, but is otherwise treated literally.
  • "${expand} and then some" - a soft-quoted string can contain an interpreted shell $expansion.
  • '"\' - a 'hard-quoted string can contain any character other than a 'hard-quote.
  • \ - an unquoted backslash will escape any following character for literal interpretation - even another backslash - excepting a \newline.
    • In a \\newline case both the \ backslash and the \newline are completely removed from the resulting interpreted command.
  • ${parameter+expand "$parameter"} - quotes resulting from a shell expansion almost never serve as delimiter markers excepting a few special cases. I won't venture to describe these further here.

I consider it odd that any application would interpret quotes in its command-line args. Such a practice doesn't make a lot of sense in that - for shells, at least - the primary purpose of a quote is generally to delimit an argument. At invocation, however, arguments are always already delimited with \0NUL characters and so a quote cannot serve much purpose.

Even a shell will typically only bother to interpret quotes in one of its invocation arguments when it is called with a -c switch - which denotes that its first operand is actually a shell script that it should run upon invocation. This is a case of twice evaluated input.

All that said, you can do a number of things to pass literal quotes via arguments on the command-line. For example:

CLUSTER='"cl1"'; command -p "cluster=$CLUSTER"

As I noted in a comment before, you can contain the " quotes within an expansion that is itself " quoted.

CLUSTER=cl1; command -p "cluster=\"$CLUSTER\""

You can escape the " with a \backslash within the " quoted string.

CLUSTER=cl1; command -p cluster='"'"$CLUSTER"'"'

You can alternate and concatenate quoting styles to arrive at your desired end result as @jimmij notes above.

CLUSTER=cl1; ( set -f; IFS=; command -p cluster=\"$CLUSTER\" )

You can disable both file name generation and $IFS splitting - thereby avoiding the need to quote the $expansion at all - and so only quote the quotes. This is probably overkill.

Last, there is another type of shell-quote that might be used. As I noted before the sh -c "$scriptlet" form of shell invocation is often used to provide a shell's script on the command-line. When $scriptlet gets complicated though - such as when quotes must contain other quotes - it can often be advantageous to use a here-document and sh -s instead - where the shell is specifically instructed to assign all following operands to the positional parameters as it would do in a -c case and yet to also take its script from stdin.

If your command must interpret quotes in this way then I would consider it better if it could do so in a file input. For example:

command --stdin <<-SCRIPT

If you do not quote the delimiter of a <<here-document then all of its contents are treated almost exactly like they were "soft-quoted - except that "double-quotes themselves are not treated specially. And so if we run the above with cat instead:

cat <<-SCRIPT

...it prints...


Like mikeserv wrote :

 CLUSTER='"cl1"'; command -p "cluster=$CLUSTER" 

"Double quote" every literal that contains spaces/metacharacters and every expansion: "$var", "$(command "$var")", "${array[@]}", "a & b". Use 'single quotes' for code or literal $'s: 'Costs $5 US', ssh host 'echo "$HOSTNAME"'. See

  • You are right, thank you. But, what about automation? Suppose I want read CLUSTER? I will get stuck again with the same problem: variable inside single quotes
    – Newbie
    Jan 9, 2015 at 23:57
  • @Moi - automation is not a big deal, though you will have to sanitize the variable of " characters - only the first and last should be sufficient. The real problem here is your app interpreting quotes in an arg. Interpreting a quote in an argument is almost never a good idea because a quote should only be a means of delimiting an argument - and at invocation that delimiting is handled by \0NULs in every case. Probably there is a better way to pass the information you want to the app? Like a command --'script=/path/to/some/file' or something?
    – mikeserv
    Jan 10, 2015 at 1:21

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.