Shell Programming and Scripting

The general rule is " >> file 2>&1 " to capture both, one (stdout) first, then 2 (stderr).

Very occasionally, you will see/do these in the opposite order, and it is not always a mistake (just usually), to send stdout to a file and stderr down a pipeline. If the app writes to (or reads from) an fd opened on /dev/tty, then you are into the land of expect/rsh/ssh to create a pseudo/remote tty you can recapture onto stdout.

Keeping the controlling terminal mapped to /dev/tty, FILE*'s: stdin, stdout, stderr, fd's: 0, 1, 2 ; cooked and uncooked tty input and output all straight and separate is one of those classic initial UNIX learning tasks.

Putting both into one file is popular: you do no care which wrote what, no research, one or no files, and you can grep or otherwise process the output to see if you got what you wanted and discard the rest. You might do something like this for simplicity and volume efficiency:

Code:

for ip in $ip_list
do
 echo ==== $ip
 nslookup $ip $DNS_SERVER
 echo ====
done 2>&1 | sed '
  /^==== /{
    :loop
    /\n====$/!N
    b loop
   }
 . . .
 ' > output_file

This way, you do an nslookup for each ip and frame the output for each. One sed can collect all the lines for one ip into the buffer using that framing, and then ( . . . = depends on what your nslookup writes and what you want) you can make it into whatever you want. The only file you make is the output file -- no cleanup, no old data, no file name creation or collisions, no running out of space with big data sets.

---------- Post updated at 03:35 PM ---------- Previous update was at 02:41 PM ----------

PS: nslookup has an interactive command mode, so you can use one nslookup if you generate commands to it equivalent to the command line args, and avoid calling it so many times.

@DGPickett
Under what unix O/S does nslookup react correctly to the Shell redirects like "2>&1". It is one of the very few programs where I had to use unusual techniques.
Imho unix "nslookup" just ignores unix I/O conventions.


Btw. Scripting a unix "nslookup" global enquiry and saving the results is not hard work. The secret there is not to try to redirect the output in Shell but to use the output functions in "nslookup" itself.
There almost certainly will be issues with listing the contents of a remote Internet Name Server because most of them block such enquiries.

Yes, zone inquiry is no longer considered innocent!

nslookup is not a mainstream tool, and like many somewhat admin-level tools, it not so user friendly. For the casual user, learning the various query methods and output formats is a bit of a pain. They might be better served doing getpeername, gethostbyname and such in C, JAVA or PERL.