On 13 Jan 99 at 11:27, E.L. Meijer \(Eric\) <[EMAIL PROTECTED]> wrote:
> Um, yeah, it looks neater :) I was just mindlessly copying the original > poster's script. Anyway, you actually still have one superfluous > character there :) > > cat > $TMPFILE > > is enough, so that the entire script becomes > > #! /bin/bash > > TMPFILE=/tmp/mymore.$$.tmp > cat > $TMPFILE > vi $TMPFILE < /dev/tty > rm -f $TMPFILE When I first read this I thought, "This is better too!", and couldn't remember why I'd done it the other way. After testing it a bit, I found that there was a reason not to use 'cat' though: I wanted the 'vl' program this was clipped from to be able to exit gracefully from having no parameters and no standard input, and 'cat' tended to wait for input. So the idea was to have a 'read' loop that counts the lines, (I'm assuming the Hamm base distrib has left out 'wc' too), from standard input, and if there weren't any, to exit. This doesn't work though, as 'read' waits for input just like 'cat'! On the other hand, the ">>" was deliberate, as just prior to that snippet was a bit of code, (not posted of course), which added a header, (showing how to quit, what file was being viewed, or if it was standard input, with a few separator lines), and ">" would have zapped the header. Still, all of this advice is very helpful, and if nobody objects, the above leads to the question of: whether it's possible for a script, given no parameters, to know whether there's any standard input? Or at least for it not bother with waiting for any input from the keyboard. That is, I now have it so 'mycat', or 'vl' from which it's extracted from, can handle any of these invocations: vl foo vl < foo vl --help vl nosuchfile # bails with an error message But am presently stumped at how to handle: vl ...while still keeping the above features. At present this just outputs a blank line and waits till you hit Control-C.
