file descriptor question

How come the value of the file descriptor won't show when I run nullit
in the following example?
Just curious because stuff is still written the log file.

[cdalten@localhost oakland]$ pwd
/home/cdalten/oakland
[cdalten@localhost oakland]$ touch log
[cdalten@localhost oakland]$ more nullit.c
#include <unistd.h>
#include <stdio.h>
#include <stdlib.h>

#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>

#define PATH "/home/cdalten/oakland/log"

int main(void)
{
  int fd0, fd1, fd2;
  int fd;

  int i;

  char *s = "This is a string\n";
  char t[] = "This is a string again\n";

  printf("%s\n", s);

  for(i = 0; i < 1024; i++)
    close(i);

  fd0 = open("/dev/null", O_RDWR);
  fd1 = dup(0);
  fd2 = dup(0);

  /*printf("%s\n", t);*/

  fd = open(PATH, O_WRONLY);
  printf("The value of fd is: %d", fd);
  write(fd, t, sizeof(t));

  close(fd);

  exit(EXIT_SUCCESS);
}
[cdalten@localhost oakland]$ gcc -Wall nullit.c -o nullit
[cdalten@localhost oakland]$ ./nullit
This is a string

[cdalten@localhost oakland]$ pwd
/home/cdalten/oakland
[cdalten@localhost oakland]$ more log
This is a string again

[cdalten@localhost oakland]$

This closes fd 0,1 and 2, ie, standard input, output and error. It will be a
bit hard from this point on to see anything printed on the screen.

But yet I can use that same file descriptor to write stuff to the log
file. Why?

I can't see anything strange in that. A descriptor is a descriptor,
regardless of its number. What matters is the resource (file or whatever)
it's connected to.

If descriptor, say, 2 is assigned to file "foobar", and then you close it,
the next open file will get again fd 2 (probably), but that will be
completely unrelated to the previous one.

In your code, after you close everything, fd0, fd1 and fd2 will most likely
be assigned values 0, 1, 2 because the OS usually starts assigning numbers
from the lowest unused. Since you closed everything, 0 will be the lowest
unused descriptor. All these descriptors will be connected to /dev/null.. 
After that, you open the file "log", and get another descriptor, which is
assigned to the variable fd (probably 3, for what I said above). Then you
just write something to that fd (3), which happens to be connected to the
file "log", so data is written to the file. What's not clear in that?

The fact that printf() doesn't print the value of fd (3).

     Because if you do perverse things, you risk perverse
outcomes.  In the case at hand, you got exactly what you
asked for (which wasn't a certainty, by the way).


     Because all the mischief was over and done before you
made even the first intimation of an inkling of doing anything
with the log file: It was opened, written, and closed after
and independently of the earlier ruckus.

     It is possible to mix <stdio.h> operations with <unistd.h>
operations, but care must be taken over the finicky details.
Not only did you take no care, but you seem to have gone out
of your way to be intentionally careless.  Don't Do That.

-- 
Eric Sosman
 XXXX@XXXXX.COM 

Ok. Let's do a step back. 
If you strace printf(), you will see that it ultimately calls write() on fd
1. 

In fact, these are roughly equivalent:

printf("foobar\n");
write(1,"foobar\n",7);

(of course, normally printf does more hard work because it has to interpret
the format string, parse its arguments, etc. But eventually, it will call
write() on fd 1).

This usually results in something being written on the screen, because fd 1
is connected to the terminal device (which is basically a special device
that takes care of managing input and output from/to the user - waaaay
simplified). Normally, every program, when it's started, already has its fd
0, 1 and 2 connected to the terminal, without the need to do anything.

Now, what you do in your code is to close fd 0, 1 and 2. After that, those
descriptors are not connected to anything anymore; in fact, if you called
printf(), you would get an error EBADF (Bad file descriptor). Of course,
you won't be able to print it, but trust me (and you can check with strace
if you don't trust me).

But in your code you don't do that; instead, you reassign fd 0,1 and 2
to /dev/null, so now they exist again, are valid and are connected to
something.

Then you call printf(), which, as we know, calls write() on fd 1. But fd 1
now points to /dev/null, so whatever you print with printf(), goes
to /dev/null. That's why you don't see anything on screen.

POSIX goes so far as to guarantee it will be the lowest unused, in fact,
for open() and dup().

-Beej

In article <h2413g$63n$ XXXX@XXXXX.COM >,






Has there ever been a Unix-like system that didn't do this?  I suspect 
pk said "usually" just because he wasn't totally sure that it was 
universal, but I'm pretty sure it is.

-- 
Barry Margolin,  XXXX@XXXXX.COM 
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
*** PLEASE don't copy me on replies, I'll read them in the group ***

Right, I wasn't 100% sure, although I have always seen only systems that
behave like that. Thanks (and to Beej too).

When the program started, stdout had an underlying
file descriptor.  That descriptor was closed, but the FILE *
stdout was not.  When another file descriptor with value
1 was created, the printf used it.   printf does print
the value of fd, but it is printing it to the pseudo-file
/dev/null.

Yeah--and I wasn't so sure as to say all Unices did it, either.  I
looked in the online version of The Unix Programming Manual 1st Ed, and
it doesn't mention anything about the discriptor number itself in the
man page, so who knows.

I guess the best we can say is what pk said to start, which is we can be
pretty sure they all behave this way now. :)

-Beej