4 ms·

On one hand I applaud, but on the other strict POSIX shell seems overly limited. My personal grudges: - no local variables (even dash implements them) - no p

by hawski 8y ago

On one hand I applaud, but on the other strict POSIX shell seems overly limited. My personal grudges: - no local variables (even dash implements them) - no process substitution [0] so one has to use temp files, temp named pipes or possibly joggle fd numbers. I once did an external implementation of process substitution, so it's doable with POSIX shell, but then pointless. - set -o pipefail I understand that you know about and get over those limitations. But isn't it too cumbersome when Linux world settled on bash and BSD on ksh? Especially since ksh is a bit like a subset of bash. At least the things I mentioned are common for both. It's sad that shell makes it so hard to make more complicated pipelines than | the | old | classic. Fds, processes and pipelines should all be first class. Maybe that's the point to make it harder to make those complicated scripts in something other than shell. In other languages it may be easier to make correct pipelines, but with heavy boilerplate. Then it's probably easier to count on libraries instead of pipelines, even if those libraries spawn processes in background. I'm hoping for oil shell more as it means to address all those issues and more with an escape hatch to convert old scripts. Although I'm not so sure about the implementation details. For those in the know it made more sense to me after I read that OVM itself would become a VM for oil. So that there would be a single VM to run and not two as it is now. At least that's how I understand it. POSIX shell is kinda magical, because it's nominally portable. However the rabbit seems to have died in the hat, because it's really that old. Shell was conceived in a different era with different limitations. I think that we should go further. [0] take-in-and-out <(process-out) >(filter-this | grep that) | grep msg

Sir_Cmpwn 8y ago
>no local variables They're not standard, so don't use them. Instead I often find a subshell to be sufficient. You can declare a function like so: my_func() ( local_variable=10 echo $local_variable ) This is also a good strategy for helping you make purer shell functions. >no process substitution, so one has to use temp files, temp named pipes or possibly joggle fd numbers I don't find myself doing this often enough to care. It is possible, and if you're writing something which heavily relies on this perhaps you're better off with Go or Python. >set -o pipefail I agree, we've been talking to the Austin Group about getting this standardized. I think we should go further, too, not by attempting to replace the shell with something that tries to do shell scripts better, but by making full-blown programming languages in which shell things are nicer to use.
chubot 8y ago
Yeah making Oil more efficient is an open problem. I've been going back and forth on the whole OVM thing (long story). I think that's the right idea, but it's not clear how long it will take. But I think the efficiency problem is easier than the problem of running big hairy unmodified shell scripts, which I view as essential to replacing bash. That is, it's easier to make something that works efficient, as opposed to thinking you have 60% of a shell and really having 20% of one :-/ That was the case for awhile, but since OSH can run many real programs, I'm pretty confident in its feature set.

by hawski 8y ago

Sir_Cmpwn 8y ago

>no local variables They're not standard, so don't use them. Instead I often find a subshell to be sufficient. You can declare a function like so: my_func() ( local_variable=10 echo $local_variable ) This is also a good strategy for helping you make purer shell functions. >no process substitution, so one has to use temp files, temp named pipes or possibly joggle fd numbers I don't find myself doing this often enough to care. It is possible, and if you're writing something which heavily relies on this perhaps you're better off with Go or Python. >set -o pipefail I agree, we've been talking to the Austin Group about getting this standardized. I think we should go further, too, not by attempting to replace the shell with something that tries to do shell scripts better, but by making full-blown programming languages in which shell things are nicer to use.

chubot 8y ago

Yeah making Oil more efficient is an open problem. I've been going back and forth on the whole OVM thing (long story). I think that's the right idea, but it's not clear how long it will take. But I think the efficiency problem is easier than the problem of running big hairy unmodified shell scripts, which I view as essential to replacing bash. That is, it's easier to make something that works efficient, as opposed to thinking you have 60% of a shell and really having 20% of one :-/ That was the case for awhile, but since OSH can run many real programs, I'm pretty confident in its feature set.