Essential Terminal Commands Every Developer Should Know | Hacker News Reader

Essential Terminal Commands Every Developer Should Know

trevorlasn.com

30 pointstodsacerdoti35 comments

Open articleView on HN

> 1. grep

> 2. ls

> 3. cat

> 4. head

> 5. awk

> 6. sed

> 7. tail

> 8. chmod

> 9. xargs

> 10. find

Seems like a pretty good list. I wonder if there is anything obvious missing?

  awk '{ print $1 }' "$HISTFILE"|sort|uniq -c|sort -rn|head -15
     4887 cd
     3699 ssh
     2461 man
     1987 ls
     1558 top
     1141 less
      981 su
      905 dc
      807 pwd
      779 while
      750 find
      601 apt-cache
      529 echo
      462 cat
      426 emacs

(The above list has been cleaned from my system-specific commands which would not be generally useful for others.)

Ah, of course. They forgot the most useful command of all, namely man.

I'm not the only person who uses "dc" for throwaway calculations all the time? Woo!

The thing that I find has the biggest useful-to-popularly-known ratio is "tee".

and the moreutils equivalent, sponge

This article is such a ride. `grep`, `ls` and `cd` then BAM - `awk`.

"Here's a hammer, here's a chisel, here's a hand saw aaaand... here's a petrol powered jackhammer with a circular saw attached."

I think it might have been generated by AI. A human would have noticed huge discrepancy between simple examples with grep and ls and the magic AWK script that would basically deserve a separate article just to grasp how it works.

I think a lot of people underestimate awk or aren't aware of its capabilities - I used it quite a lot when I was new in my career before really understanding it. There's enough awk snippets floating around that you'll see it in folks' toolkits next to sed & grep even though they're just using a couple preset scripts.

I didn't really understand what it was capable of until I had a colleague use it to parse the output a CLI tool with no actual reasonable machine-readable output - something like a 100 line awk script to turn some hardware vendor's joke of a config tool into output that could be piped into another script. That's when I understood what awk was, and that my colleague might have been the devil.

I don't think anyone is arguing otherwise but that command is out of place there. Way more complex than the rest and poorly explained.

Anyway, TIL the existence of grep -e.

Awk is powerful, but I find it more portable/easy to understand implementing much of it in Python or Perl 5 these days.

Counter argument: most of these commands are great if you want to do shell scripting (including one-offs that you never save to a file), where you chain commands to do work for you. But I've never needed anything except for `ls` and (rarely) `chmod` for my actual day job, especially since everything I write needs to work cross-platform. Shell script has been the bane of "and folks on Windows should also be able to contribute" open source developers. I consider these great commands to know for personal automation, or when doing Unix(like)-only dev work, but they're the complete opposite of essential for cross-platform development. Not intimately knowing them means you literally can't be tempted to integrate them into a team-wide/project-wide workflow.

Maybe if Windows had grown up with the same Unix tools from day one, the story would be different, but as it stands if I want to do cross-platform development, I'd much rather use the tools I know that Windows devs on my team (and community contributors) can also use, so that we're all using the same tooling and everyone can help everyone else when that tooling falls short.

A lot of things in this article are (for better or for worse) "just do X in VS Code" these days, with support for a "project-recommended extensions" file that you check into version control so that folks forking/cloning automatically get told which extensions they will want to get up to speed with the rest of the team. Because if there's a "common" unix command chain, good chance there's an equivalent cross-platform extension for VS Code for it. If it's not already built in of course.

The essential part is knowing how to do get the result you need for yourself, and how to automate the tasks of getting those results using tools that everyone will be able to use if you're doing dev work (paid or as volunteered) for someone else.

It's 2024, why are we still caring about windows native development?

Sure, if you have unlimited resources, or your target audience is predominantely Windows (gaming or non-web large enterprise apps), you can worry about Windows. Otherwise, tell them to install WSL and do all you day-to-day work in *nix environment. No one but your CI have to touch Windows.

I didn't say "native Windows", I said cross-platform. The kind where the tooling you use works on every OS. Cross platform is literally the opposite of "anything-native": you workflows and tooling are OS-agnostic, even if the end results are binaries specific to all major OSses (and of course, a lot of dev work never involves generating binaries)

Sorry, I was not clear: by "native Windows", I meant the Window-specific tooling (batch files, powershell, registry etc...). This is a whole separate world in the opposition to *nix (which today means Linux, BSDs and Max OS) which use things like bash, coreutils, and so on.

My point that now, in 2024, there is really no need to bother with both Windows and *nix support, unless you have special requirements. "Cross platform including non-WSL Windows support" is much more complex and limited than "cross platform which requires WSL on windows", and no one should waste their resources on that without a very good reason. It's perfectly fine to require *nix-like OS for your workflows and enjoy the ease and compatibility that this brings to the table.

This is especially important for open-source contributors, too: someone running Mac OS or Linux is going to be heavily discouraged from contributing any scripts if all scripts are required to be Windows-compatible. And someone running Windows might contribute powershell script but that would be useless for non-Windows people, limiting its utility. My advice to everyone is: unless your app is in Windows-heavy niche, drop non-WSL windows support requirement.

I also didn't say "windows specific tooling". A modern code editor or IDE already covers 80%, if not more, of what the article's tools cover. You don't need separate applications for the things that article explains as use-cases.

And by not using or advocating unix-specific command line utilities, you solve two problems: people don't need to learn commands they don't want to learn, and the tools that you do use tend to be cross-platform by default. Anyone on Windows, Linux, MacOS, FreeBSD, etc can use those same tools. Telling a contributor "we recommend using VS Code with these extensions" in 2024 is pretty much the lowest barrier to entry you could ask for.

Whether your build tooling requires platform-specific tools is a completely different issue: this article and my comment on it isn't about that context. They're about commands that the article claims are essential to you, a person, in order to be a better developer. And to that statement my response is: you really don't. These can certainly be useful to know, but they're also completely optional.

I find Git Bash (bundled with Git for Windows, MSYS2 based), MSYS2 or WSL2; at least one of with I expect being installed on any "developer machine"; works fine for any non-obscure shell scripting need.

They all work, and a good cross-platform project setup forces you use exactly none of those. WSL/WSL2 in particular is the absolute worst in terms of "okay now use not your OS inside your OS". Just give your team a docker image then.

`sort` and `sort --numeric`, `uniq` and `uniq -c`, and `cut` in its `cut -d' ' -f 3` are things I use far, far more often than sense or reason suggests I should. Pipe all that to `xargs` (or `xargs -n1 -IAB -p10 command --flag AB`) and baby, you got a stew going.

(as the saying goes, Unix gives you enough rope to shoot yourself in the foot.)

My most used keystroke in bash is control-r. The number of folks who don’t know that amazes me. My go to shell command is tmux.

As someone who was also recently taught this, it's amazing. Props to the GNU Readline library [1] as well as Tmux as they are certified game-changers for the occasional context swap.

[1] https://en.m.wikipedia.org/wiki/GNU_Readline

http://atuin.sh for ctrl-r on steroids

Shout out to "sudo reboot"

'lsof' is another one that I can't do without.

lsof I find I'm using primarily for debugging stuff. strace and tcpdump fit into the same general category - "What the hell is this program actually _doing_ right now?".

It's especially useful when you have several processes that communicate with TCP or UDP. 'lsof -i :<port>' will quickly show if you have the connections you expect to have.

I'm sorry, but who is the intended audience of this post?

Is there really anyone who is messing around on the Unix command line who needs to be told about cat, head, and ls?

I'm not sure I'd say I'm "messing around on the Unix command line", but I've been using Linux for about 3 years on my desktop and do some hobbyist development. Have never seen head before.

New developers? Many are uncomfortable on the command line

no tar?

well they never said _all_ the essential commands ;)

You know, I used to extract and create tar files all the time, but have not done so in ages. I think it ended when software stopped being distributed as tar files. I mean, there are tar files, but you often don’t use that way to install them. For source code, you you use git clone or apt-get source. For already-compiled software, you use apt, snap, or some other package manager. General data files are usually made available as a .zip file.

Most of the upstream sources that I deal with come as tarballs.

https://www.kernel.org/

I sometimes use tar when I need to transfer a bunch of files using a USB stick. Most USB sticks I encounter are FAT (or rarely, NTFS) and the permissions get trashed if bare files are copied. Tar saves me from having to repair the perms on the other end.

(Admittedly this isn't something you're going to need to do unless you find yourself working with air-gapped systems, but .. I do)

Tar with -a (automatic) is awesome.

tar -xaf foo.tar.gz

Will auto-un-gzip based on the extension. Also works with compressing:

tar -caf bar.tar.xz bar/

I just use tar xf file. The a option is probably only required when creating a tarball.

Tar? I‘m so sorry!

https://xkcd.com/1168

$ tar --help

Reply on news.ycombinator.com