Re: Strange pager (less, more) behavior
- From: Dave Ulrick <ulrick@xxxxxxxxxxxxxxxx>
- Date: Wed, 29 Mar 2006 15:43:06 +0000 (UTC)
On 29 Mar 2006 11:13:41 GMT,
Måns Rullgård <mru@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote:
Closing stdout is fine, and the correct thing to do in this case. If
you do not close it, you have no chance of detecting errors in the
final buffer flush. There is no reason for not closing
stdin/out/err. They are all closed automatically on program exit
anyway, so there is no externally visible difference.
I should mention that my programs allow the user to associate multiple
output streams with stdout and stderr with the understanding that if, say,
multiple FILEs are associated with stdout, their output will be interleaved.
(Of course, doing that is useful mainly for troubleshooting purposes, such
as seeing program data output interleaved with a formatted report to ensure
that the two reflect the same data.) Also, my programs sometimes write
directly to stderr both explicitly and via a FILE pointer that's set
to stderr. For example:
FILE *openfile (const char *filename,
const char *mode,
FILE *defaultfile)
{
FILE *f;
if (!filename || strcmp (filename, "-") == 0)
return defaultfile;
else if (!(f = fopen (filename, mode)))
{
perror (filename);
return NULL;
}
else
return f;
}
int closefile (FILE *f)
{
if (f == stdin || f == stdout || f == stderr)
return 0;
else
return fclose (f);
}
...
if ((fp = openfile (filename, "w", stderr)))
{
fprintf (fp, "Via fp\n");
fprintf (stderr, "Via stderr\n");
closefile (f);
}
Therefore, if I were to close stdout and stderr, I'd have to do so after I'd
fclose()d all of my other files, right? I've heard that once you fclose()
a standard stream, you can't reopen it.
However, I've noticed on my Linux 2.6.9 (and above) PCs that at
least some of my programs sometimes gets involved in a rather strange
bit of (mis)behavior when I pipe its output to a pager such as 'less'
or 'more'. When I do this, my command line looks something like
this:
$ ./myprogram 2>&1 | less
99.44% of the time, this works perfectly, but every once in a while,
the pager doesn't appear. Instead, 'bash' gives me these messages:
[1]+ Stopped ./myprogram 2>&1 | less
as though I'd pressed Ctrl-Z to stop the pipeline even though I've not
pressed any such key. 'ps auxw' reveals that my program has completed
I've seen this happen on occasion as well. It's rare enough that I
haven't tried to figure out why it happens, and I've not been able to
spot any pattern.
I'm glad to hear that I'm not alone. So far I've not managed to Google
anyone else who's noticed this problem. The most promising thing I've
found is a reference in a third-party software manual to alleged behavior
on the part of Linux having to do with unexpected SIGSTOP signals being
received by processes, but the manual didn't go into enough detail to
confirm whether or not this was the same problem I've been seeing.
AFAIK, I've never run any of the OP's programs.
I'm certain you haven't, since they are for internal business use, although
I'm toying with the idea of open-sourcing certain parts of them such as
an 'ini file' function library that implements an easy-to-use way to
configure a C program via a plain-text configuration file. Features include
symbolic variable substitution and nested if/then/else.
Måns Rullgård
mru@xxxxxxxxxxxxx
Dave
--
Dave Ulrick
Email: d-ulrick@xxxxxxx
Web: http://www.niu.edu/~ulrick/
.
- References:
- Strange pager (less, more) behavior
- From: Dave Ulrick
- Re: Strange pager (less, more) behavior
- From: Måns Rullgård
- Strange pager (less, more) behavior
- Prev by Date: Re: what's the relation among wxWidgets,xWindows and GTK+?
- Next by Date: Re: Strange pager (less, more) behavior
- Previous by thread: Re: Strange pager (less, more) behavior
- Next by thread: Re: Strange pager (less, more) behavior
- Index(es):
Relevant Pages
|
