output redirection at different levels (and a standard error developer debug crap rant)

 What's the difference the way output redirection is handled in this:

$ foo > bar

and this:

$ xfoo -geometry +100+200

There are various differences, but the one I am trying to illustrate is as follows.

In the first example, foo's standard output, which is a one-way text stream, and a Unix / POSIX concept, is redirected to the file called bar.  Whether or not it is redirected does not depend on anything from foo.  The shell, which is an execution environment that runs foo and opens bar and redirects the standard output (and prints that $ prompt at the beginning of the lines), takes care of it.  If foo writes to its standard output, this output ends up in bar.  If foo really wants to care, it can look at its standard output file descriptor, and find out whether it's on a filesystem, or is it pipe, or a terminal, and find out all about about it.  But by default, it doesn't have to care.  This is nice.

In the second example, convention indicates this is a graphical program run within the X11 windowing system.  xfoo also has a "standard output" output, and that could be redirected in the same way as above, but here we're looking at the redirection of another of its outputs, which is, roughly, whereabouts on the screen it puts its GUI.  But the level at which this is done is different from the standard output example.  Here, it is up to xfoo to have a -geometry option with the conventional meaning that -geometry options have, like in xterm.  There is no execution environment setting this geometry at a nice level.  There is no reason to assume that any particular X application has a -geometry option, or that its semantics, or indeed implementation, are consistent with what we want to expect.

Sure, some window managers and desktop environments have functionality like this.  But there is space for a mechanism that is independent of the particular X client (application), and operates the same in any X session, regardless of what window manager is used.  An X shell, say.  Note that an X shell does not have to be a "graphical shell" itself.  Some kind of execution environment for graphical applications, allowing the user control over inputs and outputs at some kind of nice level of abstraction.

In reality, none of the X11 / Linux world is "architected" like this (it's not really architected at all), to the point where VMs in their own windows get un-re-mapped keyboard scancodes, for example.  Where to even start on that.

Back to the simple -geometry example.  How might it look, if we could have X client geometry handled uniformly?  This is a start:

$ xl -g +100+200 xfoo

Here the hypothetical program xl (mnemonic: x-launch) runs xfoo "adverbially", in such a way that its window geometry is as specified.  Can this be implemented?  It won't be fun, but, yes.

Sticking with text command-line interfaces, one can imagine an X shell with special support for windowy (and perhaps inputs such as keyboard and mouse) stuff.  From that, perhaps we'd be running something like

 @100,200 xfoo

with the @ indicating geometry stuff, or

100,200 xfoo

if the language design says "starting a command with a numeral means it's placement coordinates / geometry".

It depends on how you design it, but the idea would be that an X shell has X stuff as top-level concepts, and thus has convenient syntax for such, just as the POSIX shell in the top example has the convenient syntax ">" for standard output redirection in its world.

Meanwhile, back in what I'm supposed to be doing, who decided that evince, the PDF viewer, always starts up with a tiny window, much too small to read text in the document?  Dealing with PDFs is soul-destroying enough at the best of times, but every single opening of a document requires a manual resize?  And it doesn't open at a sensible zoom, or remember what window size its user likes, or have a setting for the user to save default zoom level explicitly?  And since we're talking about the text outputs, why does evince write vast amounts of developer debug gibberish to standard error, to the point where no terminal from which evince has been launched, is usable again for anything else?  This is unacceptable.  I had to make a program that runs evince and redirects its standard error to /dev/null, and I made an alias so the user is not allowed to run the normal evince, so sick was I of terminals getting rendered unusable by this.  And it's not just evince.  Firefox, chromium, openoffice (sorry, "libreoffice"), all kinds of huge GUI applications, write copious garbage to standard error, and so have to be launched defensively in this way.

So bring on xl, or x11sh, or something.  And if you're doing an OS / software distribution, take care of the user experience, and remove self-indulgent developer debug crap from being imposed on the user.