bash or its minimal version such as ash is critical for embedded systems where python/perl etc are too fat.
Things I Wish I'd Known About Bash
91–100 of 272 posts
Re: Things I Wish I'd Known About Bash
#92Earlier quoted context omitted.
I disagree. Here's how I decide: Do I need to manipulate rich data structures like hash-maps or nested lists? That sort of thing tends to stretch the capabilities of Bash to its limits and I tend to set the bar fairly low here. Is the program oriented around commands? If I'm gluing executable scripts and binaries, using bash is often superior to a scripting language. Argument passing is more natural and convenient an…
As someone who has to occasionally modify 100+ line bash scripts written by Coworkers from Christmas Past which matched your spec in terms of what they had to do, please please just use Python (or similar). Yes, you will have a few extra lines but it will be vastly more readable and maintainable. And yes, I know I will get the standard the person who wrote the script did a bad job but at some point it should be okay…
As someone who also has to semi-frequently modify 100+ lines bash scripts written by others, I'd suggest every serious bash scripter read the bash man page. It is much smaller than any book on Python.
For scripts written in Python, I'd use a similar argument and suggest every serious Python scripter to learn Python. As for Perl, or Ruby, or Julia, or anything really. It's just that learning bash from its man page is, IMO, much easier than learning any of those languages to the same degree.
Of course – and it goes without saying — that some things are just not suited to bash, and in those cases a suitable language/framework must be used and learned if not learned. As far as process calling, environment management, or stdio streams management are concerned, bash is better suited than (all the other languages I've tried) Python, Ruby, or Go.
Re: Things I Wish I'd Known About Bash
#93 `` vs $()
Another recent example I encountered is from the online book http://neuralnetworksanddeeplearning.com, there are some confusing ambiguities and plain misleading contradictions in NN terminologies, one being: multi-layer perceptions do not use perception neurons, these things can really screw with you while you're learning, especially the more subtle ones.
Some authors seem to have the ability to have full empathy for the novice while retaining expert knowledge and deep understanding by being able to both predict and answer relevant questions at the right point in an explanation at the right level of detail.
Re: Things I Wish I'd Known About Bash
#94Earlier quoted context omitted.
> Stuff like that has been huge pain in my ass over the years. Some clever programmer uses some bash-ism and the build breaks on some ancient hardware that doesn't have bash. Shouldn't the problem be the "ancient hardware that doesn't have bash" itself?
A brand new macbook pro will not have bash4.
The machine may not be ancient but I would still argue that the problem there is the ~10 year old version of Bash that Apple has decided to ship rather than the programmers that use features added to the shell within the last 10 years.
(I should add that I don't know what version High Sierra ships with but Sierra seemed to ship with 3.2.5x-ish which was 9 years old at the time.)
Re: Things I Wish I'd Known About Bash
#95Earlier quoted context omitted.
Yeah, but why are you trying to use a search engine that cares less and less about exact matches, when there's a manual? >man bash /\$\( # search pattern needs escaping ... value is evaluated as an arithmetic expression even if the $((...)) expansion is not used (see Arithmetic Expansion below). Word split‐ ... n # go to next match Command Substitution Command substitution allows the output of a command to replace th…
Man pages are specifically reference documents, not tutorials or guidebooks. To say one should use a man page is to say that one must completely digest the entirety of the tool prior to ever actually using it. That’s just simply not feasible, nor should it be expected of anyone beyond trivial tools. Man pages simply don’t provide the context for solving a problem like a guidebook or tutorial would, which is why there…
I generally find things easier to learn with reference documents than tutorials unless I'm unfamiliar with the problem domain and have no mental model to map things to. That's very rare these days, so reference documents are the way to go.
Amusingly, reference documents are themselves increasingly rare, and what you usually get is a rough tutorial and set of examples that cover perhaps 15% of the feature set, and need to dive into the source to figure everything else out.
Re: Things I Wish I'd Known About Bash
#96Can someone explain :h as the article's description was not clear at all to me what was going on there.
It's !:h - not just a plain :h $ echo foo /bar foo /bar $ !:h echo foo foo It's under `man bash` in the History Expansion section.
That's not quite what the author was talking about; your example does the same thing as !:0-
This is what the author meant:
$ echo foo/bar
foo/bar
$ !:h
echo foo
fooRe: Things I Wish I'd Known About Bash
#97shellcheck ( https://www.shellcheck.net ) is an absolute godsend when writing Bash/POSIX sh scripts. It catches so many errors that I think it's a must have in every programmer's toolbox. It even catches bash-isms when you are targeting POSIX sh. It saved me many many hours of grief trying to debug shell scripts I wrote and changed the way I write them for the better.
Targeting POSIX as much as possible is really important if you don't want to force Bash on people, especially with open-source public code. Many OSes don't have Bash in the default install, but many just assume that bash is available on all the target systems.
Re: Things I Wish I'd Known About Bash
#98Earlier quoted context omitted.
Is there some trick to searching man pages that I don’t know? Because my usual experience is: type man foo type /-p type n n n n n n n n n as there are a bunch of matches like “...does bar when combined with -p...” A presentation of man pages that used hypertext would make me a lot happier.
man man man less Not a joke. Learn the simple tools that help you daily.
Did you have something in mind? I’ve read those man pages before, and I read them again today, and with the possible exception of tags in less (but I’m not sure about that), nothing seems relevant.
Re: Things I Wish I'd Known About Bash
#99Using readline is a great thing to know about too. My favourite little-known readline command is operate-and-get-next: https://www.gnu.org/software/bash/manual/html_node/Miscellan... You can use it to search back in history with C-r and then execute that command with C-o and keep pressing C-o to execute the commands that followed that one in history. Very helpful for executing a whole block of history. For some reaso…
I've overridden ctrl-r in my local Bash to search with fzf[0] and I'm using my history so much more now. Didn't know about ctrl-o though, it sounds great! I hope that my ctrl-r override doesn't somehow break it. [0]: https://github.com/junegunn/fzf E: Fixed link.
That link is a 404 for me?
Re: Things I Wish I'd Known About Bash
#100Earlier quoted context omitted.
Is there some trick to searching man pages that I don’t know? Because my usual experience is: type man foo type /-p type n n n n n n n n n as there are a bunch of matches like “...does bar when combined with -p...” A presentation of man pages that used hypertext would make me a lot happier.
If foo has a Texinfo manual (GNU tools like bash usually do) then you can try `info foo` and search the index with i or I for -p. Texinfo manuals also have hyperlinks you can press enter on. info is a greatly underused system and I'd recommend any *nix users to spend some time learning how to navigate it.
Thanks. Is there a good way to open that in a browser, rather than a console?