Earlier 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.
You might want to search with / -p
Things I Wish I'd Known About Bash
101–110 of 272 posts
Re: Things I Wish I'd Known About Bash
#102Earlier quoted context omitted.
I prefer sh over bash for most of my scripts, but I will sometimes use Python instead.
So you use python instead of sh, but you argue that we should use sh instead of bash, perl, or python. I'm not convinced. IMHO, we should use proper tool for the job instead of making artificial limitations. Bash is proper tool in lot of cases, unless old proprietary OS or very limited embedded OS are targeted.
i.e. all the *BSDs? Many Linux distros that ship with BusyBox only or FreeBSD/Linux type systems (AFAIK Debian and also maybe Gentoo allowed FreeBSD userlands)?
POSIX Sh is quite capable. I maintain even my bashrc POSIX compatible, in order to not have any problems when I want to run my config on some remote machine, or on some local BSD installation (and I did run FreeBSD for more than a year, quite feasible option for a workstation IMO).
Re: Things I Wish I'd Known About Bash
#103Earlier quoted context omitted.
And to make things interesting Ubuntu uses dash as sh https://wiki.ubuntu.com/DashAsBinSh
In fairness, that's just for sh; if for some reason you actually need bash you can just use `#!/usr/bin/env bash`
This comes from more armature script authors not being precise enough with requirements, or not targeting the more common and portable spec.
Re: Things I Wish I'd Known About Bash
#104Earlier quoted context omitted.
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.)
You can assume everyone has a modern bash, and make it the end users problem if they don't, or you can write portable shell scripts and know it will work.
Honestly the things you can't do in posix shell compared to bash border on "use a fully featured language" anyway.
Re: Things I Wish I'd Known About Bash
#105> if [ x$(grep not_there /dev/null) = 'x' ] This is still wrong if the command can output spaces or meta-characters. You should quote the left operand, and then you don't need to prepend x: if [ "$(grep not_there /dev/null)" = '' ]
Re: Things I Wish I'd Known About Bash
#106Earlier quoted context omitted.
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
#107Using 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 knew a quite a few commands but I didn’t know the block indentation commands and that was about a third of my typing over that week.
After that, part of my regular “I’m tired or there’s nothing to work on” routine included reading the accelerator key documentation for my editor of choice. I found all sorts of good stuff and it really made me faster for quite some time. Now I do more analysis work and the accelerators that help there are less numerous. Fast code nav being a critical one.
But some of these tools make it pretty hard to find all their features, which is a shame.
Re: Things I Wish I'd Known About Bash
#108Earlier quoted context omitted.
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,…
As a test, run shellcheck on any random shell-script written by these Coworkers from Christmas Past (or your own past) and it will spew serious warnings on almost every single line, run an equivalent analyzer on an equivalently unserious python file and you might in bad cases get 2 or 3 minor warnings per 100 lines.
The comparison is a bit unfair because just by getting these compiler errors and exceptions from a real language you force yourself into a more serious mental mode of programming instead of happy scripting, but that is just another argument in favor for not using bash IMO.
Re: Things I Wish I'd Known About Bash
#109Earlier quoted context omitted.
I prefer sh over bash for most of my scripts, but I will sometimes use Python instead.
So you use python instead of sh, but you argue that we should use sh instead of bash, perl, or python. I'm not convinced. IMHO, we should use proper tool for the job instead of making artificial limitations. Bash is proper tool in lot of cases, unless old proprietary OS or very limited embedded OS are targeted.
Re: Things I Wish I'd Known About Bash
#110Earlier quoted context omitted.
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.)
Well put it this way: You can assume everyone has a modern bash, and make it the end users problem if they don't, or you can write portable shell scripts and know it will work. Honestly the things you can't do in posix shell compared to bash border on "use a fully featured language" anyway.
[0]: I know POSIX is supposed to be even more widely available but depending on what you're targeting then it may not be the best option [source: https://en.wikipedia.org/wiki/POSIX#POSIX-oriented_operating...].