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 ...
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 ...
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 "...
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 ...
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 ...
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 ...
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 ...
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,...
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 ...
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 ...
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 ...
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).
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 ...
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 ...
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) ...
Because that's a feature of the shell (of ksh, copied by bash), and the shell only.
/dev/tcp/... are not real files, the shell intercepts the attempts to redirect to a /dev/tcp/... file and then does a socket(...);connect(...) (makes a TCP connection) instead of a open("/dev/tcp/..."...) (opening that file) in that case.
Note that it has to be spelled like ...
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 ...
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 ...
devtmpfs is a file system with automated device nodes populated by the kernel. This means you don't have to have udev running nor to create a static /dev layout with additional, unneeded and not present device nodes. Instead the kernel populates the appropriate information based on the known devices.
On the other hand the standard /dev handling requires ...
This is a feature of the shell and not the operating system.
So, for example,on Solaris 10 with ksh88 as the shell:
% cat < /dev/tcp/localhost/22
ksh: /dev/tcp/localhost/22: cannot open
However if we switch to bash:
bash-3.2$ cat < /dev/tcp/localhost/22
So bash interprets the /dev/tcp but ksh88 didn't.
On Solaris 11 ...
So there are basically two different types of thing here:
Normal filesystems, which hold files in directories with data and metadata, in the familiar manner (including soft links, hard links, and so on). These are often, but not always, backed by a block device for persistent storage (a tmpfs lives in RAM only, but is otherwise identical to a normal ...
There are various alternatives to udev out there. Seemingly Gentoo can use something called mdev. Another option would be to attempt to use udev's predecessor devfsd. Finally, you can always create all the device files you need with mknod.
Note that with the latter there is no need to create everything at boot time since the nodes can be created on disk and ...