Become Shell Literate • Hacker News Board

Re: Become Shell Literate

#311

Post by antb123 » Sun, Dec 13, 2020, 3:21 PM UTC

voidhorse wrote: post #238

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…

Shell commands really have lasted... I mean if I think of the computer skills that I learned as a teenager that I still use today

1) shell commands

2) sql

3) vi

4) some programming languages c, pascal(?), basic(?)

Everything else has changed multiple times. Maybe that means its worth investing on learning them.

Re: Become Shell Literate

#312

Post by patrec » Sun, Dec 13, 2020, 3:25 PM UTC

gray_-_wolf wrote: post #225

patrec wrote: post #195

Earlier quoted context omitted.

Yeah, it's annoying that unix filenames and shell quoting are both fundamentally broken and that (as above) people would generally (knowingly) write a a broken-for-spaces-in-filenames version by default because it's easier (and the author no doubt knew he'd not encounter spaces in his repo). Having said that, it's not very hard to fix, I'd probably write something like: git status -s | awk -vORS="\0" 'gsub(/^ D /,"")…

But now you require gnu awk, it no longer works under posix (so for example busybox). Which sucks a bit.

It'll work with more than gawk (e.g. mawk as well) but yeah, it will not work with busybox awk. In the context of an interactive shell command I doubt many people care much about posix; indeed I struggle to recall any context in which I ever cared about posix compliance as such. Unless you have an personal or professional interest in fringe operating systems posix compliance is mostly of interest as an imperfect proxy for answering the question will it work on both Linux, macOS/iOS (and maybe busybox).

Anyway, I suspect the following is POSIX compliant:

    git status -s | awk 'gsub(/^ M /,"")' | tr \\0 \\n | ...

Re: Become Shell Literate

#313

Post by doppioandante » Sun, Dec 13, 2020, 3:25 PM UTC

larkinrichards wrote: post #138

I spend many hours of each day ~programming~ wrangling text files and I use macos + zsh + textmate2 for my daily drivers. I see shell as an important proficiency because it helps maintain a lower-level understanding of how the "magical" GUI "works," which often helps in debugging obtuse errors, and I'm sad to encounter more engineers who are completely unfamiliar with it. When it comes to examples like that posted by…

This is exactly how I would have done it, just using my editor of choice (kakoune) instead. I also wrote on Drew's mailing list in case anyone is interested: https://lists.sr.ht/~sircmpwn/public-inbox/%3CCAKW6382rV5iW2...

Re: Become Shell Literate

#314

Post by mannykannot » Sun, Dec 13, 2020, 3:36 PM UTC

saagarjha wrote: post #292

mannykannot wrote: post #267

Earlier quoted context omitted.

What is your specific claim here?

macOS tools generally do not match what Stack Overflow tells you.

Ah, yes - I have come across some differences in command-line flags and default behaviors between macOS and the nominally equivalent tools as implemented in Linux or specified by Posix, and sometimes, on Stack Overflow, you will find people answering Mac-specific questions on the Dunning-Krugeresque assumption that it is the same as the others. In general, one should always verify Stack Overflow answers before using, but that often gets you closer to the answer you need than one starting from a scenario that simply isn't available on your version of, say, Xcode.

The same goes for systems derived from BSD - in fact, I wonder if some of the differences between MacOS and Linux comes from the former's origins in Mach/BSD via Nextstep.

Re: Become Shell Literate

#315

Post by agumonkey » Sun, Dec 13, 2020, 4:15 PM UTC

avl999 wrote: post #294

agumonkey wrote: post #114

Earlier quoted context omitted.

Nah, the issue is that whenever the IDE doesn't provide a shortcut for whatever you're back to negative one. That's why people like mechanisms (grep, sql or similar) over policies (here, whatever is given to you by the IDE), you can always adapt. Other than that, a good deal of open mindedness and skillful use of IDEs is not a bad trait. Let's not be extremists.

> Nah, the issue is that whenever the IDE doesn't provide a shortcut for whatever you're back to negative one. You are not back to negative one, more like you are at square 85. There is nothing stopping a developer from supplementing something that the IDE doesn't easily support. For example I use PyCharm these days and I when I make a change to a file I automatically want the test associated with that file to run- t…

Maybe I was traumatized by eclipse. Anything to extend in it required a federal reunion and a taskforce.

Re: Become Shell Literate

#316

Post by nec4b » Sun, Dec 13, 2020, 4:52 PM UTC

saurik wrote: post #160

hagy wrote: post #124

Earlier quoted context omitted.

I strongly agree with this narrative and it matches my own experience. I spent 9 years of college and then grad school using exclusively either vi or emacs because I believed IDEs were a crutch that weak engineers relied upon. It wasn't until I got a real job that I found myself forced to learn a proper IDE (IntelliJ). It blew my mind just how powerful the IDE was and how it massively increased my productivity. Putti…

I think part of this is that the people who use IDEs then prefer the actual code to be dumbed down to the point where the IDE can both understand it and then is required to manipulate it; I hate programming in Java because it is a language kind of designed to make it hard for me to build my own rapid abstractions... which of course would break the ability of the IDE to parse it at all much less refactor it; but, I th…

Which powerful language do you use that can't be understood by the IDEs. Don't you think that if your compiler can understand it, the IDE can too? :)

Re: Become Shell Literate

#317

Post by nec4b » Sun, Dec 13, 2020, 4:56 PM UTC

j1elo wrote: post #104

gfxgirl wrote: post #29

Someone should write "become IDE literate" as a response to opening of using vim with no extensions and using grep a lot. I've been using editors that are language aware since at least the late 90s. Depending on the language they'll show me all references, take me to the definition or declaration, stack those jumps so as I follow the links I can pop back a level to where I was. All of this is instant. 1000x faster th…

> take me to the definition or declaration, stack those jumps so as I follow the links I can pop back a level to where I was. Know any C/C++ IDE that would do this? I transitioned from Qt Creator to VSCode and none of those have helped me with this cool nicety you mention. EDIT: I should add that for me, exploring foreign code bases has been hugely improved since I discovered Sourcetrail, so I'd suggest having a look…

Visual studio code can do this.

https://stackoverflow.com/questions/35424367/how-to-navigate...

Re: Become Shell Literate

#318

Post by jancsika » Sun, Dec 13, 2020, 5:53 PM UTC

combatentropy wrote: post #63

jancsika wrote: post #18

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…

> Thankfully, like you said, there is now Stack Overflow.

It's interesting because we can imagine a history where the docs were written much more professionally with such examples. And we can imagine that work having lowered the barrier to entry such that a critical mass of users becoming compositionally literate in shell scripting. (And perhaps shellcheck being written much earlier in this alternate history.)

But Stack Overflow not only obsoletes such an effort, it IMO obsoletes becoming literate in shell scripting, at least in the way the author describes. SO's existence is equivalent to being able to write a natural language query on the command line which "automorphs" into the relevant Stack Overflow example. At that point you just need to understand basic piping, redirection, and enough of the syntax to spot-check the magic answer in order to make small changes for a use case. That's a different kind of skill.

Re: Become Shell Literate

#319

Post by geophile » Sun, Dec 13, 2020, 6:13 PM UTC

em500 wrote: post #307

enriquto wrote: post #301

Earlier quoted context omitted.

I think this code does not fulfill the task: you need to sum columns 4 and 7, and keep the rest of the data intact in the output.

You're right, that should be awk -F, -v OFS=, '{print $4+$7, $0}' foo.csv | sort -n -k1 -t, | cut -f2- -d, Explanation: awk -F, -v OFS=, sets the input and output column separator to comma, '{print $4+$7, $0}' outputs the sum of column 4 and 7 before the rest of the line. sort -n -k1 -t, sorts the file numerically on column 1, with comma separator. cut -f2- -d, removes column 1, with comma separator. This is of cours…

> This is of course not robust for general CSV files, but I don't think OPs marcel is either. A robust solution requires a proper CSV parser.

I haven't tested corner cases, but marcel relies on the python csv module, which is probably better than any initial attempt at a parser that I could write in an hour.

This is what I meant about sublanguages. Many people, (myself included), would need to go to the man pages to find the necessary arguments to awk, sort, and cut. I find it much easier to just write a little Python, even if the end result involves more typing.

Re: Become Shell Literate

#320

Post by coliveira » Sun, Dec 13, 2020, 6:28 PM UTC

pjmlp wrote: post #286

coliveira wrote: post #275

Earlier quoted context omitted.

Yes, the IDE is supposed to be faster for the things it was designed to do. That's the whole reason for its existence. But the shell allows you to do much more than your IDE was supposed to do. If you don't learn it, you're confining yourself to the boundaries set by the IDE.

The IDE as designed at XEROX PARC, and in most Smalltalk, Common Lisp, Java and .NET ones, has a shell as part of its features, there are no boundaries.

But if it includes a shell, you still need to learn the shell, don't you? It doesn't matter from where the shell was called, a real terminal or an emulation.