UNIX for Dummies Questions & Answers

Hi

I have following code

Code:

cd /tmp/test/
for vfile in `ls -1`           
   do                             
     for vlink in `ls -l /tmp/testfile/*|bin/grep "local/init\.d/$vfile$"|bin/awk -F"->" '{print($1)}'|bin/awk -F"/" '{print($NF)}'`

I know `ls -1` list only file, but I don't understand second for loop,

I got below o/p when run ls -1

Code:

abc
def
ghi

So I tried to manually run

Code:

ls -l /tmp/testfile/*|bin/grep "local/init\.d/abc"|bin/awk -F"->" '{print($1)}'|bin/awk -F"/" '{print($NF)}'

but I am not getting any o/p

The program checking the link file

You are grep'ing for local/init.d/abc, but ls output is only abc, so it cant find it.
grep only for abc, and you should see output.
Also, your first code has no closing done.

Furthermore, you are calling bin/grep and bin/awk so you are expecting them to be in the subdrir bin of your current path.

hth

In addition to what sea said (and to what i wholeheartedly agree):

1) do not use "open-ended" for-loops, because they can have side-effects. Something like (you are effectively doing the same)

Code:

for VAR in <list of filenames> ; do
     do_something_with "$VAR"
done

will work with several or several hundreds of files but might break with a "too many arguments"-error or a "input line too long"-error with several thousands of files. Do a

Code:

ls -1 | grep <some-filter-criteria> |\
while read VAR ; do
     do_something_with "$VAR"
done

instead. This will work with even the biggest amount of files.

2) Never, NEVER use backticks any more. They are outdated and only there for backwards compatibility with other outdated software. Use the POSIX-compliant

Code:

$(command | command2 | .... )

instead.

Btw.: i am not sure what you are trying to do but to me this seems to be a search for symbolic links. This can more easily be done by:

Code:

find /start/dir -type l -print

see the man page for "find" for details.



I hope this helps.

bakunin

When you invoke a utility with a long argument list (or a large list of environment variables) you can get an E2BIG error from the exec*() or posix_spawn() call. A for loop is run entirely in the shell (no exec or spawn involved) so you can't get an argument list too long error from the for.

So, ls * | while IFS= read -r i may get an error if there are a lot of files in the current directory (due to an exec*() failure while invoking ls), but for i in * should not. But, of course (especially on 32-bit systems), the shell could run out of space trying to gather the arg list and fail with an ENOMEM error. So I wouldn't try a command like:

Code:

for i in $(find / -print)
do	whatever
done

when the command:

Code:

find / -print | while IFS= read -r i
do	whatever
done

will be much more likely to work and (besides requiring much less memory for the shell) will also have the advantage of running the find and the loop processing in parallel.

Note also that standards say that shell scripts (and standard input for an interactive shell) are text files with unlimited line lengths. So you shouldn't ever get a line too long error when processing the arguments to a for loop.