On Sat, Nov 13, 1999 at 11:17:49AM -0600, Yoink! wrote:
| On Fri, 12 Nov 1999, John Horne wrote:
| > I have a small script which uses the find command to locate files and then
| > does an 'ls -lAd' on them (don't ask why, it's not important). This however
| > has failed nicely when it hits files with spaces in them!
| > I have as a test:
| >
| > for FNAME in `find /tmp -type f -maxdepth 1 -printf '"%p"\n' `; do
| > ls -l "$FNAME"
| > done
|
| do a man on bash and look for "IFS"
| Set it to this:
| _________________________________________
| IFS="
| "
And it will now break on files with newlines in their names. Which are
perfectly legal, if uncommon. It is usually better to try to avoid
having the shell attempt word sepation altogether than to fiddle IFS.
A quick read of the find manual entry reveals the {} word in the -exec
option. He can say
find /tmp -type f -maxdepth 1 -exec ls -lAd {} ';'
No "special chars" problems at all, because the shell never has to
deal with it.
Some finds also have the -print0 option, though that's mostly useful
with some archivers which can read NUL-terminated name lists.
For an alternative (neater than fiddling IFS, but with the same
newline-in-name weakness), he could say
find /tmp -type f -maxdepth 1 -print \
| while read name
do ls -lAd "$name"
done
which should survive because only the first n-1 words are subject to
IFS separation in a "read" command, where n is the number of vars to
read into (and thus zero for "read name"). Very handy sometimes.
Which is not to say you should never hack IFS. I'm rather fond of
oIFS=$IFS
IFS=/
set x `pwd`; shift # I _know_ someone will ask about that x...
IFS=$oIFS
to split a pathname (pwd in this case) up into components.
--
Cameron Simpson, DoD#743 [EMAIL PROTECTED] http://www.zip.com.au/~cs/
You try and make the place as secure as you can, but you don't reckon
with the kind of people who try and break into an explosives factory
with an oxy-acetylene torch.
--
To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe"
as the Subject.
