Am writing a line-based filter a la sed or tr. What I would like it to do, however, is if there is no input at start-up, it should present some usage information and exit.
E.g.,
$ MyLineFilter < TextFile # OK
$ Some Command | MyLineFilter # OK
$ MyLineFilter MyLineFilter: Did not find any text to process. Exiting.
$ echo $? 1
$ MyLineFilter Command Line Args # Undecided what to do here ...
Would appreciate some ideas on how to implement this.
Currently, am writing the usage information to stderr (unconditionally), but the executable waits for input until it finds EOF.
> Am writing a line-based filter a la sed or tr. What I would like it to > do, however, is if there is no input at start-up, it should present some > usage information and exit.
> E.g.,
> $ MyLineFilter < TextFile # OK
> $ Some Command | MyLineFilter # OK
> $ MyLineFilter > MyLineFilter: Did not find any text to process. Exiting.
> $ echo $? > 1
> $ MyLineFilter Command Line Args # Undecided what to do here ...
> Would appreciate some ideas on how to implement this.
> Currently, am writing the usage information to stderr (unconditionally), > but the executable waits for input until it finds EOF.
In the third case, there IS input -- standard input is connected to the terminal, and the user is supposed to type the input.
If you don't want to take input from the terminal, you can use:
if test -t then echo $0: Did not find any text to process. Exiting. >&2 exit 1 fi
-- Barry Margolin, bar...@alum.mit.edu Arlington, MA *** PLEASE post questions in newsgroups, not directly to me *** *** PLEASE don't copy me on replies, I'll read them in the group ***
>Am writing a line-based filter a la sed or tr. What I would like it to >do, however, is if there is no input at start-up, it should present some >usage information and exit.
What is *NO INPUT*? If stdin is closed (redirection <&- or 0<&- ), you'll get an error when you try to read from stdin. It is unlikely that anyone will do this. Chances are most commands will not react cleanly to being invoked with stdin closed if they expect to use it.
Reading from the user's terminal is not "no input". If you want to detect if stdin is connected to the user's terminal or has been redirected to another terminal, isatty() can detect this.
Anand Hariharan wrote: > Am writing a line-based filter a la sed or tr. What I would like it to > do, however, is if there is no input at start-up, it should present some > usage information and exit.
> E.g.,
> $ MyLineFilter < TextFile # OK
> $ Some Command | MyLineFilter # OK
> $ MyLineFilter > MyLineFilter: Did not find any text to process. Exiting.
> $ echo $? > 1
> $ MyLineFilter Command Line Args # Undecided what to do here ...
> Would appreciate some ideas on how to implement this.
> Currently, am writing the usage information to stderr (unconditionally), > but the executable waits for input until it finds EOF.
I guess what you mean is that if the stdin is a terminal, it should print the usade information? That can then be accomplished by calling isatty() on stdin, but I would say it would be better behaviour for the program to accept input from the terminal as well, to allow users to simply start the program and type text into it to test things easily or do small amounts of work directly with minimum bother or copy and paste text to the program. This is the way other unix filters work.
> Am writing a line-based filter a la sed or tr. What I would like it to > do, however, is if there is no input at start-up, it should present some > usage information and exit.
> E.g.,
(...) > $ MyLineFilter > MyLineFilter: Did not find any text to process. Exiting.
> $ echo $? > 1
(...) > Would appreciate some ideas on how to implement this.
|
