Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Become Shell Literate

drewdevault.com

Post reply on HN
Print view View original

281–290 of 341 posts

Re: Become Shell Literate

#281

Post by vram22 »

divbzero wrote: post #123
combatentropy wrote: post #63

Earlier quoted context omitted.

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…

> The Linux man pages are upside down. Examples don't come till the very end, if at all. man pages are meant to be a full reference, not a quick tutorial. To get the quick tutorial others have already mentioned cheat.sh [1] and tldr pages [2] is another good resource. [1]: https://cheat.sh/ [2]: https://tldr.sh/

> man pages are meant to be a full reference, not a quick tutorial.

Yes, and for both quick and longer tutorials, there are also these things called books and courses - both of which are available in hard copy / offline as well as soft copy / online versions from many years now :) Many of us grew up using them and investing in them for our careers ...

Re: Become Shell Literate

#282

Post by hibbelig »

coliveira wrote: post #275
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…

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.

And vice versa! The IDE will show me the inheritance hierarchy. It will help me find places where a method is called (and knows to skip like named variables and other methods that happen to have the same name).

Re: Become Shell Literate

#283

Post by combatentropy »

coliveira wrote: post #279
combatentropy wrote: post #215

Earlier quoted context omitted.

Sorry, I meant Shift-G. I can no longer edit that comment.

In most keyboards Shift-G is the same as G, otherwise it would be g.

Ha ha, you're right, in a way. It depends on whether you take G to mean the figure on the keyboard or the figure on the screen.

The figure on most keyboards is G. Yet when you press it, it puts on the screen, g. Chromebooks are better in this way. Their keyboards are labeled in lowercase.

I actually went back and forth between saying Shift-G, or just G, for this very reason. So I erred on the side of clarity.

Re: Become Shell Literate

#284

Post by efrecon »

spicyramen wrote: post #85

Our codebase uses tons of shellscripts and Python. Shell has been great for running installations tasks. Recently we added presubmits and added shellcheck utility to check for style and syntax. Any suggestions for adding unit tests for she'll scripts will be great. I'm planning to unify the syntax across the board

Try shellspec for tests. https://shellspec.info/

Re: Become Shell Literate

#285

Post by pjmlp »

tracyhenry wrote: post #253
dragonwriter wrote: post #242

Earlier quoted context omitted.

> 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 wh…

I use IDE mainly for code editing and exploration (e.g. jump from usage to definition), for which I can't see how shell is easier. Modern IDEs have shell built-in so when I finish coding, I can just open up a terminal inside IDE to run shell scripts. Effectively I'm getting the best of both worlds. I never knew that I have to follow some sort of rails laid by IDE designers, which I think it's a very common misconcept…

Shells inside IDEs are an idea that goes back to Xerox PARC workstations, the UNIX folks just have an hard time grasping that in spite of urban myths, there aren't other ways to achieve the same.

Even better, because IDE integrated shells are many cases graphical REPLs with additional interaction capabilities and graphical abilities.

As for the travel into memory lane, here out of 1977,

https://en.wikipedia.org/wiki/Xerox_Development_Environment

You can have a nice view how it worked, by following the Wikipedia links, or checking the presentation on Mesa/Cedar, which was the evolution of XDE as Mesa evolved into Cedar, and one of the latest version of XDE as well.

"Emulating a Xerox Star (8010) Information System Running the Xerox Development Environment (XDE) 5.0"

https://www.youtube.com/watch?v=HP4hRUEIuxo

"Eric Bier Demonstrates Cedar"

https://www.youtube.com/watch?v=z_dt7NG38V4

And naturally Smalltalk-80 and Interlisp-D enviroments that precedded it,

"Emulating Smalltalk-80 DV6 on a Xerox 1186 (6085 Daybreak Development Kit)"

https://www.youtube.com/watch?v=dpjRZnUw8MU

"The Interlisp Programming Environment", 1981

http://larry.masinter.net/interlisp-ieee.pdf

The lack of teaching of the computing world outside Bell Labs leads to a UNIX cult, unaware of the progress that was actually already available in the 70 and 80's, but unfortunely failed to pick up due to several reasons, so in the end there is this idolatration of the UNIX shell.

Re: Become Shell Literate

#286

Post by pjmlp »

coliveira wrote: post #275
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…

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.

Re: Become Shell Literate

#287

Post by pjmlp »

rubatuga wrote: post #264
addicted wrote: post #260

Earlier quoted context omitted.

I used git bash and it worked just fine. But now you can use Linux subsystem for Windows. I don’t have much experience with this so I’m not sure how well it works in practice but most people seem to rave about it.

More than once did I type ls -lah into a command prompt window to be sorely disappointed.

Powershell has an ls alias.

Re: Become Shell Literate

#288

Post by Reelin »

porknubbins wrote: post #222
ddevault wrote: post #80

Earlier quoted context omitted.

>The Linux man pages are upside down. Examples don't come till the very end, if at all. You only learn the tool once. Every subsequent time you visit the man page, the information you're probably looking for is frontloaded. Just scroll to the bottom if you want examples?

I always thought someday I would become a hardcore Linux hacker and know all the commands and flags but the reality is I have to relearn every time. Who spends that much time just in the command line these days? I’m sure some people do but I don’t know what they do unless its CTFs or security related.

> Who spends that much time just in the command line these days?

Just stop using GUI utilities. It really is that simple. If you just don't use them you'll end up in a shell out of necessity because you still need to get things done.

Of course, the majority of my time is spent in my web browser reading documentation followed closely by vim for writing things. Actual time spent interacting with CLIs is a small minority at the end of the day.

Re: Become Shell Literate

#289

Post by em500 »

enriquto wrote: post #152
geophile wrote: post #146

Earlier quoted context omitted.

Read a CSV file, foo.csv, and sort by the sum of the 4th and 7th columns (which are integers): read -c foo.csv | sort (*x: int(x[3]) + int(x[6])) I suppose we could argue about what is a "natural" operation. Marcel grew out of a set of tasks that were "natural" in the domain I was working in. An important part of that domain was operating on databases, and clusters of nodes, and databases on those nodes. So marcel ha…

> Read a CSV file, foo.csv, and sort by the sum of the 4th and 7th columns (which are integers): Yes, that's a much better example. Here the "obvious" shell solution involves using awk to compute the sum of the two columns and putting it as the first field, sorting by the first field, and then removing that field. I guess a "rosetta stone" of such examples (e.g. on the frontpage of the site) would make a strong case…

Concretely,

    awk -F, -v OFS=, {print $2+$3, $1, $2, $3}' foo.csv  |  sort -n  |  cut -d, -f2-

Re: Become Shell Literate

#290

Post by avl999 »

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…

You have it totally backwards, people who use IDEs don't like "dumbed down code" for the sake of the IDE. Nor are languages like Java designed with their IDEs in mind. The IDE is designed with the full language spec in mind, understands the language at the AST level and supports the full set of language features and all their permutations. A developer who is writing code in IDE is utilizing every permutation of what the language provides and it is upto the IDE to understand it.

IDEs for the most part are not covering for language flaws, they are helping developers be more productive by removing the need to focus less interesting parts of the process and focus on the the problem being solved. While the need for an IDE is more important in some languages over others, there are a set of common problems that exist in every language that the IDE can help solve (navigating the codebase by jumping around to symbol definition/usages, auto importing packages/modues, intellisense, refactoring).

Refactoring does not mean going back and refactoring 6 weeks worth of work that you seem to have in mind. Most people who refer to refactoring are referring to it in the context of multiple small refactors during very short development cycles (every few minutes or hours). My workflow and the workflow of many developers I have worked with goes like this:

* Write some code (not more than 200-500 lines)

* Write tests

* Refactor if needed- potentially rename variables, potentially extract some code into methods, potentially pull stuff up into constants, potentially introduce a new class or interface, potentially change types of certain members, potentially visibility of certain members or methods.

* Repeat for the entire workday when you are not in meetings.

Refactoring- specifically the kind of small scale refactoring that you do as go through your workday to me is almost as important a part of the development process as anything else and IDEs remove almost all friction from it by removing any cognitive load of the task from the developer.

Post reply on HN