Live data from Hacker News

Things I Wish I'd Known About Bash

zwischenzugs.com

261–270 of 272 posts

Re: Things I Wish I'd Known About Bash

#261
post #184

Earlier quoted context omitted.

I don't know why not? At the least, rather than Bash, you might consider Perl as a default, lowest common denominator for scripts that need to run anywhere. - It's nearly as ubiquitous as bash. - It has approximately the same kinds of file/path operations built in. - It has reasonably good support for strings/regexes/etc. all built-in, so you don't have to call out to tools like sed/awk/grep all the time and hope tha…

Great point about ubiquity. Perl regexes are the best of breed that everyone else replicates — far better than “reasonably good.” The Perl erasure in this HN thread is startling.

Perl erasure?

After using the linux command line (or its many «relatives» like cygwin, mac os, unixes) for more than 10 years now, I’ve talked to exactly one person that used perl to accomplish anything at all. He used it to edit text files, so he could have done the same in awk/sed/vim in my opinion.

I know more people who write fortran 77 than perl.

People just don’t seem to use (or like) Perl very much.

Re: Things I Wish I'd Known About Bash

#262
post #97

shellcheck ( 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.

like which?

I'm hard pressed to think of a modern unix that doesn't include bash by default. Solaris maybe?

Re: Things I Wish I'd Known About Bash

#263

Earlier quoted context omitted.

The domain under discussion is scripting and specifically comparisons with Bash. Python 3 has not achieved anywhere close to the platform deployment that Python 2.7 has. When the common OS distributions you're likely to need to script on ship with Python 3 as the default rather than python 2.7, we can start using Python 3 in random comparisons with shell scripts. Until then, Python 2.7 is the language for comparison…

Most distros ship with python3 (though `python` will refer to python2). Is there a reason you cannot just say `#!/usr/bin/env python3` in your scripts? I don't see why you require python3 to be the default, am I missing something here?

The first OS I've used that includes Python3 in the base install is Debian 8(Jessie) and I no longer use Debian in production. CentOS 7 does not include Python3 in the base install. You can install it, sure, but why bother when you can just use the python that is already there? Or better yet, /bin/bash...

Again, in the context of this discussion, the whole argument is yet another point in shell's favor. There's no major backwards-incompatible change in the language. With Bash, you just decide whether POSIX compliance is something you need, and that's basically it. Both versions are still supported and no one interrupts discussions to announce that beatings will continue until morale improves whenever the deprecated version of Python comes up.

Re: Things I Wish I'd Known About Bash

#264
post #226

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.

BSD man pages (and many Linux man pages, though a minority) are written in semantic “mdoc” macros, rather than the classic “man” macros that are strictly presentational. If you’re using mandoc ( http://mandoc.bsd.lv/ ) as your man(1) program—the default on OpenBSD and a couple of Linuxes like Void and Alpine—it will use these semantics to generate hyperlinks in the terminal using more(1) and less(1)’s ctags support.…

That’s awesome! I think a table of contents could be nice addition for the HTML version (at least for pages that are longer than less).

Re: Things I Wish I'd Known About Bash

#265
post #122
post #30

I wrote a book on Bash too. The most important thing for anyone to know about Bash is that it's intended as a command language, not a general purpose scripting language. If it's longer than 10 lines, or if it uses two or more variables, you should probably have written it in something other than Bash.

I disagree too. Bash has many downsides, but there are very few languages out there which have the ability to 'connect' different programs so easily. Bash scripts are slow as hell (as most commands have to spawn new processes), it is hard to write "secure" code (if even possible), handling whitespaces can be a pain in the * and the amount of repetition is awful. If your kid has done something wrong, just tell it to w…

I'd rather use perl for these use cases. It's almost as concise as bash regarding subprocess management. It's ubiquitous as bash, and have the python like 2 vs 3 version issue.

Re: Things I Wish I'd Known About Bash

#266
I wasted a lot of time on this one:

If you declare a local variable and set it in the same step e.g: local MYVAR = $(/bin/false) The return code you get is from the local declaration, not assigning a value to the variable. It can be quite confusing when you afterwards check the return code with $? and it returns 0. Avoid it by assigning the value in a seperate command.

Re: Things I Wish I'd Known About Bash

#267

Damn it this boils down to RTFM, specifically the bash man page.

The real 'Learn bash the hard way' is to read the man page top to bottom every 6 months. Ye gods, I've read it so many times… Also: lol at HN downvoting advice to read a tool's docs. Bash is terrible for a lot of reasons, but not because of its lack of informative documentation.

Yes, the bash man page is a treasure trove. Reading the article I kept thinking, "this is in the man page", over and over.

There seem to be things like "Testing" and "RTFM" that many people (including me) resist until they actually try it and see for themselves. I can remember the feeling of revelation when I finally learned to try "$ man foo" on everything...

Re: Things I Wish I'd Known About Bash

#268
post #262
post #97

Earlier quoted context omitted.

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.

like which? I'm hard pressed to think of a modern unix that doesn't include bash by default. Solaris maybe?

everything embedded - OpenWRT/LEDE uses busybox with ash - Android uses mksh? that only supports a subset of bash features. Every Debian/Ubuntu has ash as /bin/sh that only supports POSIX.

Re: Things I Wish I'd Known About Bash

#269
post #268
post #262

Earlier quoted context omitted.

like which? I'm hard pressed to think of a modern unix that doesn't include bash by default. Solaris maybe?

everything embedded - OpenWRT/LEDE uses busybox with ash - Android uses mksh? that only supports a subset of bash features. Every Debian/Ubuntu has ash as /bin/sh that only supports POSIX.

I'd argue that writing scripts for an embedded target for a regular server/workstation target are fundamentally different problems - almost anything I'd write for those platforms would be targeted for them - not for general purpose unix.

Portability is only desirable, if you need portability - otherwise it frequently adds complexity for little return benefit.

Re: Things I Wish I'd Known About Bash

#270
post #262
post #97

Earlier quoted context omitted.

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.

like which? I'm hard pressed to think of a modern unix that doesn't include bash by default. Solaris maybe?

All the current BSD systems, and some GNU/Linux distributions. I'd guess that illumos does not have bash installed by default, too.
Post reply on HN