5 ms·
The weakness of the shell is that it did not emerge as an LR-parsed language that could easily be expressed with a concise yacc grammar. The "one true awk," for
by chasil 5y ago
The weakness of the shell is that it did not emerge as an LR-parsed language that could easily be expressed with a concise yacc grammar. The "one true awk," for example, bundled a yacc grammar as part of the build until relatively recently. The complex grammar of the POSIX shell is ambiguous in the extreme in many situations.
The shell language was further constrained by POSIX that removed much Korn shell functionality, even though a public domain implementation of Korn existed. This was done to allow the shell parser to be very small, and Debian's Almquist shell compiles to under 100k on i386 (unlike bash, which trails it also in speed).
This new Hush shell looks a bit too wordy and reminiscent of javascript.
Anyone designing a new shell grammar should also design in such a way that Busybox could bundle this new interpreter, should popularity justify it.
- nine_k 5y agoWhile being extremely small is a worthy goal, I suppose the aim of Hush is to make writing larger shell scripts easier and less error-prone. It's more for the niche of Perl of old than of minimal shells like ash. For a very limited device, a very limited shell like that in Busybox is sufficient, because it likely does not need large shell scripts, or a lot of interactive work. Looking at [1], current Hush is under 700k, which is still way smaller than Python or Perl, with much of its expressiveness. [1]: https://github.com/hush-shell/hush/releases https://github.com/hush-shell/hush/releases
- chasil 5y agoThe whole of Busybox is a megabyte. If Hush is 700k, then there are many, many places that it cannot go. As such, it cannot be a standard default shell. Use on smaller embedded platforms will not be possible. That is the trade.
- nine_k 5y agozsh is also rather large, but it does not prevent zsh from being useful and popular. I'm not going to run it on my router, though. OTOH I'm not going to run Busybox as the main shell on my laptop. Right tool for the job.
- chasil 5y agoThe requirement, as set by POSIX, was to run the shell in Xenix on an 80286, which only supported a 64k text segment. There are few tools that can meet this requirement, and the limit is as relevant now as the day it was first published. Any aspiring shell must run within this limit to fully pervade POSIX. Ignoring this requirement greatly reduces applicable scope. Korn '88 could do it, but the code was not pretty. Any POSIX shell replacement has to hit that target.
- nine_k 5y ago> the limit is as relevant now as the day it was first published Can't say if it's ironic or serious.
- chasil 5y agoGuess. "Indeed, in 2014 -- 42 years after Intel’s rollout of the 8008 -- the godfather of microcontrollers accounted for 39.7% of overall sales revenues in the MCU market... That’s more than 32-bit devices (38.5%) and 16-bitters (21.8%), which grabbed most of the headlines." https://www.designnews.com/electronics-test/why-8-bit-microcontrollers-refuse-go-away https://www.designnews.com/electronics-test/why-8-bit-microc...
- oblio 5y ago1. How many people connect to shells on those microcontrollers? 2. How many people actually develop for those microcontrollers? The numbers of devices doesn't matter. Exaggerating a bit, if you have 100 folks developing for 50 billion devices and 10 million developing for 10 billion devices, we will always optimize for the development experience of the 10 million developers, not the 100. I'm quite convinced (based on job board statistics) that embedded developers are a minority. And that's not even counting sysadmins, devops, testers, etc, in which case the community outside of embedded completely dwarfs the embedded community.