I was thinking of playing a prank on someone by running one of the following commands:

echo bash >> .bashrc


echo source .bashrc >> .bashrc

If someone did this to you, what could you do to fix it (assuming you only have command line access)? Is there anything you could do, short of asking another user to edit it with sudo?

  • 1
    The second will just appear to hang that bash process, so another user can repair it. I think the first one will eventually bring the whole system down due to the increasing number of processes spawned (think "fork bomb"). So, yeah, evil. Less evil, but as annoying would be echo exec bash >> .bashrc – glenn jackman Jun 7 '18 at 15:27
  • 3
    Also less evil and more prankish would be echo exec csh >> ~/.bashrc. – DopeGhoti Jun 7 '18 at 15:36
  • On my machines where my login shell is the Z shell, the Korn shell, and even sometimes the TENEX C shell, it would not do anything to me at all, which indicates that you haven't defined the terms of the question properly. Define "command-line access". Does it include SSH? Is the user logged in at the time? Is the Bourne Again shell even the user's login shell in the first place? – JdeBP Jun 7 '18 at 15:51
  • Do you have ssh access? – ctrl-alt-delor Jun 7 '18 at 15:53
  • 1
    Not evil at all, but frightening if you don't expect it: Install hollywood und put it in .bashrc – mviereck Jun 7 '18 at 19:46

You can not edit the other user's shell startup files unless the permissions are set insecurely. Doing it without their knowledge or consent (which goes for any file in their home directory) would be considered unethical and may also be considered a breach of conduct, depending on what rules of conduct are in effect on the system.

If you have sudo rights on the system, and consider playing this "prank", then you should not have sudo rights on that system.

The first command would add bash as a command at the end of .bashrc. If this was .bashrc in the user's home directory, and if the user was a bash user, then this would cause an infinite recursive loop of interactive shells to be started (as soon as one such shell session was initiated), until terminated or running into resource restrictions.

The second command would cause a similar loop, but the code would only run in a single bash process environment. This would continue until terminated, or until some environment variable (like PATH, if the script added to it in each iteration) got too big at which point a resource limit would be reached.

On a multi-user system, both of these "pranks" may affect other users as shared resources (CPU and memory mostly) are consumed.

Editing, correcting and then saving the .bashrc file while the above scenarios are ongoing would halt the loop, but would not release resources until the bash process(es) of the affected user were terminated.

As a panic fix, one would be able to halt it using pkill -U username bash as root, or with pkill bash as the affected user. This would terminate all bash processes of the affected user.

  • 2
    These sort of pranks are normally done when someone forgets to lock their session and walks away, otherwise I'd call it "cheating". They can actually be useful to encourage following security measures (locking the screen when walking away) so long as they're harmless. Commonly though it's just echo some funny message in the bashrc. In that instance, the prank doesn't stop someone from using the machine, and is easy to fix, which is generally how I'd recommend doing these pranks. – Centimane Jun 7 '18 at 15:56

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.