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.
Become Shell Literate
231–240 of 341 posts
Re: Become Shell Literate
#232Earlier quoted context omitted.
One of the best things (in my opinion) shells could have done is do newline separated filenames instead of spaces, which would make filenames with spaces much easier to handle (you can have newlines in filenames, but in this magic world let's ban those).
That would pose problems also. The real solution, with no need to magic as you say, is to disallow spaces at the filesystem level (just like slashes and the null character are forbidden). For users typing filenames, this shouldn't be a problem, as those can be encoded e.g., as unicode's non-breaking space. Using space as a separator is a very important power, that other programming languages share. In what other prog…
You can have spaces in F# variable names and functions :)
Re: Become Shell Literate
#233Earlier quoted context omitted.
I mean shouldn't you feel bad if you're trying to discourage active engagement in a topic if one doesn't do it in a specific "correct" way? Personally I've found a diverse set of viewpoints to be incredibly valuable on the teams I've been a part of. I have my own biases on testing, stability, performance and seeing how others approach it has broadened my understanding of how to build software. To put it another way,…
I literally said that "IDEs are great tools" and my whole argument was that people can broaden their understanding by also learning some shell in addition to their IDE. So not sure what your point is.
I'm sure that was your true intent, but the way you framed it made it seem like it was in exclusion(the dismissive "Cool." at the top didn't help).
At the risk of sounding patronizing as much as we'd like to everything to be binary pass/fail and survive on the technical merits or semantic details, how you frame things and driving communication in an inclusive way is important of you want to convince people that something is worthwhile.
Re: Become Shell Literate
#234Earlier 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.
Devops-style workload means a lot of the time spent in the console.
Even then, I lookup the quoting difference between $* and $@ every single time, and how to use `read`. Or more likely decide it's time to drop bash at that point...
Re: Become Shell Literate
#235Earlier 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/
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.
Re: Become Shell Literate
#236Earlier quoted context omitted.
Hint: if you're still using grep to search files rather than a file , install and start using the "newer generation" of greps (ag, ripgrep etc). You likely won't believe the speed. I use ag many times a day to search 10,400 files comprising about 800k lines of code, and it is in every meaningful way completely instantaneous. It also understands repository structures, and so won't waste your time there. It seriously c…
Integrating rg and fzf into vim changed my programming life. I find that combo pretty incredible and something I haven't found in IntelliJ. I usually find myself switching back to my shell and then back to IntelliJ.
Yes, I probably should have said "use ag in the context of emacs" just to clarify how it gets used.
Re: Become Shell Literate
#237Hear hear! I remember a senior dev at my first job being stymied by the command line; he was very adept in the IDE, but had a hard time navigating directories. It was definitely a disadvantage when it came to getting stuff done. One thing the author didn't cover is how you can share reified knowledge when you write shell scripts. (It's the same with other programming languages, but they aren't as easy to write or mod…
I used to joke at my previous position that I was a "programmer-lite", because I was in a support role and they wouldn't let me write code, but for some reason I was allowed to write and commit bash scripts, so all of the programmers started coming to me to write the shell script interfaces to their programs. I took pride in making the scripts "safe", running them through shellcheck and actually checking the exit status on things.
To this day, I've still never quite gotten the hang of the whole "trap" mechanic, though...
Re: Become Shell Literate
#238I 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 pipeline can, often in two keystrokes instead of N trial and error command inputs because you forgot, yet again that, e.g. while `grep` takes a pattern argument before a path, `find` does the opposite--in spite of POSIX there's an incredible lack of UX standardization when it comes to unix tooling.
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. Most of us do most of our work on one machine, in one environment, so at the end of the day, it really comes down to preference. 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--if you took the time to learn the IDE keybindings and the IDE is on par with anything Jetbrains puts out, you're not losing in efficiency at all and possibly making gains when it comes to certain tasks.
Re: Become Shell Literate
#239I 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…
It’s even worse if you man test: you’re directed to the shell builtins page, that’s a few hundred pages long.
For builtins, use help. 'help test'
Re: Become Shell Literate
#240Someone 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…
I do like my IDE but my one complaint with leaning on it a lot is that it lets you write code that is harder to understand if you don't have that IDE readily available. For example, if you name a member "flag" and you have several types with the same member, your IDE can tell you where this flag is used, so it's not a big deal if you wanted to refactor or are trying to track down a bug. But god help you if you're loo…
I think it also comes into the language design. If you expect programmers to use an IDE, then language features and best practices can require large amounts of boilerplate, on the expectation that the IDE will be generating that boilerplate. For languages expecting no IDE to be used, the language itself needs to avoid that boilerplate.