3 ms·

Two ergonomic issues in POSIX/bash not mentioned that I’d like to see a new shell improve on: - splitting pipes to separate flows (e.g one flow for stderr, one

by 3np 6y ago

Two ergonomic issues in POSIX/bash not mentioned that I’d like to see a new shell improve on: - splitting pipes to separate flows (e.g one flow for stderr, one for stdout). Think of it as a graph. - native parallelization; I have to look in man every other time I use parallel.

RMPR 6y ago
> native parallelization; I have to look in man every other time I use parallel. Can relate, the syntax is very strange, at least to me. And I wonder where it came from.
Splognosticus 6y ago
> - splitting pipes to separate flows (e.g one flow for stderr, one for stdout). Think of it as a graph. Could you elaborate a little on what you mean by this? bash already has the ability to redirect STDERR and STDOUT independently, and when you introduce named pipes into the mix things can get really fancy (probably too fancy, this is about where your script stops being a script and starts being a program written in perhaps the most inconvenient language available.)
- e12e 6y ago
  I imagine an easy/intuitive way to set up FIFOs for stdout/stderr with redirection, maybe? A way to say: for this following section, I want stderr to go trough "|sort -n|logger -t DEBUG -f -" and standard out to go through (... Other pipeline)?
  - folmar 6y ago
    command 2> >(sort -n|logger -t DEBUG -f -) | other pipeline
titanomachy 6y ago
The first is interesting. I have a hard time imagining what that syntax would look like. You'd need a way to refer to your graph nodes, so I don't think you would get much better than what named pipes (aka FIFOs) already provide. Totally agree about GNU parallel. The syntax is not badly-designed IMO, but I don't use it very frequently and it's different from everything else so I often get it wrong. Using it as a drop-in replacement for xargs is easy enough though.
chubot 6y ago
Yes absolutely! That's been on the table for along time, and we even have a nascent xargs from a contributor (that has languished -- I need help!) Let's discuss on the issue if interested: https://github.com/oilshell/oil/issues/843 https://github.com/oilshell/oil/issues/843 Oil is easy to prototype (it's just Python code), so anyone who wants to make this feature their own should feel free to dive in :) A lot of people have ideas, which may or may not be implementable with fork(), wait(), pipe() and dup(). Anything that can be done safely with those syscalls is basically viable. The syntax is generally the easy part compared to the runtime execution. Oil has first-class blocks already which will help a lot. ---- Related: I also want to fix redirect and here doc syntax (in a compatible way): https://github.com/oilshell/oil/issues/841 https://github.com/oilshell/oil/issues/841 https://github.com/oilshell/oil/issues/832 https://github.com/oilshell/oil/issues/832

by 3np 6y ago

RMPR 6y ago

> native parallelization; I have to look in man every other time I use parallel. Can relate, the syntax is very strange, at least to me. And I wonder where it came from.

Splognosticus 6y ago

> - splitting pipes to separate flows (e.g one flow for stderr, one for stdout). Think of it as a graph. Could you elaborate a little on what you mean by this? bash already has the ability to redirect STDERR and STDOUT independently, and when you introduce named pipes into the mix things can get really fancy (probably too fancy, this is about where your script stops being a script and starts being a program written in perhaps the most inconvenient language available.)

e12e 6y ago
I imagine an easy/intuitive way to set up FIFOs for stdout/stderr with redirection, maybe? A way to say: for this following section, I want stderr to go trough "|sort -n|logger -t DEBUG -f -" and standard out to go through (... Other pipeline)?
- folmar 6y ago
  command 2> >(sort -n|logger -t DEBUG -f -) | other pipeline

titanomachy 6y ago

The first is interesting. I have a hard time imagining what that syntax would look like. You'd need a way to refer to your graph nodes, so I don't think you would get much better than what named pipes (aka FIFOs) already provide. Totally agree about GNU parallel. The syntax is not badly-designed IMO, but I don't use it very frequently and it's different from everything else so I often get it wrong. Using it as a drop-in replacement for xargs is easy enough though.

chubot 6y ago

Yes absolutely! That's been on the table for along time, and we even have a nascent xargs from a contributor (that has languished -- I need help!) Let's discuss on the issue if interested: https://github.com/oilshell/oil/issues/843 https://github.com/oilshell/oil/issues/843 Oil is easy to prototype (it's just Python code), so anyone who wants to make this feature their own should feel free to dive in :) A lot of people have ideas, which may or may not be implementable with fork(), wait(), pipe() and dup(). Anything that can be done safely with those syscalls is basically viable. The syntax is generally the easy part compared to the runtime execution. Oil has first-class blocks already which will help a lot. ---- Related: I also want to fix redirect and here doc syntax (in a compatible way): https://github.com/oilshell/oil/issues/841 https://github.com/oilshell/oil/issues/841 https://github.com/oilshell/oil/issues/832 https://github.com/oilshell/oil/issues/832