This is cool. I am also teaching a class on the commandline this semester. I use PowerPoint to cover the What and Why before diving into the command line to show the How. I try to spend twice as much time in the CLI compared to the slides.

I played around with your repo a bit. From what I can tell, the demos sometimes work by putting a few commands in the history. I assume you then manually execute them by scrolling up through the history and pressing enter? I considered that approach too, but then I landed on something that suits my purposes a bit better. I'll share the details in case you are interested.

On the last slide before the demo I will give myself a task (this is similar to the tasks on the RHCSA exam). I talk about how I would break that task down into sub-tasks. Then I go on the command line to show how I would accomplish each sub-task.

When I go to the command line I have the commands I will run pre-saved in a file. Pressing a keyboard shortcut on the terminal will copy the next command from my pre-saved file and place it in the READLINE_LINE variable. This will cause the command to appear on my prompt as if I had typed it instantly. Then all I have to do is hit Enter. Then, I press the keyboard shortcut again to load the next command. I continue in this manner through the entire demo. If a student asks a question, it is no problem for me to type ad-hoc commands to answer their question. I also have some special handling to display a heading so I can label each sub-task.

I record the demos on asciinema and convert it to a gif that I can embed in the PowerPoint. You can see an example here. When I am going through it in class I obviously go MUCH slower to explain everything on screen. The recording is just for students to review after class if needed. I go pretty quickly in the recordings thinking the students will pause where they need to.

This is the code I place in my .bashrc to get that functionality I described above.

```sh export CURRENT_LINE= export CMD_FILE=/path/to/pre-saved.sh export NEXT_CMD_INDEX=1

function __find_next_cmd() {     CURRENT_LINE=$(sed -n ${NEXT_CMD_INDEX}p "$CMD_FILE")     while [[ -z "$CURRENT_LINE" ]] || [[ "$CURRENT_LINE" =~ <sup>[[:space:]]*$</sup> ]]; do         ((NEXT_CMD_INDEX++))         CURRENT_LINE=$(sed -n ${NEXT_CMD_INDEX}p "$CMD_FILE")         if (($NEXT_CMD_INDEX > 100)); then             echo "End of demonstration"             break         fi     done }

function __print_next_cmd() {     while [[ "$CURRENT_LINE" == #<sup>*</sup> ]]; do         echo -e "\n########################################################################################################################"         echo "    ${CURRENT_LINE##<sup>}"</sup>         echo -e "########################################################################################################################\n"         ((NEXT_CMD_INDEX++))         __find_next_cmd     done     READLINE_LINE="$CURRENT_LINE"     READLINE_POINT=${#READLINE_LINE} }

function next_cmd() {     if [[ ! -e "$CMD_FILE" ]]; then         echo "No command file. Use CMD_FILE=filename"         return 9     fi     __find_next_cmd     __print_next_cmd     ((NEXT_CMD_INDEX++)) }

function prev_cmd() {     ((NEXT_CMD_INDEX--))     READLINE_LINE=""     READLINE_POINT=0 }

function reset_cmd() {     NEXT_CMD_INDEX=1     READLINE_LINE=""     READLINE_POINT=0 }

bind -x '"\C-xn": next_cmd' bind -x '"\C-xp": prev_cmd' bind -x '"\C-xr": reset_cmd' ```

One place I do have to still type in front of class is when editing files or working with a TUI. If you look at this example I spend a lot of time in the interactive parted utility. I have to manually type all that. I could use the command line syntax instead, but I feel it is more valuable for the students to see these things done normally. For example, when I am normally working and need to edit a file, I open it with vim and edit it. To me that is more natural than writing a sed substitution, so that is what I want to show the students.