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.
Any resources/recommendations for truly learning SQL? I feel pretty comfortable with the basics, but could certainly stand to improve my SQL toolkit!
Become Shell Literate
291–300 of 341 posts
Re: Become Shell Literate
#292Re: Become Shell Literate
#293Learning 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.
Any resources/recommendations for truly learning SQL? I feel pretty comfortable with the basics, but could certainly stand to improve my SQL toolkit!
I'm a big fan of Markus Winand: https://use-the-index-luke.com/
I've got a bunch of SQL resources I've collected on my blog that you might find helpful: https://simonwillison.net/tags/sql/
Re: Become Shell Literate
#294Someone 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…
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- this is not supported in PyCharm (or atleast I don't know how to get PyCharm to do it) so I wrote a script that runs in the background of my shell watching for changes on files on my project and running appropriate tests.
The point if an IDE doesn't have a quick way of doing something that is necessary for your workflow, it doesn't mean that the 20 other things that the IDE does are useless. Any working developer should continue to be able to extract value from the features that the IDE provides and jump back to fill the holes themselves (via shell scripts or what have you) instead of saying "Whelp this means IDE is a crutch now and I must revert to only using 'Unix as IDE' and only relying on sed/awk/grep and friends" to aid my development workflow.
Re: Become Shell Literate
#295Earlier quoted context omitted.
> 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/
They can still be both! You can flip the general structure of man pages to be examples first while still having all the complete reference material after.
The downside of that is that searching for something would mean I'd first get the examples, and then the reference.
Re: Become Shell Literate
#296It still strikes me that after all this time, the next step in the direction of the author is to use an editor like ACME ( https://en.wikipedia.org/wiki/Acme_(text_editor) ): use the shell to its maximum power, where the output of a command can be edited and used to control the existing interface. Take for instance this video: https://www.youtube.com/watch?v=4djoOiLste0 The author shows how the output of "git status"…
Your git example is very similar to what can be done in my terminal, [Extraterm](https://extraterm.org/). See demo here: https://extraterm.org/features.html#reusing-command-output
Thanks for the tip about Acme. I'm always looking for ideas about how to improve integration between the terminal based work flows and other applications, command line, GUI, or others.
Re: Become Shell Literate
#297Earlier quoted context omitted.
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.
I thought the way you wrote it was clear but these comments got me curious what the various conventions might be so I took a quick look at :help in Vim (since it lists an awful lot of key bindings). I'm now officially confused and don't think you can go too far wrong.
In some contexts :help notates things as characters (ex zh, zH, and z). In other cases I'm seeing things written as and . There's also CTRL-H (instead of ) but I'm not seeing shift written out like that for whatever reason. Sometimes they get mixed (I'm not sure what the rules are) such as for hh and hh. Amusingly enough, :help appears to treat Meta-{char} as case sensitive but CTRL-{char} as case insensitive (I assume there's a reason). I also spotted a (for the keypad).
What an amusingly pointless distraction!
Re: Become Shell Literate
#298Earlier quoted context omitted.
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.
I’m not sure why you think CTFs/security has an extra focus on the command line? Most of the security people I know spend their days staring into IDA…
As security person I run stuff in command line as many tools are there and they really are mostly scripts. I don't really need to do much shell magic to do stuff. If I actually need something special I will write a python script.
Re: Become Shell Literate
#299I 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…
If you work with mechanical or electrical engineers, then you're going to run into Windows machines pretty quick, and then you need to convince them to install minGW to run your shell scripts. Sure, shell scripts are portable between Mac and *nix, but you're leaving out a large elephant.
Depending on your needs, the Windows port of Busybox might do the trick.
Personally, I don't like the shell that much. As others pointed out, it is a consistency-lacking set of programs that often do only trivial tasks (by design).
A proper cross-platform scripting language such as Perl, Python or Newlisp. The latter is very much like Busybox : it packs a lot in a small single executable (plus it is a Lisp-like language so the syntax is simple and the documentation is good).
Re: Become Shell Literate
#300I 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…
From my experience, the capabilities IDEs and unix tools offer are mostly orthogonal. Also, your arguments against consistent UX has the solution of just writing a simple wrapper around the offending tool (or using newer ones, e.g., ripgrep and fd). `tldr` also tells you the correct interface quickly.