@ -220,9 +220,110 @@ This also omits Edubuntu which, as a former teacher, I am very interested in.
\chapter{What's to Like About Linux}
As I get older, I find that I want to spend less time doing repetitive tasks that need to be done, and spend more time doing the stuff I want to do, like writing.
As it turns out, Linux can help with that goal. More time writing and drawing and making photographs is a good thing, and something I'm grateful to Linux for. The trick is, you have to be comfortable with the command line.
\section{bash Aliases for \texttt{git}}
\section{Bash Aliases for \texttt{git}}
One of the nice things about Linux is that once you get used to working on the terminal, it makes your life a lot easier. I'm a huge believer in having a workflow so that you are doing things consistently, and so that you can make gradual improvements to that workflow so you can get more done with less.\footnote{Also, having a workflow means that if you are doing something wrong, you are doing consistently doing it wrong the same way. In which case, you only need to figure out a single fix and apply it to each mistake. If you don't have a workflow, you can screw up in many different ways, and have to figure out a lot of different fixes. Making mistakes is a part of life; making consistent mistakes makes fixing them a less miserable task.} Linux makes it easy for you to do that.
Back in issue \#2 I talked about using Bash aliases to make your life easier. I've also started using them with \texttt{git} as well. Here's what they look like:
\begin{Verbatim}[frame=lines, numbers=left, xleftmargin=5mm, framesep=3mm, breaklines=true, label=\fbox{Bash aliases for git}]
alias gits="git status"
alias gita="git add *"
alias gitx="git add *.tex"
\end{Verbatim}
The first one just prints out the status of any git project that I'm working. The second one will automatically add all files (except for invisible files) to the commit. Because I use \LaTeX{} a lot, I also have the third one, which will commit any changed files that end in a \texttt{.tex} extension.
I rarely have invisible files in my git repositories except for the .gitignore file, which I rarely change, so I don't need a Bash alias here. I find it easy enough to type \verb+git add .gitignore+ on the rare occasion that I need it. But if I did want to add that file on a regular basis, I could just change that line to:
\begin{Verbatim}[]
alias gita="git add * .*"
\end{Verbatim}
or I could just add a separate command for it:
\begin{Verbatim}[]
alias giti="git add .gitignore"
\end{Verbatim}
Of course, if I were changing my \textit{.gitignore} file that often, I would start to (quite rightly) question some of the other choices I've been making with my life.
\section{Bash Commands for \textit{git}}
It would be nice if we could do the same sort of thing for \texttt{git commit}, but we can't, because we need to add some sort of message to our commit. (In other words, it requires an \textit{argument}.) So for that, we need to add a \textit{function} to Bash.
As it turns out, this is pretty simple. It looks like this:
\begin{Verbatim}[]
gitm(){ git commit -m "$1"; }
\end{Verbatim}
%$
First, we start with our basic function, which is written like any other function:
\begin{Verbatim}[]
gitm()
\end{Verbatim}
So, to invoke this function, we'll use \textit{gitm} on the terminal. Now we add whatever commands we want between curly brackets. In this case we're only going to add one, which is the \verb+git commit -m "$1";+ bit. The only thing unique here is that we have a variable (\verb+$1+) which references our first and only argument, which is the commit message we are going to add.
Once we have added all the files we need to our commit, we can then create the commit with something like this:
\begin{Verbatim}[]
gitm "Updated section on bash aliases"
\end{Verbatim}
which is a \textit{bit} shorter than typing
\begin{Verbatim}[]
git commit -m "Updated section on bash aliases"
\end{Verbatim}
Admittedly, this doesn't save us a ton of keystrokes every time we use it, but if we make git commits on a regular basis, over time, this will save us a number of keystrokes.
\section{More about Bash commands}
As it turns out, you can add more than a single command to a Bash function. For example, you can use this
\begin{Verbatim}[frame=lines, numbers=left, xleftmargin=5mm, framesep=3mm, breaklines=true, label=\fbox{Bash function with multiple commands}]
cdl() {
cd "$1" && ls -ahl;
}
\end{Verbatim}
%$
This will change to whichever directory we specify with the \verb+$1+ placeholder, and then present a directory listing which shows all files, with human-readable sizes, in a long format. That may not be highly useful, but it's enough to give you an idea of how powerful this using bash aliases and Bash functions can be.
As an example, I like to write rough drafts in longhand, on notebook paper. I find that I am more creative that way. The problem is that I intensely dislike being surrounded by piles of paper. (ADHD means that if I can't see something, it no longer exists. So my brain will only really see whatever is on top of the pile.) So whenever I finish up a rough draft, I scan it to a ``Drafts'' folder, where it goes into a subfolder labeled for whatever projects it belongs to.\footnote{Yep, there is a subfolder labeled ``the codex'' with drafts for this zine.} So that I can see everything, I use the \texttt{tree} command to create a file which lists every single scan in that ``Drafts'' folder.
So far, so good, but running the same \texttt{tree} command consistently is not something my brain is set up to do. So I added this function to my \texttt{.bashrc} file:
\begin{Verbatim}[breaklines=true]
drafts(){ tree $HOME/Drafts/-R --prune > $HOME/Drafts/list.txt; }
\end{Verbatim}
What that command does is go to that ``Drafts'' folder, runs the \texttt{tree} command with the \texttt{-R} (recursive) and \texttt{--prune} (to ignore empty directories) options and then sends the standard output to a file called \texttt{list.txt}. I print out the \texttt{list.txt} file whenever I am searching for something to write up, and I can see in an instant what rough drafts I can work on. My ADHD brain is pretty happy with this arrangement, as nothing gets buried in a pile of files, and I don't have a ton of paper sitting around.
For what it's worth, I also have a backup script (as I mentioned in issue \#2) just for this folder. And I added that command to the top of that backup script, so that before anything gets backed up to my cloud, that \texttt{list.txt} file gets updated and uploaded as well.
\section{Reloading the \texttt{.bashrc} File}
For any of these things to work, you need to reload your \texttt{.bashrc} file after you edit it. You can log out and then log in again, or you can just go to the command line and type
\begin{Verbatim}[]
source ~/.bashrc
\end{Verbatim}
And of course, there is also a shorthand version:
\begin{Verbatim}[]
. ~/.bashrc
\end{Verbatim}
@ -274,7 +375,7 @@ And, as we shall see, sometimes it's beneficial to do something the wrong way.
\end{itemize}
\end{itemize}
\section*{Very Wrong Ways}
\section{Very Wrong Ways}
Very wrongs ways are very wrong because not only do they not work, they take other things down with them.
@ -284,7 +385,7 @@ Very wrongs ways are very wrong because not only do they not work, they take oth
\paragraph{It doesn't work and it still manages to break a few local things.} No complaints here. You have to undo what you did and maybe fix a few things, but you probably don't have a whole lot more to think about here.
\section*{Wrong Ways}
\section{Wrong Ways}
Wrong ways may work, but they break other things along the way. As we shall see, this is not always a bad thing.
@ -294,13 +395,13 @@ Wrong ways may work, but they break other things along the way. As we shall see,
\paragraph{It works, but it still manages to break a few local things.} Even though this is listed as a wrong way---you are still breaking things, after all---this is not always a bad outcome to experience. It's possible that those few things that are breaking are breaking because they are weak. If you strengthen those items and then apply this technique, it turns out that this isn't actually wrong after all, it only seemed wrong at the time. In the end, you have a much project that is much less fragile overall.
\section*{Wrong\textit{ish} Ways}
\section{Wrong\textit{ish} Ways}
\paragraph{It works in this specific instance, but not in all instances.} It works, so why is this way still wrong? Because it's not \textit{universal} for all similar situations. If it works in \textit{this one particular instance} but not similar instances, and you don't know why, then there is something about this particular instance that you are not aware of. This is not a bad thing if you're willing to chase down that unknown thing; it's potentially disastrous if you are not.
\paragraph{It works, but it's far more work than it should be.} This is often a case of not having the right tools, or having the right tools but not knowing how to use them. If you need to dig a ditch, a shovel will work, but a backhoe works much better. All that time you spent working with a shovel is time you could have spent doing something else.
\section*{Right\textit{ish} Ways}
\section{Right\textit{ish} Ways}
\paragraph{It works, but you have no idea why.} I was very tempted to put this in the wrong\textit{ish} section, and in some cases it may certainly belong there. Quite frankly, you should know why a technique works. Not knowing why can be dangerous, because you assume too much about this particular technique. That may cause you to be a bit overconfident with it, and use it in a situation that doesn't really warrant its use.
@ -308,13 +409,13 @@ Wrong ways may work, but they break other things along the way. As we shall see,
\paragraph{It works, but it's a bit of a kludge.} A kludge is not always a bad thing (sometimes you have to work with what you have) but they are at best, inelegant, and at worst weighty and ugly. But they work for now, they don't break things, and they will last until you learn or can afford a better way. (I created a bit of a kludge when I couldn't figure out how to indent a bibliography entry. \footnote{You can see it in action in this commit for a different project: \kref{https://git.kjodle.net/kjodle/Notes-on-Python/commit/d4f93ec00f1e1078b1cfcb3aacd3481eb82bb0cd}{https://git.kjodle.net/kjodle/Notes-on-Python/commit/d4f93ec00f1e1078b1cfcb3a\\acd3481eb82bb0cd}.} Does it work? Yes. Am I happy with it? Not entirely. I'm 75\% there is a better way to do this, but I haven't found it yet. But it works for now, and I've marked it as a kludge, so I know this is something that I can come back to later. At least I made this less weighty and hid its heft and inelegance by turning it into a macro.)
\section*{Right Ways}
\section{Right Ways}
\paragraph{It works, and is considered a best practice.} A best practice is one that has generally been accepted as the best way to do things not because it is perfect, but because it produces results that are better than the results achieved by other methods. This is a good thing. A best practice is a best practice because it's proven itself. It's not perfect (hence it's a ``best practice'' not a ``perfect practice''), but you can count on it to get the job done. And because it is a best practice, when things go pear-shaped, it's probably because of something you've done, but if it isn't, there will most likely be a lot of people who are \textit{very} interested in helping you.
Unfortunately, sometimes a best practice is arrived at that for no other reason than ``that's how we've always done it and nothing has exploded yet.'' That's not great, but still, have a fire extinguisher handy.
