Stick the args to CMD in a list. Fixes #3.

[rgbkrk]

Well, I finally figured out what was going on with slow shell access (#3). It was all about how the Dockerfile was laid out.

CMD /notebook.sh

is very different from

CMD ["/notebook.sh"]

From the section on CMD in the Docker docs:

If you use the shell form of the CMD, then the <command> will execute in /bin/sh -c

Switching over made the timings sane.

[rgbkrk]

Other fine points of note from Project Atomic:

Always exec in Wrapper Scripts

Many images use wrapper scripts to do some setup before starting a process for the software being run. It is important that if your image uses such a script, that script should use exec so that the script’s process is replaced by your software. If you do not use exec, then signals sent by docker will go to your wrapper script instead of your software’s process. This is not what you want - as illustrated by the following example:

Say that you have a wrapper script that starts a process for a server of some kind. You start your container (using docker run -i), which runs the wrapper script, which in turn starts your process. Now say that you want to kill your container with CTRL+C. If your wrapper script used exec to start the server process, docker will send SIGINT to the server process, and everything will work as you expect. If you didn’t use exec in your wrapper script, docker will send SIGINT to the process for the wrapper script - and your process will keep running like nothing happened.

Perhaps we need to use exec on the notebook server launch too then!

[takluyver]

Odd, I'm not sure how that would make a difference to pexpect for running
shell commands.

[rgbkrk]

/bin/sh -c "ipython notebook" doesn't seem to cause any issues from my Mac (no Docker). I'll probably continue to dig.