Date: Sat, 26 Jan 2019 13:00:48 +0100 From: Stefan Esser <se@freebsd.org> To: arch@freebsd.org Cc: gljennjohn@gmail.com Subject: Deficiencies compared to /bin/sh Message-ID: <2b7adc50-e423-b36e-6f08-a30c69e3f189@freebsd.org> In-Reply-To: <20190126102238.3b5e0a80@ernst.home> References: <20190125165751.kpcjjncmf7j7maxd@ivaldir.net> <201901251936.x0PJaepi089796@pdx.rh.CN85.dnsmgr.net> <20190125210833.ltnvsxbnlkc6njaw@ivaldir.net> <20190126102238.3b5e0a80@ernst.home>
next in thread | previous in thread | raw e-mail | index | archive | help
Am 26.01.19 um 10:22 schrieb Gary Jennejohn: > On Fri, 25 Jan 2019 22:08:33 +0100 > Baptiste Daroussin <bapt@freebsd.org> wrote: > >> On Fri, Jan 25, 2019 at 11:36:40AM -0800, Rodney W. Grimes wrote: >>>> Hi everyone, >>>> >>>> I would like to import mksh in base, https://www.mirbsd.org/mksh.htm >>>> And make it the default root shell (not necessary in one step) >>>> >>>> Why: >>>> 1/ it is tiny 400k (in the packaged version) all other shells fitting the >>>> expectation are bigger >>> It is more than twice the size of our current /bin/sh, and giving up >>> 200k on the nano/tiny/wifi BSD is hard to justify. 400k is near the >>> size of tcsh. >>> >> To be fair here: >> mksh is 331k on my amd64 machine >> /bin/sh is 165k >> >> mksh only depends on libc >> /bin/sh depends on libc + libedit which adds an additional 231k to the battle. >> >> If now we are comparing to the actual root shell: >> csh is 419k on the same machine and it depends on libncursesw and libcrypt >> > > How large is a statically linked mksh? /rescue/sh is 8.5MB. > Amazingly, that's four times larger than a statically linked > bash. > > If mksh is supposed to be the default, then it might make sense > to have a statically linked binary under /rescue. While I'd appreciate a more feature rich shell in base, I do not think that mksh is a good choice. It even lacks features that have been in our /bin/sh for quite a long time (e.g. 64 bit arithmetics) and diverges from all other shells in non-obvious ways (e.g. shell functions behave differently dependent on whether they are defined as "fn ()" or "function fn"). Unicode handling is also "special" and there are a number of features for which the man page announces planned behavioral changes that are planned for future versions and which will introduce semantic changes that might break shell scripts. There is also no support for associative arrays and the syntax for variable expansion differs in details from other shells (not that relevant for an interactive shell, but I'd really like to have a shell in base with support for associative arrays, if we consider adding one beyond sh and tcsh ...). All these details make it less suited for running shell scripts, and even if the suggestion is to make mksh the default interactive root shell, it will probably be used for scripting, since it offers at least numerically indexed arrays (albeit not fully compatible with e.g. bash). An import of ksh93 would not suffer from these problems, but ksh93 is a much larger shell and not supported on all relevant architectures (broken on aarch64 due to lack of sbrk() according to the port ...). I'd think that such issues should be resolved before any new shell is considered for integration in base ... Regards, STefan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?2b7adc50-e423-b36e-6f08-a30c69e3f189>