{
  "$type": "site.standard.document",
  "canonicalUrl": "https://rednafi.com/misc/to-quote-or-not-to-quote/",
  "description": "Master shell quoting rules: single vs double quotes, backticks vs $(). Learn when to quote variables to prevent spaces and special characters from breaking commands.",
  "path": "/misc/to-quote-or-not-to-quote/",
  "publishedAt": "2022-10-05T00:00:00.000Z",
  "site": "at://did:plc:fgtm2c26vfcj74rfmeggbyqj/site.standard.publication/3mnl6f7ob462z",
  "tags": [
    "Shell",
    "Unix"
  ],
  "textContent": "My [grug brain] can never remember the correct semantics of quoting commands and variables\nin a UNIX shell environment. Every time I work with a shell script or run some commands in a\nDocker compose file, I've to look up how to quote things properly to stop my ivory tower\nfrom crashing down. So, I thought I'd list out some of the most common rules that I usually\nlook up all the time.\n\nI mostly work with bash; so that's what I'll focus on. However, the rules should be similar\nfor any POSIX compliant shell.\n\nSingle quotes vs double quotes vs backticks\n\nUse single quotes when you don't want your shell to expand variables. For example:\n\nThis prints:\n\nIn the previous snippet, the single quotes ensure that the value of the HOST variable\ndoesn't get expanded by the shell and instead the literal name of the variable is used. On\nthe contrary, your shell will evaulate the variable if you use double quotes here:\n\nIn this case, the command prints the name of my host machine. Lastly, a backtick pair is\nused to open a subshell and run some command. The following command allows you to check out\nto the HEAD-1th commit in Git:\n\nIn the above command, first, the command within the backtick runs in a subshell and then\nreturns the result to the main shell. The git checkout part of the command in the main\nshell then uses the output value of the git rev-parse --short HEAD~1 sub-command to carry\nout the intended action.\n\n> While this works, ` ...  is the [legacy syntax] for command substitution, required by\n> only the very oldest of non-POSIX-compatible Bourne shells. A better alternative is to use\n> the $(...) syntax.\n\nWhen to quote variables\n\nQuote if the variable can either be empty or contain any whitespace or special characters\nlike spaces, backslashs or wildcards. Not quoting strings with spaces often leads to the\nshell breaking apart a single argument into many. Consider this command:\n\nThis will print:\n\nIdeally, this should've returned some filename. You can fix this by quoting the value:\n\nIn the shell environment, the value of a variable is delimited by space. So if the value of\nyour variable contains a space, it won't work correctly unless you quote it properly. This\ncan also happen while accepting a value from a user and assigning it to a variable. For\nexample:\n\nIf the user provides a file name that contains a space or any special character like *,\n? or /, the command above will behave unexpectedly. To ensure that the cat is applied\non a single file, wrap the file variable with double quotes.\n\nInstead of double quotes, if you wrap the variable with single quotes, the command will try\nto apply cat on a file that's literally named $file` which is most likely not what you\nwant.\n\n\n\n\n[grug brain]:\n    https://grugbrain.dev/\n\n[legacy syntax]:\n    http://mywiki.wooledge.org/BashFAQ/082",
  "title": "To quote or not to quote"
}