command line

The Best Command-Line-Only Video Games

Bryan Lunduke — Wed, 07 Aug 2019 17:00:00 +0000

A rundown of the biggest, most expansive and impressive games that you can run entirely in your Linux shell.

The original UNIX operating system was created, in large part, to facilitate porting a video game to a different computer. And, without UNIX, we wouldn't have Linux, which means we owe the very existence of Linux to...video games.

It's crazy, but it's true.

With that in mind, and in celebration of all things shell/terminal/command line, I want to introduce some of the best video games that run entirely in a shell—no graphics, just ASCII jumping around the screen.

And, when I say "best", I mean the very best—the terminal games that really stand out above the rest.

Although these games may not be considered to have "modern fancy-pants graphics" (also known as MFPG—it's a technical term), they are fantastically fun. Some are big, sprawling adventures, and others are smaller time-wasters. Either way, none of them are terribly large (in terms of drive storage space), and they deserve a place on any Linux rig.

AsciiPatrol

AsciiPatrol is, in my opinion, one of the most impressive terminal games out there. A clone of the classic Moon Patrol, which is a ton of fun already, this terminal-based game provides surprisingly good visuals for a game using only ASCII characters for artwork.

It has color, parallax scrolling backgrounds, animated enemies, sound effects—I mean, even the opening screen is impressive looking in a terminal.

Figure 1. Shooting Aliens and Dodging Potholes in AsciiPatrol

For a quick round of arcade-style fun, this one really can't be beat.

Cataclysm: Dark Days Ahead

Cataclysm: Dark Days Ahead is absolutely huge in scale. Think of it as a top-down, rogue-like, survival game with zombies, monsters and real end-of-the-world-type stuff.

The game features a crafting system, bodily injuries (such as a broken arm), bionic implants, farming, building of structures and vehicles, a huge map (with destructible terrain)—this game is massive. The visuals may be incredibly simple, but the gameplay is deep and open-ended.

Figure 2. Running from zombies in Cataclysm

SSHTron

The Tron-inspired light-cycle games (and non-Tron-themed variants, such as Snake) have been a staple of gaming since the 1980s. And, SSHTron provides a four-player version right in your terminal.

Simply open your terminal and type in the following:

Go to Full Article

Arduino from the Command Line: Break Free from the GUI with Git and Vim!

Matthew Hoskins — Tue, 16 Jul 2019 11:30:00 +0000

by Matthew Hoskins

Love Arduino but hate the GUI? Try arduino-cli.

In this article, I explore a new tool released by the Arduino team that can free you from the existing Java-based Arduino graphical user interface. This allows developers to use their preferred tools and workflow. And perhaps more important, it'll enable easier and deeper innovation into the Arduino toolchain itself.

The Good-Old Days

When I started building hobby electronics projects with microprocessors in the 1990s, the process entailed a discrete processor, RAM, ROM and masses of glue logic chips connected together using a point-to-point or "wire wrapping" technique. (Look it up kids!) Programs were stored on glass-windowed EPROM chips that needed to be erased under UV light. All the tools were expensive and difficult to use, and development cycles were very slow. Figures 1–3 show some examples of my mid-1990s microprocessor projects with discrete CPU, RAM and ROM. Note: no Flash, no I/O, no DACs, no ADCs, no timers—all that means more chips!

Figure 1. Example Mid-1990s Microprocessor

Figure 2. Example Mid-1990s Microprocessor

Figure 3. Example Mid-1990s Microprocessor

It all changed in 2003 with Arduino.

The word "Arduino" often invokes a wide range of opinions and sometimes emotion. For many, it represents a very low bar to entry into the world of microcontrollers. This world before 2003 often required costly, obscure and closed-source development tools. Arduino has been a great equalizer, blowing the doors off the walled garden. Arduino now represents a huge ecosystem of hardware that speaks a (mostly) common language and eases transition from one hardware platform to another. Today, if you are a company that sells microcontrollers, it's in your best interest to get your dev boards working with Arduino. It offers a low-friction path to getting your products into lots of hands quickly.

It's also important to note that Arduino's simplicity does not inhibit digging deep into the microcontroller. Nothing stops you from directly twiddling registers and using advanced features. It does, however, decrease your portability between boards.

Go to Full Article

In the End Is the Command Line

Doc Searls — Wed, 03 Jul 2019 11:30:00 +0000

by Doc Searls

Times have changed every character but one in Neal Stephenson's classic. That one is Linux.

I was wandering through Kepler's, the legendary bookstore, sometime late in 1999, when I spotted a thin volume with a hard-to-read title on the new book table. In the Beginning...Was the Command Line, the cover said.

The command line was new to me when I started writing for Linux Journal in 1996. I hadn't come from UNIX or from programming. My tech background was in ham radio and broadcast engineering, and nearly all my hacking was on RF hardware. It wasn't a joke when I said the only code I knew was Morse. But I was amazed at how useful and necessary the command line was, and I was thrilled to see Neal Stephenson was the author of that book. (Pro tip: you can tell the commercial worth of an author by the size of his or her name on the cover. If it's bigger than the title of the book, the writer's a big deal. Literally.)

So I bought it, and then I read it in one sitting. You can do the same. In fact, I command that you do, if you haven't already, because (IMHO) it's the most classic book ever written about both the command line and Linux itself—a two-fer of the first order.

And I say this in full knowledge (having re-read the whole thing many times, which is easy, because it's short) that much of what it brings up and dwells on is stale in the extreme. The MacOS and the Be operating systems are long gone (and the Be computer was kind of dead on arrival), along with the Windows of that time. Today Apple's OS X is BSD at its core, while Microsoft produces lots of open-source code and contributes mightily to The Linux Foundation. Some of Neal's observations and complaints about computing and the culture of the time also have faded in relevance, although some remain enduringly right-on. (If you want to read a section-by-section critique of the thing, Garrett Birkel produced one in the mid-2000s with Neal's permission. But do read the book first.)

What's great about Command Line is how well it explains the original virtues of UNIX, and of Linux as the operating system making the most of it:

The file systems of Unix machines all have the same general structure. On your flimsy operating systems, you can create directories (folders) and give them names like Frodo or My Stuff and put them pretty much anywhere you like. But under Unix the highest level—the root—of the filesystem is always designated with the single character "/" and it always contains the same set of top-level directories:

Go to Full Article

The Command-Line Issue

Bryan Lunduke — Mon, 01 Jul 2019 15:00:00 +0000

by Bryan Lunduke

Summer. 1980-something. An elementary-school-attending, Knight Rider-T-Shirt-wearing version of myself slowly rolls out of bed and shuffles to the living room. There, nestled between an imposingly large potted plant and an over-stocked knick-knack shelf, rested a beautifully gray, metallic case powered by an Intel 80286 processor—with a glorious, 16-color EGA monitor resting atop.

This was to be my primary resting place for the remainder of the day: in front of the family computer.

That PC had no graphical user interface to speak of—no X Window System, no Microsoft Windows, no Macintosh Finder. There was just a simple command line—in this case, MS-DOS. (This was long before Linux became a thing.) Every task I wished to perform—executing a game, moving files—required me to type the commands in via a satisfyingly loud, clicky keyboard. No, "required" isn't the right word here. Using the computer was a joy. "Allowed" is the right word. I was allowed to enjoy typing those commands in. I never once resented that my computer needed to be interacted with via a keyboard. That is, after all, what computers do. That's what they're for—you type in commands, and the computer executes them for you, often with a "beep".

For a kid, this was empowering—taking my rudimentary understanding of language (aided, at first, by a handy DOS command cheat sheet) and weaving together strings of words that commanded the computer to do my bidding. It was like organizing runes to enact an ancient spell. It was magic. And I was a wizard. Did I miss not being able to "double click" or "drag and drop"? Of course not. I'd seen some such, mouse-driven user interfaces (like the early Macintoshes) but—from my vantage—that wasn't how computers really worked. I viewed such things as cool-looking, but not necessary. Computers use words. Powerful, magical words.

But this isn't 1980-something. In fact, it's barely 2010-something. (Did anyone else just realize that it's almost 2020?) For better or worse, how people use—and view—computers has changed dramatically since the days of Knight Rider. Modern operating systems are, often, belittled if they require users to interact with the machine via a command line. The graphical user interface is king. Which is, perhaps, the inevitable evolution of how we all interact with our computers.

Yet the value of the command line (or terminal, shell and so on) is still there. For many, it makes using computers more accessible. For others, it provides streamlined workflows that a mouse or touch-driven interface simply can't compete with. And, for others still, the blinking cursor provides a bit of nostalgic joy—or an aesthetically simple, and distraction free, environment.

This issue of Linux Journal celebrates the cursor—that wonderful blinking underscore and all the potential that it holds.

Go to Full Article

Without a GUI--How to Live Entirely in a Terminal

Bryan Lunduke — Fri, 28 Jun 2019 11:00:00 +0000

by Bryan Lunduke

Sure, it may be hard, but it is possible to give up graphical interfaces entirely—even in 2019.

About three years back, I attempted to live entirely on the command line for 30 days—no graphical interface, no X Server, just a big-old terminal and me, for a month.

I lasted all of ten days.

Why did I attempt this? What on Earth would compel a man to give up all the trappings and features of modern graphical desktops and, instead, artificially restrict himself to using nothing but text-based, command-line software, as if he were stuck in the early 1980s?

Who knows. Clearly, I make questionable decisions.

But you know, if I'm being honest, the experience was not entirely unpleasant. Sure, I missed certain niceties from the graphical side of things, but there were some distinct benefits to living in a shell. My computers, even the low-powered ones, felt faster (command-line software tends to be a whole lot lighter and leaner than those with a graphical user interface). Plus, I was able to focus and get more work done without all the distractions of a graphical desktop, which wasn't bad.

What follows are the applications I found myself relying upon the most during those fateful ten days, separated into categories. In some cases, these are applications I currently use over (or in addition to) their graphical equivalents.

Quite honestly, it is entirely possible to live completely without a GUI (more or less)—even today, in 2019. And, these applications make it possible—challenging, but possible.

Web Browsing

Plenty of command-line web browsers exist. The classic Lynx typically comes to mind, as does ELinks. Both are capable of browsing basic HTML websites just fine. In fact, the experience of doing so is rather enjoyable. Sure, most websites don't load properly in the "everything is a dynamically loading, JavaScript thingamadoodle" future we live in, but the ones that do load, load fast, and free of distractions, which makes reading them downright enjoyable.

But for me, personally, I recommend w3m.

Figure 1. Browsing Wikipedia with Inline Images Using w3m

w3m supports inline images (via installing the w3m-img package)—seriously, a web browser with image support, inside the terminal. The future is now.

It also makes filling out web forms easy—well, maybe not easy, but at least doable—by opening a configured text editor (such as nano or vim) for entering form text. It feels a little weird the first time you do it, but it's surprisingly intuitive.

Go to Full Article

FreeDOS's Linux Roots

Jim Hall — Thu, 27 Jun 2019 11:30:00 +0000

by Jim Hall

On June 29, 2019, the FreeDOS Project turns 25 years old. That's a major milestone for any open-source software project! In honor of this anniversary, Jim Hall shares this look at how FreeDOS got started and describes its Linux roots.

The Origins of FreeDOS

I've been involved with computers from an early age. In the late 1970s, my family bought an Apple II computer. It was here that I taught myself how to write programs in AppleSoft BASIC. These were not always simple programs. I quickly advanced from writing trivial "math quiz" programs to more complex "Dungeons and Dragons"-style adventure games, complete with graphics.

In the early 1980s, my parents replaced the Apple with an IBM Personal Computer running MS-DOS. Compared to the Apple, the PC had a much more powerful command line. You could connect simple utilities and commands to do more complex functions. I fell in love with DOS.

Throughout the 1980s and into the early 1990s, I considered myself a DOS "power user". I taught myself how to write programs in C and created new DOS command-line utilities that enhanced my MS-DOS experience. Some of my custom utilities merely reproduced the MS-DOS command line with a few extra features. Other programs added new functionality to my command-line experience.

I discovered Linux in 1993 and instantly recognized it as a Big Deal. Linux had a command line that was much more powerful than MS-DOS, and you could view the source code to study the Linux commands, fix bugs and add new features. I installed Linux on my computer, in a dual-boot configuration with MS-DOS. Since Linux didn't have the applications I needed as a working college student (a word processor to write class papers or a spreadsheet program to do physics lab analysis), I booted into MS-DOS to do much of my classwork and into Linux to do other things. I was moving to Linux, but I still relied on MS-DOS.

In 1994, I read articles in technology magazines saying that Microsoft planned to do away with MS-DOS soon. The next version of Windows would not use DOS. MS-DOS was on the way out. I'd already tried Windows 3, and I wasn't impressed. Windows was not great. And, running Windows would mean replacing the DOS applications that I used every day. I wanted to keep using DOS. I decided that the only way to keep DOS was to write my own. On June 29, 1994, I announced my plans on the Usenet discussion group comp.os.msdos.apps, and things took off from there:

ANNOUNCEMENT OF PD-DOS PROJECT:

A few months ago, I posted articles relating to starting a public domain version of DOS. The general support for this at the time was strong, and many people agreed with the statement, "start writing!" So, I have...

Go to Full Article

Text Processing in Rust

Mihalis Tsoukalos — Mon, 18 Mar 2019 13:07:07 +0000

by Mihalis Tsoukalos

Create handy command-line utilities in Rust.

This article is about text processing in Rust, but it also contains a quick introduction to pattern matching, which can be very handy when working with text.

Strings are a huge subject in Rust, which can be easily realized by the fact that Rust has two data types for representing strings as well as support for macros for formatting strings. However, all of this also proves how powerful Rust is in string and text processing.

Apart from covering some theoretical topics, this article shows how to develop some handy yet easy-to-implement command-line utilities that let you work with plain-text files. If you have the time, it'd be great to experiment with the Rust code presented here, and maybe develop your own utilities.

Rust and Text

Rust supports two data types for working with strings: String and str. The String type is for working with mutable strings that belong to you, and it has length and a capacity property. On the other hand, the str type is for working with immutable strings that you want to pass around. You most likely will see an str variable be used as &str. Put simply, an str variable is accessed as a reference to some UTF-8 data. An str variable is usually called a "string slice" or, even simpler, a "slice". Due to its nature, you can't add and remove any data from an existing str variable. Moreover, if you try to call the capacity() function on an &str variable, you'll get an error message similar to the following:


error[E0599]: no method named `capacity` found for type
 ↪`&str` in the current scope

Generally speaking, you'll want to use an str when you want to pass a string as a function parameter or when you want to have a read-only version of a string, and then use a String variable when you want to have a mutable string that you want to own.

The good thing is that a function that accepts &str parameters can also accept String parameters. (You'll see such an example in the basicOps.rs program presented later in this article.) Additionally, Rust supports the char type, which is for representing single Unicode characters, as well as string literals, which are strings that begin and end with double quotes.

Finally, Rust supports what is called a byte string. You can define a new byte string as follows:

Go to Full Article

Command-Line Tip: Put Down the Pipe

Kyle Rankin — Tue, 22 Jan 2019 12:30:00 +0000

by Kyle Rankin

Learn a few techniques for avoiding the pipe and making your command-line commands more efficient.

Anyone who uses the command line would acknowledge how powerful the pipe is. Because of the pipe, you can take the output from one command and feed it to another command as input. What's more, you can chain one command after another until you have exactly the output you want.

Pipes are powerful, but people also tend to overuse them. Although it's not necessarily wrong to do so, and it may not even be less efficient, it does make your commands more complicated. More important though, it also wastes keystrokes! Here I highlight a few examples where pipes are commonly used but aren't necessary.

Stop Putting Your Cat in Your Pipe

One of the most common overuses of the pipe is in conjunction with cat. The cat command concatenates multiple files from input into a single output, but it has become the overworked workhorse for piped commands. You often will find people using cat just to output the contents of a single file so they can feed it into a pipe. Here's the most common example:


cat file | grep "foo"

Far too often, if people want to find out whether a file contains a particular pattern, they'll cat the file piped into a grep command. This works, but grep can take a filename as an argument directly, so you can replace the above command with:


grep "foo" file

The next most common overuse of cat is when you want to sort the output from one or more files:


cat file1 file2 | sort | uniq

Like with grep, sort supports multiple files as arguments, so you can replace the above with:


sort file1 file2 | uniq

In general, every time you find yourself catting a file into a pipe, re-examine the piped command and see whether it can accept files directly as input first either as direct arguments or as STDIN redirection. For instance, both sort and grep can accept files as arguments as you saw earlier, but if they couldn't, you could achieve the same thing with redirection:


sort < file1 file2 | uniq
grep "foo" < file

Remove Files without xargs

The xargs command is very powerful on the command line—in particular, when piped to from the find command. Often you'll use the find command to pick out files that have a certain criteria. Once you have identified those files, you naturally want to pipe that output to some command to operate on them. What you'll eventually discover is that commands often have upper limits on the number of arguments they can accept.

Go to Full Article

Back to Basics: Sort and Uniq

Kyle Rankin — Tue, 08 Jan 2019 13:00:00 +0000

by Kyle Rankin

Learn the fundamentals of sorting and de-duplicating text on the command line.

If you've been using the command line for a long time, it's easy to take the commands you use every day for granted. But, if you're new to the Linux command line, there are several commands that make your life easier that you may not stumble upon automatically. In this article, I cover the basics of two commands that are essential in anyone's arsenal: sort and uniq.

The sort command does exactly what it says: it takes text data as input and outputs sorted data. There are many scenarios on the command line when you may need to sort output, such as the output from a command that doesn't offer sorting options of its own (or the sort arguments are obscure enough that you just use the sort command instead). In other cases, you may have a text file full of data (perhaps generated with some other script), and you need a quick way to view it in a sorted form.

Let's start with a file named "test" that contains three lines:


Foo
Bar
Baz

sort can operate either on STDIN redirection, the input from a pipe, or, in the case of a file, you also can just specify the file on the command. So, the three following commands all accomplish the same thing:


cat test | sort
sort < test
sort test

And the output that you get from all of these commands is:


Bar
Baz
Foo

Sorting Numerical Output

Now, let's complicate the file by adding three more lines:


Foo
Bar
Baz
1. ZZZ
2. YYY
11. XXX

If you run one of the above sort commands again, this time, you'll see different output:


11. XXX
1. ZZZ
2. YYY
Bar
Baz
Foo

This is likely not the output you wanted, but it points out an important fact about sort. By default, it sorts alphabetically, not numerically. This means that a line that starts with "11." is sorted above a line that starts with "1.", and all of the lines that start with numbers are sorted above lines that start with letters.

To sort numerically, pass sort the -n option:


sort -n test

Bar
Baz
Foo
1. ZZZ
2. YYY
11. XXX

Find the Largest Directories on a Filesystem

Numerical sorting comes in handy for a lot of command-line output—in particular, when your command contains a tally of some kind, and you want to see the largest or smallest in the tally. For instance, if you want to find out what files are using the most space in a particular directory and you want to dig down recursively, you would run a command like this:

Go to Full Article

Schedule One-Time Commands with the UNIX at Tool

Kyle Rankin — Mon, 19 Nov 2018 12:30:00 +0000

by Kyle Rankin

Cron is nice and all, but don't forget about its cousin at.

When I first started using Linux, it was like being tossed into the deep end of the UNIX pool. You were expected to use the command line heavily along with all the standard utilities and services that came with your distribution. At lot has changed since then, and nowadays, you can use a standard Linux desktop without ever having to open a terminal or use old UNIX services. Even as a sysadmin, these days, you often are a few layers of abstraction above some of these core services.

I say all of this to point out that for us old-timers, it's easy to take for granted that everyone around us innately knows about all the command-line tools we use. Yet, even though I've been using Linux for 20 years, I still learn about new (to me) command-line tools all the time. In this "Back to Basics" article series, I plan to cover some of the command-line tools that those new to Linux may never have used before. For those of you who are more advanced, I'll spread out this series, so you can expect future articles to be more technical. In this article, I describe how to use the at utility to schedule jobs to run at a later date.

`at` vs. Cron

at is one of those commands that isn't discussed very much. When people talk about scheduling commands, typically cron gets the most coverage. Cron allows you to schedule commands to be run on a periodic basis. With cron, you can run a command as frequently as every minute or as seldom as once a day, week, month or even year. You also can define more sophisticated rules, so commands run, for example, every five minutes, every weekday, every other hour and many other combinations. System administrators sometimes will use cron to schedule a local script to collect metrics every minute or to schedule backups.

On the other hand, although the at command also allows you to schedule commands, it serves a completely different purpose from cron. While cron lets you schedule commands to run periodically, at lets you schedule commands that run only once at a particular time in the future. This means that at fills a different and usually more immediate need from cron.

Using `at`

At one point, the at command came standard on most Linux distributions, but these days, even on servers, you may find yourself having to install the at package explicitly. Once installed, the easiest way to use at is to type it on the command line followed by the time you want the command to run:


$ at 18:00

The at command also can accept a number of different time formats. For instance, it understands AM and PM as well as words like "tomorrow", so you could replace the above command with the identical:

Go to Full Article

command line

The Best Command-Line-Only Video Games

AsciiPatrol

Cataclysm: Dark Days Ahead

SSHTron

Arduino from the Command Line: Break Free from the GUI with Git and Vim!

The Good-Old Days

In the End Is the Command Line

The Command-Line Issue

Without a GUI--How to Live Entirely in a Terminal

Web Browsing

FreeDOS's Linux Roots

The Origins of FreeDOS

Text Processing in Rust

Rust and Text

Command-Line Tip: Put Down the Pipe

Stop Putting Your Cat in Your Pipe

Remove Files without xargs

Back to Basics: Sort and Uniq

Sorting Numerical Output

Find the Largest Directories on a Filesystem

Schedule One-Time Commands with the UNIX at Tool

at vs. Cron

Using at

`at` vs. Cron

Using `at`