Separation of Input and Output boxes breaks down (ep2)

[pawsey-kbuckley]

Possibly, given the lack of comments in the month after I submitted
the original "issue list" [Post-Teaching Demo feedback #1036] it's
been suggested that I separate out those issues: this is one such
seperated issue.

There are links to all of the seperated issues in the original.

I have kept the opening paragraph in for context.

I may also have corrected some typos !

I'm submitting this "issue list", ahead of one or more PRs, as a
result of recently performing a Software Carpentry Instructor
Training Teaching Demo, during the preperation for the demo of
which, I was scrutinisng the content of "The Unix Shell" lesson
quite (some might say too) intently, and so noticed some things
that PRs could address, assuming that the Lesson and/or Style
coveners agree that these things are in neeed of addressing.

• Input and Output boxes

There are a couple of places where the seperation of Input and Output
boxes, or rather the theme that a command that provides output, as
opposed to returing to a prompt, breaks down.

In the "Navigating Files and Directories" episode, we use a standalone
"Input" box to show the command "we will dissect into its component
parts", however, when we provide the command and its Output, the two
are combined into one box, thereby breaking the "Input and Output"
theme.

Perhaps that could be re-rendered as

Putting all that together, our command above

[ ls -F / ]  (the input box)

[ Applications/         System/    ]
[ Library/              Users/     ]    Output box
[ Network/              Volumes/   ]

has given us a listing of files and directories in the root directory /.

Note that we would drop the "An example of the output ..." sentence
as the presence of the Output box fits in with what the student
expects.

In the "Pipes and Filters" episode, we use the example of a "wc -l"
without any arguments to talk about the shell as "it just sits there
and waits for us to give it some data interactively."

I think this would benefit from an explict empty line after the
prompt and command line.

So, we would have

What happens if a command is supposed to process a file, but we don’t
give it a filename?

[ $ wc -l         ]
[                 ]

Notice that the shell has accepted our command but has not produced
any output, and instead presented us with an empty line.

Since it doesn’t have any filenames, wc assumes it is ...

This presentation, I suggest, links into the idea of the shell presenting
us with a new line, albeit denoted by the right-arrow, for data-entry,
that is encountered in the Loops episode that comes next.

[gcapes]

1. Well spotted. PR anyone?
2. In principle I don't object to this, but I don't think the addition of a newline at the end of the 'input' box would necessarily be obvious to learners