Skip to content
This repository was archived by the owner on Jun 28, 2023. It is now read-only.
This repository was archived by the owner on Jun 28, 2023. It is now read-only.

Brainstorming prompt visibility/consistency #5

@decklin

Description

@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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions