Yrurtj

Can I safely omit quotes on the right side of a local assignment?

function foo {

    local myvar=${bar}

    stuff()

}

I'm mainly interested in bash, but any info on corner cases in other shells are welcome.

Quotes are needed in export foo="$var" or local foo="$var" (or readonly, typeset, declare and other variable declaring commands) in:

• dash


• the sh of NetBSD (also based on the Almquist shell).


• The sh of FreeBSD 9.2 or older (see the change in 9.3)


• yash


• 
  zsh with versions prior to 5.1 in ksh or sh emulation (or for export var="$(cmd)" where zsh would perform word splitting otherwise (not globbing)).

As otherwise the variable expansion would be subject to word splitting and/or filename generation like in any argument to any other command.

And are not needed in bash or ksh or the sh of FreeBSD 9.3 or newer (where the command is somehow parsed like some sort of assignment) nor zsh (where word splitting and filename generation is not done implicitly upon variable expansion).

They are needed in every shell (except zsh) though in things like:

a="b=some value"

export "$a"

Or more generally, if anything left of the = (including the =) is quoted or the result of some expansion (like export 'foo'="$var", export foo="$var" or export foo$((n+=1))="$var" (that $((...)) should also be quoted actually)...). Or in other words when the argument to export wouldn't be a valid variable assignment if written without the export.

If the export/local command name itself is quoted (even in part like "export" a="$b", 'ex'port a="$b", export a="$b", or even ""export a="$b"), the quotes around $b are needed except in AT&T ksh and mksh.

If export/local or some part of it is the result of some expansion (like in cmd=export; "$cmd" a="$b" or even export$(:) a="$b") or if export/local is not the first word on the command line (as in dryrun=; $dryrun export a="$b"), then the quotes are needed in every shell. In the case of > /dev/null export a="$b" however, the quotes are not needed in bash/AT&T ksh and zsh (they are in pdksh and some of its derivatives).

For command export a="$b", the quotes are needed in every shell but mksh and ksh93 (with the same caveats about command and export not being the result of some expansion).

They are not needed in any shell when written:

foo=$var export foo

(that syntax being also compatible with the Bourne shell but in the case of bash and zsh only working when in sh emulation).

(note that var=value local var shouldn't be used as the behaviour varies across shells).

Also beware of this special case with bash:

$ bash -c 'IFS=; export a="$*"; echo "$a"' bash a b

ab

$ bash -c 'IFS=; export a=$*; echo "$a"' bash a b

a b

My advise would be to always quote.

I generally quote any usage of variables where there might be characters such as white spaces. Otherwise you'll run into problems like this:

#!/bin/bash



bar="hi bye"



function foo {

  local myvar=${bar}

  printf "%sn" $myvar

  printf "%sn" "$myvar"

}



foo

The usage of the variable in an assignment doesn't appear to need the quotes, but when you go to use it such as in the printf you'll need it quoted there:

  printf "%sn" "$myvar"

NOTE: Remember that the variable $IFS is what governs what the separator characters are.

IFS    The  Internal  Field  Separator that is used for word splitting after 

       expansion and to split lines into words with the read builtin command. 

       The default value is ``<space><tab><newline>''.

Example

With debugging enabled in Bash we can see what's happening behind the scenes.

$ bash -x cmd.bash 

+ bar='hi bye'

+ foo

+ local 'myvar=hi bye'

+ printf '%sn' hi bye

hi

bye

+ printf '%sn' 'hi bye'

hi bye

In the above we can see that the variable, $bar was handed off fine to $myvar but then when we went to use $myvar we had to be cognoscente of the contents of $myvar when we went to use it.