Tag Info

Hot answers tagged

63

No, you certainly don't want to close file descriptors 0, 1 and 2. If you do so, the first time the application opens a file, it will become stdin/stdout/stderr... For instance, if you do: echo text | tee file >&- When tee (at least some implementations, like busybox') opens the file for writing, it will be open on file descriptor 1 (stdout). So ...


24

For background: a number 1 = standard out (i.e. STDOUT) a number 2 = standard error (i.e. STDERR) if a number isn't explicitly given, then number 1 is assumed by the shell (bash) First let's tackle the function of these. For reference see the Advanced Bash-Scripting Guide. Functions 2>&- The general form of this one is M>&-, where "M" ...


16

First, note that the syntax for closing is 5>&- or 6<&-, depending on whether the file descriptor is being read for writing or for reading. There seems to be a typo or formatting glitch in that blog post. Here's the commented script. exec 5>/tmp/foo # open /tmp/foo for writing, on fd 5 exec 6</tmp/bar # open /tmp/bar for ...


16

Most commands have a single input channel (standard input, file descriptor 0) and a single output channel (standard output, file descriptor 1) or else operate on several files which they open by themselves (so you pass them a file name). (That's in addition from standard error (fd 2), which usually filters up all the way to the user.) It is however sometimes ...


15

I find it easier to think of using assignments. You start out with 1 = /dev/tty 2 = /dev/tty then your first example, 1> file.txt 2>&1, does 1 = file.txt 2 = 1 # and currently 1 = file.txt leaving you with 1 = file.txt 2 = file.txt If you did it the other way, again you start with 1 = /dev/tty 2 = /dev/tty then 2>&1 ...


14

The file descriptor, i.e. the 4 in your example, is the index into the process-specific file descriptor table, not the open file table. The file descriptor entry itself contains an index to an entry in the kernel's global open file table, as well as file descriptor flags.


13

It's been available on Linux back into its prehistory. It is not POSIX, although many actual shells (including AT&T ksh and bash) will simulate it if it's not present in the OS; note that this simulation only works at the shell level (i.e. redirection or command line parameter, not as explicit argument to e.g. open()). That said, it should be available ...


13

Each process has its own file descriptor table. File descriptor 4 in process 1234 points inside process 1234's table. File descriptor 4 in process 5678 points inside process 5678's table. A case you must be familiar with are file descriptors 0, 1 and 2 which for each process are the standard input, standard output and standard error, pointing wherever these ...


11

In "Advanced Programming in the UNIX Environment", W. Richard Stevens says it is a performance optimization: By specifying the highest descriptor we're interested in, the kernel can avoid going through hundred of unused bits in the three descriptor sets, looking for bits that are turned on. (1st edition, page 399) If you are doing any kind of UNIX ...


11

Nothing: there are three standard file descriptions, STDIN, STDOUT, and STDERR. They are assigned to 0, 1, and 2 respectively. What you are seeing there is an artifact of the way ls(1) works: in order to read the content of the /proc/self/fd directory and display it, it needs to open that directory. That means it gets a file handle, typically the first ...


11

IOW I have always wondered if >/dev/null means that cat mybigfile >/dev/null would actually process every byte of the file and write it to /dev/null which forgets it. It's not a full answer to your question, but yes, the above is how it works. cat reads the named file(s), or standard input if no files are named, and outputs to its standard output ...


9

The file descriptor 1 translates to the stdout FILE structure in the Kernel's Open Files Table. This is a misunderstanding. The kernel's file table has nothing whatsoever to do with user-space file structures. In any event, the kernel has two levels of indirection. There is the internal structure that represents the file itself, which is reference ...


9

Almost all the files under /dev are device files. Whereas reading and writing to a regular file stores data on a disk or other filesystem, accessing a device file communicates with a driver in the kernel, which generally in turn communicates with a piece of hardware (a hardware device, hence the name). There are two types of device files: block devices ...


9

Important is to know that there are two kinds of limit: hard limit is configurable by root only. This is the highest possible value (limit) for the soft limit. soft limit can be set by ordinary user. This is the actual limit in effect. Solution for a single session In the shell set the soft limit: ulimit -Sn 2048 This example will raise the actual ...


9

When a child is forked then it inherits parent's file descriptors, if child closes the file descriptor what will happen ? It inherits a copy of the file descriptor. So closing the descriptor in the child will close it for the child, but not the parent, and vice versa. If child starts writing what shall happen to the file at the parent's end ? Who ...


8

the /dev/std{in,out,err} files are normally just symlinks to /proc/self/fd/{0,1,2} (respectively). As such theres nothing gained over using methods that are POSIX defined. If you want to be POSIX compliant, the best way to do this is to use output redirection. Shell output redirection is defined in the POSIX standard. Additionally the STDIN, STDOUT, STDERR ...


8

Yes - either directly or as symlinks - that is what /dev/ is for. For various purposes: sometimes for compatibility between naming schemes, sometimes it is necessary for the working environment - as in the example of /dev/stdin. This does not point statically to /dev/pts/2 or any other - just switch to another terminal and you'll see. /dev/stdin is the ...


8

There is not really a more specific term. In traditional Unix, file descriptors reference entries in the file table, entries of which are referred to as files, or sometimes open files. This is in a specific context, so while obviously the term file is quite generic, in the context of the file table it specifically refers to open files. Files on disk are ...


8

3>&4- is a ksh93 extension also supported by bash and that is short for 3>&4 4>&-, that is 3 now points to where 4 used to, and 4 is now closed, so what was pointed to by 4 has now moved to 3. Typical usage would be in cases where you've duplicated stdin or stdout to save a copy of it and want to restore it, like in: Suppose you want ...


8

When you delete a file you really remove a link to the file (to the inode). If someone already has that file open, they get to keep the file descriptor they have. The file remains on disk, taking up space, and can be written to and read from if you have access to it. The unlink function is defined with this behaviour by POSIX: When the file's link count ...


7

/dev/fd/3 seems to be pointing to the current process. Ie., ls itself (notice that pid won't exist afterward). All of those actually pertain to the current process, as file descriptors are not global; there is not just a single 0, 1, and 2 for the whole system -- there's a separate 0, 1, and 2 for each process. As Frederik Dweerdt notes, /dev/fd is ...


7

You can do it like this: ./script 2>&1 1>/dev/null This redirects fd 2 to what fd 1 points to (i.e. stdout), then redirects fd 1 to /dev/null. The second redirect doesn't affect the first one, output to fd 2 will be sent to stdout. Order does matter though. With this: ./script 1>/dev/null 2>&1 will send all output to /dev/null.


7

From bash manpage: Duplicating File Descriptors The redirection operator [n]<&word is used to duplicate input file descriptors. If word expands to one or more digits, the file descriptor denoted by n is made to be a copy of that file descriptor. If the digits in word do not specify a file ...


7

The /proc/PID/fd/NUM symlinks are quasi-universal on Linux, but they don't exist anywhere else (except on Cygwin which emulates them). /proc/PID/fd/NUM also exist on AIX and Solaris, but they aren't symlinks. Portably, to get information about open files, install lsof. Unices with /proc/PID/fd Linux Under Linux, /proc/PID/fd/NUM is a slightly magic ...


6

In the context of named pipes (fifos) the use of an additional file descriptor can enable non-blocking piping behaviour. ( rm -f fifo mkfifo fifo exec 3<fifo # open fifo for reading trap "exit" 1 2 3 15 exec cat fifo | nl ) & bpid=$! ( exec 3>fifo # open fifo for writing trap "exit" 1 2 3 15 while true; do echo "blah" > fifo done ) ...


6

All four of /dev/fd/0, /dev/stdin, /proc/self/fd/0 and /dev/pts/2 are file names, as are /////dev/../dev/fd//0, /bin/sh, /etc/fstab, /fioejfoeijf, etc. All but that last example are likely to be the name of an existing file on your machine. A file name is a string that can designate a file on your filesystem; under Linux, any string that does not contain a ...


6

There is a command line utility called ttyecho that can send a command to another terminal (tty/pts) and have the command executed. sudo ttyecho -n /dev/pts/5 ls See: Utility to Send Commands or Data to Other Terminals (tty/pts) Another interesting tty command is selector, a real-time interactive pattern matcher in console that updates the tty input ...


6

/dev/fd/3 is not a standard descriptor (edit: assignment). It (edit: having more than 0, 1 and 2) is specific to your case (ls). You can run ls through strace to understand what happens: strace -e trace=openat,readlink ls -l /dev/fd/ openat(AT_FDCWD, "/dev/fd/", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 3 readlink("/dev/fd/0", "/dev/pts/0", 65) = 10 ...


6

With socat (version 2 or above): socat 'system:cat input.txt & cat > output.txt,commtype=socketpair' \ 'system:foo,nofork' Or even better: socat 'CREATE:output.txt%OPEN:input.txt' 'system:foo,commtype=socketpair' We're using a socketpair which is bidirectional (pipes are not bidirectional on Linux). Another option is to use a ...


6

Make a strace of tail -f, it explains everything. The interesting part: 13791 fstat(3, {st_mode=S_IFREG|0644, st_size=139, ...}) = 0 13791 fstatfs(3, {...}) = 0 13791 inotify_init() = 4 13791 inotify_add_watch(4, "/path/to/file", IN_MODIFY|IN_ATTRIB|IN_DELETE_SELF|IN_MOVE_SELF) = 1 13791 fstat(3, {st_mode=S_IFREG|0644, st_size=139, ...}) ...



Only top voted, non community-wiki answers of a minimum length are eligible