Here, I'll spring the explanation of the differences between the infinite loop and the infinite recursion, and hopefully this will convince you to buy a book.

When you call a function or a procedure (the "sub" in perl), the state of execution has to be stored somewhere. All the local variables get stored, and the current location of execution is stored so it can be returned to after the function is finished. This takes up memory! Moreover, this stuff usually gets pushed to the stack, although as some have pointed out here, interpreted languages might keep their own stack that's actually kept on the heap.

In a recursive algorithm, this is what you want. You want each function call to be pushed onto a stack, so that when the function returns, you can do something with it. Recursive algorithms are used for things like parsing xml (in fact, anything that has a tree structure is ideal for recursion). Also, Newton's Method for approximating a derivative is a recursive algorithm (there are a few others you'll study in Calculus, if you haven't already). Parsing mathematical statements, and even parsing code usually requires a recursive algorithm. You use them when succeeding steps depend on the results of previous steps.

However, if your data is linear, such as when reading a log file, a recursive algorithm is not what you want. You want a simple iterative algorithm, meaning just a loop that calls the same function (or set of functions) for each line. This is the situation you're in when you parse arma logs!

So, in your situation with the infinite recursion (which is always bad programming anyway, but many recursive algorithms have the potential to become infinite if the data is also infinite, but that's physically impossible), you're going to be occupying stack space with all these local variables. In a few minutes, you may not notice, but given enough time, your script will occupy all available memory, swap space, and you'll probably crash your computer. Running out of memory is really bad.

If you switch it to an infinite loop, you lose all of that. All variables local to the loop will be kept exactly where they are, and with every call to your subroutine, you'll get the variables created exactly once, then the sub will return and its variables will be destroyed.

So, in your recursive situation, you can use an infinite amount of memory. In the infinite loop situation, you will only ever use a small amount of memory. In fact, you could go through and add up the memory usage of each variable and statement and the function and compute the maximum memory usage, and it will be very low, on the order of kilobytes, if that.

The other consideration is performance. Pushing and pulling on the stack can be fast, but if you use it too much, it can slow down, because when you need an element that's far up the stack, everything between you and it has to be pulled to get what you're after, then pushed back on. This is also transparent to you, the programmer (unless you're using your own stack). So you will see your script slowing down over time, and sometime before it takes up maximum available memory, it will push your CPU usage to 99%. However, in the iterative form, with the infinite loop, your cpu usage will always correspond directly to the rate at which arma log messages are generated, and will be correspondingly low.

Now, I'm never going to suggest you make performance your most important goal early in development, but it is worth thinking about and having good coding strategies, because it really sucks to spend 30 hours writing something only to find it's a cpu hog. The best thing to do is to select good algorithms for what you're doing, and while you're in the area of the problem that is known (i.e. you can find research to support your choices), make good choices. Most interpreted languages (especially Perl) provide numerous algorithms in their standard library for you to use so you can make those choices relatively painlessly. Use them, and later on when you reach your optimization stage, profile the living piss out of your code and find where the bottlenecks really are.

Keep in mind that Perl has text parsing functions that are really hard to touch in other languages, they're vary good. Look up what the Perl acronym stands for and you'll see why, that's the whole point of Perl! The rule is, if you've written 10 lines to do some text processing, you can probably rewrite it to 5 lines and double the speed. If you've got 5 lines, you can rewrite it to 3 and double the speed, etc. Some Perl hacks claim you can reach a point where you have no code and the program runs instantaneously, and they're unfortunately right.

But in this case, for many of us anyway, it's a nobrainer. Use the infinite loop instead of the infinite recursion. As you gain experience, you'll find choices like this becoming obvious to you, as well. And you can always change the infinite loop condition to an actual check for input to see if it's time to quit.

Lucifer wrote:when you need an element that's far up the stack, everything between you and it has to be pulled to get what you're after, then pushed back on.

what kind of stack are we talking about here? c++'s stack<> doesn't allow you to access an element that's not on top, but that's their own damn fault. hardware stacks don't have that limitation.(*) so in a recursive function the only difference between accessing the top element an the one that's 100 levels deep is the higher probability that the latter has been evicted from cache/main memory.

ok, good.
should it use cat > input.txt or cat >> input.txt?
i cant remember what i have right now, but it always executes the commands in input.txt.
is there a way to empty a file with a single command (does "touch <filename>" do that)? that would be a handy crontab for the input file

btw: where does inotail keep its current PID? when i press Ctrl+C, it only kills cat, not inotail. does kill take it like "kill `file:/path`" or something? i remember seeing that somewhere before