Function composition via types is a much more satisfying take on this problem. It's too bad Unix is regarded as the holy grail of this technique when it barely provides a passable implementation of it.
Text just isn't a great medium for IPC.
> Text just isn't a great medium for IPC.
Yes, in retrospect Unix's determination to know about nothing but binary or plaintext blobs and streams looks like an adolescent rebellion against the (apparently - I haven't used them) clunky record structures of '60s operating systems.
It's also pretty hard to pass a function to a Unix command. Either your command supports its own syntax (grep, find), or you make do writing a loop or a temporary file.
On this and a few other points, it would be interesting to allow a process to call out to the shell that it's running below ("... if any" being one of several issues with the idea).
There are things that a shell function can do that a spawned program cannot - mostly to do with affecting shell state. Updating shell variables and opening file descriptors are obvious examples.
On the subject of "oh, I could do that if..." I know exactly how you feel. I really want the ability to pass multiple filestreams to a command, so you could, say, use cat on the outputs of two commands. Assuming the syntax was @`<pipeline>`, It would like something like this:
foo|grep bar|cat @`baz|grep bar`|sort -rn|tail
The above script assumes that the commands foo and baz are generating lines with time signatures at the start, and then checking for the most recent entries. I chose the @` syntax for its similarity to the lisp @, syntax, but it could be anything. Unfortunately, I think the only way to do this would be to monkey-patch either open(2) or fopen(2), probably both, which would be a Really Bad Idea (tm).
{ foo; baz; } | grep bar | sort -rn | tail
cat <(foo | grep bar) <(baz | grep bar) | sort -rn | tail
EDIT: Unless you're just piping both of them to STDIN. piping two files to STDIN is useful, just not as useful as the thing that I wanted. This seems to be what you're doing.
$ echo <(:) <(:)
/dev/fd/63 /dev/fd/62
As I mentioned though, it's a bashism.
>Text just isn't a great medium for IPC.
Yeah, text does suck for IPC. The problem is, everything else sucks even more.
POSIX itself is a huge PCB of bodge-wires due to legacy compliance. On the upside for systemd haters, they can appeal to the 2004 ISO standard as init.d being the "right way". But if you read the rationale behind a bunch of utilities especially in Section B, you'll see why it's so crusty. "This ..worked in SysV so we're going to keep it". The Linux Standard Base specification isn't much better.
The whole argument as to 'what is UNIX' is so contrived at this point, but anyone making the argument that GNU coreutils are about composibility are correct (see page 230 of https://www.gnu.org/software/coreutils/manual/coreutils.pdf). They assert that the Bell Labs UNIX philosophy was effectively "one tool to do one thing well, orthogonal to other tools, to facilitate composibility" (the authors even dedicate an entire proceeding section to demonstrate it) but that's without any direct references to previous specifications.
Anyways, I'm with you, and apparently the GNU guys claim the Bell Labs guys were with you as well.
UNIX is more than just a trademark, more importantly it is the test suite you have to pass to be allowed to use the trademark. And the trademark doesn't belong to SCO, it belongs to The Open Group, a not-for-profit industry consortium (successor to X/Open and the Open Software Foundation.)
Does it matter that much? I'm sure it makes it easier to port a package to a certified UNIX, since you know a certain collection of APIs must be there (putting aside the fact that some parts of the UNIX standard are optional)
It says something about the state of software if Unix is the thing that "taught us about composability". Laughable.