"ls" not working and Finder displaying only partial list of files

Question

On a PowerMac G5 2.5GHz with 10.3.9 client installed, I've come across a problem where, when trying to list the files in ~/Library/Fonts (i.e., the user's fonts folder, not the system-wide font folder) using the Unix "ls" command, it merely hangs for a short while (around 10 seconds) and then returns to the prompt without listing any files whatsoever. And using the Finder to do the same thing in the same folder only shows a partial list of the font files (no font files listed beyond those beginning with the letter "F"). This only occurs when trying to display the contents of the above directory--there is no problem listing the contents of any other directory using either "ls" in Terminal or the Finder, not even the /Library/Fonts directory. I am logged into that user's account as that user (he's a standard user) and not the admin user. This is a standard installation and there are no third-party installations (i.e., /usr/local doesn't exist; nor /opt). I have already deleted .DS_Store in ~/Library/Fonts and have rebooted the machine afterwards to no avail. Any ideas would be appreciated.

Answer 1

The code is now very expensive! but thats the result of avoiding the cd command. Right? Is there a max length for the ls and other commands? a limit of 128KB?
Mac OS X command line length limit is 256 kilobytes
Btw
done < <(ls -1 -d $myPath 2>&1)
Gives me, a known error. Happens a lot for me.
syntax error near unexpected token <
done < <(ls -1d $myPath 2>&1)
Are you using the bash shell? This is a bash shell feature. Does your script begin with
#!/bin/bash
So I did try to use a pipe
(ls -1d $__myPath 2>&1) | while read file
do
__filesArr[$index]="${file}"
#echo "filesArr$index ="${__filesArr[$index]}
index=$((index+1))
done
if [ -z "${__filesArr[*]}" ]; then # removed the 0 test, was never called.
echo "${__ErrHeader}Error - No files found" 1>&2
return
fi
But then, of course, I lose my variable (scope) outside the while loop
The while loop runs in a sub-shell, so when the while loop finishes, the filesArr disappears along with the sub-shell.
The < space <(...) notation in bash allows the while loop to run in the current shell, so filesArr will be visible after the loop finishes.
<div class="jive-quote">Anyway came up with,
done <<<"$(ls -1d $__myPath 2>&-)"
and that works, but why isn't your line working? Any idea?
The <<<word is a form of the "HERE DOCUMENTS". According to "man bash", the 'word' is expanded and supplied to the command on its standard input.
I have not played with <<<word with respect to spaces in file paths. If this works, then it would be similar to the < space <(...) for this example. But I did test < space <(...) to make sure spaces were preserved. You get to test <<<word for proper space handling.
<div class="jive-quote">Also why
(ls -1d $__myPath 2>&1)
instead of
(ls -1d $__myPath 2>&-)
Because 2>&1 comes from when I first learn shell scripting back in '85, so I'm more comfortable with it.
The last avoid/catch an error message when there are no matching files.
As always, thanks for your helpfull knowledge!