2 ms·
When there are a few pipes, surrounded by hundreds of lines of logic, parsing, pretty-printing, error reporting, etc. then it makes sense to use a non-shell lan
by chriswarbo 10y ago
When there are a few pipes, surrounded by hundreds of lines of logic, parsing, pretty-printing, error reporting, etc. then it makes sense to use a non-shell language.
The problem is that invoking subprocesses can be quite verbose.
If you do the naive thing and pass strings in/out of each step, it increases verbosity, gives you temporary variables to abstract away and can eat up a lot of memory with temporary data.
If you do the clever thing and set up pipes between the subprocesses, it removes some of the variables, but takes more code and hits deadlocks when the buffers fill up.
If you do the right thing and spawn separate threads to read/write data to the pipeline then it takes even more code, and now you have to worry about multithreading.
Hiding that sort of boilerplate is why I like shells and shell-like libraries. Both are rather unsuited to anything else, but at least with a shell-like library you can fall back to a decent language.
- qwertyuiop924 10y ago>The problem is that invoking subprocesses can be quite verbose. Which is why SCSH is kickass.