Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Yeah, I've been deep in the bash manual and source code during my work on https://www.oilshell.org, which basically reimplements a "cleaned up" spec-driven bash (called OSH).

But I also used bash for 15 years before that, and I hardly used the bash manual. I got by with a minimal / sane dialect, and I read a few books about Unix, and one about POSIX shell (the latter is also "meh").

Now that I've read almost all of the bash manual, I'd say it's not really a special document. It's fine, but it's not complete, and I wouldn't say it's particularly well written. It lacks examples.

--

The main recommendation I have for anyone who wants to learn bash is to learn Unix and C. Learning the underlying model explains many things, explains the bad error messages, and makes it easier to use.

https://www.oilshell.org/blog/2020/04/comics.html - Three Comics For Understanding Unix Shell

So yeah I don't think "learning shell" or "learning bash" is actually a great goal -- it's part of the operating SYSTEM, and you want to learn the OS, and its philosophy.

related - https://www.oilshell.org/blog/2021/01/philosophy-design.html - Unix Shell: Philosophy, Design, and FAQs

--

Probably the most useful part of the bash manual is the acknowledgement that there's a lexing design bug with [[ and regular expressions.

It's better to make the regex a separate var, like

    pat='[[:digit:]]+'
    if [[ $mystr ~= $pat ]]; then ... fi

... than to inline it, because bash does funky stuff when you inline it. It confuses regex metachars and bash metachars.

It's trying (and failing) to make regexes syntaically part of the bash language, but it's better to treat it like Python, where Python syntax and regex syntax are separate.



Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: