Brainstorming prompt visibility/consistency

[decklin]

A common point of confusion for newbies when using a terminal/shell is knowing what program they're actually using/typing at. We have:

• Shell on student's computer
  • The vagrant ssh command
    • Shell in the VM
      • IRB
      • rails in various modes

We've got the VM shell prompt in one color set (green/blue) and the IRB prompt/return values in another (red/cyan). I think the most common error I saw was students starting rails server and then typing shell commands into that process. Just coloring the entire Rails log something else could help. Is this possible without too much config complexity?

Really, for anything where the student is typing a command or expression, coloring that input line would also be nice, to distinguish input/output. I've never messed with this in my own environments. But anything we color has to be bold because non-bold was in practice unreadable for a number of Windows-using students, so our palette is limited.

For the shell in the VM, we can stub out commands. For ex, one of my test subjects typed "vagrant halt" in their VM shell without exiting (which results in command-not-found), so I added a vagrant help script that reminds you you're in the VM. Other scripts could be added. For IRB, maybe we could define some stub functions but that probably gets hairy quick.

Another issue: rails server instructs you to quit it with Ctrl-C (and you have to use this; it doesn't read input). In several places, we instruct the student to quit the shell by using the command exit. Would it improve consistency to exit both the shell and IRB with Ctrl-D? (I can't remember the last time I typed out "exit", but that doesn't mean sending EOF is better. Some students may not be accustomed to using any shortcut keys in any apps).

This is one of those things where you have to weigh the benefit of fundamentals (what is EOF, what is a signal, what is a control character, etc) against the time they take away from actual Rails instruction, so... I dunno. I am more knowledgeable about the Unixy stuff but less knowledgeable about Rails.

[decklin]

Also: If you need to run commands in the VM while rails server is running, you have to use another terminal window, which is probably non-intuitive. If there's a really simple way for students to background their server process and keep using their foreground shell, that might be better.

("run with nohup ... 2>&1 & and remember to stop it before you log out" is not sufficiently user-friendly.)

I personally might choose tmux as a solution (seeing the log go by live is useful), but that's yet another layer in the hierarchy above so no good.

[decklin]

Another thing: I'm not convinced workspace is a good idea. Being in a symlinked directory means things like .. don't work they way they normally do, which makes them harder to explain. The parallel between ~/workspace on the host and ~/workspace on the guest muddies the concept of the VM being a computer-within-your-computer. I'd be happy cding to /vagrant directly, and placing the workspace directory on the host based entirely on host-OS usability concerns (i.e there is a "home" dir in both Windows and OS X but they paper over this reality differently.). Then students will know to look for /vagrant on other VMs they might encounter in the future.

[gabebw]

I added a vagrant help script that reminds you you're in the VM.

I think that's a great idea.

[decklin]

I think this is probably more a curriculum problem. I'll see what I can do there.