24wi ver.
Note: this is for the Winter 2024 iteration of CSE 391. Looking for a different quarter? Please visit https://courses.cs.washington.edu/courses/cse391/.
Collecting some helpful (but completely optional) resources for topics in this class. There is no mandatory information that only lives on this page: most of it is “for fun”, and the parts that are necessary for this class are already expressed in other mediums.
Useful Links¶
Here are some useful links collated by previous instructors of 391 (and its predecessor, 390A) for “day-to-day” operations of this class.
- Linux Bash Command Reference
- Quick List of Tools for Moving files
- Slides on Moving and Editing files
- How to view “hidden” (aka dot) files
Editors¶
Why use an editor in the command line?
While you could use a fancy integrated development environment (IDE), we encourage you to take the time this quarter to practice using an editor native to the command line for this course. While these tools can be slow to pick up at first, being practiced with an editor of choice in the command line will take you a very far way. It’s very common you want to edit something quick on your computer and you can save lots of time by not having to start up a slow application like IntelliJ for a quick fix. Sometimes you might not have an IDE available if the files you need to edit live on a server like attu, so learning one of these editors now will be very helpful in the future.
There are two very popular command line editors, vim and emacs. A lot of people spend hours and hours arguing about which one is better which is a pretty useless waste of time. It’s okay to like whichever one you like and it’s also fine if you have no opinion! Hunter personally prefers vim and will use that in class, but use whichever one you prefer!
Additionally, many students choose to work on the weekly assignments on attu rather than downloading the VM. Using a command line editor on attu is much simpler than having to figure out how to download/upload your code to attu so that you can use a different editor on your local computer.
Vim Basics¶
Emacs Basics¶
Bonus Questions (and Answers!)¶
This class is only the start to all sorts of software tools, shells, and system workflows. In many topics, we’ve barely scratched the surface!
Here is a collection of ideas that extend on the topics in our class, based on questions we often get as instructors. If you’ve got an interesting one, let us know!
Can I make my editor more powerful?¶
Yes! One of the biggest benefits to vim and emacs is that they’re extraordinarily customizable. We only briefly touch on this in the resources on customizing your shell, but you can do things like run your favourite debugger, install plugins, write your own keybindings, and have fun themes!
Here are some places to start if you’d like to learn more:
- neovim: one of the most popular community extensions of
vim - spacemacs: one of the most popular community distributions of
emacs - nano: another common command-line text editor
What other shells and terminals are there?¶
In our class, we’ve talked about the “shell” as mostly one ubiquitous object. In reality, that’s not true! There are many, many different shells. When omitting the specific one, people tend to mean sh or bash on Linux/Unix systems. However, there are many other ones to check out, including:
zsh, which is now the default shell on macOS (Oh My Zsh is a common framework)fish- PowerShell
Customizing your shell is a deep-dive just like customing your editor!
Similarly, there are many other terminals you can use (outside of the default ones on your operating system). There are too many alternatives to list, but iTerm2 for macOS is one option that many folks use.
Do people still update command-line tools?¶
Yes! The tools we’ve learned about in this class are decades-old, but many still receive frequent updates. Three notable examples are git, ssh, and curl, which all receive new features, critical security updates, and small bugfixes every year.
Separately, many people work on competing tools. One of the most notable examples is grep, which faces performance bottlenecks on large directories (think in the scale of GBs or TBs). There are many, many competitors that work well for different use-cases. Andrew Gallant (the author of ripgrep) has written a stellar blog post comparing different grep-like tools and discusses some of the technical challenges in building fast software tools. It’s a fascinating read!
What other command-line tools boost developer productivity?¶
Alternatively: what would we have included if we had more weeks?
The tools you’ll use depend on the type of work that you do with the command line, so there’s no one “answer”. However, here’s a general sense of next steps if you imagine that you’ll be doing a significant amount of software engineering:
- a terminal multiplexer like tmux - split-screen your terminal, run multiple shells in parallel, and more!
- using tools to write better code:
- learning more about their system’s package manager
- diving deeper into build systems to help automate building, testing, and deployment
- become proficient in a scripting language: this could be shell scripting, but also Python, Ruby, Perl, Awk, etc. all work!
What are some more complicated features of git?¶
There is so much more to git than what we’ve covered in class! Some keywords and concepts to look into:
- more “core” git concepts: tags, blobs, and what a commit hash really means
- practical concepts related to merging: rebasing, squashing, fast-forwarding, reverting, and cherry-picking
- tools that can help you debug your code (and repository):
git blame,git bisect,git ls-tree - Git LFS
- GPG signing your git commits
There are many, many resources that teach git in all sorts of different ways! Here’s a non-exhaustive list that covers some more advanced ones: