Everything is a File: Difference between revisions
pc>Yuron No edit summary |
W81054ch [PHRhYmxlIGNsYXNzPSJ0d3BvcHVwIj48dHI+PHRkIGNsYXNzPSJ0d3BvcHVwLWVudHJ5dGl0bGUiPkdyb3Vwczo8L3RkPjx0ZD51c2VyPGJyIC8+YnVyZWF1Y3JhdDxiciAvPmludGVyZmFjZS1hZG1pbjxiciAvPnN5c29wPGJyIC8+PC90ZD48L3RyPjwvdGFibGU+] (talk | contribs) m (1 revision imported) |
||
(2 intermediate revisions by 2 users not shown) | |||
Line 5: | Line 5: | ||
However it is often useful to direct data to/from/between processes and devices in a standardised way and think of these as “files”. Characters can be picked up from a keyboard or a genuine disk file or some other new device and treated identically. | However it is often useful to direct data to/from/between processes and devices in a standardised way and think of these as “files”. Characters can be picked up from a keyboard or a genuine disk file or some other new device and treated identically. | ||
“Everything is a file descriptor.” [e.g. [https://en.wikipedia.org/wiki/Everything_is_a_file Wikipedia, quoting Linus Torvalds]] is a | “Everything is a file descriptor.” [e.g. [https://en.wikipedia.org/wiki/Everything_is_a_file Wikipedia, quoting Linus Torvalds]] is a bit closer although the term “[[File_Descriptor|file descriptor]]” is more usually used to refer to a <em>particular opening of a file</em> rather than being unique to the file. | ||
bit closer although the term “[[File_Descriptor|file | |||
descriptor]]” is more usually used to refer to a | |||
<em>particular opening of a file</em> rather than being unique to the file. | |||
Perhaps “Lots of things in Unix use [[Inodes|i-nodes]] and appear | Perhaps “Lots of things in Unix use [[Inodes|i-nodes]] and appear in the file system.” is even closer, if not as catchy. | ||
in the file system.” is even closer, if not as catchy. | |||
In practice there is a lot of commonality of functionality in use. An | In practice there is a lot of commonality of functionality in use. An I/O device may be able to supply or consume a stream of bytes and may require particular access permissions – just like a file. | ||
I/O device may be able to supply or consume a stream of bytes and may | |||
require particular access permissions – just like a file. | |||
Here are the standard i-node types: | Here are the standard i-node types: | ||
Line 28: | Line 22: | ||
== Examples == | == Examples == | ||
In most parts of a Unix file system you are likely to find only | In most parts of a Unix file system you are likely to find only ‘regular’ files and <strong>d</strong>irectories – maybe with | ||
‘regular’ files and <strong>d</strong>irectories – maybe with | |||
occasional <strong>l</strong>inks scattered here and there. There is [[Exercises:Pipes|an exercise]] to help you create your own <strong>p</strong>ipe. | occasional <strong>l</strong>inks scattered here and there. There is [[Exercises:Pipes|an exercise]] to help you create your own <strong>p</strong>ipe. | ||
To see a selection of devices-looking-like-files, try the <code>/dev</code> | To see a selection of devices-looking-like-files, try the <code>/dev</code> directory. Here are some examples (which will have been set up by the last boot) taken from the ‘kilburn’ server. | ||
directory. Here are some examples (which will have been set up by the | |||
last boot) taken from the ‘kilburn’ server. | |||
==== Link ==== | ==== Link ==== | ||
Line 42: | Line 33: | ||
==== Character device ==== | ==== Character device ==== | ||
Here are some sample character devices, masquerading as | Here are some sample character devices, masquerading as “[https://www.pexels.com/photo/equipment-tele-type-teletype-train-398324/ Teletypes]” – i.e. computer terminals. | ||
“[https://www.pexels.com/photo/equipment-tele-type-teletype-train-398324/ Teletypes]” | |||
– i.e. computer terminals. | |||
<syntaxhighlight lang="bash"> | <syntaxhighlight lang="bash"> | ||
0 crw--w---- 1 root tty 4, 0 Nov 20 03:18 tty0 | 0 crw--w---- 1 root tty 4, 0 Nov 20 03:18 tty0 | ||
Line 52: | Line 41: | ||
0 crw-rw-rw- 1 root root 1, 9 Nov 20 03:18 urandom | 0 crw-rw-rw- 1 root root 1, 9 Nov 20 03:18 urandom | ||
</syntaxhighlight> | </syntaxhighlight> | ||
In this case <code>tty0</code> will be a <em>virtual</em> device corresponding to a | In this case <code>tty0</code> will be a <em>virtual</em> device corresponding to a notional keyboard/screen window pair; there will be many ‘Teletypes’ created on a server with multiple users. | ||
notional keyboard/screen window pair; there will be many | |||
‘Teletypes’ created on a server with multiple users. | |||
<code>ttyS0</code> has a similar behaviour but is actually a hardware <em>serial | <code>ttyS0</code> has a similar behaviour but is actually a hardware <em>serial port</em> on the machine. This particular interface has been given read/write permission by any user, which means it would be accessible directly by a user application. | ||
port</em> on the machine. This particular interface has been given | (We use this feature in various labs. where the desktop workstations connect to other equipment.) | ||
read/write permission by any user, which means it would be accessible | |||
directly by a user application. | |||
(We use this feature in various labs. where the desktop workstations | |||
connect to other equipment.) | |||
<code>/dev/null</code> is not a device at all: it is a “black hole” | <code>/dev/null</code> is not a device at all: it is a “black hole” which consumes anything entering without trace. This is quite useful if something is generating output which you don’t want; it gives it somewhere to go from which it will not return. Anyone can write to (or read from!) it. | ||
which consumes anything entering without trace. This is quite useful | |||
if something is generating output which you don’t want; it gives it | |||
somewhere to go from which it will not return. Anyone can write to | |||
(or read from!) it. | |||
<code>random</code> and <code>urandom</code> are sources of notionally random data. The | <code>random</code> and <code>urandom</code> are sources of notionally random data. The latter is a ‘straightforward’ pseudo-random number generator whereas the former can try to pick up genuinely random (unpredictable) noise from some hardware source in the machine (which could not be duplicated in pure software). | ||
latter is a ‘straightforward’ pseudo-random number | |||
generator whereas the former can try to pick up genuinely random | |||
(unpredictable) noise from some hardware source in the machine (which | |||
could not be duplicated in pure software). | |||
==== Block device ==== | ==== Block device ==== | ||
Disks are <em>block</em> devices in that it is only useful to move data in | Disks are <em>block</em> devices in that it is only useful to move data in sizeable blocks. Linux uses “sd” for “SCSI | ||
sizeable blocks. Linux uses “sd” for “SCSI | Device” (even though modern disks are unlikely to use a [https://en.wikipedia.org/wiki/SCSI SCSI] interface) and a letter to | ||
Device” (even though modern disks are unlikely to use a | indicate individual identities. Thus <code>sda</code> is “Disk A”; this is somewhat like Windows “C:”, etc. The subsequent | ||
[https://en.wikipedia.org/wiki/SCSI SCSI] interface) and a letter to | <em>numeric suffix</em> indicates a further [[Disk_Partition | logical partition]] on that device. | ||
indicate individual identities. Thus <code>sda</code> is “Disk A”; | |||
this is somewhat like Windows “C:”, etc. The subsequent | |||
<em>numeric suffix</em> indicates a further [[Disk_Partition | logical | |||
partition]] on that device. | |||
<syntaxhighlight lang="bash"> | <syntaxhighlight lang="bash"> | ||
0 brw-rw---- 1 root disk 8, 0 Nov 20 03:18 sda | 0 brw-rw---- 1 root disk 8, 0 Nov 20 03:18 sda | ||
Line 91: | Line 62: | ||
== Windows == | == Windows == | ||
Windows (and other operating systems) have adopted a similar | Windows (and other operating systems) have adopted a similar convention by supporting [https://en.wikipedia.org/wiki/Device_file <strong>device files</strong>] using keywords rather than implanting the ‘virtual files’ in a unified system. | ||
convention by supporting [https://en.wikipedia.org/wiki/Device_file <strong>device files</strong>] using keywords | |||
rather than implanting the ‘virtual files’ in a unified | |||
system. | |||
---- | ---- | ||
{{PageGraph}} | {{PageGraph}} | ||
{{Category|Filing System}} | {{Category|Filing System}} | ||
{{Category|User}} | {{Category|User}} |
Latest revision as of 10:02, 5 August 2019
Depends on | User • Files • Concepts |
---|
This is sometimes said of Unix resources. Whilst this is a simple (and sometimes useful) paradigm, it is not entirely true. However it is often useful to direct data to/from/between processes and devices in a standardised way and think of these as “files”. Characters can be picked up from a keyboard or a genuine disk file or some other new device and treated identically.
“Everything is a file descriptor.” [e.g. Wikipedia, quoting Linus Torvalds] is a bit closer although the term “file descriptor” is more usually used to refer to a particular opening of a file rather than being unique to the file.
Perhaps “Lots of things in Unix use i-nodes and appear in the file system.” is even closer, if not as catchy.
In practice there is a lot of commonality of functionality in use. An I/O device may be able to supply or consume a stream of bytes and may require particular access permissions – just like a file.
Here are the standard i-node types:
- - – a regular file
- d – a directory
- l – a symbolic link
- p – a named pipe
- s – a socket
- c – a character device
- b – a block device
Examples
In most parts of a Unix file system you are likely to find only ‘regular’ files and directories – maybe with occasional links scattered here and there. There is an exercise to help you create your own pipe.
To see a selection of devices-looking-like-files, try the /dev
directory. Here are some examples (which will have been set up by the last boot) taken from the ‘kilburn’ server.
Link
0 lrwxrwxrwx 1 root root 13 Nov 20 03:18 fd -> /proc/self/fd
Character device
Here are some sample character devices, masquerading as “Teletypes” – i.e. computer terminals.
0 crw--w---- 1 root tty 4, 0 Nov 20 03:18 tty0
0 crw-rw-rw- 1 root dialout 4, 64 Nov 20 03:18 ttyS0
0 crw-rw-rw- 1 root root 1, 3 Nov 20 03:18 null
0 crw-rw-rw- 1 root root 1, 8 Nov 20 03:18 random
0 crw-rw-rw- 1 root root 1, 9 Nov 20 03:18 urandom
In this case tty0
will be a virtual device corresponding to a notional keyboard/screen window pair; there will be many ‘Teletypes’ created on a server with multiple users.
ttyS0
has a similar behaviour but is actually a hardware serial port on the machine. This particular interface has been given read/write permission by any user, which means it would be accessible directly by a user application.
(We use this feature in various labs. where the desktop workstations connect to other equipment.)
/dev/null
is not a device at all: it is a “black hole” which consumes anything entering without trace. This is quite useful if something is generating output which you don’t want; it gives it somewhere to go from which it will not return. Anyone can write to (or read from!) it.
random
and urandom
are sources of notionally random data. The latter is a ‘straightforward’ pseudo-random number generator whereas the former can try to pick up genuinely random (unpredictable) noise from some hardware source in the machine (which could not be duplicated in pure software).
Block device
Disks are block devices in that it is only useful to move data in sizeable blocks. Linux uses “sd” for “SCSI
Device” (even though modern disks are unlikely to use a SCSI interface) and a letter to
indicate individual identities. Thus sda
is “Disk A”; this is somewhat like Windows “C:”, etc. The subsequent
numeric suffix indicates a further logical partition on that device.
0 brw-rw---- 1 root disk 8, 0 Nov 20 03:18 sda
0 brw-rw---- 1 root disk 8, 1 Nov 20 03:18 sda1
Windows
Windows (and other operating systems) have adopted a similar convention by supporting device files using keywords rather than implanting the ‘virtual files’ in a unified system.