\nEnd of the Sample

Here’s a teaser of the rest of what’s available in the full book currently:

Version Control for your dotfiles
Automating Environment Setup
Editors and IDEs: Choosing and Customizing
Picking an Operating System\n
- macOS, the Safe Option
- Ubuntu: Beginner-Friendly and Stable
- Arch Linux: Minimal, Always Up to Date
\n
Terminal Emulators
Command-line Productivity

",{"_171":172,"_43":44,"_47":48,"_45":46,"_65":66,"_173":174,"_194":169},"previewContent","

\n Preface\n
- \n The Pitch\n
- \n Who is This Book For?\n
  - \n What Technologies are Covered?\n
  \n
- \n How to Read This Book\n
- \n About the Author\n
- \n What to Expect from this Book\n
- \n Conventions Used\n
\n
\n Appetizer\n
- \n Identifying your Motivation\n
- \n Mindfulness Applies Everywhere\n
- \n Supercharging your Shell\n
  - \n What’s a Shell?\n
  - \n What’s a Shell Alias?\n
  - \n Persisting Aliases\n
  - \n When Aliases are Not Enough\n
  - \n Aliases: A Case-Study\n
  - \n Also Try\n
  \n
- \n End of the Sample\n
\n

\nPreface

\n\n

\nThe Pitch

\n\n

Maybe you’ve worked with them. Maybe you saw them in a hacker (or Hackers)\nmovie. You know the type. Fingers flying on the keyboard, weird UI on the\nscreen that doesn’t look like yours at all, windows showing up for seconds,\nalways filling the whole screen, always showing the right information. Always\nthe right tool at hand, every action a shortcut, every command an alias,\nalways doing just the right thing. Idea to shell to editor to shell to passing tests\nin seconds, faster than the untrained eye can follow.

\n\n

From the outside, it just looks like that person is typing really fast – and\nthey probably are. It may feel like they’re just more experienced – and they\nmight well be. But that’s not the real source of magic. The real power comes\nfrom a toolbox that has the right tool for whatever you want to accomplish.\nWhere each tool is sharpened to an edge that can split a TCP stream in two.\nThere’s no need to think about where each tool is, or how to use it, because of\nplain old practice. Just like the guitarist of your favorite band doesn’t\nconsciously think about where to put their finger for that next chord, you\nshouldn’t need to think about whether to use sed or ngrep. After a point, it\nbecomes muscle memory.

\n\n

Not to mention: if you know what you want to do exactly, you have an easier\ntime finding the right tool. If you have a variety of tools, you have an easier\ntime pattern-matching and realizing what exactly it is you want to do. It’s a\nvirtuous cycle.

\n\n

That’s what a customized development environment feels and looks like, at its\nbest. At its worst, it’s fighting obscure bugs and weird systems. It’s finding a\nbug tracker showing your exact problem as WONTFIX from six years ago.\nSomewhere in the middle is research, hard work, mindfulness, a special mindset,\nhard work, obsession with details, lots of learning, and some more work – though\nthe work feels more like play.

\n\n

This book aims to show you a path that leads to the good parts, without\ngetting bogged down in the bad parts, no matter how much time you have to\ninvest. At its core, putting in the effort to improve your development\nenvironment is spending time you can spare, to be more efficient when you don’t have any\ntime to spare (say, when fixing an outage). Even when you’re not in a crisis,\neffortlessly and efficiently using your tools cuts down on context switches,\nhelping you stay in the flow.

\n\n\n\n

It’s a frustrating, joyous, fumbling, exciting journey through blogs, bug\ntrackers, manuals and, dotfiles. I’m glad you joined the trip.

\n\n

\nWho is This Book For?

\n\n

You’ll get the most out of this book if you’re motivated to work in that magical\nway, and are ready to improve the way you use your development environment to\nthat end, but didn’t yet put in a lot of time towards getting there. You’re\nready to jump in with both feet – this book is your diving board. You’re in the\nright place.

\n\n\n\n\n

Maybe you are motivated, but don’t have the time to pore through all the man\npages and years of forum posts to figure it all out. You can expect some quick\nwins and techniques you can implement right away, as well as warning signs on\ntime-sinks to avoid. This will be your cookbook.

\n\n

But maybe you’re on the fence about whether spending time on improving your devenv\nis worth it. Again, the quick wins and time-sink warning signs should be\nuseful. But more importantly, you’ll also be able to get a feel for the\njourney – if you get a taste for it, you can always dive deeper. If not, take\nthe quick wins. Either way, I’m happy for you.

\n\n

Or maybe you already went down the rabbit hole, and write Elisp code to make\nEmacs send birthday reminders to your family using the MTA you run on your VPS.\nFor you, this book may help you organize your knowledge. It may point out\nblind spots, open new avenues of research, show new perspectives and approaches.

\n\n

\nWhat Technologies are Covered?

\n\n

I must also mention what technologies you can expect to see here. The biggest\ndivide is across the axis of operating systems. The primary focus of the content\nis Linux, and macOS (you may know it as OSX). With minor exceptions, the same\ntechniques and technologies apply to BSD as well – but if you’re using BSD, I\ndon’t need to tell you where that breaks down.

\n\n

If you develop on Windows, and for Windows, and you’ll only ever touch Windows,\nthen I’ll be straight with you: there will be biggish chunks of content not\ndirectly applicable to your environment. You’ll still learn some ways of\nthinking that you can apply, and get ideas on what to start looking for, but\nmuch of the hands-on content will be irrelevant. In case you’re wondering, yes,\nI’m open and totally willing to add that Windows-specific content you were about\nto send to abesto0@gmail.com.

\n\n

\nHow to Read This Book

\n\n

While you can certainly read most of this book on an e-book reader, there are a\nlot of code snippets and screenshots that are going to be way less colorful.\nYou’ll definitely want to check at least those parts out on your computer.\nIdeally on the one where you’re tweaking your development environment, for easy\ncopy-pasting of snippets. Going further, I strongly encourage you to download\nthe PDF version for reading on a computer. While easy to quickly check something\nout, reading online (with the LeanPub app)

\n\n

will not serve you well.

\n\n

I encourage you to read the next chapter, “Appetizer”, straight through. It\nintroduces some basic concepts, and provides a taste for the kind of wins you\ncan get by tweaking your environment.

\n\n

For the “Main course”, reading back to front is perfectly fine as well. Some sections build on each other – for instance, we evaluate terminal emulators\nfirst, then talk about choosing a shell to run in that terminal emulator. If any\nof the sections are not relevant for you, or if one of them seem especially\nexciting, feel free to skip around. You won’t miss anything. If you do jump\naround, make sure to check out the two Interludes – they provide ways of working\nthat are useful across any part of your development environment.

\n\n

“Dessert” contains deep dives, tips, and extra-geeky ideas you can try out. Who\nknows, maybe some of them will click for you. There’s little to no connection\nbetween the topics covered here, feel free to choose and pick the ones that look\nexciting. You may still want to skim through them all, just to get a picture of\nwhat’s out there.

\n\n

\nAbout the Author

\n\n

As cheesy as it sounds, a development environment is a highly personal thing.\nEspecially so if you invest time and effort to customize it, to make it really\nyours – which is exactly what this book is for. That means it makes sense for us\nto get to know each other a bit before diving in. I hope knowing where I’m\ncoming from will also help put some of my opinions and conclusions in context.\nThey may not always make sense for you – and that’s alright!

\n\n

One of my axioms (values?) is never to waste anyone’s time. I’m not very\naltruistic about it, that also includes my own. I get annoyed when\nI – or anyone – needs to spend more time doing something than they’d strictly\nhave to, in an ideal world. So far, that’s not unique.

\n\n

Where it gets weird is what I think about how much time things should take in an\nideal world. It usually depends on how often you do something. For something\nthat’s as common as opening a terminal, cd-ing or whatever to your project,\nand starting its unit tests? I want that whole thing to take somewhere around 2\nseconds tops. Switching to documentation / editor / e-mail? O(1), a single\nshortcut. It shouldn’t matter how many windows you have open.

\n\n

I’m most at home with tooling, infrastructure, Linux, and backend code, but I\ntinker with a lot of software things. I learned monads. Three times. Know them?\nHell no. But there’s just something inherently fun in taking a piece of\ntechnology, learning it, then bending it as far as it will go. Wonder if I can\nmake React talk to that Bacon.js stream? Speaking of JS, how does Emacs handle\nJS embedded in HTML? React DOM elements in JS embedded in HTML? How about a\nscript tag in a React DOM element in JS embedded in HTML? Will that break syntax\nhighlighting? How about in Vim?

\n\n

A big chunk of that tinkering necessarily went into the development environment\nitself. Let’s see if I can give you the result of that tinkering, without you\nneeding to spend the same hours – after all, we all hate wasted time.

\n\n

\nWhat to Expect from this Book

\n\n

I’ll do my best to make all these weird tweaks accessible, quick to implement,\nand quick to learn. This does not mean that this book will let you sit down,\nspend thirty minutes reading the chapter on Vim, and be a Vim expert. We’ll\ncover many diverse fields that are deep in themselves. This book scratches the\nsurface of these areas, explores why and how you may want to incorporate them\ninto your workflow, and then provides pointers on diving deep, if you want to\ndive deep.

\n\n

Don’t expect yourself to dive deep into all those topics. Any one of them can\ntake months, if not years, of your free time, if you choose to spend your time\nthere. Staying with the easy-to-use example of editors and IDEs, there’s no\npoint to mastering five different flavors of Vim and Emacs and three IDEs. You\ncan do it, if that’s your idea of fun (it is mine). You may have to do it in\nsome very specific lines of work, but otherwise just invest enough time so you\ncan make an educated decision, and go with it. Each chapter ends with an “In a\nHurry?” section with my personal recommendation, so you don’t even need to do\nthat if you don’t want to. Even so, I recommend skimming all the sections, just\nto get a taster of what’s out there.

\n\n

Once again: you don’t have to learn all this stuff. Take what’s useful, leave\nthe rest, maybe look it up when it becomes useful because your work changes. My\nbackground is in infrastructure, the cloud, and distributed systems, and my perspective on\nwhat’s useful is heavily influenced by this. Don’t take my word for it. Evaluate\nit for yourself.

\n\n

All this takes time. Why would you invest that time? There’s a simple way to\nmake that decision: do you expect the time you invest to make a positive return\non investment, during your developer lifetime? If yes, it’s probably a good\ninvestment to make. To make that call, you’ll need understand where you could be\ninvesting time. A good rule of thumb is that you should first sharpen the tool\nyou use the most.

\n\n

Another reason to invest time may be that it’s fun. I get a feeling of\nsatisfaction when the whole system works exactly like it should, after tweaking\nit for hours. “Like it should” is absolutely subjective – I can give you my list\nof shell aliases, and they’ll annoy you. Because they’re not solving a problem\nyou have, in a way that makes sense to you. So instead, I’ll show you why and\nhow you may want to create your own aliases. Realize that the development\nenvironment you’re using is made of the same stuff that you work on day to day.\nIt’s software, it’s code. You can understand it, you can tweak it, you can\nchange it – especially if it’s well designed.

\n\n

Finally, let’s tackle a topic that comes up a lot when discussing this\nkind of development environment tweaking. It seems there is a correlation\nbetween how customized ones environment is, and how efficient an engineer they\nare in general. I think this works in a number of ways. Obviously, if your\nenvironment helps you more than my environment helps me, then you can work\nfaster than me. This book contains many specific snippets, and quick techniques to build your\nown customizations, so you can reap this benefit without spending years to dive\ndeep into everything. But that seems to not explain all the effects we’re seeing.

\n\n

During the course of working on your environment, you learn a lot – you pick up\nlexical knowledge of how the components you’re touching work. Over time this can\ngalvanize into an intuitive understanding of these kinds of systems, leading\nto sentences like “I expect this to work like X, and I can test this by\nperforming experiment Y”. The Main Course of this book provides some of that lexical knowledge on\njust-in-time basis. The Dessert chapters at the discuss some of the topics\ntouched upon in more depth than is strictly needed for tweaking your development\nenvironment. This is most useful if your development environment share\ncomponents with your actual work items, like if you both work on a Linux desktop\nand manage Linux servers. If that’s not the case, some of that knowledge is\nuseful just to understand your own desktop. I also expect that at least some\nof this knowledge and intuition transfers into other areas, but we’re getting to\nrather shaky ground here.

\n\n

Even more importantly, your development environment is a great training course\nfor software development in general. You get to explore your own requirements in\ndepth. You get to understand how the existing tools solve those requirements,\nand then you get to make changes to said tools, so that they better solve the\nrequirements. Most importantly, you hit bugs and problems, and you fix them.\nThis loop of identifying a requirement or problem, debugging it, learning as you\ngo, and finally fixing the problem, builds a habit of fixing stuff. It teaches\nyou that you can fix everything; there’s always a bigger hammer. Your own\ndevelopment environment provides visceral feedback, and iterations tend to be\nshort – much shorter than any kind of project work. You make a change, maybe\nrestart an application, and boom, it’s in production. Make sure to use virtual\nor test environments for experiments though!

\n\n

The conviction that the complex and weird behavior you’re seeing is something\nyou can fix translates into any kind of software engineering. Unfortunately this\nbook can’t do this part for you – you need to make your own mistakes, debug\nthem, and fix them. The point here is not to have the problem fixed – it’s to\nhave fixed the problem. The best we can do here is give you the lexical\nknowledge so you know where to start debugging. Or at least, know what to break\nin the first place.

\n\n

However! Messing around with your development environment is not the only way\nto gain that confidence for fixing problems. It is not the way to becoming a\ngreat engineer. Spending hours and months and years tweaking your development\nenvironment, making new mistakes and learning new things, seems to “cause” good\nsoftware engineering skills. But there are other ways to get there. I’m not\nsaying this is even the right way, I’m saying it’s one way. And it’s the one\njourney this book takes you on.

\n\n

\nConventions Used

\n\n\n\n\n\n\n\n\n\n

Capitalization of names of software follows the most standard way I can find -\nthis is usually the way the name appears on the website and documentation of the\nsoftware in question: tmux, GNU Screen, Bash.

\n\n

When mentioned in the context of a command to run from the command-line,\nsoftware names are in monospace, and capitalization follows the name of the\nexecutable: tmux, screen, bash.

\n\n

The string “development environment” tends to come up a lot when talking about,\nyou know, how to build a great development environment. To make sentences\nshorter and more comprehensible, the string “devenv” will usually be used instead\nof the long form “development environment”.

\n\n

class CodeExamples:\n   \"Look like this, obviously\"\n   def run(self):\n       print('With syntax highlighting, when appropriate')\n

\n\n\n\n

$ echo 'Interactive shell sessions always include the prompt'\nInteractive shell sessions always include the prompt\n$ echo -e 'To separate the command\\nfrom the output\\nLike this\\n\\n'\nTo separate the command\nfrom the output\nLike this\n\n\n$\n

\n\n\n\n

# Some longer sections designed for copy-pasting into a terminal\necho 'are formatted like this, with no prompts'\necho 'so that you can really just take the whole thing and paste it into your shell'\n

\n\n\n\n\n\n

\nAppetizer

\n\n

In this chapter we’ll first look at the philosophy behind all the customizations\nand optimizations we’ll do later on. We’ll also take a detour into philosophy,\nand look at a few specific techniques you can start applying today without\nup-front investment. Finally, we’ll touch on how to make sure you don’t need to\nfind the same tutorial more than once.

\n\n

\nIdentifying your Motivation

\n\n

Different people will have different reasons for optimizing a development\nenvironment. One thing’s for sure: whatever the first links in the causal chain,\nthe last item is always “therefore, I want to reduce the friction of my\ndevelopment environment”. Put it differently: I want to do my work more quickly,\nfight less with the environment. I want to make the environment support my\nworkflow, as opposed to changing my workflow to suit the workflow of the tools\nat hand.

\n\n

Unfortunately, as they say, there are no free lunches. Just as energy doesn’t\ncome from nothing, that speed improvement, that time saving, also needs to come\nfrom somewhere. You can think of it as the law of conservation of development\ntime. Or maybe it’s really just conservation of energy – put in energy to\nimprove your environment, and you’ll need to spend less energy later to do your work.

\n\n

Either way, there’s a critical realization hiding here. In terms of invested\nenergy, your development environment is a bit like a savings account – you can put in energy\nnow, and realize the saved time days, or weeks, or months later. Better yet, any\nimprovement you make keeps on giving. It doesn’t run out.

\n\n

What also helps is that all time is not made equal. You have your work-time and\nfree-time, obviously, but there’s also crunch-time, off-time, tea-time,\noutage-fixing-time, hacking time, time for side projects, time for cooking, and\ntime for sleeping. The art of improving your development environment is founded\non finding time you can spare (be that off-time, hacking time, or sleep time)\nand investing that so that you can be more efficient when time is at a premium\n(like recovering from an outage).

\n\n\n\n

Remember to have fun as well. Since you’re doing this in time you can spare,\nit’s OK to go down more rabbit holes than usual. No need to justify it, just let\ngo and geek out!

\n\n

So fine, good, we say we want to do work more efficiently when we’re low on\ntime. What does that look like? For one, it means minimizing mental context\nswitches. Every time you need to think about how to accomplish what you want,\nyou experience a micro-context switch. You go from “I want to know which\nserver is generating error logs” to “is the server name field 3 or field 4 in\nthe access logs?”. You go from “I want to rename this function” to “does this\nIDE properly refactor this language?”

\n\n

A related, but not equivalent, idea is staying in the flow. Context switches\nobviously kill flow, but so does the wrong kind of frustration. A problem needs\nto be challenging enough for you to stay in the flow, but the half-second input\nlag of your terminal should not be that challenge. Conversely, there’s a\nsatisfaction to the well-choreographed dance of meet problem – deploy right tool – meet next\nproblem – deploy the next right tool – meet next problem.

\n\n

All that is a long way of saying: we want to minimize the time and number of actions\nneeded to get from “I know exactly what I want to do” to “what I wanted to do\nhas happened”. Note that this does not solve the problem of “I\ndon’t exactly know what I want to do”. Only analyzing the problem and examining\nthe available tools can do that. Having a wide array of tools ready to use\ndefinitely helps, though.

\n\n

When you know what you want, but not how to get there, having more efficient\ntools can also help. Imagine you can think of five ways to refactor a piece of\ncode. The refactorings are not conceptually hard, but they need a lot of code to\nbe moved around. If your IDE can do most of that work in a few clicks, you’re\nquite likely to try all five ways, and choose the one that’s actually the\ncleanest one. Similarly, you might try all of them if you’re extremely efficient\nin using the text editing functions of your IDE or editor. But you’re quite\nlikely to call “good enough” after the second one if each refactoring takes an\nhour, because your tools don’t support you.

\n\n

\nMindfulness Applies Everywhere

\n\n

Let’s talk a bit about a soft, squishy topic before jumping into our first\nhard tech discussion.

\n\n

According to Wikipedia, mindfulness\n“is the psychological process of bringing one’s attention to the internal and\nexternal experiences occurring in the present moment”. Mindfulness meditation is\ntraditionally practiced sitting down, eyes closed, focusing on the breathing.\nFor me personally, it didn’t change my life, but if nothing else, it’s a\nfascinating experience.

\n\n

In the context of software development, and improving your development\nenvironment, this is the very first step to take: to notice what can be\nimproved. There are broad strokes that are true for any developer, but to make\nyourself really efficient, you need to become conscious of your own habits and\npractices, and make those practices flow smoothly in your environment.

\n\n

Of course the traditional practice of sitting eyes closed, hands in your laps\ndoesn’t mesh well with paying attention to your development process. Not all\nmeditation needs to be done like that, though. There’s walking meditation,\nrunning meditation, even meditation while doing repetitive power exercises.\nBut coding meditation is not something I’ve read or heard about – maybe flow\nis a bit like that.

\n\n

Either way, we don’t need to get stuck on the practice of meditation – the\nconcept of mindfulness, of paying attention to internal and external processes,\nis useful in itself, and we can build our own practice around it.

\n\n\n\n

That’s a structured, somewhat forced way of experiencing what it feels like to\npay attention to your workflow, the interaction of yourself and your development\nenvironment. Strive for a habit of continually noting opportunities for\nimprovement. Usually you shouldn’t break your flow to fix them, but do make sure\nyou know what they were once you have the time. Personally, I collect my\nissues on GitHub, at https://github.com/abesto/ansible-devenv/issues.

\n\n

After noting down the issues, the next step is of course to go ahead and fix\nthem. Generally, this should be an iterative improvement – tweaking a bit here,\nadding an argument there, installing a package, changing a configuration option.\nThere will be times for big changes, designing, researching, and planning\nthough – especially when you first set out to make your development environment\ntruly your own. The next section, “Main course”, will take you through some of those big\nchanges. Before that though, let’s take a look at a specific change you can\nstart implementing today, iteratively.

\n\n\n\n

\nSupercharging your Shell

\n\n

Shell aliases are one of the easiest, quickest, most ubiquitous ways to sharpen\nyour devenv. Let’s first unpack what a “shell alias” is.

\n\n

\nWhat’s a Shell?

\n\n

Strictly speaking, a shell is any piece of software built with the intention of\nallowing access to functions of an operating system. The command prompt of\nMS-DOS is a shell, Windows 3.1 is another shell, and Bash is also a shell.\nHowever, in daily use, we don’t usually refer to graphical interfaces as\nshells – that word is reserved for text-based “shells” using a CLI (command-line\ninterface). That’s also what “shell” will mean in the rest of this book.

\n\n

Shells have, without exception, two modes of operation: an interactive, and a\nbatch mode. If you know of an exception, let me know – I love esoteric software.\nInteractive mode is what everyone who’s ever seen a terminal knows: you have a\nprompt at the left-hand side with some information about the state of the\nsystem and shell. It might look something like this:

\n\n

[username@hostname]$\n

\n\n\n\n

This is followed by the area where commands are entered\n(usually one line at a time). Once a command is finished, the output is printed,\nthen the prompt again, and on and on it goes. In code listings of showing shell\nsessions, the prompt will be just the character $. Unless otherwise indicated,\nthe shell used is Bash version 4.3.

\n\n

On the other hand, batch mode is about capturing a series of commands to\nexecute in a script, and running them at once – in a batch. These scripts are\ncalled shell scripts (except for Windows, where they’re called batch scripts).\nAt their simplest, they’re just a series of commands to run, one after the\nother. For example, this is how you’d create a directory, create a file inside\nit, then delete the directory, in an interactive shell:

\n\n

$ mkdir -v awesome-dir\nmkdir: created directory 'awesome-dir'\n$ touch awesome-dir/awesome-file\n$ rm -rv awesome-dir\nremoved 'awesome-dir/awesome-file'\nremoved directory 'awesome-dir'\n

\n\n\n\n

Now we can create a file called awesome-script.sh with the following contents:

\n\n

mkdir -v awesome-dir\ntouch awesome-dir/awesome-file\nrm -rv awesome-dir\n

\n\n\n\n

These are exactly the commands issued above in the interactive shell session.\nWhen we run the script, we get:

\n\n

$ bash awesome-script.sh\nmkdir: created directory 'awesome-dir'\nremoved 'awesome-dir/awesome-file'\nremoved directory 'awesome-dir'\n

\n\n\n\n

That’s exactly the output we got above, without the interleaved prompts.\nCreating shell scripts is a way of automating repetitive work, especially useful\nwhen that work is error-prone. We’ll look at constructs and practices making\nthat as painless as possible in the chapter dedicated to\ncommand-line productivity. For now, let’s focus on ways of making the interactive mode of\noperation easier, without diving deep into hard-core shell scripting.

\n\n

\nWhat’s a Shell Alias?

\n\n

I imagine you use a shell at least a couple of times a day. I further imagine\nsome of the commands you type are the same, over and over again. Someone working\non Node.js projects might type npm test over and over (then again, someone\nworking on Node.js projects is probably using something to automatically re-run\ntests as the code changes). Someone working on Python projects might find\nthemselves typing nosetests over and over. Pretty much everyone these days is\nusing some version control system. If they use the CLI, they’ll be typing things\nlike git checkout master, git commit -a, and git pull all day.

\n\n

A shell alias is a way to say “when I say this, I mean that”. Oh and: you\nusually want to make this shorter and easier to type than that. For example,\nyou can try this in your shell right now:

\n\n

$ alias la='ls -lhat'\n$ la\ntotal 8.0K\ndrwxrwxr-x  2 abesto abesto 4.0K Apr  5 21:55 .\n-rw-rw-r--  1 abesto abesto    0 Apr  5 21:55 awesome-file-3\n-rw-rw-r--  1 abesto abesto    0 Apr  5 21:52 awesome-file-2\n-rw-rw-r--  1 abesto abesto    0 Apr  5 21:52 awesome-file\ndrwxr-xr-x 63 abesto abesto 4.0K Apr  5 21:52 ..\n

\n\n\n\n\n\n

Let’s break down what happened there. First, what are all those arguments to\nls?

\n\n

\n-l turns on the long listing format, providing a big bunch of metadata\nabout each file
\n-h prints file sizes in a human-readable format like 12M for 12\nmegabytes, instead of printing the number of bytes
\n-a prints all files, including hidden ones
\n-t sorts the listing by modification time, newest first.

\n\n

So that would be ls -l -h -a -t. We can contract short command-line flags into\njust ls -lhat, or ls -hatl, or any other ordering – the order of the flags\nhere doesn’t matter.

\n\n

Next, we have quotes around the command on the right-hand side. Why is that?\nNotice also that there’s no space around the =, unlike what you would see in any\ncultured programming language. The construct lefthand=righthand is how variable\nassignment looks like in Bash; lefthand must be a valid variable name, then\ncomes = without any spaces on either side, then righthand, which must be a\nsingle string. In Bash, the unquoted character sequence foo bar represents two\nstrings - foo and bar. To create a single string containing both words, we\ncan escape the space like this: foo\\ bar, but that’s not very easy to read.\nBetter, we can quote the string: 'foo bar'. Note the use of single quotes -\nvariable and subshell interpolation happens inside double quotes, so if you just\nwant to represent a string verbatim, it’s safest to go with the single quotes.\nPutting all that together, here’s what variables look like in use:

\n\n

$ apology='sorry if this is too trivial'\n$ echo \"$apology\"\nsorry if this is too trivial\n

\n\n\n\n

Fine, so what does all this have to do with aliases? Only this: creating an\nalias uses exactly the same syntax and rules as defining a variable, preceded\nwith the special keyword alias. That is, the command alias\nlefthand=righthand tells Bash to, whenever it sees lefthand, pretend it saw\nrighthand instead, taking all the above rules into account. Putting all that\ntogether, it’s now quite clear that in alias la='ls -lhat' defines an alias\ncalled la that expands to ls -lhat, as well as how it does that.

\n\n

Note that any arguments you pass to the invocation of the alias will be passed\nto the expanded command. You might type ls -lhat awesome-dir to list the\ncontents of that awesome directory. Having defined alias la='ls -lhat', you\ncan equivalently type la awesome-dir.

\n\n

Why would you want to do this though? Couple of reasons:

\n\n

It’s shorter. Fewer key-presses means not only shorter time to type, but also\nfewer chances to mistype a character.
It encapsulates knowledge. You may need to search the internet\nand read man ls to get all the options you want – and chances are, if you\nwanted them once, you’ll need them again. So create an alias, and remember\nthat la is that thing with the verbose output, instead of “l for long, a\nfor hidden, and what was it for the human-readable file-sizes again?”
It opens the way to iterative improvement. For instance, you might learn that adding\n--color=auto to the arguments of ls causes it to use color in its output\nto highlight different kinds of files – blue for directories, light-blue for\nsymlinks, green for executables. You can now extend the alias you defined\npreviously. This increases the other two gains – compared to the full\ncommand, the alias is even shorter. It encapsulates more knowledge. The best\npart? You don’t need to commit anything to working memory. Just keep using\nthe alias you’ve been using all this time, except now it’s better.

\n\n

\nPersisting Aliases

\n\n

Unfortunately any aliases you define in an interactive session are lost the\nmoment that interactive session ends – when you close the terminal, in plain\nEnglish. Not to worry though - ~/.bashrc to the rescue!

\n\n

When an interactive Bash session starts, all the lines in ~/.bashrc are\nevaluated as if you had entered them directly on the command line. This is\ndifferent from just running it as a script in a number of significant ways -\nagain, we’ll cover those in the chapter dedicated to each shell. For now, it’s\nenough to know that to persist an alias, as well as any other customization of\nyour shell, just open up ~/.bashrc in your favorite text editor and add the\ncommands, same way as you would type them in an interactive shell.

\n\n\n\n

\nWhen Aliases are Not Enough

\n\n

One of my favorite aliases goes like this (line-breaks inserted to fit on a page):

\n\n

alias glg=\"git log --graph \\\n--pretty=format:'%Cred%H%Creset -%C(yellow)%d%Creset \\\n%s %Cgreen(%cr) %C(bold blue)<%an>%Creset' \\\n--abbrev-commit\"\n

\n\n\n\n

There’s no way in hell I’d want to type this more than once. I don’t even know\nwhat half of it does. I probably didn’t even write it myself, just copy-pasted\nit from somewhere on the internet because I like the output. It prints an\nextremely fancy and nice-to-read version of the history of the git repository\nI’m in.

\n\n

And this is about the limit of what aliases can do. If you want something more\ncomplex – for example, something that needs flow control, you should absolutely\nnot use an alias. It’s possible to do. Technically, anything in Bash can be a\none-liner, it’s just the line will be extremely long. But there’s a better way.

\n\n

Instead of diving into deep and complex examples though, consider this: what if the logical\nargument of an “alias” is not the last string on the command line? For instance,\nin the configuration management system Chef, whose main command-line interface\nis the command knife, sometimes it’s necessary to “force” uploading a\n“cookbook”. (If you’ve never touched Chef, don’t fret; the functionality of the\ncommand is irrelevant for the example. Feel free to imagine this is the CLI of a\ndeveloper-friendly collaborative cookbook-collecting site). Here’s what it looks like:

\n\n

knife cookbook upload <name-of-cookbook> --force\n

\n\n\n\n

That’s quite a mouthful, so of course defining an alias for it makes sense. But\noh no! If we define the alias as alias kcuf='knife cookbook upload --force',\nthen the name of the cookbook to upload can only be passed as an argument to\nkcuf, which means the expanded command will be knife cookbook upload --force <name-of-cookbook>.

\n\n

The solution is to use a function instead of an alias:

\n\n

kcuf() {\n    knife cookbook upload \"$1\" --force\n}\n

\n\n\n\n

The syntax identifier() { starts a function in Bash. It’s designed to look\nlike the definition of a function in any C-like language, but it doesn’t have\nany of the features you’d expect: you can’t define the argument list inside the\nparentheses. You can’t even move the { to the next line, even if you prefer one of\nthe inferior coding standards out there. } of course ends the function\ndefinition. Finally, $1 is a built-in special variable in Bash – its value is the\nfirst argument passed to the function it’s used in. When used outside a\nfunction, it’s the first argument passed to the process it’s used in. In case\nyou’re wondering, it has a few friends like $2 and $3. There’s also $0,\nthen name of the function (or the “name” of the process, when used outside a function).

\n\n

All in all, this is a tiny bit more typing than defining an alias, but it\nelegantly resolves the limitation of aliases around argument order. You\ncan also use any and all Bash features inside the body of a function, which can\nlead to powerful abstractions, as shown in the story below.

\n\n

\nAliases: A Case-Study

\n\n

I used to work quite a bit on projects based on the Django web framework. For\nreasons that are not worth detailing, I didn’t have a way to run the unit test\nsuite from the IDE – I had to switch to a terminal, optionally switch to the\nright project, activate the virtualenv of the project, and then invoke\n./manage.py test.

\n\n\n\n

At a guess, I would do this around ten to thirty times a day. It quickly became\nannoying. The part I’d do most often was running the tests. That’s pretty easy\nto fix in bash. It’s as simple as adding this line to ~/.bashrc:

\n\n

alias mt='./manage.py test'\n

\n\n\n\n

This saves some keystrokes, but more importantly it erases the mental burden of\n“how do I run the tests again?” - mt is simple enough that it can go straight\nto muscle memory. Alt-Tab mt return. Tests are running, elapsed time: ~0.3\nseconds. Nice.

\n\n

Sometimes I’d want to run the unit tests with the env var TEST_WITH_REMOTE set\nto 1. That’s quite a lot of typing, and easy to get wrong, and the only\nindication I’ll get of getting it wrong is that tests fail in the wrong way. No\nsurprise, I guess, here’s our alias to fix that:

\n\n

alias rmt='TEST_WITH_REMOTE=1 ./manage.py test'\n

\n\n\n\n\n\n

Working outwards, next up is activating the virtualenv. In all our projects, the\nvirtualenv is always stored in the root of the project, a directory called\nvirtualenv, and you have to activate it using the magic incantation .\nvirtualenv/bin/activate, where the dot (.) tells bash to “source” that file -\npretend that you typed the contents of the file directly, instead of running it\nas a command. Typing that becomes second nature over time, and is easy to always\nget right using auto-completion, but it’s still time that could be saved. Not to\nmention, if you’re not in the root of the project, you need to put the right\nnumber of ../s in front of virtualenv/bin/activate. That’s mental effort\nthat does nothing, at all, to get you closer to your goal, whatever that may be.\nIt’s a function of the environment – and you can change the environment. Here’s\none way of doing that – again, in ~/.bashrc:

\n\n

v() {\n for candidate in virtualenv ../virtualenv ../../virtualenv; do\n  if [ -f $candidate/bin/activate ]; then\n   . $candidate/bin/activate\n   return\n  fi\n done\n}\n

\n\n\n\n

This looks a bit different – the logic is complex enough that it doesn’t fit in\na simple alias. We have to define a function. The idea is to check all the usual\nlocations where the virtualenv can be, and activate it once we find it. Note\nthat it could be generalized in a lot of ways, it could traverse the directory\nstructure more generally to generate more possible candidates. But it hits the\ngolden standard of It Works.

\n\n

Now for how impactful such a small tweak can be: an engineer I worked together\nwith at the time asked what v does when he saw me use it in my shell. I\nexplained it to him; he got excited, we copy-pasted it into his .bashrc, he\nwas happy, then I forgot about it. A year or so later a new hire asked me for\nhelp to solve a tricky problem he hit while setting up the virtualenv for a\nproject. As he was explaining the steps to reproduce the problem, he said “then I\nuse v to activate the virtualenv”. I got suspicious; I asked him what that is\nand where it comes from. He showed me the exact same code, which he got from his\ntech-lead - not the engineer I showed it to. Turns out, this function was so\nuseful that it got passed around across a chain of at least three engineers. Not\nonly that, it was so useful that it was included in the welcome package of a\nnewly hired developer!

\n\n

For completeness’ sake, v is only complete with its counterpart d that\ndeactivates the virtualenv. Virtualenvs define a function deactivate to\ndeactivate themselves, so this is trivial:

\n\n

alias d=deactivate\n

\n\n\n\n\n\n

Tying it back to the original story of running unit tests: given all this\npreparation, I now had a sequence of keystrokes, in muscle memory, that I could\nuse to run tests. Starting from the IDE being open, it goes like this, and takes\naround 1.2 seconds from “I want to run tests” to “tests are running”:

\n\n

Alt-Tab (switches from IDE to terminal)
\nj auth (uses autojump to go to the project, called authservice in this\ncase)
\nv (activates the virtualenv)
\nmt (runs tests)

\n\n

If you’re wondering about the weirdly accurate timings: I once gave a little\ninternal talk on optimizing the development workflow on Django services – I\nrecorded my screen, and measured how long each step takes.

\n\n

So what should you turn into aliases / functions? How much is too much? Should\nyou even use aliases? Won’t that make things confusing when you need to work at\nanother computer? Generally speaking, the right balance is what feels right for\nyou, personally. If you’re just starting out on the path of customizing your\nshell environment, I’d suggest starting slow and adding just a few aliases,\nseeing how they work, tweaking them over time. Slowly expanding your arsenal\nallows you time to recognize the situations when you can use that alias.\nInitially you can expect to have a tiny shock when you use an alias. Your brain\ngets confused. It usually takes another 3-5 seconds to implement that intention,\nand your brain tends to turn off for that time. Now that the intention takes a\nfraction of a second to complete, you must unlearn that pause.

\n\n\n\n\n\n

Once you start looking for ways to customize your environment (shell or\notherwise), you’ll inevitably come across situations where you just want to have\nthe same features that other developer seems to have. Copy-pasting their\nconfiguration might do just that, or it might mess up your environment or\nworkflow. Keep in mind that you can only customize what you understand. In one\nextreme case, I’ve helped someone debug a messed-up shell where they copy-pasted\nconfiguration into their .bashrc that was written for another shell.

\n\n

Some of the systems you’ll need to understand will be ones specific to your\ncompany or project. I can’t directly help you with those; but hopefully by the\nend of this book you’ll understand enough of the underlying open-source,\nstandard technologies they’re built on to be confident in exploring and\ncustomizing them.

\n\n

\nAlso Try

\n\n

\nhuffshell suggests new aliases based on your shell history
\ncommandlinefu is a\ncrowdsourced repository of shell commands that do useful, complex stuff\n\n\n

\n\n\n

\nEnd of the Sample

\n\n

Here’s a teaser of the rest of what’s available in the full book currently:

\n\n

Version Control for your dotfiles
Automating Environment Setup
Editors and IDEs: Choosing and Customizing
Picking an Operating System\n
- macOS, the Safe Option
- Ubuntu: Beginner-Friendly and Stable
- Arch Linux: Minimal, Always Up to Date
\n
Terminal Emulators
Command-line Productivity

\n\n

\n\n","tocStructure",[175,176,177,178,179,180,181,182,183,184,185,186,187,188,189,190,191,192,193],{"_79":73,"_43":70,"_71":-5,"_74":75,"_72":73,"_94":-5,"_95":-5,"_85":-5},{"_79":80,"_43":81,"_71":-5,"_74":82,"_72":73,"_94":-5,"_95":-5,"_85":-5},{"_79":80,"_43":87,"_71":-5,"_74":88,"_72":73,"_94":-5,"_95":-5,"_85":-5},{"_79":91,"_43":92,"_71":-5,"_74":93,"_72":73,"_94":-5,"_95":-5,"_85":-5},{"_79":80,"_43":97,"_71":-5,"_74":98,"_72":73,"_94":-5,"_95":-5,"_85":-5},{"_79":80,"_43":101,"_71":-5,"_74":102,"_72":73,"_94":-5,"_95":-5,"_85":-5},{"_79":80,"_43":105,"_71":-5,"_74":106,"_72":73,"_94":-5,"_95":-5,"_85":-5},{"_79":80,"_43":109,"_71":-5,"_74":110,"_72":73,"_94":-5,"_95":-5,"_85":-5},{"_79":73,"_43":113,"_71":-5,"_74":114,"_72":73,"_94":-5,"_95":-5,"_85":-5},{"_79":80,"_43":117,"_71":-5,"_74":118,"_72":73,"_94":-5,"_95":-5,"_85":-5},{"_79":80,"_43":121,"_71":-5,"_74":122,"_72":73,"_94":-5,"_95":-5,"_85":-5},{"_79":80,"_43":125,"_71":-5,"_74":126,"_72":73,"_94":-5,"_95":-5,"_85":-5},{"_79":91,"_43":129,"_71":-5,"_74":130,"_72":73,"_94":-5,"_95":-5,"_85":-5},{"_79":91,"_43":132,"_71":-5,"_74":133,"_72":73,"_94":-5,"_95":-5,"_85":-5},{"_79":91,"_43":135,"_71":-5,"_74":136,"_72":73,"_94":-5,"_95":-5,"_85":-5},{"_79":91,"_43":138,"_71":-5,"_74":139,"_72":73,"_94":-5,"_95":-5,"_85":-5},{"_79":91,"_43":141,"_71":-5,"_74":142,"_72":73,"_94":-5,"_95":-5,"_85":-5},{"_79":91,"_43":144,"_71":-5,"_74":145,"_72":73,"_94":-5,"_95":-5,"_85":-5},{"_79":80,"_43":147,"_71":-5,"_74":148,"_72":73,"_94":-5,"_95":-5,"_85":-5},"publicChapterContent","nextChapter","sections",[],"routes/_store+/_layout","routes/_store+/_readers+/_layout","actionData","errors"]

\nEnd of the Sample

Table of Contents

\nPreface

\nThe Pitch

\nWho is This Book For?

\nWhat Technologies are Covered?

\nHow to Read This Book

\nAbout the Author

\nWhat to Expect from this Book

\nConventions Used

\nAppetizer

\nIdentifying your Motivation

\nMindfulness Applies Everywhere

\nSupercharging your Shell

\nWhat’s a Shell?

\nWhat’s a Shell Alias?

\nPersisting Aliases

\nWhen Aliases are Not Enough

\nAliases: A Case-Study

\nAlso Try

\nEnd of the Sample