4 ms·

Shell without a userland is like FORTH without the ability to define new words. It's really contrary to the whole idea of what a shell is. Bootstrapping in very

by t-3 7mo ago

Shell without a userland is like FORTH without the ability to define new words. It's really contrary to the whole idea of what a shell is. Bootstrapping in very constrained conditions makes some sense, but where would you have a POSIX shell and not a POSIX userland (or close equivalent) to work with? When I wrote a similar compiler in shell, I purposely offloaded everything I could to external tools and used the shell for composition, so I found the approach intriguing and wanted to ask. I wasn't trying to criticize or dismiss the project, I think it's really cool or else I wouldn't have bothered to read the code in the first place.

anthk 7mo ago
Busybox it's what you need. On Forth, Subleq+EForth can do a lot more than you think.
Brian_K_White 7mo ago
gcc exists essentially everywhere a shell exists too. If you're ok with using grep and bc or whatever, then why not gcc? Or better yet, awk? awk is as old and ubiquitous as sh itself, on every machine even ancient ones that don't even have a compiler because that was a paid extra. Only unlike sh it's actually a full normal programming language that can do basically everything the shell can do only in a far more readable and sane way instead of using wierd expansions and abusing the command line parser to achieve functions it doesn't have overt functions for. Just write directly in awk the same way you would in say python or js. If you have sh, especially if you also have the userland you are talking about, then you have awk. It's part of that userland in a way that gcc is admittedly not. More in your vein actually, when I do things like this I pick yet a different ideal goal than either you or the author. I avoid all externals (and even child shells) to whatever extent possible, but I do use bash for all its' worth. Every possible intentional or hack bashism. Require bash, but leverage bash to within an inch of it's life and require nothing else. But this project tageting more portable code that doesn't require bash is really cool and valuable. Even though it's not a standard I personally shoot for even when I am specifically shell-golfing. There are probably as many different points along the spectrum to draw the line as there are individual developers, each with some actually reasonbable argument to justify that particular place to draw the line. To me using grep and sed and tr and ls and cat etc etc when I don't need them is just unsatisfying, inelegant, uninteresting. If you are in bash or ksh93 or zsh, you don't need all kinds of things like basename, dirname, cut, tr, wc, nor some of the more powerful stuff either most of the time. I have a shell function that uses the built-in read combined with a named pipe file created in tmp to make a sleep that doesn't need /bin/sleep. Why bother? because it's awesome. And usually the only times I need to use sleep it's in some rapid short duration polling loop that really is better if you don't have to fork & exec & teardown on every iteration. It's bad enough to be polling like that in the first place. And it just doesn't matter how "probably all the externals will be there", not using them is even better. And these days a lot of once-common "userland" is no longer common or installed by default. A script that never tries to run dos2unix never cares that it's not installed, or that the bsd version behaves differently, or the mac version is stupid old, etc.

by t-3 7mo ago

anthk 7mo ago

Busybox it's what you need. On Forth, Subleq+EForth can do a lot more than you think.

Brian_K_White 7mo ago

gcc exists essentially everywhere a shell exists too. If you're ok with using grep and bc or whatever, then why not gcc? Or better yet, awk? awk is as old and ubiquitous as sh itself, on every machine even ancient ones that don't even have a compiler because that was a paid extra. Only unlike sh it's actually a full normal programming language that can do basically everything the shell can do only in a far more readable and sane way instead of using wierd expansions and abusing the command line parser to achieve functions it doesn't have overt functions for. Just write directly in awk the same way you would in say python or js. If you have sh, especially if you also have the userland you are talking about, then you have awk. It's part of that userland in a way that gcc is admittedly not. More in your vein actually, when I do things like this I pick yet a different ideal goal than either you or the author. I avoid all externals (and even child shells) to whatever extent possible, but I do use bash for all its' worth. Every possible intentional or hack bashism. Require bash, but leverage bash to within an inch of it's life and require nothing else. But this project tageting more portable code that doesn't require bash is really cool and valuable. Even though it's not a standard I personally shoot for even when I am specifically shell-golfing. There are probably as many different points along the spectrum to draw the line as there are individual developers, each with some actually reasonbable argument to justify that particular place to draw the line. To me using grep and sed and tr and ls and cat etc etc when I don't need them is just unsatisfying, inelegant, uninteresting. If you are in bash or ksh93 or zsh, you don't need all kinds of things like basename, dirname, cut, tr, wc, nor some of the more powerful stuff either most of the time. I have a shell function that uses the built-in read combined with a named pipe file created in tmp to make a sleep that doesn't need /bin/sleep. Why bother? because it's awesome. And usually the only times I need to use sleep it's in some rapid short duration polling loop that really is better if you don't have to fork & exec & teardown on every iteration. It's bad enough to be polling like that in the first place. And it just doesn't matter how "probably all the externals will be there", not using them is even better. And these days a lot of once-common "userland" is no longer common or installed by default. A script that never tries to run dos2unix never cares that it's not installed, or that the bsd version behaves differently, or the mac version is stupid old, etc.