Live data from Hacker News

Become Shell Literate

drewdevault.com

81–90 of 341 posts

Re: Become Shell Literate

#81
post #4

I wish that shell would be more sane. I don't think that a shell should be a complete programming language. If you need a programming language, then better use one. There is xonsh if you are looking for something like this. I think there should be a better bash with an very clean and consistent interface. Some of the most commonly used utils like awk '{ print $2}', sed, grep, sort, ... should be included out of the b…

Your wish has been granted: awk '{ print $2 }' can be replaced by 'cut -f2'. And all of the commands are part of the set of POSIX command-line utilities having been included on Unix systems since basically forever, with awk (the one true awk) having been introduced only in 1983 or so.

Re: Become Shell Literate

#82
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…

A literary man creates new meaning out of words. You can do this in the shell by combining tools in new ways. You can not do this easily with an IDE, it only has a predefined meaning. Using an IDE is not literature but transcription.

Re: Become Shell Literate

#83
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…

Cool. Still, a lot of people start out programming with complex IDEs and end up being unable to run their code without the "play" button of their IDE. Starting out, or only ever leaning an IDE is also hiding a lot of things from you. For me, knowing the shell isn't about IDE vs. shell tooling, it's about, whatever you use, be aware and knowledgeable about the foundation and being able to do stuff even if there is no…

Cant we make this argument for any level of abstraction?

A lot of people start out with shells and end up being unable to understand how to construct a switch or adder in logic gates. A shell is a great tool but shouldn't be a crutch.

Re: Become Shell Literate

#84

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 would probably love the tldr[1] command, then. It's a user maintained library of common example incantations of any given command. Nowadays I check it before `man`.

[1] https://tldr.sh/

Re: Become Shell Literate

#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

Re: Become Shell Literate

#86
To me the main argument for getting used to the shell is that it's a compounding investment. Sure, initially one would be slower using a shell driven workflow as opposed to someone using an IDE. However, the more you stick to it, the more you find out that the skills you've gathered are very transferable and are applicable across languages, projects, types of projects, tasks, types of work, and even whole industries.

If you know the shell well and are well versed in a good CLI text editor such as Vim or Emacs, the programming language of the day doesn't matter. Whether you're coding or setting up some environment doesn't matter. Whether you're on your computer, connected to some server, or an embedded device doesn't matter.

EDIT: And eventually, you're not slower than someone using an IDE either.

Re: Become Shell Literate

#87

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 Rust had five mutually incompatible borrow-checkers which get called based on who wrote the code for a particular language construction-- that might get across the frustration I feel when using the shell.

You mean like the five mutually incompatible async solutions in rust?

Re: Become Shell Literate

#88

Earlier quoted context omitted.

Cool. Still, a lot of people start out programming with complex IDEs and end up being unable to run their code without the "play" button of their IDE. Starting out, or only ever leaning an IDE is also hiding a lot of things from you. For me, knowing the shell isn't about IDE vs. shell tooling, it's about, whatever you use, be aware and knowledgeable about the foundation and being able to do stuff even if there is no…

Cant we make this argument for any level of abstraction? A lot of people start out with shells and end up being unable to understand how to construct a switch or adder in logic gates. A shell is a great tool but shouldn't be a crutch.

Emotionally, I actually agree with this. I'd love for at least a basic understanding of computers down to boolean logic and the very basics of semiconductors up to the OS level and beyond to be "widely known" by programmers and "computer literate".

At the same time, I know that's extremely unreasonable to expect. I guess for the shell and editor, you can argue you ought to understand it stripped of abstractions, since it's actually the level you're working at, while most people don't work at the logic gate level.

Re: Become Shell Literate

#89
Learning to use the shell and learning SQL are the two skills that have stayed relevant throughout my entire 20 year career.

Other tools and languages come and go, but the shell and SQL just keep on providing value.

Re: Become Shell Literate

#90
post #4

I wish that shell would be more sane. I don't think that a shell should be a complete programming language. If you need a programming language, then better use one. There is xonsh if you are looking for something like this. I think there should be a better bash with an very clean and consistent interface. Some of the most commonly used utils like awk '{ print $2}', sed, grep, sort, ... should be included out of the b…

> I wish that shell would be more sane. Absolutely agreed, shell is in many respects terrible. >I don't think that a shell should be a complete programming language. On the contrary, I think shell should be a more complete programming language! Drop the stringly typing and add actual types (hence eliminating 80% of bothersome awksedgrep magic; yes, no need to tell me it's a real tall order), add proper error handling…

This is exactly the idea behind Powershell. You don't pipe strings between commands, you pipe typed objects etc etc. I'm convinced that if it had better support on Linux it would usher in a new age if shells. As it is though, it would be hard to use it as a daily driver.[1]

[1] https://code.joejag.com/2020/a-month-with-powershell.html

Post reply on HN