David Gillon

It's December Days time again. This year, I have decided that I'm going to talk about skills and applications thereof, if for no other reason than because I am prone to both the fixed mindset and the downplaying of any skills that I might have obtained as not "real" skills because they do not fit some form of ideal.

14: Terminal

Being a child of DOS sometimes gives me an advantage and a bit of comfort whenever a project or a task that I have to do involves the command line. I still love a good Graphical User Interface (GUI), and I firmly believe that most applications these days are well-suited to having a GUI, even if it's basically a visual wrapper for three command line applications dressed in a trenchcoat. Having a GUI makes your application more accessible to the person who does not feel at home running cryptic commands and not understanding what they will do. I especially like the people who provide the GUI in a terminal (a TUI) when it makes the most sense for their application to be run from the command line and manipulated in such a way.

Others extol the terminal and the command line as the superior option for all things, because the terminal runs faster than the GUI does, needs smaller files to produce the same outputs, requires less clicking and typing, and because being able to run a thing from the terminal generally means it can run on a much wider variety of things, instead of being locked to those things that have enough horsepower behind them to run graphical environments.

Still others, the people who get the side-eye, say that the terminal is the superior option for all because it functions as a skill gate. People who cling to their GUIs are still n00bs and lusers who have not demonstrated sufficient computer touchery and geekery to be allowed access to this particular tool, and therefore anyone who wants to use this jewel has to git gud. Snobbery is not a good look on anyone, but technological snobbery can be particularly vicious, and there are more people than we'd like to admit who fall into the third category of "people who don't want the less technical 'polluting' their spaces with demands for things like accessibility or an easier-to-use interface or syntax."

It is a potentially scary thing to type in a command that someone has put on the Internet, or in a script, or to run as an executable, and hope that it doesn't do something awful to your machine. And even scarier when the potential for malice is not embedded in an executable program, but instead a script inside an innocuous-looking document, or even as things that may or may not require someone to do anything before their system is compromised. And unlike many GUI programs, the command line is a place where the assumption is that you know what you're doing when you type the command and press enter. Great power, great responsibility, great potential for disaster. Not everyone necessarily wants to learn how the syntax of the command works, what it does and any tertiary pieces of knowledge that go along with it, like how to construct regular expressions, how to pipe the output from one program as input into another for further manipulation, or how to construct Boolean logic to capture all the possible conditions and find the correct one for the situation. These people are still valid users and they should have access to tools just as much as the people who want to run everything through the terminal.

Some of the most common situations I had for working with the command line as a youngling were, naturally, in pursuit of playing games. As described in the first post, once I left the comforts and constraints of Automenu, I learned how to navigate around in DOS and do things with it. As games progressed and started taking up more and more memory, there had to be some tricks involved to ensure there was enough available memory for the game to successfully run. DOS in those days had what they called "TSR" programs (no relation to the company that developed Dungeons and Dragons) - Terminate and Stay Resident. Most of the time, these TSRs were drivers so that hardware attached to the system would function properly. Others might be ways of taking advantage of greater amounts of system memory, and setting things up for something like bank switching, so that from the "conventional" memory space, you could still address, store, and retrieve things from "high" memory or "upper" memory that wasn't subject to the 640k limitations of "conventional" memory. (The deep dive into how to store and retrieve information from a Game Boy cartridge was intensely fascinating, and also helped me understand a little more about clever solutions used in limited circumstances.) The difficulty with TSRs is that they had to stay in the "conventional" memory space, and while there were all kinds of solutions and methods to access and use the higher memory spaces, many of them relied on there being enough conventional memory space available in the right places to implement their tricks. So, as time went on, while there may have been enough available RAM and processing power to run Sierra family games, the setup wasn't distributed properly to work.

Thus, the boot disk. From the TUI of the game installer, there was always an option of creating a "boot disk." In those days and times, DOS progressed through the various drives available to determine what to boot from, and the floppy disk drives were always assigned letters earlier in the alphabet than hard disk drives., so they would always be earlier in the boot order than the hard disks. By sacrificing a floppy to the installer, it would craft a DOS boot environment where the bare minimum of TSRs would be loaded to make playing the game functional, with the assumption that after using the boot disk to load the correct environment, you'd then proceed through the directory structure to the hard disk and load the game that way. And they worked very well, loading the drivers for keyboard, mouse, sound card, and sometimes the CD drive, as well as the tools needed to access the higher memory blocks. Once I was done gaming, I'd reboot the system so that it could return to normal operations and access to things like Windows. These days, we don't need to fiddle around with such things, even as RAM requirements and availability have grown. And these days it would be something more like a boot image of some sort, a way of loading a specific environment and then booting directly into the game itself. I wonder what kind of game might take that on as their packaging method, trying not to allow installs, even if they might allow for the mounting and running of the image inside some form of container, but otherwise trying to keep the entire thing on the disc image created.

Boot disks were another way of helping me get comfortable with the command line, and with giving me an incomplete understanding of how a computer actually sets itself up to run and produces the environment that the user will be working in. That's all basically abstracted away, and we only see a little bit of it when watching the console output scroll by as my current machines load up. I'm glad of not having to make boot disks any more, and I'm glad that we have more sensible ways of managing memory and startup now, so that people don't have to do arcane things to set themselves up for playing games and running software. Terminal comfort can come from other sources than hacing to rearrange your entire environment just to play a game.

For some time after that, as Windows got better, and then became the way that most games were played, and DOS eventually found its way to emulation, rather than being a major part of everyone's lives, those command line skills didn't pick up a lot of use, although they also never really went away, because, as I was getting older, this somewhat new-fangled object called The World Wide Web had joined the scene (again, telling you more about how old I am than not) and the interconnectedness of computers was now not only possible, but achievable to people who weren't on defense or university networks. The early parts of this interconnectedness relied on a few different protocols to make it all work - HTTP for HTML document transfer, FTP for binary file transfer, there was Gopher around, and a few other protocols. (All of these protocols still exist, although not many people are maintaining FTP servers any more, I suspect, having found it easier, faster, and better on the bandwidth to seed large files through BitTorrent.) ECMAScript/Javascript/Typescript were promising new ways of doing things, and a lot of website addresses at the time had a /cgi-bin/ in their paths, so even at that time, there were attempts to bolt interactivity and responsiveness onto the more static HTTP protocol.

Since I missed the BBS scene entirely, and never had newsreader access, I don't have the experience of dialing in with a modem and using a program to peruse the bulletin boards and the newsgroups - that would come later, with things like phpBB and other implementations of forum software, before we all decamped for our individual blogs and tried to link them together through rings and RSS. What I do have, however, is that there was a…surge? resurgence? rediscovery? of the Multi-User Dungeon and the use of the telnet protocol to connect to such things and interact with them. I won't say I was any good at any of them at all, and a friend of mine wanted to have me build some things for their own MUD, but I didn't get very involved with that, and so I didn't contribute all that much to it, either. I could have possibly learned a few things about scripting and other such things if I had persisted with the building aspect of it, but I didn't have the time nor the always-available Internet connection, to do most of my building and scripting work with. A more involved me might have instead grabbed the ability to run a local server on a non-Internet-connected machine and put together all of the things that needed doing to make it work, before uploading all of that to the live instance when I had an Internet connection. Which very well may have required either exporting in some way or retyping everything that I did in the local copy onto the non-local copy.

As it is, I entered university days with some amount of telnet experience with the MUDs, and a little more from having used the earliest form of using computers to make requests from other locations in the library system. (With the added bonus of being able to use that same system to look up and make requests from home, instead of having to be at the library to do so.) This made me particularly well-suited to using whatever computers were handy to do things like work on assignments, check e-mail, and do the occasional bit of socializing or other such between classes. While the university provided us with a disc of useful programs to put on our personal computers in the dormitories, or off-campus, I don't remember how many, if any, of the machines that were in the shared computing labs had those same programs present. As a further not-really-complication, since most students were comfortable with Windows machines, that usually meant the available machines were on the Macintosh side of the lab. As someone who could get things done in both of those environments, it mostly meant that I was on the Mac side of the lab instead of the Windows side. (Even more so in graduate school, as the Macs had a good text editor with syntax highlighting that I could use when I was away from my own Linux machine and its syntax highlighting.) The University e-mail system had a command-line interface and interaction point, and I think that was accessed by telnet as well. (What I remember much more clearly about it was that all of the servers we could connect to were identified as being arcade games. While we used a single point of entry to connect, the server we were assigned at random always was a classic arcade game. Zaxxon, Xevious, Pac-man (and Ms. Pac-Man), Asteroids, Battlezone, etc. I liked being able to get the reference and wondered which game I would be working with every time I signed in.) Pine was the system, I remember that, and it was a perfectly serviceable TUI to check, manage, and respond quickly to various e-mails that had been sent out and I was looking at in the time between classes, or when I was in the lab. I felt smart and technologically awesome that I was able to use the terminal for this kind of purpose, and to do it well. And, yes, I did feel a little smug and superior that I could do this on whichever machine was available, instead of having to wait for a specific machine to come available or to trek to a specific laboratory where those machines were available. My university-aged self is still unlearning things as much as they are learning things, and so I have to treat them with patience and understanding.

So when it comes to the terminal and the command line, I have decades of experience in using it, in having things blow up in my face, in having to use it because various utilities, servers, and tools run best (or at all) from terminal, and in using it because I want to see what a piece of software does, and whether I can get things to go faster from there than from other methods. I'd say that comfort with the command line is a second-order comfort when it comes to computers, because you can't really get comfortable with a command line until you are properly comfortable with the machine itself, and feeling competent and curious enough to try things, have them explode, recover from them, and otherwise recognize that many things that wreck a computer can be recovered from, although what form the recovery takes is different depending on how big of an explosion happened, and that most systems with a GUI will ask if you're sure before they do something destructive. This is the kind of thing that a spare machine is perfect for, because spare machines are what you do things that are destructive or explosive on, and then when they do explode or do unwanted things, you have gained knowledge about what to do or what not to do, or that the thing you tried to do was not properly formed, even if it was accepted as valid. Sometimes you discover some really cool things you can do and then take that knowledge back to the main machine to make it run better and more according to your needs.

Once you have the willingness to experiment and see what happens, and the knowledge backstopping you that you can get out of most common bad situations, and perhaps even the knowledge of how to reconstruct a system from scratch and start again, then you can start getting more comfortable on the command line and using the terminal when it seems appropriate or useful to do so. Because, again, many terminal commands don't ask if you're sure, they just do what you told them to do. (More of them probably should ask, but most of the core utilities and commands on any operating system were developed and used by people who did know what they were doing, and they probably found it annoying to have to confirm it every time they wanted to do something. For Linux specifically, even though many distributions of Linux are better about not requiring the use of the terminal or the command line, there's still a certain assumption baked in that the terminal is the real heart of using Linux, and everything else is eye candy, abstraction, or concession made to those who don't want to do everything from the terminal. The terminal-centric focus of Linux makes it both very powerful and very portable, since the terminal itself, and the core utilities don't require a lot of fancy anything to work, and can be put in embedded or underpowered systems to provide functionality and flexibility to their operation. Terminal commands and abilities are also part of creating scripts and programs that will chain together commands to produce useful output, which is the part where the possibilities expand outward exponentially.

I'm trying not to make the terminal sound completely intimidating, and that you need all the time and experience that I have with it to produce useful things and be comfortable with it. But especially in Linux systems, grasping the terminal and what you can do with it is almost a prerequisite for unlocking the full potential of such a system. And I don't fully know everything that I can do with the terminal, because I haven't had to learn it yet, so you don't have to know everything and read all the man pages before you can start using and experimenting with it. I do think, though, that having grown up in an era where the command line was the primary method of accessing programs and using the computer has made it easier for me to re-adopt a terminal, now that I've chosen an operating system that relies on it. I'd still rather that people took the time to put in interfaces and help for people when they release programs to users, or that, if it makes sense, they build a GUI component for their program so that it's more widely accessible, but that is not always the case.

I guess the point is to say that computer touchery does not have to involve terminals and text editors, and that there are several fine programs that require neither to run admirably and well. And that for as much as I have experience with it, there's still plenty that I don't know and may never know. It's one of the places where I can have a growth mindset about myself, and I think it's one of the places where others can, as well, so I'd encourage you to dive in, in whatever way that you can. There will be gatekeeping jerks, there will be unhelpful StackOverflow answers, and sometimes the thing that's the best and most useful response for you will be a blog post from decades ago, but there is a certain satisfaction, at least for me, that comes from accomplishing a task through clever program use or even writing the script yourself and seeing the output that you wanted to have happen scroll by in the console. I am unlikely to claim that I'm good at any of this, but I could venture forth that I am at least semi-competent.