Click to See Complete Forum and Search --> : [SOLVED] someone please explain this file redirect


gamblor01
05-26-2005, 02:43 PM
Hey I'm still not sure what exactly these few lines do, and what the purpose of EOF is. Can someone clarify? I have seen many examples in shell scripts of something like the following:


$ONE_DIR/foo.exe $VAL1 $VAL2 > /dev/null <<EOF
$FLAG
$TWO_DIR/bar.exe
EOF


It looks to me like foo's main takes 2 args, $VAL1 and $VAL2 and executes, and redirects its output to the file /dev/null (is this a special system file or something?). Then I'm not sure what the EOF stuff does. Looks like it's reading this file until it finds EOF which is 3 lines later? But then what's the point of the $FLAG and bar.exe? I know this is probably pretty simple, but I didn't find any examples like this in my "Complete Reference" for Linux book, but I've seen this style stuff in many shell scripts and Perl scripts. Figured it's useful so can someone please explain? :D

Icarus
05-26-2005, 04:16 PM
/dev/null is the magical device located on all systems which will suck all data into nothingness :D
It's telling the output to not be displayed anywere

The EOF is "End Of File" which tells the script that it's done and to exit, this could be other things depending on what language is being used. orther examples would be exit, return 0; and done

No idea what $FLAG and $TWO_DIR/bar.exe do since we don't know what they are for, $FLAG would be setup as a variable at the begining of the script or from the output of some other command

Hope that helps some

gamblor01
05-26-2005, 04:20 PM
So that " << EOF" stuff is the same typing "exit 0" ? I would've assumed it caused something to happen with the next two lines seeing how EOF is right after them.

nevin180
05-26-2005, 04:28 PM
The EOF is most certainly NOT a indicator of the end of the script!!!

That structure is known as a here-document, which directs the text found between << EOF and EOF on its own line to the standard input of the program called. (note that EOF could be replaced by anything you want. In this case it would be like running:

$ONE_DIR/foo.exe $VAL1 $VAL2

then typing in

$FLAG
$TWO_DIR/bar.exe

You can read more about here-documents at http://www.tldp.org/LDP/abs/html/here-docs.html

gamblor01
05-26-2005, 05:46 PM
Ah ok I think I understand. So what you're saying is if I ran:

$ONE_DIR/foo.exe $VAL1 $VAL2


Then it would be sitting there waiting for someone to give it something input. So I would type in whatever $FLAG is, it would do it's thing, and then it would wait again for input and I would type in the next executable to run?

So if I understand correctly, let's say I had a program that multiplied two numbers together, but it would halt and wait for input from the keyboard and I didn't want that. Let's suppose the user already input the numbers elsewhere in the program, so I don't want to prompt them again. I could just use something like:


mult > /tmp/answerFile << EOF
$factor1
$factor2
EOF


And instead of waiting on input it would know to use the $factor1 and $factor2 as a sort of psuedo input and write the answer to /tmp/answerFile?

bwkaz
05-26-2005, 09:27 PM
As long as it reads standard input, and doesn't check to make sure that standard input is coming from a terminal, then yes, that will work.

You can't use a here document to send a password to su, for example, because if you try, su will check that its input is coming from a terminal, and it will find out that it is not. It'll give you an error and fail. But that's done per program; it's not a feature of everything. (If it was, here documents would be fairly pointless. ;))

gamblor01
05-26-2005, 10:44 PM
Great thanks a lot guys. It actually made the scripts and C code that I was looking at make sense as to what was going on! ...a LOT of sense! And I've never been a very avid C fan so I don't know it very well. I tend to code in languages named after beverages wherever possible. :p

So yeah, the C code was easy enough for me to understand, but I had no idea what that construct (now I even now the name!) was in the shell script. Now I see the light! Thanks again.