Live data from Hacker News

Become Shell Literate

drewdevault.com

241–250 of 341 posts

Re: Become Shell Literate

#241

I can just never get past the arg/flag inconsistency/complexity across commands. Perhaps if the docs started with a simple example of what has been seen over time to be the most common incantation for each command it might be tolerable. But as it is, I spend more time dealing with idiosyncracies of a command than I do expressively piping stuff. Perhaps if Rust had five mutually incompatible borrow-checkers which get…

> Perhaps if the docs started with a simple example of what has been seen over time to be the most common incantation for each command it might be tolerable.

Rsync’s man page opens with examples, and even though I never actually those specific commands, they are usually enough for me to remember how to do whatever I wanted to do.

Re: Become Shell Literate

#242

I used to think this way as well, but out of necessity, had to work specifically with a commercial IDE for some time. Turns out, if you are confident learning the keybindings of a robust IDE is worthwhile (e.g. you know that you must use it for some particular project for a decent amount of time) the investment pays off just as well as learning shell commands. A good IDE can do everything a cobbled together shell pip…

> People like to pretend that learning shell commands is somehow better because it's more portable,

No, it's better because if you aren't doing exactly the workflow an IDE or GUI tool designer has envisioned, it is almost invariably much easier to do it in shell (and then make it a script and then bind it to a command in your IDE or GUI tool, if they support that) than to beat the non-shell tool into, first, doing what you want, and then making it easily repeatable.

It's also more portable, which, contrary to your description, is very useful for most people, because even if there are some dev-only tasks that “I can only do it in the IDE” is fine for, for many things you may also want to do in a CI pipeline, on a deployment box, or other places where your IDE isn't running. Shell scripts generally work there.

Re: Become Shell Literate

#243

The following sets up a key binding to grab interesting lines from the history, throw them into a file, and pop it up in an editor: # put interesting lines from history into a file, open an editor function h2e() { echo "#! /bin/bash" > "$3" history | tail -n"$1" | egrep "$2" | sed -re 's/\s*[0-9]+\s+//' >> "$3" "${EDITOR:-emacs}" "$3" } # prompt for h2e's arguments function h2ei() { read -p 'num. lines [1]: ' lines r…

So you would run "h2ei 10 somepattern out.txt"?

Which would put the last 10 lines matching some pattern to the txt file?

Re: Become Shell Literate

#244

I used to think this way as well, but out of necessity, had to work specifically with a commercial IDE for some time. Turns out, if you are confident learning the keybindings of a robust IDE is worthwhile (e.g. you know that you must use it for some particular project for a decent amount of time) the investment pays off just as well as learning shell commands. A good IDE can do everything a cobbled together shell pip…

"Personally, I do prefer working in the shell, but if you prefer working in a modern IDE, don't let anyone fool you that you're somehow wasting time or being less proficient than you could be in a shell"

I totally agree with that sentiment.

"[...] unless your work entails working across multiple machines and environments daily"

That situation might be a lot more likely than you'd think. I started out doing WordPress, and that's still what mostly what makes me money.

But now that I am using 30-40 different machines that host 3-400 sites, each with their own installs, and knowing how to do stuff efficiently with the shell is super useful.

To me, that situation feels kinda unlikely, but at the same time dang it's nice to just ssh into a machine and know what I'm doing.

I have coworkers and clients who just can't do certain kinds of tasks or troubleshoot stuff with certain kinds of tools because they just don't have the CLI knowledge.

So while I generally agree with your post, I will offer an alternate idea to balance it: if folks are thinking that learning how to use a shell is a waste of time because they can do everything in a GUI, if they took the time to learn the shell at a a level of most of the things they use every day in an IDE, they are "not losing in efficiency at all and possibly making gains when it comes to certain tasks."

Re: Become Shell Literate

#245
post #201
post #165

Sign me up for someone who hates the shell. I've always tried to write scripts in Python or even C++ is so much easier than bash, awk, etc. Bash has no repl, no unit tests not debugger its anachronistic. Don't get me started on emacs.

Bash has no REPL?

yeah OK its probably the definition of repl.

Re: Become Shell Literate

#246
post #61

Earlier quoted context omitted.

Opening a shell is not an obstacle when you've already got several open. Also, not all of us are refactoring huge codebases or using verbose languages that require a lot of handholding. The hard part of development is typically not at the typing or syntax levels, and I have the stdlib of my favorite libs close to memorized already. The most helpful ides tend to be massive as well. Tools can be useful however, such as…

It wasn't clear from your comment if you're aware of this, but Flutter hot-reload works from the command line too! I do all my Flutter development in 3 windows (vim, `flutter run` shell, android emulator).

Glad to hear, I've barely started with it.

Re: Become Shell Literate

#247

I can just never get past the arg/flag inconsistency/complexity across commands. Perhaps if the docs started with a simple example of what has been seen over time to be the most common incantation for each command it might be tolerable. But as it is, I spend more time dealing with idiosyncracies of a command than I do expressively piping stuff. Perhaps if Rust had five mutually incompatible borrow-checkers which get…

You're right. I often think the man page should begin with a few examples, then launch into the neverending list of options. That is no way to learn. In foreign language 101, they start you off with a small group of examples. "Como estas?" "Muy bien. Y tu?" Afterward, they explain the rules of the language (this is a noun, this is a verb, this is how you conjugate for first-person singular, etc.). In fact, this is ho…

I've really come to appreciate PowerShell exactly for the "-Examples" argument for Get-Help (or help/man alias). Although I still prefer a POSIX shell, I've been messing around with PowerShell and quite enjoy it.

Re: Become Shell Literate

#248
post #202

Nice post, but 2020 and still using an unauthenticated connection (plain netcat) to transfer data including executables (if I understood correctly) is not something you can justify when there are plenty of safe alternatives (e.g. wormhole, syncthing). Maybe the recipient and the sender just compare hashes via a secure channel, but there's no mention of this.

The files were transferred via yggdrasil. In any case, it would have to be an unusually clever attacker to identify executables in a tarball being transmitted unwrapped via TCP on a port chosen out of a hat, and intercept it to do something malicious.

Re: Become Shell Literate

#249

I used to think this way as well, but out of necessity, had to work specifically with a commercial IDE for some time. Turns out, if you are confident learning the keybindings of a robust IDE is worthwhile (e.g. you know that you must use it for some particular project for a decent amount of time) the investment pays off just as well as learning shell commands. A good IDE can do everything a cobbled together shell pip…

"People like to pretend that learning shell commands is somehow better because it's more portable, but unless your work entails working across multiple machines and environments daily, it doesn't matter."

It is more portable. No pretending is necessary. It's true. I run multiple computers with different resource constraints and operating systems. I neither have the patience nor the time (not to mention the system requirements) to install an IDE on all of them. However each one has an OS that comes with a POSIX-like shell, e.g., NetBSD's sh, FreeBSD's sh, OpenBSD's sh and Linux's sh, which is derived from NetBSD's sh.

The author of this blog post begins his demonstration of shell wizardry with the "history" command. This command does not exist in POSIX sh. On NetBSD I use "fc -l 0". Go figure, it is more portable (nevermind fewer keystrokes). The scripts I write in NetBSD sh run on FreeBSD, OpenBSD, Linux, and a number of other OS without any modification. I do not have learn multiple shells to do work. On BSD, I also use the POSIX-like scripting shell (sh) as the interactive shell.

The best part is I do not have to install anything, it has already been included, no worries about system requirements. All these OS require a POSIX-like sh. None of them require an IDE.

Re: Become Shell Literate

#250

I don’t think this is necessarily true anymore. Today we have much more intuitive tools at our disposable such as vscode. I understand some people were raised on grep and vim, and it is like a second nature to them, but actively encouraging people to use these tools in 2020 in light of the alternatives is not pragmatic.

Much more intuitive, and much less useful.
Post reply on HN