Hot answers tagged

76

/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 ...


27

Most of the /dev entries are block device inodes or character device inodes. One previous answer has many details about 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 ...


18

The following bash code is set to work with the byte being representred in binary. However you can easily change it to handle ocatal, decimal or hex by simply changing the radix r value of 2 to 8, 10 or 16 respectively and setting b= accordingly. r=2; b=01111110 printf -vo '\\%o' "$(($r#$b))"; </dev/zero tr '\0' "$o" EDIT - It does handle the full ...


18

You cannot easily do that. You might consider writing your own kernel module providing such a device. I don't recommend that. You could write a tiny C program writing an infinite stream of same bytes on some pipe (or on stdout) or FIFO. You could use tr(1) to read from /dev/zero and translate every 0 byte to somethng else. You could use perhaps yes(1), ...


17

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


16

In addition of device nodes explained in other answers (created with mknod(2) or supplied by some devfs), notably the one from Sepahrad Salour, Linux has other "magical" files provided by special virtual file systems, in particular in /proc/ (see proc(5), read about procfs) and in /sys/ (read about sysfs). These pseudo files (which appear -e.g. to stat(2)- ...


13

Well, if you literally want to achieve this, you can use a LD_PRELOAD hook. The basic idea is to rewrite a function from the C library and use it instead of the normal one. Here is a simple example where we override the read() function to XOR the output buffer with 0x42. #define _GNU_SOURCE #include <string.h> #include <errno.h> #include ...


11

They're called device nodes, and are created either manually with mknod or automatically by udev. They are typically file-like interfaces to character or block devices with drivers in the kernel - e.g. disks are block devices, ttys and serial ports etc are character devices. There are other "special" file types too, including named pipes and fifos and ...


10

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


10

In terms of speed, the fastest I found was: $ PERLIO=:unix perl -e '$s="\1" x 65536; for(;;){print $s}' | pv -a > /dev/null [4.02GiB/s] For comparison: $ tr '\0' '\1' < /dev/zero | pv -a > /dev/null [ 765MiB/s] $ busybox tr '\0' '\1' < /dev/zero | pv -a > /dev/null [ 399MiB/s] $ yes $'\1' | tr -d '\n' | pv -a > /dev/null [26.7MiB/s] ...


7

It's kind of pointless to try and bitmask/xor zero bytes, isn't it? Taking a byte and xoring it with zero is a no-op. Just create a loop that gives you the bytes you want and put it behind a pipe or named pipe. It'll behave pretty much the same as a character device (won't waste CPU cycles when idle): mkfifo pipe while : ; do echo -n "a"; done > pipe ...


7

You cannot mmap() /dev/random or /dev/urandom. Nor can you seek() them for that matter. And as a general rule, you cannot mmap() unseekable things. Pipes are another example of things you cannot mmap() because they are not seekable. /dev/random and /dev/urandom are fundamentally stream-based, sequential access, devices. They produce bytes on demand when you ...


7

/dev/tty is the controlling tty of the current process, for any process that actually opens this special file. It isn’t necessarily a virtual console device (/dev/ttyn), and can be a pty, a serial port, etc. If the controlling tty isn’t a virtual console, then the process has not to interact with console devices even if its pseudotty is actually implemented ...


7

No, /dev/raw is different from the conventional /dev/sda block device. According to The Linux 2.4 SCSI subsystem HOWTO: Chapter 11. Raw devices: A raw device can be bound to an existing block device (e.g. a disk) and be used to perform "raw" IO with that existing block device. Such "raw" IO bypasses the caching that is normally associated with block ...


7

As other users have already explained in great detail, special files require code to back them up. However, nobody seems to have mentioned that Linux provides several ways to write that code in userspace: A. FUSE (Filesystem in USErspace) allows you to write something like /proc without risk of crashing the kernel and do it in a language/runtime of your ...


7

If you could call mknod arbitrarily, then you could create device files owned and accessible by you for any device. The device files give you unlimited access to the corresponding devices; therefore, any user could access devices arbitrarily. For instance, suppose /dev/sda1 holds a file system to which you have no access. (Say, it is mounted to /secret). ...


6

For tcp, just checking $?. If connection failed, $? won't be 0: $ >/dev/tcp/google.com/81 bash: connect: Network is unreachable bash: /dev/tcp/google.com/81: Network is unreachable $ echo $? 1 It will take time for bash to realize that the connection failed. You can use timeout to trigger bash: $ timeout 1 bash -c '>/dev/tcp/google.com/80' ...


6

Device files on Unix systems in general are just one way for user programs to access device drivers; there isn't a one-to-one mapping from devices files to physical hardware, and not all hardware has a device file (or even a device driver). The kernel itself doesn't use device files to interact with hardware. As pointed out by lcd047, network cards don't ...


6

The book Linux Device Drivers (highly recommended) explains this in detail, and even has you create a kernel module that does this as an example, but in a nutshell, each device driver has specific functions that get called when a file is opened, closed, read, written, etc. The "special" files just do something special inside those functions, instead of ...


5

Read zeros, translate each zero to your pattern! We read zero bytes out of /dev/zero, and use tr to apply a bit mask to each of the bytes by translating each zero byte: $ </dev/zero tr '\000' '\176' | head -c 10 ~~~~~~~~~~$ Octal 176 is the ascii code of ~, so we get 10 ~. (The $ at the end of the output indicates in my shell that there was no line ...


4

Historical reasons. Originally, before devfs existed, these device files were created by hand or by a script called MAKEDEV. This is also why many drivers have a fixed device number assignment; because the device numbers had to be known so that the device files would work properly. There aren't really any common use cases for the mknod command on modern ...


4

A loop device is a particular type of block device, managed by the loop device driver. A loop device is a block device whose content is stored in a file, similar to the way a SCSI disk device is a block device whose content is stored on a SCSI disk, a USB storage device is a block device whose content is stored on a USB storage peripheral, etc. Linux has a ...


4

After the regular, FIFO and socket file types, mknod can also create device files. These are used to access devices. Granting access to devices is considered a privileged operation. Generally, we don't want to create arbitrary device nodes and make them accessible to regular users. That would be Bad. [Aside: Typically device access is granted by ...


4

With mknod, you create device-special files that allow raw access to the hardware. That is, the kernel looks at the device-special file's permissions to decide whether a given user is allowed raw acess to hardware, not to anything in configuration or some such. E.g., on Debian, devices related to optical drives are created with 0660 permission bits, user ...


3

Depends what you want to do with the data and how flexible you want to use it. Worst case if you need speed, you could do the same as the /dev/zero, and just compile the /dev/one, /dev/two, .. /dev/fourtytwo .. and so on devices. In most cases it should be better to create the data directly where it is needed, so inside a program/script as a constant. With ...


3

In general, you can't. Unlike TCP, UDP is connectionless. You can't detect that a port is open simply by making a do-nothing connection to it like you can with TCP. Rather, you need to send data to the port and see what happens, and the details of UDP as implemented in the real world make interpreting the results difficult. Even sophisticated ...


3

DEL doesn't indicate that that process deleted /dev/zero, but that that process is using /dev/zero and the instance of /dev/zero that was being used has since been deleted. For example, if I have a command (say some-command) that uses /some/file and I do: $ some-command & $ rm /some/file $ touch /some/file Then lsof for /some/file would look like: ...


3

It is not --special that "should" sync the devices, it is the --devices indirect switch. For that the man page says: --devices This option causes rsync to transfer character and block device files to the remote system to recreate these devices. This option has no effect if the receiving rsync is not run as the ...


3

Libncurses was recently updated from /usr/lib32/libncursesw.so.5 to /usr/lib32/libncursesw.so.6. There would have been a matching bash update, but you don't have it. In fact, I just found this in my own pacman.log: [2015-09-19 23:45] [ALPM] upgraded ncurses (5.9-7 -> 6.0-3) [2015-09-19 23:45] [ALPM] upgraded readline (6.3.008-1 -> 6.3.008-3) ...


3

ttyUSBx devices are not simple USB ports, but rather USB UART devices which emulate a serial port via USB. They are often based on Prolific (PL2303) or FTDI chip. You'll have to obtain such a device and connect it to your computer for a /dev/ttyUSBx entry to appear, in the same way as plugging in a USB flash drive creates a /dev/sdx device.



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