detecting EOF in Bash script

[Cri]

Greetings,

I'm writing a Bash script and I would like to know how to detect an EOF. My script opens a file for input and uses a while loop to read each line of text. Currently, the loop header is:

while [ "$input" ]; do

So, as long as $input is not null, the loop continues. The problem with this is that the input file cannot have any blank lines until the end of the file, otherwise the loop will terminate prematurely. This isn't a big deal, but blank lines would help make my input (configuration) file easier on the ol' eyes :D

How can I get a loop header similar to:

while [ !EOF ]; do

The above does not work, and although I've done a lot of searching, I cannot figure out how to detect EOF in a file to which stdin has been redirected. This seems like a standard thing to do...I'm sure it can be done, but how?

Thanks in advance to all who reply.

[l01yuk]

What do you do in the while loop? Can't you just do -

cat <file> | <other commands in a pipeline>

Or alternatively learn some awk.

I do loads of text processing with scripts (and I do mean loads) and I've never felt the need to know how to find EOF explicitly. Let us know what you want to do and perhaps someone can let you know a better way to do it.

[morphman]

This is a rather cheap way to do it but it would work. Its along the lines of what lo1yuk, was saying: do a pipeline with cat.
If you do:
cat -n filename
that will output your file to the terminal with all lines numbered. That way you will have text on each line. So you could use your same loop if you wanted to and then use sed to edit out the space and number from each line that you added with the cat -n. Does that make sense? You didnt really say what you were doing so this may or may not work with what you are asking for.

--Morphman

[Stuka]

If you're reading from stdin in your script, the read command should work (man read). It will read in the lines, and return > 0 when it hits EOF (or error).

[Cri]

Thanks for all the replies. Sorry I wasn't more explicit in my post, but I didn't want to overburden friendly readers with details. I guess I was a little too careful.

Anyways, I did figure out that 'wc -l <filename>' gives a useful line count that is helpful as long as you trim out the echoed file name. However, Stuka's suggestion was just what I was looking for. Thanks!

I am somewhat new to Bash scripting (just a student here!). I wanted more experience with Bash so I decided to write a system backup script. Originally it was supposed to be simple and just for me. However, I got carried away and now its more complex and applicable to any Bash-running *nix system. Here's my new question:

How do you know when it is more appropriate to write something in, say C, rather than Bash (or other shell scripting languages)? It would be easy to translate my script to C, but is that necessarily better? I wouldn't call my script sophisticated, resource intensive, math intensive, etc.

Also, are functions not a very good thing to use while scripting? You just don't see them that often in system scripts (at least in my experience)...

Thanks for all previous posts, and in advance for all new replies.

[jscott]

For automating system admin jobs [back-up, restore, shuffling accounts, so on] shell scripts are perfect. They're also great for glueing a bunch of system commands together. You can bang out quick scripts and debug them fairly easily. Functions are A Good Thing even in shell scripts. If you find yourself doing something more than once, make it a function. You should check out O'Reilly's Learning the Bash Shell (http://www.oreilly.com/catalog/bash2/) it's a great intro to scripting and has lots of useful examples.