That is the power of Linux and C, and would be alien to someone not familiar 
with those platforms/languages.

stdin, stdout and stderr just.. are.  The same way if we say DSPLY  MYVAL in 
RPG we know it is going to go to the interactive device session without us 
having to open it, or set up a display file, etc...  The OS takes care of that.

It is very possible to redirect STDIN and STDOUT and is done in Linux/C all the 
time.

cat myfile >myotherfile

cat will normally display a file to the screen (type in MS-DOS).  The > 
redirector redirects stdout to myotherfile by the OS and so it gets written to 
that file isntead.  cat doesn't know, or care, where stdout is directed to.  If 
it started to mess around with stdout, in fact, it would mess up the OS level 
redirection (very similar to AS/400 OVRPRT or OVRDBF).

Yes, it *is* possible to get a hold of the stdin, stdout or stderr file 
pointers and redirect them somewhere else, and they are, normally, 0 1 and 2, 
but you shouldn't do that unless you have a very very reason.  And you 
shouldn't worry about closing them either.  Those are the exceptions to the 
rule about closing open files.

HTH.

Regards,

Jim Langston

David Morris wrote:

> James,
>
> Thanks for the help. I am still wondering
> if you don't assign a specific file handle
> to stdin/out/err, how do the utilities find
> these files? For example, it looks like QSH
> uses /dev/qsh-stdin-null. When I asked a
> friend who is familiar with Linux how STDIN
> is identified he said that /dev/stdin-null
> is the norm, but he didn't know see know how
> Linux finds this since redirection could pick
> up STDIN from another source. How do nested
> utilities know this unless there is some
> standard file handle?
>
> I suppose I could make this easy and just use
> C, but I really want to find out how the
> utilities make this association and don't end
> up walking on each other.
>
> Thanks,
>
> David Morris
>
> >>> james@eaerich.com 04/13/02 12:19 PM >>>
> On Sat, 13 Apr 2002, David Morris wrote:
>
> > STDIN should be assigned a handle of 0, STDOUT 1, and STDERR 2. At
> least
> > that is what the PASE manual says.
>
> stdin, stdout, and stderr should not be assigned anything by your
> program.
> The OS assigns the values of the handles.  Your program just remembers
> what was assigned.  I'm not sure of the RPG code but it should be
> similar
> to this:
>
> C               eval    filehandle = open (stdin)
>
> filehandle could be anything. Of course some values indicate an error
> occurred.  Maybe some C code will help since stdin and friends come from
> that world:
>
> infile = fopen(stdin, "r");
> if (infile == NULL)
> {
>         printf("Unable to open stdin\n");
> }
>
> However (in C anyway) stdin, stdout, and stderr are always open, even if
> your program does not use them.  You don't need to do the above because
> you would be trying to open an already open file.  Now I don't think the
> same is true of RPG but that may help to explain your other questions
> below.
>
> > You should close these if you open them when your process is
> completed,
> > this just seems like a good practice.
>
> In other languages you don't have to worry about this in the case of
> stdin, etc. because they are always opened and closed for you.
>
> > I found something strange. With QSH it opens a single file at 0 if
> > possible, but it will use anything if 0 is not available. QSH closes
> > this file when you press F3. Debug does not operate this way. Debug
> > appears to 0,1,2 and never close them.
> >
> > How does a unix utility like grep locate STDIN, STDOUT, and STDERR?
> Does
> > it use the file handle 0,1,2 or some other means?
>
> Since they are always opened and closed for you the utilities (and every
> *nix program) work something like this (given in C since that what they
> are written in on *nix):
>
> int main()
> {
> char junk[10];
>
> fprintf (stderr, "I am writing to stderr.\n");
> fprintf (stdout, "I am writing to stdout.\n");
> printf ("I am writing to stdout here, too.\n");
> /* Read from stdin and store it in junk */
> /* This is how you do a buffer overflow! */
> fscanf (stdin, "%s", junk);
> }
>
> James Rich
> james@eaerich.com
> _______________________________________________
> This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing list
> To post a message email: RPG400-L@midrange.com
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/cgi-bin/listinfo/rpg400-l
> or email: RPG400-L-request@midrange.com
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/rpg400-l.





As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.