file descriptor question



  • 1. mutex: busy waitting or sleep??
    when one thread try to lock a locked mutex, it will be busy waitting or sleep??how wakeup the thread if it sleep?
  • 2. Make file problem
    Hi All, below is my makefile to indent C source files....... ############################################################### vpath %.c ../src BLANKLINE_OPTS = -bad -bap -bbb -nsob COMMENTS_OPTS = -fca STATEMENTS_OPTS = -br -ce -cdw -cli2 -cbi2 -ss -npcs DECLARATIONS_OPTS = -di26 -bfda -psl -brs INDENTATION_OPTS = -ppi3 BREAKING_LONG_LINES = -bbo INDENT = indent ALL_OPTS = $(BLANKLINE_OPTS) $(COMMENTS_OPTS) $(STATEMENTS_OPTS) \ $(DECLARATIONS_OPTS) $(INDENTATION_OPTS) $(BREAKING_LONG_LINES) ALL_OPTS_STR = "$(ALL_OPTS)" #put all the source files here SRCS = App_pactivity.c App_per.c AppCommands.c APP_DevSDK.c App_main.c DEPS = $(patsubst %.c, %.d, $(SRCS)) include $(DEPS:.c=.d) %.d : %.c @printf "%s : %s\n\t %s %s -st %s > %s\n" $*.bak.c $< $(INDENT) $ (ALL_OPTS_STR) $< $*.bak.c > $@ .PHONY:clean clean: rm -f *.d *.bak.c ####################################################################### dependency files are generated for all the c files..but make is including only the first dependency file i.e App_pactivity.d Any help for the above problem is appreciated. Regards, Kiran
  • 3. Increment counter upon each execution of shell script
    Hello: I am writing a Unix shell script which will be executing by means of a cron job every day once a day. Inside the shell script, I have a counter which must be incremented every time the shell script runs. For example, if today the counter is 4408, after the shell script is executed tomorrow, it should be 4409, the day after tomorrow 4410, etc. This value is to be used in the shell script, which transfers a certain file (via ftp). The number will tell what file to extract. Any help on how to set up this counter will be greatly appreciated. Another solution that I thought may be feasible to my problem is instead of keeping a counter, if I can figure out a way to determine which file is the most recently modified file (which should be the one with the greater number) - but I don't know how to do this or even if this is possible. Thanks
  • 4. Will a signal interrupt a read(2) in it's middle way?
    Hi, I am working on unix domain sockets. In the sockets, we transfer data with a specific structure. Will a signal interrupt my read(2) when it get part of the data which already in kernel's buffer? If a reading can be interrupted when I got part of bytes of the whole structure, restart is not easy. Thanks.

file descriptor question

Postby K-mart Cashier » Sun, 28 Jun 2009 06:11:25 GMT

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
[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++)

  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));


[cdalten@localhost oakland]$ gcc -Wall nullit.c -o nullit
[cdalten@localhost oakland]$ ./nullit
This is a string

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

[cdalten@localhost oakland]$

Re: file descriptor question

Postby pk » Sun, 28 Jun 2009 06:22:08 GMT

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.

Re: file descriptor question

Postby chad » Sun, 28 Jun 2009 06:37:41 GMT

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

Re: file descriptor question

Postby pk » Sun, 28 Jun 2009 06:50:57 GMT

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?

Re: file descriptor question

Postby chad » Sun, 28 Jun 2009 07:01:30 GMT

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

Re: file descriptor question

Postby Eric Sosman » Sun, 28 Jun 2009 07:16:41 GMT

     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

Re: file descriptor question

Postby pk » Sun, 28 Jun 2009 07:18:15 GMT

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

In fact, these are roughly equivalent:


(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

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.

Re: file descriptor question

Postby Beej Jorgensen » Sun, 28 Jun 2009 11:45:04 GMT

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


Re: file descriptor question

Postby Barry Margolin » Sun, 28 Jun 2009 11:51:22 GMT

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 ***

Re: file descriptor question

Postby pk » Sun, 28 Jun 2009 18:06:03 GMT

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

Re: file descriptor question

Postby William Pursell » Sun, 28 Jun 2009 21:41:10 GMT

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

Re: file descriptor question

Postby Beej Jorgensen » Mon, 29 Jun 2009 01:17:35 GMT

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. :)


Similar Threads:

1.File descriptor question

Hey forum!

read command takes -u fd option. How can I do the same with sed?

exec 3<>$FILE

# save stdin to fd 3
exec 3<&0

# redirect motherfucker   ??
exec 0<"$FILE"

# noop not working :(
sed -i 's/foo/bar/'

exec 3>&-

Trying on GNU sed 4.1.x, bash 3.2.xx and Ubuntu Linux 8.10. I'm aware
of sed -i option but I want it on fd. All inputs and suggestions are

2.rlim file descriptor question

I'm analysing a Solaris 8 server for stability and i'm suspicious of the
file desciptor settings.  I've been monitoring the server every hour using a
script I wrote via cron.  My script checks the number of file descriptors
per process in the /proc directory.  I'm seeing a process increase it's file
descriptors over time and now it's at 580 file descriptors.

In /etc/system the following parameters are set:-

set rlim_fd_max=1024
set rlim_fd_cur=256

What is the impact of a process with 580 file descriptors when the rlim
settings above are set?  I assume that the server will be ok because the max
is set to 1024 but i'm not sure....

3.question about file descriptor

I haven't a clear idea about file descriptor......A file descriptor is
an integer:
0-standard input
1-standard output
2-standard error
Can i have more file descriptors?How can be used?
I can duplicate a file descriptor with <& or >&: what means 1<&2 ?I
think that standard input (1) displays also standard error (2)
this correct?

4.File descriptors in linux question

Hi there i'm programming a linux application for a university
homework. I was asking myself: if I have a pthread multithreading
application and I want each thread to open a different file descriptor
on the same file for file reading only, how many file descriptors can
my app open? Will each descriptor store a different cursor for the i/o
position or do I risk incoherent reading?

Thank you :)

5.Conceptual question on writeable file descriptors

Say  program A closes it's write half of the connection and then
Program B, which was communicating ith Program A (via a pipe), then
tries to write to the fd on Program A. Program A would generate
SIGPIPE right?

If Program A generates a SIGPIPE, how can the fd on Program A be ready
for writing? Ie, if program A closes it's write end, then how can it
be ready for writing?

6. A question on file descriptors

7. syncronizing between two file descriptors open on the same file

8. 3.0-release and "can't stat file system, bad file descriptor"

Return to unix


Who is online

Users browsing this forum: No registered users and 18 guest