2011-08-17, 08:24(-04), Greg Wooledge: > On Tue, Aug 16, 2011 at 03:41:19PM -0700, Linda Walsh wrote: >> Ken Irving wrote: >> >Maybe this? >> > today_snaps=( ${snap_prefix} ) > >> but as you mention, that will put them into an array....sorry "imprecise >> terminology".... list for me is some number of objects in a string >> separated by some >> separator. > > This is an extremely bad idea. Legacy Bourne shell code from the > 1980s kind of bad -- from the horrible days before we *had* arrays > in shells. How are you going to handle filenames with spaces in them? > With newlines in them? With commas in them? With colons in them? Tabs? > DEL characters? Those are all valid in filenames. Any delimiter you > can *put* in a shell string is also a valid character in a filename (or > at least in a pathname, which eliminates the possibility of using slash). >
In this code: today_snaps=( ${snap_prefix} ) With the default value of IFS in bash and without globbing disabled, the problematic characters are SPC, TAB, NL, *, ?, [ and potentially more if you have extended globbing enabled. If $snap_prefix is meant to be space delimited, then you can make it a bit safer by doing: IFS=" " set -f today_snaps=( $snap_prefix ) NL is a good delimited because it's rare in filenames (but are allowed, so if the data is foreign and security is a concern, not an option) and you can also pass the list to line-based (text_ utilities var='a1 a2 b2' IFS=' ' set -f set -- $var Or a_vars=$(printf '%s\n' "$var" | grep '^a') -- Stephane