Sponsored Content
Full Discussion: file descriptors
Top Forums UNIX for Dummies Questions & Answers file descriptors Post 46809 by oombera on Tuesday 27th of January 2004 12:14:54 AM
Old 01-27-2004
Short File Descriptors Tutorial

Here's a nice little (basic) tutorial: http://www.livefirelabs.com/unix_tip...3/06092003.htm.

This explains what "info" about a file they hold ... as for the more technical side, you'll have to dig deeper.
Quote:
The Standard UNIX File Descriptors - Standard Input (stdin), Standard Output (stdout), and Standard Error (stderr)

If you are familiar with UNIX I/O redirection, syntax similar to the following should not be new to you:
  • command > file 2>&1
Briefly, when command runs it sends "normal" output to file, and any error messages generated by command are also written to file. "2>&1" handles the latter.

Have you ever wondered where the numbers 2 and 1 come from? This may be common knowledge to our more experienced readers, buy may need some explaining to those who are relatively new to the UNIX operating system environment. The 2 and 1 are file descriptors. Okay, so what's a file descriptor?

When a UNIX program wants to use a file, it must first open that file. When it does so, UNIX will associate a number with the file. This number, which is used by the program when reading from and writing to the file, is the file descriptor.

A typical UNIX program will open three files when it starts. These files are:
  • standard input (also known as stdin)
  • standard output (also known as stdout)
  • standard error (also known as stderr)
Standard input has a file descriptor of 0, standard output uses 1, and the number 2 is used by standard error. Are you starting to see where this is headed?

Looking at our command again,
  • command > file 2>&1
you should now recognize that 2>&1 instructs the shell to send messages headed to stderr (2) to the same place messages to stdout (1) are sent. In our example, that place is file.

If you are wondering, > is equivalent to 1>, and < is short for <0.
 

10 More Discussions You Might Find Interesting

1. Programming

File Descriptors

Hi, I have written a daemon process, to perform certain operations in the background. For this I have to close, the open file descriptors, Does anybody know how to find out the number of open file descriptors ? Thanks in Advance, Sheetal (2 Replies)
Discussion started by: s_chordia
2 Replies

2. UNIX for Advanced & Expert Users

File Descriptors

Hello all, A few questions on file descriptors ... scenario : Sun Ultra 30 with Sun OS 5.5.1 , E250 with Solaris 2.6 In one of my servers, the file descriptor status from the soft limit and hard limits are 64 and 1024 respectively for root user. Is the soft limit (64) represents the... (3 Replies)
Discussion started by: shibz
3 Replies

3. Shell Programming and Scripting

Multiple co-processor file descriptors

I have a script that creates a KSH co-process for Oracle sqlplus and I am presently interacting with it via print -p and read -p. I also need to interact with another Oracle database what isn't permitted to have any direct connection to the first. Presently, I simply disconnect from the first... (10 Replies)
Discussion started by: tmarikle
10 Replies

4. Programming

Sockets and File descriptors

I am in a Systems programming class this semester, and our current project is to write a program utilizing sockets and fork. For the project, I decided to make my own instant messaging program. I have the code completed, but I have a problem that keeps old clients from communicating with new... (3 Replies)
Discussion started by: gstlouis
3 Replies

5. UNIX for Advanced & Expert Users

File Descriptors + cron

Hi All, This thread is going to be a discussion basically bringing out more information from the experts on cron jobs and the associated file handles. So, here is the question. There is definitely a constant ' n ' as the maximum number of file handles alloted to a process ' p '. Will... (7 Replies)
Discussion started by: matrixmadhan
7 Replies

6. UNIX for Dummies Questions & Answers

how to list the files using File Descriptors

hello, I have written a script named listall.sh with the following codes init. #!/bin/bash PATH="/proj/cmon/$1" echo $PATH if ; then echo "Usage: $0 ***" exit 1 else ls -l $PATH/*.sc fi Here there are 3 subdirectories (namely - src, data and jobs)under /proj/cmon, so... (2 Replies)
Discussion started by: shyjuezy
2 Replies

7. UNIX for Dummies Questions & Answers

Write/read to file descriptors

Is it possible to write to file descriptor 0 and read from 1 or 2? How could this be implemented? (3 Replies)
Discussion started by: machshev
3 Replies

8. HP-UX

exec and file descriptors

Hi, I speak and write english more or less, so I hope my asking be clear. :) In the company I am working, they are using control-m software to lunch shell scripts. So i put this command in all shell scripts: export LOGFILE_tmp=$PRODUC_DATA/tmp/${SCRIPT}_${PAIS}_`date... (0 Replies)
Discussion started by: anamcara
0 Replies

9. UNIX for Dummies Questions & Answers

Semaphores and File Descriptors

What is the difference between a file descriptor and a semaphore? My basic understanding is: - a file descriptor is a small positive integer that the system uses instead of the file name to identify an open file or socket. - a semaphore is a variable with a value that indicates the... (1 Reply)
Discussion started by: Mr_Webster
1 Replies

10. Shell Programming and Scripting

Questions about file descriptors

Hi, I'm playing with KSH I entered following command in terminal { echo "stdout" >&1; echo "stderr" >&2; } > out And I get only stoud in a new file out. My question is: Where did my stderr vanish ? (5 Replies)
Discussion started by: solaris_user
5 Replies
STDIN(3)						     Linux Programmer's Manual							  STDIN(3)

NAME
stdin, stdout, stderr - standard I/O streams SYNOPSIS
#include <stdio.h> extern FILE *stdin; extern FILE *stdout; extern FILE *stderr; DESCRIPTION
Under normal circumstances every UNIX program has three streams opened for it when it starts up, one for input, one for output, and one for printing diagnostic or error messages. These are typically attached to the user's terminal (see tty(4) but might instead refer to files or other devices, depending on what the parent process chose to set up. (See also the "Redirection" section of sh(1).) The input stream is referred to as "standard input"; the output stream is referred to as "standard output"; and the error stream is referred to as "standard error". These terms are abbreviated to form the symbols used to refer to these files, namely stdin, stdout, and stderr. Each of these symbols is a stdio(3) macro of type pointer to FILE, and can be used with functions like fprintf(3) or fread(3). Since FILEs are a buffering wrapper around UNIX file descriptors, the same underlying files may also be accessed using the raw UNIX file interface, that is, the functions like read(2) and lseek(2). On program startup, the integer file descriptors associated with the streams stdin, stdout, and stderr are 0, 1, and 2, respectively. The preprocessor symbols STDIN_FILENO, STDOUT_FILENO, and STDERR_FILENO are defined with these values in <unistd.h>. (Applying freopen(3) to one of these streams can change the file descriptor number associated with the stream.) Note that mixing use of FILEs and raw file descriptors can produce unexpected results and should generally be avoided. (For the masochis- tic among you: POSIX.1, section 8.2.3, describes in detail how this interaction is supposed to work.) A general rule is that file descrip- tors are handled in the kernel, while stdio is just a library. This means for example, that after an exec(3), the child inherits all open file descriptors, but all old streams have become inaccessible. Since the symbols stdin, stdout, and stderr are specified to be macros, assigning to them is nonportable. The standard streams can be made to refer to different files with help of the library function freopen(3), specially introduced to make it possible to reassign stdin, std- out, and stderr. The standard streams are closed by a call to exit(3) and by normal program termination. CONFORMING TO
The stdin, stdout, and stderr macros conform to C89 and this standard also stipulates that these three streams shall be open at program startup. NOTES
The stream stderr is unbuffered. The stream stdout is line-buffered when it points to a terminal. Partial lines will not appear until fflush(3) or exit(3) is called, or a newline is printed. This can produce unexpected results, especially with debugging output. The buffering mode of the standard streams (or any other stream) can be changed using the setbuf(3) or setvbuf(3) call. Note that in case stdin is associated with a terminal, there may also be input buffering in the terminal driver, entirely unrelated to stdio buffering. (Indeed, normally terminal input is line buffered in the kernel.) This kernel input handling can be modified using calls like tcse- tattr(3); see also stty(1), and termios(3). SEE ALSO
csh(1), sh(1), open(2), fopen(3), stdio(3) COLOPHON
This page is part of release 3.53 of the Linux man-pages project. A description of the project, and information about reporting bugs, can be found at http://www.kernel.org/doc/man-pages/. Linux 2008-07-14 STDIN(3)
All times are GMT -4. The time now is 09:24 AM.
Unix & Linux Forums Content Copyright 1993-2022. All Rights Reserved.
Privacy Policy