3 ms·

Ahh, I used to queue this up on another screen when I needed things to look "busy": cat /dev/random | hexdump -C | grep 'ca fe' Note that it runs a lot fa

Ahh, I used to queue this up on another screen when I needed things to look "busy": cat /dev/random | hexdump -C | grep 'ca fe' Note that it runs a lot faster now than it used to in the 90s.

regentbowerbird 2y ago
Super cool, thanks. I wondered how its speed could be adjusted and found `pv` can be used for throttling pipe throughput, so thanks for that too! Limited to reading 50kB per second: cat /dev/urandom | pv -q -L 50k | hexdump -C | grep 'ca fe'
- taway-20230404 2y ago
  Alternatively, slow it down by a factor of 16 for every additional specified character. cat /dev/urandom | hexdump -C | grep '9 ca fe'
AkshayGenius 2y ago
Only tangentially related, but on my MacBook Pro simply running cat /dev/random causes my terminal to hang and my speakers start emitting a loud buzzing sound until the terminal is force-quit or system is restarted. I can understand the terminal not being able to handle the amount of data from /dev/random but for the speakers to start emitting sounds as a result of this is certainly very strange. Almost like /dev/random was being piped into /dev/audio or something. Anyone have an explanation?
- Neywiny 2y ago
  My initial thought is you're getting escape sequences or other signals to trigger the bell/chime. I've never had it crash a terminal but I've never really used a macbook. A common one I'll see in gnome terminal is the terminal printing out some info about itself (I guess there's a way to get some info back from the other side of a link) or changing the title bar. An easy test would be to have something dump that bell character to the terminal as fast as possible and see if that does it, and also try /dev/zero to check that doesn't.
- signa11 2y ago
  just a guess “visual bell” might fix it perhaps ?
- thwarted 2y ago
  This ASCII 7 (C escape "\a"), which when printed emits a bell sound. The exact sound is terminal dependent, and modern terminals won't use the PC speaker but rather play a sound using the audio hardware (which is required on Macs because they don't have a PC speaker). The bell isn't expected to be emitted often and quickly in series, so depending on the capabilities of the terminal program and the audio hardware, it may go haywire trying to play a more complex/longer sound repeatedly or overlapping (like seeming to lock up or slow down as the audio is queued). Your terminal may be configured to "flash" instead of emitting a sound when ASCII 7 is printed -- this may be implemented as rendering the entire window in reverse video for a short duration. A series of discrete bells played quickly may sound like a tone with a rising pitch. Other terminal oddities could occur if ANSI escape sequences. There are many ANSI escape sequences, for changing colors of text, moving the cursor, changing the typeface, or for querying terminal capabilities or customizing the terminal window title bar, that when printed randomly may make the terminal go haywire. PC Speaker - https://en.wikipedia.org/wiki/PC_speaker https://en.wikipedia.org/wiki/PC_speaker ANSI Escape Sequences - https://en.wikipedia.org/wiki/ANSI_escape_code https://en.wikipedia.org/wiki/ANSI_escape_code
- deleted 2y ago
  [deleted]
- 0points 2y ago
  That's the ascii bell symbol being rendered on your terminal. See parent's comment, how he piped output from /dev/random into the next command and not to stdout.
0points 2y ago
(Sorry if too off-topic) I just saw this and thought this was pretty cool! Running your command in nushell, and eventually aborting it gives the following output ^CError: nu::shell::terminated_by_signal × External command was terminated by a signal ╭─[entry #28:1:32] 1 │ cat /dev/random | hexdump -C | grep 'ca fe' · ──┬─ · ╰── terminated by SIGINT (2) ╰──── Just wanted to random praise the nushell team for this amazing level of detail!
- yencabulator 2y ago
  Ehh. Nushell error handling is poorly built and buggy as hell. I wanted to use it, I really believed in the sales pitch, but it's just utterly unreliable and I have zero faith left in them ever actually fixing it. - error handling is neglected in the basic design: <https://github.com/nushell/nushell/issues/10633 https://github.com/nushell/nushell/issues/10633>, <https://github.com/nushell/nushell/issues/10856 https://github.com/nushell/nushell/issues/10856>, <https://github.com/nushell/nushell/issues/8615 https://github.com/nushell/nushell/issues/8615>, <https://github.com/nushell/nushell/issues/6617 https://github.com/nushell/nushell/issues/6617> - control-C interrupts its internals with obviously-wrong error: <https://github.com/nushell/nushell/issues/8828 https://github.com/nushell/nushell/issues/8828>, is midhandled in other ways <https://github.com/nushell/nushell/issues/8206 https://github.com/nushell/nushell/issues/8206> - something is horribly wrong with the basic design of command-line arguments: <https://github.com/nushell/nushell/issues/9939 https://github.com/nushell/nushell/issues/9939>, <https://github.com/nushell/nushell/issues/9766 https://github.com/nushell/nushell/issues/9766> - they're getting the fundamentals of globs on command lines wrong: if you pass string literals to an external command, they're still processed for globs. this means `ls ""` (internal) and `^ls ""` (external) behave differently: <https://github.com/nushell/nushell/issues/9558 https://github.com/nushell/nushell/issues/9558>

Ahh, I used to queue this up on another screen when I needed things to look "busy": cat /dev/random | hexdump -C | grep 'ca fe' Note that it runs a lot faster now than it used to in the 90s.

regentbowerbird 2y ago

Super cool, thanks. I wondered how its speed could be adjusted and found `pv` can be used for throttling pipe throughput, so thanks for that too! Limited to reading 50kB per second: cat /dev/urandom | pv -q -L 50k | hexdump -C | grep 'ca fe'

taway-20230404 2y ago
Alternatively, slow it down by a factor of 16 for every additional specified character. cat /dev/urandom | hexdump -C | grep '9 ca fe'

AkshayGenius 2y ago

Only tangentially related, but on my MacBook Pro simply running cat /dev/random causes my terminal to hang and my speakers start emitting a loud buzzing sound until the terminal is force-quit or system is restarted. I can understand the terminal not being able to handle the amount of data from /dev/random but for the speakers to start emitting sounds as a result of this is certainly very strange. Almost like /dev/random was being piped into /dev/audio or something. Anyone have an explanation?

Neywiny 2y ago
My initial thought is you're getting escape sequences or other signals to trigger the bell/chime. I've never had it crash a terminal but I've never really used a macbook. A common one I'll see in gnome terminal is the terminal printing out some info about itself (I guess there's a way to get some info back from the other side of a link) or changing the title bar. An easy test would be to have something dump that bell character to the terminal as fast as possible and see if that does it, and also try /dev/zero to check that doesn't.
signa11 2y ago
just a guess “visual bell” might fix it perhaps ?
thwarted 2y ago
This ASCII 7 (C escape "\a"), which when printed emits a bell sound. The exact sound is terminal dependent, and modern terminals won't use the PC speaker but rather play a sound using the audio hardware (which is required on Macs because they don't have a PC speaker). The bell isn't expected to be emitted often and quickly in series, so depending on the capabilities of the terminal program and the audio hardware, it may go haywire trying to play a more complex/longer sound repeatedly or overlapping (like seeming to lock up or slow down as the audio is queued). Your terminal may be configured to "flash" instead of emitting a sound when ASCII 7 is printed -- this may be implemented as rendering the entire window in reverse video for a short duration. A series of discrete bells played quickly may sound like a tone with a rising pitch. Other terminal oddities could occur if ANSI escape sequences. There are many ANSI escape sequences, for changing colors of text, moving the cursor, changing the typeface, or for querying terminal capabilities or customizing the terminal window title bar, that when printed randomly may make the terminal go haywire. PC Speaker - https://en.wikipedia.org/wiki/PC_speaker https://en.wikipedia.org/wiki/PC_speaker ANSI Escape Sequences - https://en.wikipedia.org/wiki/ANSI_escape_code https://en.wikipedia.org/wiki/ANSI_escape_code
deleted 2y ago
[deleted]
0points 2y ago
That's the ascii bell symbol being rendered on your terminal. See parent's comment, how he piped output from /dev/random into the next command and not to stdout.

0points 2y ago

(Sorry if too off-topic) I just saw this and thought this was pretty cool! Running your command in nushell, and eventually aborting it gives the following output ^CError: nu::shell::terminated_by_signal × External command was terminated by a signal ╭─[entry #28:1:32] 1 │ cat /dev/random | hexdump -C | grep 'ca fe' · ──┬─ · ╰── terminated by SIGINT (2) ╰──── Just wanted to random praise the nushell team for this amazing level of detail!

yencabulator 2y ago
Ehh. Nushell error handling is poorly built and buggy as hell. I wanted to use it, I really believed in the sales pitch, but it's just utterly unreliable and I have zero faith left in them ever actually fixing it. - error handling is neglected in the basic design: <https://github.com/nushell/nushell/issues/10633 https://github.com/nushell/nushell/issues/10633>, <https://github.com/nushell/nushell/issues/10856 https://github.com/nushell/nushell/issues/10856>, <https://github.com/nushell/nushell/issues/8615 https://github.com/nushell/nushell/issues/8615>, <https://github.com/nushell/nushell/issues/6617 https://github.com/nushell/nushell/issues/6617> - control-C interrupts its internals with obviously-wrong error: <https://github.com/nushell/nushell/issues/8828 https://github.com/nushell/nushell/issues/8828>, is midhandled in other ways <https://github.com/nushell/nushell/issues/8206 https://github.com/nushell/nushell/issues/8206> - something is horribly wrong with the basic design of command-line arguments: <https://github.com/nushell/nushell/issues/9939 https://github.com/nushell/nushell/issues/9939>, <https://github.com/nushell/nushell/issues/9766 https://github.com/nushell/nushell/issues/9766> - they're getting the fundamentals of globs on command lines wrong: if you pass string literals to an external command, they're still processed for globs. this means `ls ""` (internal) and `^ls ""` (external) behave differently: <https://github.com/nushell/nushell/issues/9558 https://github.com/nushell/nushell/issues/9558>