fclose then fopen equivalent for stdout?

[David Mathog]

A program of mine writes to a tape unit. Output can be either through
stdout or through a file opened with fopen(). When all the data is
transferred to tape the program needs to close the output stream so that
the tape driver will write a filemark on the tape. Otherwise multiple
clumps of data saved to tape would all appear to be one big file on the
tape.

When the tape unit device was explicitly opened with fopen()
that's possible: call fclose() and then for the next batch
of data fopen() the tape device again and write some more.

However when data is going through stdout like:

program /dev/nst0

is there an equivalent operation? Maybe something like this:

fputc(stdout,EO F);

or this

freopen(NULL,"w b",stdout);

?

Thanks,

David Mathog

[David Mathog]

David Mathog wrote:

fputc(stdout,EO F);

oops, that should have been:

fputc(EOF,stdou t);

David Mathog

[Eric Sosman]

David Mathog wrote On 10/25/06 12:48,:

A program of mine writes to a tape unit. Output can be either through
stdout or through a file opened with fopen(). When all the data is
transferred to tape the program needs to close the output stream so that
the tape driver will write a filemark on the tape. Otherwise multiple
clumps of data saved to tape would all appear to be one big file on the
tape.

When the tape unit device was explicitly opened with fopen()
that's possible: call fclose() and then for the next batch
of data fopen() the tape device again and write some more.

However when data is going through stdout like:

program /dev/nst0

is there an equivalent operation? Maybe something like this:

fputc(stdout,EO F);

(Corrected to fputc(EOF, stdout) in a follow-up.)

No, this would merely write a character to the output.
The identity of exactly which character gets written is a
little fuzzy in that it depends on the value of the EOF
macro (usually -1, but could be another negative integer)
and on what you get when converting that value to a char
in the local encoding.

or this

freopen(NULL,"w b",stdout);

Undefined behavior: The first argument is supposed to
be a string (a string that names a file), but NULL is not
a string. It's much like trying fopen(NULL, "wb").

Here's a suggestion: You're trying to obtain the effect
of fclose(), right? Does any particular function spring to
mind as being likely to perform the operations of fclose()?
How about ... <<wait for it>... fclose()?

--
Er*********@sun .com

[David Mathog]

Eric Sosman wrote:

Here's a suggestion: You're trying to obtain the effect
of fclose(), right? Does any particular function spring to
mind as being likely to perform the operations of fclose()?
How about ... <<wait for it>... fclose()?

I'm not trying to get fclose, I'm trying to get

fclose()
fopen()

How then does the program CONTINUE to write to stdout
so that data gets to the tape device after having called
fclose(stdout)?

What parameters for fopen() reassociate stdout with the same
output stream following the fclose()?

Regards,

David mathog

[Harald van Dijk]

Eric Sosman wrote:

David Mathog wrote On 10/25/06 12:48,:

A program of mine writes to a tape unit. Output can be either through
stdout or through a file opened with fopen(). When all the data is
transferred to tape the program needs to close the output stream so that
the tape driver will write a filemark on the tape. Otherwise multiple
clumps of data saved to tape would all appear to be one big file on the
tape.

When the tape unit device was explicitly opened with fopen()
that's possible: call fclose() and then for the next batch
of data fopen() the tape device again and write some more.

However when data is going through stdout like:

program /dev/nst0

is there an equivalent operation? Maybe something like this:

fputc(stdout,EO F);

(Corrected to fputc(EOF, stdout) in a follow-up.)

No, this would merely write a character to the output.
The identity of exactly which character gets written is a
little fuzzy in that it depends on the value of the EOF
macro (usually -1, but could be another negative integer)
and on what you get when converting that value to a char
in the local encoding.

or this

freopen(NULL,"w b",stdout);

Undefined behavior: The first argument is supposed to
be a string (a string that names a file), but NULL is not
a string. It's much like trying fopen(NULL, "wb").

Actually, freopen() has special behaviour for a NULL filename. I don't
know enough about it to know if that special behaviour is useful here,
though.

Here's a suggestion: You're trying to obtain the effect
of fclose(), right? Does any particular function spring to
mind as being likely to perform the operations of fclose()?
How about ... <<wait for it>... fclose()?

So how do you write to stdout again after closing it?

[David Mathog]

Harald van Dijk wrote:

Eric Sosman wrote:

>David Mathog wrote On 10/25/06 12:48,:

>> freopen(NULL,"w b",stdout);

Undefined behavior: The first argument is supposed to
be a string (a string that names a file), but NULL is not
a string. It's much like trying fopen(NULL, "wb").

Actually, freopen() has special behaviour for a NULL filename. I don't
know enough about it to know if that special behaviour is useful here,
though.

I think probably not helpful. From what I can tell this syntax is
supposed to be used to switch the stream from binary to text (for
instance), but doesn't specify that the stream must be closed and
reopened. And it's C99. Perhaps one of the language gurus can
clarify that point.

Anyway, as far as I can tell C allows stdin,stdout,st derr to be closed,
but provides no way to open them again afterwards such that the
stream is connected to the previous source or destination.

Thanks,

David Mathog

[Christopher Benson-Manica]

David Mathog <ma****@caltech .eduwrote:

What parameters for fopen() reassociate stdout with the same
output stream following the fclose()?

It sounds like what you want to do is fclose(stdout) and then somehow
open it again; while not an exact match for your situation, FAQ 12.34
(http://c-faq.com/stdio/undofreopen.html) suggests strongly to me that
once you fclose(stdout) you are on your own getting it open again.
I don't believe you stated what your system setup is, but 12.34
suggests that you have some potential options if you're using Unix -
of course, those options would be best discussed on
comp.unix.progr ammer.

--
C. Benson Manica | I *should* know what I'm talking about - if I
cbmanica(at)gma il.com | don't, I need to know. Flames welcome.

[Jordan Abel]

2006-10-25 <eh**********@n aig.caltech.edu >,
David Mathog wrote:

Eric Sosman wrote:

> Here's a suggestion: You're trying to obtain the effect
of fclose(), right? Does any particular function spring to
mind as being likely to perform the operations of fclose()?
How about ... <<wait for it>... fclose()?

I'm not trying to get fclose, I'm trying to get

fclose()
fopen()

How then does the program CONTINUE to write to stdout
so that data gets to the tape device after having called
fclose(stdout)?

I think his question is, basically. WHY do you need to fclose() in the
first place? What's the fclose() for, if not to have the stream be
permanently closed i.e. completely done with writing data to it?

[David Mathog]

Christopher Benson-Manica wrote:

David Mathog <ma****@caltech .eduwrote:

>What parameters for fopen() reassociate stdout with the same
output stream following the fclose()?

It sounds like what you want to do is fclose(stdout) and then somehow
open it again; while not an exact match for your situation, FAQ 12.34
(http://c-faq.com/stdio/undofreopen.html) suggests strongly to me that
once you fclose(stdout) you are on your own getting it open again.
I don't believe you stated what your system setup is, but 12.34
suggests that you have some potential options if you're using Unix -
of course, those options would be best discussed on
comp.unix.progr ammer.

Yes, that does suggest that what I'm after is not supported by the C
language standard. Actually I didn't want so much to fclose it as to
set EOF, but there was no other way to do it besides calling fclose().

It is a bit odd that ANSI C provides the functions clearerr()
and feof(), to clear and test the EOF status on a file, but
it does not provide conjugate seteof() or seterr() functions.
These would have allowed a couple of bits of out of band
communication to ride along on a binary data stream. That's
a pity because in the general unixy pipeline processing
of an arbitrary binary data stream

program1 | program2

there is currently no way to signal through that same pipe any other
information, in particular, EOF. Open another pipe and you must then
take pains to make sure the data streams stay in sync. The
safest way to process multiple independent
blocks of binary information with this pipe is to run it multiple times
with separate data, as opposed to running it once and stuffing EOF
states into the pipe in program1 with:

seteof(stdout)

which could then be caught in program2 which could then issue
a cleareof(stdin) to open up the pipe again.

Thanks,

David Mathog

[David Mathog]

Jordan Abel wrote:

2006-10-25 <eh**********@n aig.caltech.edu >,
David Mathog wrote:

>I'm not trying to get fclose, I'm trying to get

fclose()
fopen()

I think his question is, basically. WHY do you need to fclose() in the
first place? What's the fclose() for, if not to have the stream be
permanently closed i.e. completely done with writing data to it?

See the first two paragraphs of the top post.

David Mathog