Here is a simple script, distilled from something actually useful, that works on fedora but not on OS X Lion.
declare -a directory_contents=($(ls .))
test -e ${directory_contents[0]}
echo $?
On linux it returns 0, i.e., test -e passes. On Mac, it returns 1.
Any idea what could be going wrong here?
If the first file returned by ls has spaces in the name, ${directory_contents[0]} will not expand to the full file name (only up to the first space). Does this condition apply to your OSX test and not your Fedora test?
Adding the following line before the declare statement might fix the problem:
IFS=$'\n'
reference: http://www.linuxquestions.org/questions/programming-9/bash-passing-arrays-with-spaces-611159/
Nick's answer is correct. But you should also remember that except in highly controlled environments, ls is not something you should use to populate variables with filenames. There are a number of other ways to pick a single filename.
[ghoti@pc ~]$ ls -l foo*
-rw-r--r-- 1 ghoti wheel 0 Apr 16 21:01 foo bar.txt
-rw-r--r-- 1 ghoti wheel 0 Apr 16 21:01 foo.txt
[ghoti@pc ~]$ test1=`for i in foo*txt;do echo $i; break; done`
[ghoti@pc ~]$ echo $test1
foo bar.txt
[ghoti@pc ~]$ test2=`find . -name foo\*.txt -print | head -1`
[ghoti@pc ~]$ echo $test2
./foo.txt
[ghoti@pc ~]$
Obviously, not all methods will return files in the same order.
Also be mindful of filenames that begin with a hyphen. :-)
What I neglected to clarify in my original question is that my "script" is really a bash function. The cause of my issue is that "ls" is resolving to an alias with "--color=auto", adding unprintable characters to the actual filename.
Always define variables to hold the full path to the executables used in a script, e.g., "LS=/bin/ls". And, per answers above, ls might not be you best choice for a robust production script.
${directory_contents[0]}?