Tip of the hat to @gniourf_gniourf and @chepner for their help.
tl;dr
To be safe, double-quote: it'll work in all cases, across all POSIX-like shells.
If you want to add a ~-based path, selectively leave the ~/ unquoted to ensure that ~ is expanded; e.g.: export PATH=~/"bin:$PATH".
See below for the rules of ~ expansion in variable assignments.
Alternatively, simply use $HOME inside a single, double-quoted string:
export PATH="$HOME/bin:$PATH"
NOTE: The following applies to bash, ksh, and zsh, but NOT to (mostly) strictly POSIX compliant shells such as dash; thus, when you target /bin/sh, you MUST double-quote the RHS of export.[1]
- Double-quotes are optional, ONLY IF the literal part of your RHS (the value to assign) contains neither whitespace nor other shell metacharacters.
- Whether the values of the variables referenced contain whitespace/metacharacters or not does not matter - see below.
- Again: It does matter with
sh, when export is used, so always double-quote there.
The reason you can get away without double-quoting in this case is that variable-assignment statements in POSIX-like shells interpret their RHS differently than arguments passed to commands, as described in section 2.9.1 of the POSIX spec:
Specifically, even though initial word-splitting is performed, it is only applied to the unexpanded (raw) RHS (that's why you do need quoting with whitespace/metacharacters in literals), and not to its results.
This only applies to genuine assignment statements of the form
<name>=<value> in all POSIX-like shells, i.e., if there is no command name before the variable name; note that that includes assignments prepended to a command to define ad-hoc environment variables for it, e.g., foo=$bar cmd ....
Assignments in the context of other commands should always be double-quoted, to be safe:
With sh (in a (mostly) strictly POSIX-compliant shell such as dash) an assignment with export is treated as a regular command, and the foo=$bar part is treated as the 1st argument to the export builtin and therefore treated as usual (subject to word-splitting of the result, too).
(POSIX doesn't specify any other commands involving (explicit) variable-assignment; declare, typeset, and local are nonstandard extensions).
bash, ksh, zsh, in an understandable deviation from POSIX, extend the assignment logic to export foo=$bar and typeset/declare/local foo=$bar as well. In other words: in bash, ksh, zsh, export/typeset/declare/local commands are treated like assignments, so that quoting isn't strictly necessary.
- Perhaps surprisingly,
dash, which also chose to implement the non-POSIX local builtin[2]
, does NOT extend assignment logic to it; it is consistent with its export behavior, however.
Assignments passed to env (e.g., env foo=$bar cmd ...) are also subject to expansion as a command argument and therefore need double-quoting - except in zsh.
- That
env acts differently from export in ksh and bash in that regard is due to the fact that env is an external utility, whereas export is a shell builtin.
(zsh's behavior fundamentally differs from that of the other shells when it comes to unquoted variable references).
Tilde (~) expansion happens as follows in genuine assignment statements:
- In addition to the
~ needing to be unquoted, as usual, it is also only applied:
- If the entire RHS is
~; e.g.:
foo=~ # same as: foo="$HOME"
- Otherwise: only if both of the following conditions are met:
- if
~ starts the string or is preceded by an unquoted :
- if
~ is followed by an unquoted /.
- e.g.,
foo=~/bin # same as foo="$HOME/bin"
foo=$foo:~/bin # same as foo="$foo:$HOME/bin"
Example
This example demonstrates that in bash, ksh, and zsh you can get away without double-quoting, even when using export, but I do not recommend it.
#!/usr/bin/env bash
# or ksh or zsh - but NOT /bin/sh!
# Create env. variable with whitespace and other shell metacharacters
export FOO="b:c &|<> d"
# Extend the value - the double quotes here are optional, but ONLY
# because the literal part, 'a:`, contains no whitespace or other shell metacharacters.
# To be safe, DO double-quote the RHS.
export FOO=a:$foo # OK - $FOO now contains 'a:b:c &|<> d'
[1] As @gniourf_gniourf points out: Use of export to modify the value of PATH is optional, because once a variable is marked as exported, you can use a regular assignment (PATH=...) to change its value.
That said, you may still choose to use export, so as to make it explicit that the variable being modified is exported.
[2] @gniourf_gniourf states that a future version of the POSIX standard may introduce the local builtin.
PATHis certainly already exported, so you don't need toexportit again.PATH=/users/me/path:$PATH(this time without quotes) is enough. – Muoimuon