Live data from Hacker News

Things I Wish I'd Known About Bash

zwischenzugs.com

101–110 of 272 posts

Re: Things I Wish I'd Known About Bash

#101
post #54

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

Thanks, but I think this validates a demand for real hypertext.

Re: Things I Wish I'd Known About Bash

#102

Earlier 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.

> old proprietary OS or very limited embedded OS

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

#103

Earlier 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`

If you actually //need// bash ask for it, not sh.

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

#104

Earlier 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.)

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.

Re: Things I Wish I'd Known About Bash

#105
post #3

> 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)" = '' ]

Does the second only work with bash? Because IIRC it didn't work with FreeBSD's /bin/sh, you needed the initial x too.

Re: Things I Wish I'd Known About Bash

#106

Earlier 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?

It had a trailing >, https://github.com/junegunn/fzf

Re: Things I Wish I'd Known About Bash

#107
post #52

Using 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 have since gotten out of the habit, but when I was just starting out I gave myself CTS one Christmas doing a giant refactor with just vi to remove a disasterous idiom from the codebase that was O(n^2).

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

#108

Earlier 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,…

The problem is most people don't want to consider themselves "serious bash scripters" but still think they can write bash, which always results in unstable and vulnerable scripts. Python on the other hand can be written by unserious python scripters and more often be at least accidentally correct. Another big issue is that the quoting, escaping and expansion rules in bash can be daunting even for serious bash scripters, with silent errors or completely different behaviour just because you forgot a : before (or was it after?) the $-

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

#109

Earlier 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 see so many #!/bin/sh scripts with bashisms in them. These scripts are broken and will cause errors. /bin/sh is not always Bash even on Linux systems. It definitely is not on BSDs. There is no reason to use Bash for shell scripts when you can do the same thing portably.

Re: Things I Wish I'd Known About Bash

#110

Earlier 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.

Thing is that Bash is something you can assume to be reasonably widely available[0] — like Perl or Python — but I wouldn't expect to have to avoid any features from the last 10 years of either of those two. Sure, a certain grace period is to be expected but I think 10 years is way past that.

[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...].

Post reply on HN