In all honesty, just man bash or whatever shell you have. most of these articles generally just publish what is very easy to find in bash’s manpage.


      Author suggests using minimalist shells such as dash or busybox for everyday use. Anyone here doing this?

      1. 5

        I’m not sure s/he does - it suggests using a basic shell for scripts.


          good point


          I use mksh, which is like “modern ksh” (actually, a MirBSD Korn Shell) for me.


            /bin/sh on FreeBSD, ash-derivative.


              For scripts? Of course! If you use a big, fancy shell to run your scripts you can more easily accidentally use a non-standard feature. Also, the big, fancy shells are noticeably slower.


                god no. unless your shell use cases are exceedingly simplistic, writing pure POSIX shell scripts is tedious.

                bash out of the box has useful things like:

                • parameter transformations like @Q which makes it easy to safely eval values.
                • pattern substitution
                • an ERE regexp engine
                • hash maps and arrays
                • mapfile
                • compgen

                and a lot more.

              1. 4

                Or maybe shells were pretty much built to be primitive User interfaces and not serious “typed” languages. Stop trying to see shells as “scripting” and a lot of your problems pretty much become secondary.

                Seriously, just use a REAL scripting language, then you can readdir() or whatever without having to depend on ls and all the weird ways you can invoke it.

                1. 4

                  While I understand your argument, you should consider that we use the term “script” instead of, say, “command” exactly because scripts were originally a sequence of shell commands saved in a file for future convenience.

                  So there is a continuous between the glue provided by a shell and a full interpreted programming language.

                  Shell were designed to glue small programs providing specific features into larger ones.

                  Interpreted language are designed to write larger programs in the first place, by composing the available libraries that provide the specific features.