5 offered a new guess as to the reason for `mknod u`, and added man page links showing that no other implementation understands `mknod u`
source | link

That nails it, as far as I'm concerned: aA u in the command gives the same dev node as c. Case closed.

As to why both characters are allowed, I assumemy best guess is that it's just an alias for compatibility with some other OS, where there is a distinction betweenthose who think of cb andas meaning "buffered" rather than "block," so that you need u. That's as far as I'm willing to speculateits opposite, howevermeaning "unbuffered," rather than c for "character."

I originally thought that this feature of GNU mknod might have been for compatibility with some pre-Linux flavor of Unix, since diggingmknod in GNU Fileutils predates Linux itself,¹ and this feature of GNU mknod goes clear back to the very first version-controlled checkin of mknod.c in the old GNU Fileutils shows that this aspect of the code has remained unchanged since at least 1992, which probably makes the feature older than Linux itself.¹ Since Linux 1.0 also doesn't care about this,but I must assume that this feature dates to some pre-Linux feature of Fileutils cateringhave yet to some now-obsolete flavor of Unix.

I can't find evidence ofdocumentation for any modern Unix that acceptswill accept u here. That isn't documented in the currentas an argument to mknod(1) man pages for FreeBSD, OS X, or Solarisso that hypothesis doesn't hold water.²

  1. A mknod utility was added to GNU Fileutils in July 1991. The first version of the Linux kernel wasn't posted to Usenet until September 1991. That tells us that the first version of GNU mknod must have supported non-Linux OSes from the start. Nevertheless, I say "probably" above because I have not found a version of the GNU Fileutils mknod.c older than October 1992. Apparently the Fileutils maintainers weren't using version control before that. I haven't found a place to download an older soruce tarball to check this guess.

    A mknod utility was added to GNU Fileutils in July 1991. The first version of the Linux kernel wasn't posted to Usenet until September 1991. That tells us that the first version of GNU mknod must have supported non-Linux OSes from the start.

  2. I've checked the online man pages for Solaris, HP-UX, AIX, FreeBSD, SCO OpenServer, SCO UnixWare, Minix 2, Ultrix, 2.11BSD, and OS X.

    You will find mknod u documented for other OSes — such as Minix 3 — but only because they're also using the GNU Coreutils implementation of mknod(1). Another oddity is modern Solaris, which ships both AT&T mknod and GNU mknod, documented separately in manual sections 1m (linked above) and in section 1g, respectively.

That nails it, as far as I'm concerned: a u in the command gives the same dev node as c.

As to why both characters are allowed, I assume it's for compatibility with some other OS, where there is a distinction between c and u. That's as far as I'm willing to speculate, however, since digging clear back to the very first version-controlled checkin of mknod.c in the old GNU Fileutils shows that this aspect of the code has remained unchanged since at least 1992, which probably makes the feature older than Linux itself.¹ Since Linux 1.0 also doesn't care about this, I must assume that this feature dates to some pre-Linux feature of Fileutils catering to some now-obsolete flavor of Unix.

I can't find evidence of any modern Unix that accepts u here. That isn't documented in the current mknod(1) man pages for FreeBSD, OS X, or Solaris.

  1. A mknod utility was added to GNU Fileutils in July 1991. The first version of the Linux kernel wasn't posted to Usenet until September 1991. That tells us that the first version of GNU mknod must have supported non-Linux OSes from the start. Nevertheless, I say "probably" above because I have not found a version of the GNU Fileutils mknod.c older than October 1992. Apparently the Fileutils maintainers weren't using version control before that. I haven't found a place to download an older soruce tarball to check this guess.

A u in the command gives the same dev node as c. Case closed.

As to why both characters are allowed, my best guess is that it's just an alias for those who think of b as meaning "buffered" rather than "block," so that you need u as its opposite, meaning "unbuffered," rather than c for "character."

I originally thought that this feature of GNU mknod might have been for compatibility with some pre-Linux flavor of Unix, since mknod in GNU Fileutils predates Linux itself,¹ and this feature of GNU mknod goes clear back to the very first version-controlled checkin of mknod.c, but I have yet to find documentation for any Unix that will accept u as an argument to mknod(1), so that hypothesis doesn't hold water.²

  1. A mknod utility was added to GNU Fileutils in July 1991. The first version of the Linux kernel wasn't posted to Usenet until September 1991. That tells us that the first version of GNU mknod must have supported non-Linux OSes from the start.

  2. I've checked the online man pages for Solaris, HP-UX, AIX, FreeBSD, SCO OpenServer, SCO UnixWare, Minix 2, Ultrix, 2.11BSD, and OS X.

    You will find mknod u documented for other OSes — such as Minix 3 — but only because they're also using the GNU Coreutils implementation of mknod(1). Another oddity is modern Solaris, which ships both AT&T mknod and GNU mknod, documented separately in manual sections 1m (linked above) and in section 1g, respectively.

4 clarity pass
source | link

They're identical, at least on Linux, which I assume you're using since the quoted message is from the GNU coreutils docs.

I came to this conclusion by first looking at the source code for mknod(1) in the GNU coreutils, where on line 217 in the current version we find that the 'c' and 'u' cases are treated identically, getting the same device type. The S_IFCHR value is defined in the Linux kernel headers, but the value is not important. All that matters is that the same value gets stored in the filesystem's dev node.

I clinched the issue with a simple test:

$ sudo mknod /dev/null2 u 1 3
$ ls -l /dev/null*
crw-rw-rw- 1 root root 1, 3 Jan 12  2015 /dev/null
crw-r--r-- 1 root root 1, 3 Oct 19 22:56 /dev/null2

That nails it, as far as I'm concerned: a u in the command gives the same dev node as c.

As to why both characters are allowed, I assume it's for compatibility with some other OS, where there is a distinction between c and u. That's as far as I'm willing to speculate, however, since digging clear back to the very first version-controlled checkin of mknod.c in the old GNU Fileutils shows that this aspect of the code has remained unchanged since at least 1992, which probably makes the feature roughly as old asolder than Linux itself.¹ Since Linux 1.0 also doesn't care about this, I must assume that this feature dates to some pre-Linux feature of Fileutils catering to some now-obsolete flavor of Unix.

I can't find evidence of any modern Unix that accepts u here. That isn't documented in the current mknod(1) man pages for FreeBSD, OS X, or Solaris.


Asides:

  1. A mknod utility was added to GNU Fileutils in July 1991. The first version of the Linux kernel wasn't posted to Usenet until September 1991. That tells us that the first version of GNU mknod must have supported non-Linux OSes from the start. Nevertheless, I say "probably" above because I have not found a version of the GNU Fileutils mknod.c older than October 1992. Apparently the Fileutils maintainers weren't using version control before that. I haven't found a place to download an older soruce tarball to check this guess.

They're identical, at least on Linux, which I assume you're using since the quoted message is from the GNU coreutils docs.

I came to this conclusion by first looking at the source code for mknod(1), where on line 217 in the current version we find that the 'c' and 'u' cases are treated identically, getting the same device type. The S_IFCHR value is defined in the Linux kernel headers, but the value is not important. All that matters is that the same value gets stored in the filesystem's dev node.

I clinched the issue with a simple test:

$ sudo mknod /dev/null2 u 1 3
$ ls -l /dev/null*
crw-rw-rw- 1 root root 1, 3 Jan 12  2015 /dev/null
crw-r--r-- 1 root root 1, 3 Oct 19 22:56 /dev/null2

That nails it, as far as I'm concerned: a u in the command gives the same dev node as c.

As to why both characters are allowed, I assume it's for compatibility with some other OS, where there is a distinction between c and u. That's as far as I'm willing to speculate, however, since digging clear back to the very first version-controlled checkin of mknod.c in the old GNU Fileutils shows that this aspect of the code has remained unchanged since 1992, which makes the feature roughly as old as Linux itself. Since Linux 1.0 also doesn't care about this, I must assume that this feature dates to some pre-Linux feature of Fileutils catering to some now-obsolete flavor of Unix.

I can't find evidence of any modern Unix that accepts u here. That isn't documented in the current mknod(1) man pages for FreeBSD, OS X, or Solaris.

They're identical, at least on Linux.

I came to this conclusion by first looking at the source code for mknod(1) in the GNU coreutils, where on line 217 in the current version we find that the 'c' and 'u' cases are treated identically, getting the same device type. The S_IFCHR value is defined in the Linux kernel headers, but the value is not important. All that matters is that the same value gets stored in the filesystem's dev node.

I clinched the issue with a simple test:

$ sudo mknod /dev/null2 u 1 3
$ ls -l /dev/null*
crw-rw-rw- 1 root root 1, 3 Jan 12  2015 /dev/null
crw-r--r-- 1 root root 1, 3 Oct 19 22:56 /dev/null2

That nails it, as far as I'm concerned: a u in the command gives the same dev node as c.

As to why both characters are allowed, I assume it's for compatibility with some other OS, where there is a distinction between c and u. That's as far as I'm willing to speculate, however, since digging clear back to the very first version-controlled checkin of mknod.c in the old GNU Fileutils shows that this aspect of the code has remained unchanged since at least 1992, which probably makes the feature older than Linux itself.¹ Since Linux 1.0 also doesn't care about this, I must assume that this feature dates to some pre-Linux feature of Fileutils catering to some now-obsolete flavor of Unix.

I can't find evidence of any modern Unix that accepts u here. That isn't documented in the current mknod(1) man pages for FreeBSD, OS X, or Solaris.


Asides:

  1. A mknod utility was added to GNU Fileutils in July 1991. The first version of the Linux kernel wasn't posted to Usenet until September 1991. That tells us that the first version of GNU mknod must have supported non-Linux OSes from the start. Nevertheless, I say "probably" above because I have not found a version of the GNU Fileutils mknod.c older than October 1992. Apparently the Fileutils maintainers weren't using version control before that. I haven't found a place to download an older soruce tarball to check this guess.
3 updated speculation after digging back to Fileutils and Linux ca 1992
source | link

They're identical, at least on Linux, which I assume you're using since the quoted message is from the GNU coreutils docs.

I came to this conclusion by first looking at the source code for mknod(1), where on line 217 in the current version we find that the 'c' and 'u' cases are treated identically, getting the same device type. The S_IFCHR value is defined in the Linux kernel headers, but the value is not important. All that matters is that the same value gets stored in the filesystem's dev node.

I clinched the issue with a simple test:

$ sudo mknod /dev/null2 u 1 3
$ ls -l /dev/null*
crw-rw-rw- 1 root root 1, 3 Jan 12  2015 /dev/null
crw-r--r-- 1 root root 1, 3 Oct 19 22:56 /dev/null2

That nails it, as far as I'm concerned: a u in the command gives the same dev node as c.

As to why both characters are allowed, I assume it's for compatibility with some other OS, where there is a distinction between c and u. There may be scripts that callThat's as far as I'm willing to speculate, however, since digging clear back to /bin/mknod with athe very first version-controlled checkin of mknod.c in the old u argumentGNU Fileutils shows that this aspect of the code has remained unchanged since 1992, sowhich makes the GNU coreutils maintainers decided to supportfeature roughly as old as Linux itself. Since Linux 1.0 also doesn't care about this, I must assume that case rather than force the modificationthis feature dates to some pre-Linux feature of the scriptFileutils catering to some now-obsolete flavor of Unix.

That guess wants proof, though, since I can't find another OS's man page for mknod(1)evidence of any modern Unix that documents aaccepts u optionhere. I've looked atThat isn't documented in the current mknod(1) man pages for FreeBSD, OS X, andor Solaris versions so far. The only "hit" I had is on OpenIndiana Hipster, but that's just because they're also using GNU Coreutils.

So, if you want a second guess to the "why" of it, perhaps an old version of Linux made a distinction between character device types here.

They're identical, at least on Linux, which I assume you're using since the quoted message is from the GNU coreutils docs.

I came to this conclusion by first looking at the source code for mknod(1), where on line 217 in the current version we find that the 'c' and 'u' cases are treated identically, getting the same device type. The S_IFCHR value is defined in the Linux kernel headers, but the value is not important. All that matters is that the same value gets stored in the filesystem's dev node.

I clinched the issue with a simple test:

$ sudo mknod /dev/null2 u 1 3
$ ls -l /dev/null*
crw-rw-rw- 1 root root 1, 3 Jan 12  2015 /dev/null
crw-r--r-- 1 root root 1, 3 Oct 19 22:56 /dev/null2

That nails it, as far as I'm concerned: a u in the command gives the same dev node as c.

As to why both characters are allowed, I assume it's for compatibility with some other OS, where there is a distinction between c and u. There may be scripts that call /bin/mknod with a u argument, so the GNU coreutils maintainers decided to support that case rather than force the modification of the script.

That guess wants proof, though, since I can't find another OS's man page for mknod(1) that documents a u option. I've looked at the current FreeBSD, OS X, and Solaris versions so far. The only "hit" I had is on OpenIndiana Hipster, but that's just because they're also using GNU Coreutils.

So, if you want a second guess to the "why" of it, perhaps an old version of Linux made a distinction between character device types here.

They're identical, at least on Linux, which I assume you're using since the quoted message is from the GNU coreutils docs.

I came to this conclusion by first looking at the source code for mknod(1), where on line 217 in the current version we find that the 'c' and 'u' cases are treated identically, getting the same device type. The S_IFCHR value is defined in the Linux kernel headers, but the value is not important. All that matters is that the same value gets stored in the filesystem's dev node.

I clinched the issue with a simple test:

$ sudo mknod /dev/null2 u 1 3
$ ls -l /dev/null*
crw-rw-rw- 1 root root 1, 3 Jan 12  2015 /dev/null
crw-r--r-- 1 root root 1, 3 Oct 19 22:56 /dev/null2

That nails it, as far as I'm concerned: a u in the command gives the same dev node as c.

As to why both characters are allowed, I assume it's for compatibility with some other OS, where there is a distinction between c and u. That's as far as I'm willing to speculate, however, since digging clear back to the very first version-controlled checkin of mknod.c in the old GNU Fileutils shows that this aspect of the code has remained unchanged since 1992, which makes the feature roughly as old as Linux itself. Since Linux 1.0 also doesn't care about this, I must assume that this feature dates to some pre-Linux feature of Fileutils catering to some now-obsolete flavor of Unix.

I can't find evidence of any modern Unix that accepts u here. That isn't documented in the current mknod(1) man pages for FreeBSD, OS X, or Solaris.

2 added more "why" speculation and resutls
source | link
1
source | link