Frequently Answered Questions

Over-reliance on control key shortcuts: Nano uses control key shortcuts (Ctrl + letter) for basic operations like saving, exiting, or searching. While these shortcuts seem straightforward, they often overlap with critical terminal functions like Ctrl+C (interrupt) and Ctrl+S (pause/lock terminal output), causing confusion when beginners accidentally lock their terminal or interrupt running processes.

Limited Editing Features: Nano lacks advanced features that even basic vi provides, such as:

Encourages Dependency: Nano’s heavy reliance on displayed shortcuts can prevent users from internalizing commands, making them less adaptable to other tools.

Widely available:

Learn once, apply everywhere:

Encourages muscle memory:

By not relying on on-screen prompts, vi forces users to internalize commands quickly, building long-term proficiency and preserving terminal screen real-estate.

While nano’s simplicity might seem appealing at first, it ultimately hinders growth and can foster bad habits. Starting with vi, even at a basic level, sets a strong foundation for effective text editing. Vi’s ubiquity, efficiency, and transferable skills make it the better choice for beginners who want to build confidence and adaptability in the command line.

Modal editing: Vim’s modal nature separates editing, navigating, and selecting text into distinct modes. This allows for precise and fast text manipulation without needing to move your hands away from the keyboard.

Keyboard-driven workflow: Everything in Vim can be done without a mouse, significantly speeding up tasks for those accustomed to its commands.

Commands as composable primitives: Vim commands can be combined in intuitive ways (e.g., daw deletes a word, yap yanks a paragraph). This composability makes it exceptionally powerful for editing text.

Low resource usage: Vim is highly efficient, making it an excellent choice for older machines or resource-constrained environments.

Available everywhere: Vim comes pre-installed on almost all Unix-like systems, ensuring it’s accessible in nearly any server or terminal environment.

Highly configurable: Vim’s configuration through .vimrc (or init.lua for Neovim) allows users to create tailored environments for specific workflows.

Plugin ecosystem: Thousands of plugins extend Vim’s functionality, from language servers (LSP) for autocompletion and linting to themes like Gruvbox-Material for aesthetic improvements.

Scriptable: Vimscript or Lua (for Neovim) can be used to automate repetitive tasks or create custom commands.

Powerful search and replace: Vim’s regex-based search and replace (:%s/pattern/replacement/g) works across entire files or custom ranges.

Macros: Record and replay sequences of commands, making repetitive edits easy and consistent.

Versatility: Suitable for quick edits or complex projects, Vim adapts to any programming or text editing need.

Muscle memory: Learning Vim takes effort, but once mastered, it becomes second nature, allowing you to edit text faster than with GUI-based editors.

Fewer context switches: Vim can be embedded into many tools (e.g., Git, terminal multipliers like tmux), reducing the need to leave your environment.

Long history: Vim has been around for decades, and its continued evolution ensures it remains relevant.

Active community: An engaged user base and contributors produce a steady stream of tutorials, plugins, and updates.

In summary, Vim shines for users who prioritize speed, flexibility, and control over out-of-the-box features or visual interfaces. It excels in environments where efficiency and keyboard-driven workflows are paramount. While it has a steeper learning curve than other editors, the productivity payoff makes it a beloved tool for developers, sysadmins, and writers alike.

Vim is ubiquitous: Vim is pre-installed on virtually all Unix-like systems, including Linux distributions and macOS. It’s also commonly found on remote servers and even embedded systems. This ensures you can always access a familiar editing environment without needing to install anything extra.

.vimrc compatibility: The .vimrc file is recognized by all standard Vim installations. By sticking to .vimrc, you ensure your configurations work everywhere that Vim is available. Neovim can also read .vimrc, either natively or by sourcing it, making it possible to share your configuration between Vim and Neovim.

Avoids Neovim-specific features: Neovim introduces some features, such as Lua-based configuration, that are not compatible with standard Vim. While these can be powerful, they may lock you into using Neovim exclusively. By using .vimrc, you focus on features and plugins that work universally, avoiding incompatibilities on systems where only Vim is available.

Quick setup: If you frequently work on different machines or servers, having a portable .vimrc file that you can quickly copy or source makes it easier to get up and running. You can even store your .vimrc in a version-controlled repository (like GitHub), allowing you to fetch it quickly on any machine.

Immediate usability: With .vimrc, your configurations and workflows are immediately usable on systems with Vim pre-installed. No need to install Neovim or additional dependencies. This is particularly useful in environments like remote servers, where you may not have the permissions or the time to install Neovim.

Standard features: Vim and .vimrc cover the majority of use cases for editing, scripting, and navigating text. For someone who values speed and universality over cutting-edge features, .vimrc is often enough.

Remote work: If you SSH into servers or work on machines where you cannot control the software installed, Vim is more likely to be available, and your .vimrc will ensure a consistent editing environment.

Team environments: Some workplaces or collaborative environments may standardize on Vim instead of Neovim, making .vimrc the more practical choice. For example, it is common to have a bastion or jump host machine to get to other machines and only authentication from that system can be done for access to services such at Kubernetes.

Emergency situations: If you find yourself on a system without Neovim, being familiar with and having a .vimrc setup ensures you won’t lose productivity.

The best solution for most people is to combine both in a dual configuration that allows all the power of Neovim plugins when available and all the flexibility of a single .vimrc when not. In addition to .vimrc is a ~/.config/neovim/init.lua file with vim.cmd('source ~/.vimrc') to load the other main file. This way, you can enjoy Neovim’s advanced features when it’s installed while maintaining a universal configuration for Vim. Adding something like the following to ~/.bashrc ensures that the right vim is used:

Using .vimrc as your main configuration file provides the most flexibility and portability. It ensures you can work comfortably in almost any environment without needing to rely on Neovim-specific features. For someone who values a consistent workflow across systems, .vimrc is the pragmatic choice.

GitHub’s dominance in the market isn’t just a matter of numbers—it’s a testament to its value:

Largest Developer Community: With millions of active users and repositories, GitHub is the go-to platform for collaboration and discovery. The sheer size of its community means more opportunities for networking, learning, and contributing to meaningful projects.

Industry Standard: Most companies, open-source projects, and educational platforms use GitHub as their primary development hub. Knowledge of GitHub is often expected in job applications, making it a must-know platform for developers.

Searchability: GitHub’s advanced search tools make it easy to find projects, issues, and contributions, helping you discover opportunities and solutions faster.

Project Showcase: A GitHub profile serves as a portfolio, showcasing your work to potential employers, collaborators, and contributors. Public repositories on GitHub are more likely to be discovered and gain traction compared to other platforms.

Integration with Ecosystems: GitHub integrates seamlessly with countless third-party tools and services, from CI/CD pipelines to deployment platforms.

GitHub’s command-line tool, gh, offers unparalleled efficiency for developers who prefer working in the terminal:

Ease of Use: gh simplifies common tasks like creating issues, managing pull requests, and cloning repositories—all without leaving the command line.

Efficiency in Workflow: GitHub’s CLI provides shortcuts for managing projects and repositories directly, saving time and effort.

Advanced Features: Interactive features like viewing pull request details or switching between branches are intuitive and developer-focused.

GitLab: While GitLab offers powerful CI/CD features, its interface and community size don’t match GitHub’s. GitLab’s paid tiers are often necessary for features GitHub offers for free, like private repositories.

SourceHut: SourceHut appeals to minimalists but lacks the extensive features, integrations, and user base that GitHub provides.

Bitbucket: Popular for enterprise solutions, Bitbucket trails GitHub in open-source adoption and community engagement.

For some, Microsoft’s acquisition of GitHub in 2018 raised concerns. Many don’t know that Microsoft saved GitHub from catastrophic bankruptcy. However, Microsoft has largely honored its commitment to maintaining GitHub’s independence and focus on supporting open-source development.

Investment in Features: Since the acquisition, GitHub has introduced numerous improvements, including GitHub Actions, Codespaces, and enhanced security features.

Open-Source Support: GitHub remains home to the world’s largest collection of open-source projects, demonstrating its dedication to fostering community-driven development.

While alternatives like GitLab and SourceHut have their merits, GitHub’s unparalleled visibility, expansive community, and best-in-class tools make it the platform of choice for developers worldwide. Even for those wary of Microsoft’s involvement, GitHub’s contributions to open-source development and its continued innovation make it an essential part of any developer’s toolkit. Choosing GitHub means joining the largest, most active network of developers and setting yourself up for success in the modern software development ecosystem.

There are a tiny fraction of companies that sell computers that come with Linux, but usually they are as expensive as buying a Mac.

Within a two years I had a garage full of old computers given new life as Linux servers. I had to clean them and burn CDs with Linux OS on them. It took forever to set them up. In the process I was so anxious I put my servers online in a rush after I got my first domain (tuxzone.net). I got hacked immediately because I forgot to run the hardening software of the day. I was in too much of a hurry to give out free access to Linux so others could learn about it like Joey had done for me. I did manage to catch that hacker right away, however, by setting up Tripwire.

At work (Teleport Internet Services) I was given the most powerful workstation of anyone in the company (that wasn’t a Sun box) a Pentium II. Despite all the power it would not run any of the graphic Linux desktops. The best admins in the building, who creating an ISP couldn’t get it to work. It had the power, but—as is still the case—Linux desktop environments are just quirky and unstable, then and now.

People hate me for telling them the truth about Linux desktop. It’s horrible—even today—compared to the experience of a Macbook Pro or, yes, even a Windows machine. I’ve got more years of experience using all Linux DT environments than many people have been alive—including the most recent stuff.

Use the right tool for the job, and the right tool for the desktop is just not Linux and never has been. Perhaps someday, but I’ve heard people say that for nearly 30 years and it still hasn’t happened. Linux server is where it’s at, not the desktop.

My Linux lab saved my job during the crash of 2000. I took a SysAdmin job because of the skills I had learned managing Linux in my garage.

Coming soon …​

Coming soon …​

Coming soon …​

Coming soon …​

Coming soon …​

Coming soon …​

Coming soon …​

My first livestreams were from a Linux machine. Not many people could say they were streaming from Linux desktop in 2021. I was constantly fighting with one thing or another. Ultimately, I gave it up. The main reason: I value my time. Here’s why:

Coming soon …​

While testing it on Windows I noticed a bunch of [ showing up on the screen using the terminal the same was I have for more than 25 years. This turns out to be because Alacritty has a bug that does not observe the standard Control-[ as Esc. If nothing else were wrong this would be enough for me to never use it again.

Last week while working on this book and trying to standardize on Alacritty (eventually going with Wezterm instead). Alacritty crashed without explanation or error at least a dozen times. I wasn’t doing anything fancy. At least it was a good reminder why to write about tmux saving the day by being able to reattach after restarting.

I absolutely hate that Alacritty forces me to use TOML for configuration for now good reason at all even though it quietly supports YAML still.

(See Why Not TOML.)

Want to use your favorite emoji with the emoji picker on a Mac? Tough. Alacritty doesn’t support pasting them inline like every other terminal on the planet.

I abandoned Alacritty once already in 2021 when I realized that some of the terminal animation and coloring using popular ANSI escapes wasn’t supported. While I think that is supported now, the fact that it didn’t work and now Control-[ isn’t supported suggests the team is not too keen on supporting the actual ANSI standards. All the other major terminals definitely do.

I have waited most of my life for a proper terminal to support thin and think text in the same font. Alacritty doesn’t, most of the other modern ones do, including Windows Terminal Preview. That’s right, Windows Terminal Preview is better than Alacritty and every bit as fast.

It took using Wezterm for a day or two to realize just how much I was needlessly suffering with terminal display lag on Alacritty. With things like pop-up completion options and such that lag is noticeable and annoying. Such is simply not an issue in all the others. Alacritty can’t even compare and increasing speed on that level is not something Alacritty will ever be able to catch up with since it is a core implementation thing. They’d have to rewrite the entire engine.

TOML has no tools for dynamically altering it from a simple shell script like yq does for YAML. The yq tool will do some TOML in-place edits, but nothing fancy. I know a tool shouldn’t drive a structured data choice, but for me it does. Plus, can we just accept please that YAML has complete won at this point. (I cannot believe I liked TOML enough to make the logo. I really loathe it now.)

TOML was big with the Rust people for a while and still remains required for Cargo files.

The -T switch is so powerful, unknown and obscure. All it does it test that the file not only exists and is readable, but is also a text file. Such a simple thing, but I use it all the time. All by itself this is a reason to choose Perl over Bash for almost everything I do.

While awk remains a respected tool for lightweight text processing, it pales in comparison to Perl’s versatility and depth. Tasks that require multiple pipelines in awk can often be handled in a single Perl script.

For example, extracting and transforming data with awk:

In Perl, the equivalent is just as simple but far more extensible:

Perl’s unmatched supremacy in text processing makes it a natural companion to Vim or Neovim for advanced editing workflows. Its concise syntax, powerful regular expressions, and vast array of built-in text-manipulation tools allow users to quickly and efficiently transform content. Pairing Perl with Vim’s filter functionality (!!) creates a seamless editing experience: you can write transformations or scripts directly within your document, execute them by piping the content to the Perl interpreter, and replace the original text with the output—all without leaving your editor.

This workflow exemplifies the Unix philosophy of combining small, powerful tools to create robust solutions. By leveraging Perl’s flexibility and efficiency, you can perform anything from basic substitutions to complex data transformations inline. This eliminates the need for external preprocessing or postprocessing steps, making your editing environment not just a tool for writing but a dynamic, programmable text-processing powerhouse. For anyone serious about crafting or editing text at scale, the synergy between Perl and Vim offers unparalleled power and flexibility.

The idea that Perl is a "boomer language" is a complete misunderstanding of its power and relevance. While newer languages like Python have gained popularity, Perl remains the tool of choice for those who value:

Trends come and go, but Perl’s utility and efficiency have stood the test of time. When you need to process text on the command line, nothing matches Perl’s combination of power, flexibility, and ease of use.

So next time someone questions why you use Perl, just point them to this page and let them know: Perl is not just a tool—it’s a way of getting things done right the first time.

I’m not exactly sure why but I have always been absolutely obsessed with parsing text in every and any way possible. Sometimes I wonder if this is because I started with Perl for the beginning of my career for most significant stuff. Maybe it’s my affinity for syntax and spoken and written languages. Maybe all of that comes from other particular way my semi-autistic brain is wired. I love that stuff.

I’ve never actually made a compiler but I have made transpilers before. For some reason the compiler part doesn’t interest me. I’m all about finding the syntax of one thing and transforming it into something else. For example, writing this book in bash code and then transpiling it to an Excalidraw flow chart by implementing an AST parser for bash itself and interpreting it into API commands that generate the flow chart automatically. Now there’s a project I find so amazing I have a hard time not dropping everything and just working on that right now.

According to Ramesh, an Amazon Senior Tech Lead responsible for putting together engineering teams, here are the five main traits describing a SysDE:

Just reading that list fills me with glee. Finally, I feel seen! I have been doing exactly these things for 30 years and always felt uncomfortable with the titles that didn’t quite fit:

I’ve been renamed so many titles in my career it’s insane—usually while doing exactly the same thing. When I got an huge raise (if you include bonuses) they changed my title from Infrastructure Engineer to Senior Backend Systems Software Developer even though no one calls me that. At another employer I changed from IT Specialist to Software Engineer and got a $5000 raise (although now I realize just how much they low-balled me there).

Let me highlight the stuff I’ve worked on over the years, each thing is perfectly in the list of what a SysDE would be focused on doing:

The point is that these titles don’t seem to matter much—until they do. Not getting your title right on a resume or interview or even phone call with someone interested in you can automatically shut doors that lazy interviewers are too lazy to open to figure out what it is you really do.

All the Amazon job postings require mastery of "at least one modern programming language" which they list as the following:

A few of the postings did not include Rust or Java. None of them include Perl. All of they have Python and Go prominently listed, probably because all the modern automation and cloud-native tools are written in one of these two languages.

Perl, Python, Ruby, Bash, POSIX Shell, JavaScript, hell, even TCL for expect. A kick-ass SysDE can script in anything—on a Unix system.

A SysDE knows how to read and write any scripting language that exists. They might not be a specialist, and will forget a lot over time, but they can interpret anything that they might encounter or have to integrate.

SysDEs live for processing text since text is the language of integration and automation—because that is the Unix way. Since Perl is the undisputed leader in text processing—the reason it was created—it remains a dominant skill for all SysDEs. Parsing the same thing in Python or Ruby or Go is often painfully annoying when a SysDE is throwing together a proof-of-concept automation. A SysDE knows why using awk is just idiotic compared to perl and can articulate why.