Wandering Thoughts archives


A Unix irritation: pipeline status

Let's start with a Bourne shell irritation. Suppose you have a command sequence that looks like:

may-fail | grep ...

Further suppose that you want to know whether may-fail actually failed. In the normal Bourne shell, you're out of luck; the exit status of a pipeline is the exit status of the last command, and grep will probably succeed no matter what happens to may-fail. You're going to need to use a temporary file instead of the pipeline or get very creative.

It's tempting to blame the Bourne shell for this, but I think that its hands are at least partially forced by our old friend SIGPIPE. Consider this pipeline:

produce-lots | sed 10q

What's the exit status of this pipeline, assuming that produce-lots would succeed if left alone?

Sed will exit successfully after writing ten lines. But this closes the pipe, which means that produce-lots gets either a SIGPIPE signal or an EPIPE write error (if SIGPIPE is being ignored). Unless produce-lots is specially coded, it is going to exit with some sort of error status. If the Bourne shell only considered pipelines successful if all of their commands succeeded, this sort of pipeline would fail, much to people's surprise.

(The shell could consider pipeline commands that exited on SIGPIPE to have succeeded, but that's an unreliable hack.)

Hence, the only reliable exit status is the exit status of the last command in the pipeline; everything else can wind up 'failing' when they have not in fact failed, it's just that the pipeline has shut down early.

unix/PipelineStatus written at 22:59:52; Add Comment

More on why users keep mailing specific people

Perhaps unsurprisingly, most of the people who've commented on my last entry have attributed this behavior to people's desire to get their issues dealt with promptly (to some, this is jumping the queue; what you could call a 'vigorous discussion' has broken out in the comments about this, rather to my surprise). I have a couple of reactions to this view.

First, I am pretty sure that this is not why people here do it, at least for the kind of cases that I'm thinking of. We don't have a trouble ticketing system or the like, just email aliases, and generally the users email the person who was going to deal with their issue anyways; the only effective difference is what email address they use. Hence my belief that our users really do keep emailing specific people because it's easier to remember people than mail aliases.

(From our perspective it matters what they email; when you mail an alias, everyone is in the loop and we have a record of it. But these are internal process issues, not things that the users care about, at least not until the person they emailed is out sick one day. And I actually suspect that they accept that sort of thing happening, because after all they did email a specific person.)

Second, if getting prompt responses is the reason that users are mailing you directly you have at least one problem, to wit either your response times are perceived as too slow or the procedures for going through regular channels are too complicated. If users are also doing it to jump the queue, it is my opinion that you also have either problem users or a significantly dysfunctional organizational environment (at a minimum, one where there is vigorous disagreement over what your priorities should be).

In either case, swatting users on the nose is generally not an effective way to solve your problems (although it is a great way to make them worse). Instead, you need to deal with the root causes, the hard social problems. Sometimes this will be beyond your power; in that case I believe that you need to do the best you can and be as transparent about what is going on as possible.

(If the problem is organizational politics, the last thing you want to do is put yourself in the position of being everyone's chewtoy. Let aggravated people see that it is not your fault, so that they can take their gripes to higher powers. And if you're dealing with problem users, you really want to have management approval of what you're doing; otherwise, you may find out the hard way that the problem users have more power than you do.)

sysadmin/WhyPeopleMailPeopleII written at 00:46:15; Add Comment

Page tools: See As Normal.
Login: Password:
Atom Syndication: Recent Pages, Recent Comments.

This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.