Hector Martin

Anyway, the reality is we *don’t* use processes and pipes for important things, *because* they fail roughly like this. You can say “but error codes” all you want, we don’t do this with browsers or ssh or gzip or REPLs (hello, Jupyter) or anything else. Because this hits a wall.https://twitter.com/marcan42/status/996231278276919296 …

You can say it shouldn’t matter. But it really does. It’s nice to have Unix process management, it’s great to be able to lash things together with stringly types blobs, but eventually, we always move from pidgin to creole (to borrow phrasing from actual linguistics).

So how are process exit codes different from shared library return codes different, exactly? What makes it more likely that a stupid user will not check the former but will check the latter? Your argument is valid, but *this bug* is not a good example against processes and pipes

No, that’s what you’re not getting. It really is the fragility of the interface that gets you the “It returns content by default, hope you’re smart enough to check the error code, what do you mean nothing did” surprise not surprised dynamic

Arguably nobody wanted to add a —just-give-me-what-you-got command line (or —insecure).

This is a backwards compatibility argument. gpg was designed with streamability in mind. Sure, you could add an --unbuffered argument, but then you'd break many existing use cases. We both know "secure by default" choices are hard when your public interface is frozen.

They are. You tend to get to reset expectations with a major rev, which we do everywhere else every so often. libssh2 didn’t always exist.

This is harder with commandline apps (especially ones as dedicated to backwards compat as gpg) because people don't tend to introduce "gpg2" style "new interface here" breaks. It's a bigger change than library sonames (where you can at least install both at once).