It's nice to copy-paste a series of Bash commands that you find on a website. But depending on the commands, sometimes you lose a few. Maybe they get swallowed up by programs that read from standard input, or perhaps there's another explanation.

So I end up doing this sometimes:

$ bash <<EOF

Is there a better way? Some Bash option? An SSH option? (My setup is an Bash running on an Ubuntu server, which I'm SSH'ed to from a standard OS X terminal. Not sure how much of that is relevant.)



In response to requests for a concrete example, here's one. I pasted the following four lines into an SSH shell (from my Snow Leopard desktop) connected to a stock Ubuntu Quantal running on an OpenStack VM, in the Bash shell.

sudo apt-get install -y r-base gdebi-core
sudo apt-get install -y libapparmor1 # Required only for Ubuntu, not Debian
wget http://download2.rstudio.org/rstudio-server-0.97.314-amd64.deb
sudo gdebi rstudio-server-0.97.314-amd64.deb

The first two commands executed (successfully), while the last two were apparently never received by the server (or at least, never processed by Bash).

  • 1
    Do you have a specific example of what fails? – slhck May 13 '13 at 6:57
  • No. Usually a long-running command, like apt-get update, git clone, wget etc. – Steve Bennett May 13 '13 at 8:00
  • 1
    Problem: need a convenient, robust mechanism for pasting a series of commands into a shell then executing them, that doesn't rely on the vagaries of the terminal itself. – Steve Bennett May 13 '13 at 8:05
  • 1
    OT here, but interesting nevertheless. At least I was really surprised, that you sometimes don't get what you expect with copy&paste from websites: h-online.com/open/news/item/… – mpy May 13 '13 at 16:50
  • 2
    This reads like game of "Find me a rock"("No, that one's too big."; "No, that one's too small."; "Not that one, I don't like the color.") A more explicit problem description might get you fewer guesses and some more relevant answers you'd like better. – JRobert May 13 '13 at 17:32

A quick and dirty solution is to run this:

bash -c '<paste commands here>'

This works even if the paste contains newline characters. It may fail if the paste contains single quotes. If you're aware of the bash quoting rules, you should be able to modify this method for the specific commands that you're trying to run.

  • That's excellent - I had no idea you could put newlines in command lines. – Steve Bennett May 15 '13 at 7:15

You could also use something like pbpaste | bash. And edit-and-execute-command (\C-x\C-e) also works with multiple commands.

If some commands require root permissions, you can use sudo -v to validate the timestamp for 5 minutes.

  • The OP is SSHing into an Ubuntu server, so pbpasteing into bash is not easily doable there. – slhck May 13 '13 at 8:02
  • 2
    Ah, that edit-current-line trick works. (Ctrl-x, Ctrl-E or ^X^E in other notation). – Steve Bennett May 13 '13 at 8:03
  • It is quite a few keystrokes all up.: Ctrl+X, Ctrl+E, Cmd-V, Ctrl+X, Y, <enter> – Steve Bennett May 13 '13 at 8:06
  • xsel on Linux. – Ciro Santilli 新疆改造中心法轮功六四事件 Aug 25 '15 at 7:58
  • @SteveBennett looks like your $VISUAL editor is nano ;) the keystrokes are different for other editors – törzsmókus Jun 29 '18 at 7:43

I make such cuts and pastes into my favourite text editor, named appropriately, where I can then carefully look for extraneous characters, and ensure that I'll be running what I expect to be running. I'm strongly adverse to cutting and pasting code snippets into an interactive shell: who knows what extra commands might be picked up by the cut & paste operation?

Once your text file has the verified commands saved, they can then be executed with the built-in command

source <filename>

  • Ok, and once you've satisfied yourself that the contents of the clipboard is precisely what you want to run? – Steve Bennett May 13 '13 at 8:00
  • Original updated; On the saved file, use 'source <filename>' to execute the statements within, without having to make it executable. – Nevin Williams May 13 '13 at 9:41
  • And now you have a script file lying around which you'll never run again. That's pretty clumsy. – Steve Bennett May 13 '13 at 9:53
  • then you delete it and it won't be around anymore. – ShinTakezou May 13 '13 at 10:06
  • 1
    Yep. Way clumsier than the original <<EOF method. – Steve Bennett May 15 '13 at 7:14

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.