1

yes produces a stream of "y" chars, or other requested.

If Unixen have a pseudodevice for random numbers, why not useful streams like this too?

Glorfindel
  • 805
  • 2
  • 10
  • 19
interstar
  • 1,027
  • 3
  • 14
  • 27
  • 1
    You've asked the question the wrong way around, which is no doubt partly why people are objecting to it. A perhaps slightly better way around is to ask why, if Unices and Linux have a general purpose mechanism where any "useful stream" can be obtained from whatever program one cares to write to generate it, _the pipe_, is `/dev/random` a device file and not just a program that runs the very same CSPRNG in application space and writes to standard output. Not _Why isn't everything like this all in the kernel?_ which is obvious, but _Why is this in the kernel at all?_ – JdeBP Apr 21 '18 at 17:07
  • I think even by itself this question is quite valid and I feel it deserves a good answer. As for _why is this in the kernel_ , it kind of has an answer [here](https://unix.stackexchange.com/questions/438130/why-is-dev-null-a-file-why-isnt-its-function-implemented-as-a-simple-program). This question is about the reverse statement i.e. _why isn't everything in the kernel then_ – Ankur S Apr 21 '18 at 20:59
  • I agree that the question is valid and is formulated properly. The answers to [Ankur S’s question](https://unix.stackexchange.com/q/438130/80216 "Why is ‘/dev/null’ a [special] file? Why isn’t its function implemented as a simple program?") illuminate the usefulness of having such a capability in the kernel. The only note I’d make is that `/dev/random` is not the best comparison; `/dev/zero` is the same as `yes` except it provides nulls instead of `y` bytes. – G-Man Says 'Reinstate Monica' Apr 22 '18 at 03:36

1 Answers1

3

yes produces a stream of "y" chars, or other requested.

Precisely because of that. See yes(1) (which can repeat strings, not necessarily a single character - followed by newline).

It would be unpractical to have many devices, like /dev/repeatY to repeat Y, /dev/repeatO to repeat O etc.

Indeed, if you just want to get repeated zero bytes, consider /dev/zero (see zero(4))

BTW, on Linux, you could easily write your own kernel module implementing /dev/repeatY. But it is probably not worth the effort.

(so the why is also perhaps an historical reason)

Unixen have a pseudodevice for random numbers

These are probably much more difficult to get than a flow of constant bytes, and much more useful (and requires in practice some hardware support). See random(4) and this question. Read also myths about /dev/urandom

Basile Starynkevitch
  • 10,411
  • 1
  • 32
  • 52
  • Your point that the `yes` program *can* write arbitrary strings is a valid argument why there should be a `yes` program; not so much that there should not be a ``/dev/yes``. It would be trivial to make a family of ``/dev/zero`` clones that provide arbitrary byte values. – G-Man Says 'Reinstate Monica' Apr 22 '18 at 03:36
  • Do we really want 256 different devices `/dev/repeat0x00`, `/dev/repeat0x01`, .... `/dev/repeat0xfe`, `/dev/repeat0xff`? I feel that would be too much (especially in the previous century) – Basile Starynkevitch Apr 22 '18 at 06:02
  • I would like the freedom to say `mknod /dev/zero c 42 0` and `mknod /dev/yes c 42 121` (at least as a matter of principle).  The modification to the `/dev/zero` driver — and I estimate that it would be a one-line change — wouldn’t require the user / administrator to instantiate all 256 nodes in `/dev`. Alternatively, we could make `/dev/repeat/0x00` through `/dev/repeat/0xFF` and then link to the ones we want.  There’s lots of clutter under `/dev/char` and `/dev/disk`, and it doesn’t bother anybody. – G-Man Says 'Reinstate Monica' Apr 22 '18 at 15:24
  • But if you want `yes helloworld` to be done by a device, it could be more difficult. I really think the reason is mostly historical: in the 1980s, 256 device inodes was not unsignificant – Basile Starynkevitch Apr 22 '18 at 16:23
  • OK, perhaps I was unclear.  I’m not suggesting that the driver be able to repeat arbitrary strings, just an arbitrary byte.  (I said that you had justified the existence of a `yes` program — although I would raise the point that the produce-a-string-repeatedly functionality could just as easily have been added to `echo` or `printf` as an option.) And, as I said, (a) it’s a one-line change to the kernel code, and (b) you don’t need to create all 256 inodes; just create the ones you want.  ``/bin/yes`` also takes an inode, and some disk space, too. – G-Man Says 'Reinstate Monica' Apr 22 '18 at 16:34
  • We could also have something similar to `losetup` for loop device for the hypothetical `/dev/repeat`. Loop Device makes a regular file accessible just like a block device. It uses the `losetup` command to to send the loop device the name of this file via `ioctl`. In the same way we could send the name of the string we wish to repeat to the repeat device – Ankur S Apr 22 '18 at 21:03
  • 1
    First off, "yes" doesn't repeat one byte, it repeats two: 0x79 ('y') and 0x0a ('\n'). Second, /dev/null and /dev/zero are clearly useful (though I'd argue that the *contents* of /dev/zero don't matter as much as the fact that they are infinite). The use cases for other devices in that vein are less clear, and that makes it harder to justify putting this functionality in the kernel. – ioctl Apr 23 '18 at 18:31