Wandering Thoughts archives

Fiddling with X selections from shell scripts

I know of three command-line programs that will fiddle with the X selection (and/or the cut buffers) in a way that's useful for shell scripts: xsnarf from Smarasderagd's collection of X things, xcb, and xclip.

I use xsnarf for a variety of reasons, I think partly historical (in that I had it around well before I found the others); I'm jotting down the other two here partly so that I have the information handy the next time someone asks me about this.

You may reasonably ask why this is actually interesting. Here's why:

Shell scripts are the easy way to automate things on Unix. Doing things in X Windows sessions is no exception, but there you need some extra programs as building blocks. One of the important building blocks is some way to fiddle with the X selection (or the cut buffers); having this lets you set things up so that you can do things like select a URL in a terminal window and fire it into a browser.

Yes, yes, some terminal emulators have this specific feature built in now. Some; making a shell script to do this means it works for anything that can make an X selection. Terminals. GNU Emacs. A help browser. Everything.

I would much rather set up a general facility, once, than run around repeatedly adding yet another feature to yet another program, and hoping that I wedged it into all of the ones I care about. It's a lot easier, for a start, and it scales much better.

SCGI is a form of caching

This is perhaps an obvious observation, but I've recently consciously realized that persistent SCGI and FastCGI daemons are a form of caching of regular CGI programs; rather than caching data, they're caching code and often configurations. Thinking about them this way has made several things clearer to me.

As caches, they have all of the usual concerns with detecting and dealing with cache invalidation, complicated by the fact that few environments have really good support for loading new versions of your program's code on the fly. Even fewer can cope with data structure changes.

While I have my reasons for disliking resorting to caching, I don't wind up feeling that using persistent daemons is giving in in the same way. I think the reason is because the speed problems that prompt persistent daemons are beyond my control; how fast CGI processes start is mostly up to the operating system and the language interpreters. (Some of it is how fast my program parses its configuration files, but this is usually a small portion of the time.)

This doesn't mean that I like SCGI daemons et al, but I dislike them for different reasons: they're harder to manage, partly because of the caching issues, and I often feel that they shouldn't be necessary. Just running CGI programs directly means that I am always using the latest code and configuration and so on, and if something goes wrong it goes wrong very directly and immediately. (And if it works it's going to keep working.)

A small user interface suggestion

Your button for 'mark all items as read' should not be right next to the button for 'advance to next unread item'. Liferea, I'm looking at you.

(Fortunately it was not a feed with a lot of unread or updated items. I think.)

SCGI versus FastCGI

SCGI and FastCGI are both CGI 'replacements', in that they are protocols for forwarding HTTP requests to persistent daemons instead of starting a possibly big, heavyweight program for each request. Ideally your web server will have a built in gateway for them; less ideally you can run a tiny, fast to start CGI program to talk the protocol to your persistent daemon. There's discussions around the Internet about which one is better; you can find people on both sides, and to some extent it depends on what your web server supports best (lighttpd seems to prefer FastCGI, for example).

(This is a good overview of the whole subject and its history.)

From my perspective SCGI is the clear winner, for a basic reason: SCGI is simple enough to actually implement.

FastCGI is a very complicated protocol (see here), with all sorts of features and a bunch of worrying about efficiency. SCGI is dirt simple; the specification is only 100 lines long, and you can implement either end of it in the language of your choice in an hour or so. Since I'm not just plugging existing components together, this difference is important.

(Some people have even reported that SCGI's simplicity means that it runs faster than FastCGI in practice.)

For all the extra complexity of FastCGI, all I seem to get is the ability to send standard error back to the web server in addition to standard output. I think I can live without that. (Of course it's hard to tell if that's all, since the FastCGI specification is so large.)

I like to think that there's a general idea lurking here: simple protocols and things are often better because they are simpler to use and to integrate into environments. It's rare that existing pieces (that support some complicated protocol) are all perfect fits for what people want to do; when you have to adopt things, the simpler they are the easier it is.

Sidebar: what about plain old HTTP?

There's some opinions that the real answer is for the persistent daemon that does the real work to just speak HTTP directly and have requests proxied to it. I am personally dubious about this; I would much rather delegate the job of dealing with all of the tricky, complex bits of HTTP to a dedicated program, ie the web server. Ian Bicking has another set of reasons for coming to the same conclusion.

(Another person arguing the non-HTTP side, for reasons pretty similar to mine, is here.)