3 ms·

The idea to use a real programming language as a shell is a common one but I'm not sure it's really a problem that can be solved without reworking the kernel in

by simias 9y ago

The idea to use a real programming language as a shell is a common one but I'm not sure it's really a problem that can be solved without reworking the kernel interface. Whatever you do pipes will still be byte streams, error handling will always be using integer return values, you'll always have stdin, stdout and stderr, job control and signal handling will always work pretty much the same way. The kernel interface exposes an interface, the userland app expect the shell to behave in the certain way, there's not a lot of wiggle room to make things differently in between the two. Not that the POSIX-like shell syntax is not all sorts of clunky and odd but I almost consider it a feature, it's a deterrent to force you to move to a "real" scripting language when the concepts become too complex to express in a shell script.

laumars 9y ago
I've been considering this problem myself and I believe there are ways to get around the limitations you've described. It's not pretty (from an ideological perspective) but it does work and is mostly invisible to the end user. The problem is when users hit those weird edge cases where the hack becomes visible. :-/
effie 9y ago
The whole point of these projects is to evolve the shell, go beyond the current bash standard to make the work with the shell more fun and more productive. Unix may seem to have limited default interfaces, but this was by design - the idea was, the programmer/user knows much better what he needs so let him build it. The system's role was shaped to provide robust universal mechanisms. Also, the current standard shell is very limited when compared to even existing unix interfaces. For example, the kernel provides select/poll system calls but standard shell has no facility to use them, so simultaneous processing of two or more data streams without blocking is not currently possible. A new shell could finally provide them.
- jklowden 9y ago
  Finally? You don’t need a new shell. Write select(1). Job done.

by simias 9y ago

laumars 9y ago

I've been considering this problem myself and I believe there are ways to get around the limitations you've described. It's not pretty (from an ideological perspective) but it does work and is mostly invisible to the end user. The problem is when users hit those weird edge cases where the hack becomes visible. :-/

effie 9y ago

The whole point of these projects is to evolve the shell, go beyond the current bash standard to make the work with the shell more fun and more productive. Unix may seem to have limited default interfaces, but this was by design - the idea was, the programmer/user knows much better what he needs so let him build it. The system's role was shaped to provide robust universal mechanisms. Also, the current standard shell is very limited when compared to even existing unix interfaces. For example, the kernel provides select/poll system calls but standard shell has no facility to use them, so simultaneous processing of two or more data streams without blocking is not currently possible. A new shell could finally provide them.

jklowden 9y ago
Finally? You don’t need a new shell. Write select(1). Job done.