In addition to the performance benefits of using a character-special device, the primary benefit is modularity. /dev/null may be used in almost any context where a file is expected, not just in shell pipelines. Consider programs that accept files as command-line parameters.
# We don't care about log output.
$ frobify --log-file=/dev/null
# We are not ...
lsblk will list all block devices. It lends itself well to scripting:
$ lsblk -io KNAME,TYPE,SIZE,MODEL
KNAME TYPE SIZE MODEL
sda disk 149.1G TOSHIBA MK1637GS
sda1 part 23.3G
sda2 part 28G
sda3 part 93.6G
sda4 part 4.3G
sr0 rom 1024M CD/DVDW TS-L632M
lsblk is present in util-linux package and is thus far more universal than proposed ...
Nothing is stored in /dev/pts. This filesystem lives purely in memory.
Entries in /dev/pts are pseudo-terminals (pty for short). Unix kernels have a generic notion of terminals. A terminal provides a way for applications to display output and to receive input through a terminal device. A process may have a controlling terminal — for a text mode application, ...
/dev/zero is an example of a "special file" — particularly, a "device node". Normally these get created by the distro installation process, but you can totally create them yourself if you want to.
If you ask ls about /dev/zero:
# ls -l /dev/zero
crw-rw-rw- 1 root root 1, 5 Nov 5 09:34 /dev/zero
The "c" at the start tells you that this is a "...
In Linux, comparing the kernel functions named random_read and random_read_unlimited
indicates that the etymology of the letter u in urandom isunlimited.
This is confirmed by line 114:
The /dev/urandom device does not have this limit [...]
Regarding which came first for Linux, /dev/random or /dev/urandom, @Stéphane Chazelas gave ...
When a program reads or writes data from a file, the requests go to a kernel driver. If the file is a regular file, the data is handled by a filesystem driver and it is typically stored in zones on a disk or other storage media, and the data that is read from a file is what was previously written in that place. There are other file types for which different ...
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 (...
One reason is that block level access is a bit lower level than ls would be able to work with. /dev/cdrom, or dev/sda1 may be your CD ROM drive and partition 1 of your hard drive, respectively, but they aren't implementing ISO 9660 / ext4 - they're just RAW pointers to those devices known as Device Files.
One of the things mount determines is HOW to use ...
Use /dev/urandom for most practical purposes.
The longer answer depends on the flavour of Unix that you're running.
Historically, /dev/random and /dev/urandom were both introduced at the same time.
As @DavidSchwartz pointed out in a comment, using /dev/urandom is preferred in the vast majority of cases. He and others also provided a link to ...
The kernel lists them by name in /sys, both separately in (e.g.) the tree of PCI devices -- although finding them there if you don't know where they are to start with is not simple -- and together via symlinks in /sys/class/net. E.g.:
> ls /sys/class/net
em1 lo wlp6so
> ls /sys/class/net
lo p6s1 wlan0
If you are not sure which is ...
In fairness, it's not a regular file per se; it's a character special device:
$ file /dev/null
/dev/null: character special (3/2)
It functioning as a device rather than as a file or program means that it's a simpler operation to redirect input to or output from it, as it can be attached to any file descriptor, including standard input/output/error.
I suspect the why has a lot to do with the vision/design that shaped Unix (and consequently Linux), and the advantages stemming from it.
No doubt there's a non-negligible performance benefit to not spinning up an extra process, but I think there's more to it: Early Unix had an "everything is a file" metaphor, which has a non-obvious but elegant advantage if ...
They do count as I/O, but not of the type measured by the fields you’re looking at.
In htop, IO_RBYTES and IO_WBYTES show the read_bytes and write_bytes fields from /proc/<pid>/io, and those fields measure bytes which go through the block layer. /dev/zero doesn’t involve the block layer, so reads from it don’t show up there.
To see I/O from /dev/zero,...
Some of these have man pages (in section 4; leave out the final digit(s) and in a few cases such as sda the final letter).
For a more definitive, but usually less easy to read answer, look in the kernel documentation. First determine whether the device is a block device or a character device, and its major and minor number. For example
$ ls -l /dev/sda
mknod was originally used to create the character and block devices that populate /dev/. Nowadays software like udev automatically creates and removes device nodes on the virtual filesystem when the corresponding hardware is detected by the kernel, but originally /dev was just a directory in / that was populated during install.
So yes, in case of a near ...
Yes, both accept and discard all input, but their output is not the same:
/dev/null produces no output.
/dev/zero produces a continuous stream of NULL (zero value) bytes.
You can see the difference by executing cat /dev/null and cat /dev/zero.
Try cat /dev/null > file and you will find an empty file.
Now try cat /dev/zero > file,
while watching ...
On many devices, the main operations are to send bytes from the computer to a peripheral, or to receive bytes from a peripheral on the computer. Such devices are similar to pipes and work well as character devices. For operations that aren't reading and writing (such as flow control on a serial line), the device provides ad-hoc commands called ioctl.
Most of the /dev entries are block device inodes or character device inodes. Wikipedia has many detailsabout that, which I am not going to repeat.
But /dev/tcp which is mentioned in your question is not explained by any of the existing answers. /dev/tcp and /dev/udp are different from most other /dev entries. The block and character devices are implemented ...
Unfortunately serial ports are non-PlugNPlay, so kernel doesn't know which device was plugged in. After reading a HowTo tutorial I've got the working idea.
The /dev/ directory of unix like OSes contains files named as ttySn (with n being a number). Most of them doesn't correspond to existing devices. To find which ones do, issue a command:
$ dmesg | grep ...
The stty utility sets or reports on terminal I/O characteristics for the device that is its standard input. These characteristics are used when establishing a connection over that particular medium. cat doesn't know the baud rate as such, it rather prints on the screen information received from the particular connection.
As an example stty -F /dev/ttyACM0 ...
Under many traditional unices, you can recreate devices with their default permissions with the MAKEDEV script. This script is traditionally in /dev but is in /sbin on Ubuntu. Pass it an argument that indicates what devices you want to create; on Ubuntu that's std (you can write MAKEDEV null as well, that creates null as well as a number of other devices).
Those are simply (special) files. They only serve as "pointers" to the actual device. (i.e. the driver module inside the kernel.)
If some command/service already opened that file, it already has a handle to the device and will continue working.
If some command/service tries to open a new connection, it will try to access that file and fail because of "file ...
Because access to the underlying device is controlled only by file permissions by default, so if your USB stick contains a POSIX filesystem with a world-writable device node corresponding to a real device in the system, you can use that device node to access the corresponding device as a "plain" user. Imagine a device corresponding to one of the audio ...
By definition /dev/null sinks anything written to it, so it doesn't matter if you write in append mode or not, it's all discarded. Since it doesn't store the data, there's nothing to append to, really.
So in the end, it's just shorter to write > /dev/null with one > sign.
As for the edited addition:
The open(2) manpage says lseek is called before ...
The terms raw and cooked only apply to terminal drivers. "Cooked" is called canonical and "raw" is called non-canonical mode.
The terminal driver is, by default a line-based system: characters are buffered internally until a carriage return (Enter or Return) before it is passed to the program - this is called "cooked". This allows certain characters to be ...
The files in /dev are actual devices files which UDEV creates at run time. The directory /sys/class is exported by the kernel at run time, exposing the hierarchy of the hardware through sysfs.
From the libudev and Sysfs Tutorial
On Unix and Unix-like systems, hardware devices are accessed through special files (also called device files or nodes) ...
The /sys filesystem (sysfs) contains files that provide information about devices: whether it's powered on, the vendor name and model, what bus the device is plugged into, etc. It's of interest to applications that manage devices.
The /dev filesystem contains files that allow programs to access the devices themselves: write data to a serial port, read a ...