bug-grep
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bug-grep] rewriting the main loop


From: Stepan Kasal
Subject: [bug-grep] rewriting the main loop
Date: Fri, 25 Feb 2005 08:35:08 +0100
User-agent: Mutt/1.4.1i

Hello,
  Claudio has volunteered to rewrite the main loop.
This is something I think about for a long time, so I'm looking forward
to it.  Plese allow me to propose a sketch of how the code should look
like, in pseudo-code:

main() {
  ...options etc...
  if (no args given)
        grep_stdin();
  else
        foreach(arg) grep_parameter(arg)
}

grep_parameter(arg) {
  if (arg == "-")
        grep_stdin()
  else
        grep_file(arg)
}

grep_file(file) {
  if (DIRECTORIES != READ || DEVICES != READ) {
        stat(file)
        if(is a dir) {
                if (DIRECTORIES == RECURSE)
                        return grep_dir(file);
                if (DIRECTORIES == SKIP)
                        return;
        } else if (DEVICES == SKIP && is a device)
                return;
  }
  try to open the file, if an error occurs, report it and return
  perhaps set the title
  grep_fd(fd);
}

grep_stdin() {
  set the title for stdin
  grep_fd(0)
}

... and grep_fd inherits most of the code currently living in grep()

One more note about errors and suppressing of errors:

Without -s, all errors should be reported; grep 2.5 and 2.5.1 doesn't
say anything on "grep pat dir" while it really should report that it
cannot read "dirname", eg. by this line on GNU/Linux:
        grep: dirname: Is a directory
This should also be derived from the sketch above.

For -s, POSIX says:
        Suppress the error messages ordinarily written for nonexistent or
        unreadable files. Other error messages shall not be suppressed.

So with -s, we should suppress EACCESS and EISDIR errors.

Perhaps we should be more exact and suppress these errors only if they
appear at the open() call or at the moment we read first chunk of data.
If it somehow happens that they appear later, we should rather report them.
And if we have (DIRECTORIES != READ) we shouldn't encounter any EISDIR.
Again, we could be careful and report EISDIR, if it somehow sneaks in.

But perhaps this I'm too paranoid in the previous paragraph.

Thanks in advance:
- to all of you for reviewing this design sketch
- to Claudio for implementing it

Have a nice day,
        Stepan




reply via email to

[Prev in Thread] Current Thread [Next in Thread]