16 ms·

Yes `yes no`

200 points by tylermenezes 14y ago

aprescott 14y ago
Here's something similar that is cumbersome to stop, but not so disastrous: yes 'yes yes&' | sh
HNLogInShit 14y ago
This might be useful when I go to RM one of my own goddamned directories and get asked, "override rrblahblah for blahblah" a thousand times. But of course it is't; I'll just continue using sudo.
mortenlarsen 14y ago
I just killed the shell that it was running in. By then it was consuming one CPU core, and about 2 GB of RAM. Then i tried again, in a subshell, and let it run... [user@machine] ~ % zsh [user@machine] ~ % yes `yes no` zsh: fatal error: out of heap memory [user@machine] ~ % [user@machine] ~ % bash user@machine:~$ yes `yes no` bash: xrealloc: ../bash/subst.c:5184: cannot allocate 18446744071562067968 bytes (4297060352 bytes allocated)
- chrismorgan 14y ago
  I'm surprised bash wasn't able to allocate 16 exabytes, though I will accept it's a fairly large step up from having 4GB allocated. But surely your machine had heaps of memory?
  - graylights 14y ago
    Linux will let you allocate as much memory as you want. It doesn't ever return failure based on available memory. Instead if you attempt to write to memory it will then map memory and if there is none available it will trigger the OOM killer. The kernel will attempt to kill misbehaving processes. The 4GB limit is maximum memory that can be allocated to a process (this is configurable) http://en.wikipedia.org/wiki/OOM_Killer http://en.wikipedia.org/wiki/OOM_Killer
eridius 14y ago
The explanation is completely incorrect. The outer invocation of `yes` is never actually started. The reason is because the inner invocation is being used as an argument to the outer invocation, which means bash needs to know the entire output of the inner invocation before it even starts the outer invocation. Instead, all you're seeing is bash thrashing as it tries desperately to capture all the output of `yes no` in-memory. I expect you'd see the exact same behavior with echo `yes no`. Now if you really want to screw over your machine, the classic bash fork bomb is :(){ :|:& };:
- gjulianm 14y ago
  I've always preferred this tougher command to screw VMs I was going to delete. dd if=/dev/random of=/dev/sda Depending on how long does it run, you end up with a more or less screwed computer. It's funny to see how does the machine fall over when you invoke a simple 'cd' command after this.
  - srl 14y ago
    Back when `/dev/mem` was a thing in default kernels (now you need a special config, or a module), I enjoyed `cat /dev/urandom > /dev/mem`. That would usually bork things pretty quickly, so then I would set random offsets with `dd`. Fun times.
    - mikeash 14y ago
      See also kmem Russian Roulette: https://twitter.com/shadowcat_mst/status/754107237269504 https://twitter.com/shadowcat_mst/status/754107237269504
      - zx2c4 14y ago
        Or try this -- http://git.zx2c4.com/memory-hemlock/tree/slow-death.c http://git.zx2c4.com/memory-hemlock/tree/slow-death.c It picks a random device on your system -- ram, video, bios, etc -- and writes a random number of random bytes into it and then sleeps for a random amount of time. Last one standing lives.
nvartolomei 14y ago
Try this: yes 'c=(╱ ╲);printf ${c[RANDOM%2]}'|bash It doesn't do any harm, promise.
- pluies_public 14y ago
  That's pretty awesome! (For the sceptics, it indeed does no harm and can be interrupted at will)
  - paul_f 14y ago
    Haha, good one. Here's another harmless command you can try. It's fun! sudo rm -rf /
    - crayola 14y ago
      I wouldn't joke with that.. Someone may actually try and lose a lot of time and data. Yes, most HN readers will get your 'joke', but possibly not all.
      - nivla 14y ago
        Its atleast disabled by default in latest versions of Ubuntu and other distros, but regardless paul_f shouldn't have posted it without any disclaimer.
      - Ao7bei3s 14y ago
        It'd teach them not to run random commands they found on the internet, what rm does, and to make backups. Three valueable lessons. That is, if it would actually work: modern rm implementations have a special case for /. Read the manpage and/or try this instead: rm -rf --no-preserve-root /
      - charliesome 14y ago
        If you blindly run code you find on the Internet without understanding what it does, you deserve all you get.
    - 14y ago
__alexs 14y ago
`yes` will do the same thing. It's just accumulating all the output from yes inside your shell. The yes command is actually pretty crappy for making fork bombs.
- andrewflnr 14y ago
  It's a memory bomb, not a fork bomb.
deleted 14y ago
[deleted]
Rovanion 14y ago
Interestingly enough the lxterm I run echo `yes no` or yes `yes no` in dies after allocating somewhere around 4GB of RAM. I would expect this on a 32 or 32-pae kernel but I don't understand why on a 64 bit kernel. EDIT: Got the output by running bash in bash: bash: xrealloc: ../bash/subst.c:5184: cannot allocate 18446744071562067968 bytes (4296822784 bytes allocated) So now I'm wondering why 18446744071562067968 bytes is the next logical step after 4GB.
- sltkr 14y ago
  It isn't -- it's just a typical 32-bit signed integer overflow that gets sign-extended to create a 64-bit unsigned integer. The previous size was probably just under 2 GB for this string. My guess is that “4296822784 bytes allocated” (which is already a little over 4 GB) refers to all the heap memory allocated so far, not just for this one string, which was actually slightly under 2 GB long. Bash is full of bugs like this; e.g. on a 64-bit system try doing echo $[263/-1].
  - chrismorgan 14y ago
    $ bash --version GNU bash, version 4.2.37(1)-release (x86_64-pc-linux-gnu) ... $ echo $[263/-1] -263 What is it "supposed" (failure case) to do?
    - Dylan16807 14y ago
      Bit by HN formatting. $ echo $[2**63/-1] Floating point exception Bash crashes out entirely because it doesn't check the operands are safe. See also http://kqueue.org/blog/2012/12/31/idiv-dos/ http://kqueue.org/blog/2012/12/31/idiv-dos/
- deleted 14y ago
  [deleted]
- JoshuaDavid 14y ago
  2^32 = 4294967296 2^64 = 18446744073709551616
auctiontheory 14y ago
Improv teaches us to say "yes, and" to opportunities. Note that "yes, and" is very different from "yes, but." Source: _Improv Wisdom_.
tadfisher 14y ago
For some reason I keep thinking of the halting problem.
- derleth 14y ago
  Actually, this is an example of where the halting problem can be trivially solved through static analysis. Finding all of the programs that are isomorphic to this one when given certain input, now... that's the problem.
aroman 14y ago
In school my friends and I used to have little "hacking" competitions -- who could do the most damage to the other's computer using only an SSH session. An old favorite of mine was the elegant: `yes > no` [1] [1] I'm fairly certain I made this up... though it's obviously trivially easy to "discover" on your own.
- wvenable 14y ago
  My friends and I would play similar game in DOS and it was how much you could mess up their machine but in reversible fashion. Every so often I'd come to my machine and just have a blinking cursor on a blank screen and have to figure out how to get back to a working machine.
decklin 14y ago
This is an interesting illustration of the GNU coding standards: http://www.gnu.org/prep/standards/html_node/Semantics.html http://www.gnu.org/prep/standards/html_node/Semantics.html (as others have noted, the program actually doing something here is bash: it attempts to dynamically allocate as much memory as it can to store the output of 'yes no'. Hopefully the author discovers ulimit.)
js2 14y ago
I was a sysop for the University of Florida CS department once upon a time. It was always fun when students first learned about fork(). This post reminded me of that.
rogerbinns 14y ago
I'm proud that I actually found a bug in yes over a decade ago. Yes should exit when whatever it is talking to exits, but under some circumstances doesn't and instead goes into an infinite loop. http://permalink.gmane.org/gmane.comp.gnu.sh-utils.bugs/48 http://permalink.gmane.org/gmane.comp.gnu.sh-utils.bugs/48
languagehacker 14y ago
Looking at this blog, I started to say myself, "Wow, the Subtle network is getting worse and worse contributors," and then I realized that this blog just _looks_ a lot like a Subtle blog. Then I wiped my forehead, mostly because I expect not to read things that actually have to tell me that the the the thing that makes Unix difference from MS-DOS (uh, what?) is "the terminal".
brvs 14y ago
"say" is cool. cat /usr/share/dict/words | perl -mList::Utilhuffle -e 'print shuffle(<STDIN>);' | head -n 5 | say -r 150
deleted 14y ago
[deleted]
hakaaaaak 14y ago
This thread is one of the best I've seen on HN. 1001 ways to screw yourself in bash. Love it. My contribution is a message from Mr. Odus himself- also a Reverend. Don't do this unless you want a bad day: :) `printf "\ fr- mr odus"|rev`
- sneak 14y ago
  Sorry, but sudo rm -rf \ ...doesn't do anything. rev(1) doesn't reverse your slashes. :D
- deleted 14y ago
  [deleted]
anonymous 14y ago
The effect is interesting. I ran it and, sure enough, started running out of memory. However, simply killing the yes process didn't stop it. I had to kill the bash process in which I had typed the command.
- ygra 14y ago
  Probably yes was just waiting for the write buffer to clear so it could write again while bash was busy asking the system for more memory which was busy swapping everything to make room.
prg318 14y ago
Interesting read. Another use I have found for "yes" is separating terminal output. Since "clear" doesn't delete your terminal scrollback, it can be easy to scroll up and get confused of what you are looking at. I've noticed this is especially useful when compiling testing programs to separate build output with "yes" so that you're not hunting down compiler errors/warnings that you have already fixed :) you can even be descriptive with your yes call -- ie: "yes fixed x checking to see if y is still broken"

Yes `yes no`

200 points by tylermenezes 14y ago

Here's something similar that is cumbersome to stop, but not so disastrous: yes 'yes yes&' | sh

This might be useful when I go to RM one of my own goddamned directories and get asked, "override rrblahblah for blahblah" a thousand times. But of course it is't; I'll just continue using sudo.

mortenlarsen 14y ago

I just killed the shell that it was running in. By then it was consuming one CPU core, and about 2 GB of RAM. Then i tried again, in a subshell, and let it run... [user@machine] ~ % zsh [user@machine] ~ % yes `yes no` zsh: fatal error: out of heap memory [user@machine] ~ % [user@machine] ~ % bash user@machine:~$ yes `yes no` bash: xrealloc: ../bash/subst.c:5184: cannot allocate 18446744071562067968 bytes (4297060352 bytes allocated)

chrismorgan 14y ago
I'm surprised bash wasn't able to allocate 16 exabytes, though I will accept it's a fairly large step up from having 4GB allocated. But surely your machine had heaps of memory?
- graylights 14y ago
  Linux will let you allocate as much memory as you want. It doesn't ever return failure based on available memory. Instead if you attempt to write to memory it will then map memory and if there is none available it will trigger the OOM killer. The kernel will attempt to kill misbehaving processes. The 4GB limit is maximum memory that can be allocated to a process (this is configurable) http://en.wikipedia.org/wiki/OOM_Killer http://en.wikipedia.org/wiki/OOM_Killer

eridius 14y ago

The explanation is completely incorrect. The outer invocation of `yes` is never actually started. The reason is because the inner invocation is being used as an argument to the outer invocation, which means bash needs to know the entire output of the inner invocation before it even starts the outer invocation. Instead, all you're seeing is bash thrashing as it tries desperately to capture all the output of `yes no` in-memory. I expect you'd see the exact same behavior with echo `yes no`. Now if you really want to screw over your machine, the classic bash fork bomb is :(){ :|:& };:

gjulianm 14y ago
I've always preferred this tougher command to screw VMs I was going to delete. dd if=/dev/random of=/dev/sda Depending on how long does it run, you end up with a more or less screwed computer. It's funny to see how does the machine fall over when you invoke a simple 'cd' command after this.
- srl 14y ago
  Back when `/dev/mem` was a thing in default kernels (now you need a special config, or a module), I enjoyed `cat /dev/urandom > /dev/mem`. That would usually bork things pretty quickly, so then I would set random offsets with `dd`. Fun times.
  - mikeash 14y ago
    See also kmem Russian Roulette: https://twitter.com/shadowcat_mst/status/754107237269504 https://twitter.com/shadowcat_mst/status/754107237269504
    - zx2c4 14y ago
      Or try this -- http://git.zx2c4.com/memory-hemlock/tree/slow-death.c http://git.zx2c4.com/memory-hemlock/tree/slow-death.c It picks a random device on your system -- ram, video, bios, etc -- and writes a random number of random bytes into it and then sleeps for a random amount of time. Last one standing lives.

nvartolomei 14y ago

Try this: yes 'c=(╱ ╲);printf ${c[RANDOM%2]}'|bash It doesn't do any harm, promise.

pluies_public 14y ago
That's pretty awesome! (For the sceptics, it indeed does no harm and can be interrupted at will)
- paul_f 14y ago
  Haha, good one. Here's another harmless command you can try. It's fun! sudo rm -rf /
  - crayola 14y ago
    I wouldn't joke with that.. Someone may actually try and lose a lot of time and data. Yes, most HN readers will get your 'joke', but possibly not all.
    - nivla 14y ago
      Its atleast disabled by default in latest versions of Ubuntu and other distros, but regardless paul_f shouldn't have posted it without any disclaimer.
    - Ao7bei3s 14y ago
      It'd teach them not to run random commands they found on the internet, what rm does, and to make backups. Three valueable lessons. That is, if it would actually work: modern rm implementations have a special case for /. Read the manpage and/or try this instead: rm -rf --no-preserve-root /
    - charliesome 14y ago
      If you blindly run code you find on the Internet without understanding what it does, you deserve all you get.
  - 14y ago

__alexs 14y ago

`yes` will do the same thing. It's just accumulating all the output from yes inside your shell. The yes command is actually pretty crappy for making fork bombs.

andrewflnr 14y ago
It's a memory bomb, not a fork bomb.

deleted 14y ago

[deleted]

Rovanion 14y ago

Interestingly enough the lxterm I run echo `yes no` or yes `yes no` in dies after allocating somewhere around 4GB of RAM. I would expect this on a 32 or 32-pae kernel but I don't understand why on a 64 bit kernel. EDIT: Got the output by running bash in bash: bash: xrealloc: ../bash/subst.c:5184: cannot allocate 18446744071562067968 bytes (4296822784 bytes allocated) So now I'm wondering why 18446744071562067968 bytes is the next logical step after 4GB.

sltkr 14y ago
It isn't -- it's just a typical 32-bit signed integer overflow that gets sign-extended to create a 64-bit unsigned integer. The previous size was probably just under 2 GB for this string. My guess is that “4296822784 bytes allocated” (which is already a little over 4 GB) refers to all the heap memory allocated so far, not just for this one string, which was actually slightly under 2 GB long. Bash is full of bugs like this; e.g. on a 64-bit system try doing echo $[263/-1].
- chrismorgan 14y ago
  $ bash --version GNU bash, version 4.2.37(1)-release (x86_64-pc-linux-gnu) ... $ echo $[263/-1] -263 What is it "supposed" (failure case) to do?
  - Dylan16807 14y ago
    Bit by HN formatting. $ echo $[2**63/-1] Floating point exception Bash crashes out entirely because it doesn't check the operands are safe. See also http://kqueue.org/blog/2012/12/31/idiv-dos/ http://kqueue.org/blog/2012/12/31/idiv-dos/
deleted 14y ago
[deleted]
JoshuaDavid 14y ago
2^32 = 4294967296 2^64 = 18446744073709551616

auctiontheory 14y ago

Improv teaches us to say "yes, and" to opportunities. Note that "yes, and" is very different from "yes, but." Source: _Improv Wisdom_.

tadfisher 14y ago

For some reason I keep thinking of the halting problem.

derleth 14y ago
Actually, this is an example of where the halting problem can be trivially solved through static analysis. Finding all of the programs that are isomorphic to this one when given certain input, now... that's the problem.

aroman 14y ago

In school my friends and I used to have little "hacking" competitions -- who could do the most damage to the other's computer using only an SSH session. An old favorite of mine was the elegant: `yes > no` [1] [1] I'm fairly certain I made this up... though it's obviously trivially easy to "discover" on your own.

wvenable 14y ago
My friends and I would play similar game in DOS and it was how much you could mess up their machine but in reversible fashion. Every so often I'd come to my machine and just have a blinking cursor on a blank screen and have to figure out how to get back to a working machine.

decklin 14y ago

This is an interesting illustration of the GNU coding standards: http://www.gnu.org/prep/standards/html_node/Semantics.html http://www.gnu.org/prep/standards/html_node/Semantics.html (as others have noted, the program actually doing something here is bash: it attempts to dynamically allocate as much memory as it can to store the output of 'yes no'. Hopefully the author discovers ulimit.)

js2 14y ago

I was a sysop for the University of Florida CS department once upon a time. It was always fun when students first learned about fork(). This post reminded me of that.

rogerbinns 14y ago

I'm proud that I actually found a bug in yes over a decade ago. Yes should exit when whatever it is talking to exits, but under some circumstances doesn't and instead goes into an infinite loop. http://permalink.gmane.org/gmane.comp.gnu.sh-utils.bugs/48 http://permalink.gmane.org/gmane.comp.gnu.sh-utils.bugs/48

languagehacker 14y ago

Looking at this blog, I started to say myself, "Wow, the Subtle network is getting worse and worse contributors," and then I realized that this blog just _looks_ a lot like a Subtle blog. Then I wiped my forehead, mostly because I expect not to read things that actually have to tell me that the the the thing that makes Unix difference from MS-DOS (uh, what?) is "the terminal".

brvs 14y ago

"say" is cool. cat /usr/share/dict/words | perl -mList::Utilhuffle -e 'print shuffle(<STDIN>);' | head -n 5 | say -r 150

deleted 14y ago

[deleted]

hakaaaaak 14y ago

This thread is one of the best I've seen on HN. 1001 ways to screw yourself in bash. Love it. My contribution is a message from Mr. Odus himself- also a Reverend. Don't do this unless you want a bad day: :) `printf "\ fr- mr odus"|rev`

sneak 14y ago
Sorry, but sudo rm -rf \ ...doesn't do anything. rev(1) doesn't reverse your slashes. :D
deleted 14y ago
[deleted]

anonymous 14y ago

The effect is interesting. I ran it and, sure enough, started running out of memory. However, simply killing the yes process didn't stop it. I had to kill the bash process in which I had typed the command.

ygra 14y ago
Probably yes was just waiting for the write buffer to clear so it could write again while bash was busy asking the system for more memory which was busy swapping everything to make room.

prg318 14y ago

Interesting read. Another use I have found for "yes" is separating terminal output. Since "clear" doesn't delete your terminal scrollback, it can be easy to scroll up and get confused of what you are looking at. I've noticed this is especially useful when compiling testing programs to separate build output with "yes" so that you're not hunting down compiler errors/warnings that you have already fixed :) you can even be descriptive with your yes call -- ie: "yes fixed x checking to see if y is still broken"