ISO C has no control over the Shell; there's nothing that requires that
the shell be implemented in C (or in any other specific way). In any
case, the problem lies with the application written in C that (in the
example) rewinds stdout.
This appears to be a bug in the C standard that breaks backwards
compatibility with existing shell scripts (if freopen(NULL,... is used)
in a very big way. (I would expect that in fact it breaks backwards
compatability not only with sh (and *sh) but with cmd.exe, and whatever
other scripting languages there are on other systems.) (For
completeness, perl, python, tcl and friends have the same problem if
used in the same way as the shells.)
Donn
P.S. There may be a weirdnix here; did we ever actually require that
"(cat a; cat b)> foo" be the same as "cat a b > foo" or did this just
fall so deeply into the "common sense" category that we never said it?
(Obviously more generalized than here.)
> -----Original Message-----
> From: Clive D.W. Feather [mailto:yyyyy@xxxxxxxxx]
> Sent: Tuesday, September 09, 2003 3:39 AM
> To: Donn Terry
> Cc: Geoff Clare; yyyyyyyyyyyyyy@xxxxxxxxxxxxx
> Subject: Re: C99 questions about freopen(NULL, ...)
>
> Donn Terry said:
> >> You know, I can make a reasonable argument that at program startup
it
> is
> >> required for stdin/stdout/stderr to act as if they have just been
> opened:
> >> [#7] At program startup, three text streams are predefined
> >> and need not be opened explicitly
> >> implies that they have been opened as if by stdin. So the file open
on
> >> stdin must be at the start and the ones on stdout/stderr must
either be
> at
> >> the start or opened in an append mode.
> >
> > Caution here: this statement should be tested against all the ways a
> > file can be opened in the shell, and if it precludes any of them,
then
> > it's probably wrong.
>
> No, if it precludes them then the shell is not acting in conformance
with
> ISO C.
>
> > In particular, depending on how you interpret
> > things, the following shell lines might be a problem for a version
of
> > cat and an implementation that are both strictly conforming to the
> > above.
> >
> > (cat a; cat b) >foo # by some measures, the 2'd cat's access to
foo
> > (stdout) won't be "as if [it] had just been opened".
> >
> > (head; cat) < bar # there are OTHER synchronization problems with
this,
> > but clearly the cat won't/shouldn't see the beginning of bar
(stdin).
> >
> > cat <&6 # where fd 6 was already open in the shell.
>
> I agree that Here Be Dragons. This needs a full revisiting by all
parties.
>
> --
> Clive D.W. Feather | Work: <yyyyy@xxxxxxxxx> | Tel: +44 20 8495
> 6138
> Internet Expert | Home: <yyyyy@xxxxxxxxxx> | *** NOTE CHANGE ***
> Demon Internet | WWW: http://www.davros.org | Fax: +44 870 051
> 9937
> Thus plc | | Mobile: +44 7973
377646
|