The Boston Diaries

The ongoing saga of a programmer who doesn't live in Boston, nor does he even like Boston, but yet named his weblog/journal “The Boston Diaries.”

Go figure.

Wednesday, February 04, 2015

A silly little file redirection trick under Unix

I'm in the process of writing a regression test for “Project: Sippy-Cup” and right now I'm more concentrating on writing what I call a “smoke-test”—something that can be run on my development machine after fixing bugs or adding features so that any obvious problems are “smoked out” before it hits the version control system.

Like “Project: Wolowizard,” this involves running multiple components. That isn't that much of an issue, I have plenty of Lua code to launch a program, and it typically looks like:

errno   = require "org.conman.errno"
syslog  = require "org.conman.syslog"
process = require "org.conman.process"

pid,err = process.fork()
if not pid then
  syslog('error',"fork() = %s",errno[err])
  os.exit(process.EXIT.SOFTWARE) -- who knew about /usr/include/sysexits.h?
elseif pid == 0 -- child process
  local stdin ="/dev/null","r")
  local stdout ="foobar.stdout.txt","w")
  local stderr ="foobar.stderr.txt","w")

  -- --------------------------------------------------------------------
  -- redirect stdin, stdout and stderr to these files.  Once we've done
  -- the redirection, we can close the files---they're still "open" as
  -- stdin, stdout and stderr.  Then we attempt to start the program.  If
  -- that fails, there's not much we can do, so just exit the child
  -- process at that point.
  -- --------------------------------------------------------------------


  process.exec(EXE,{ "–config" , "config.xml" })

Each program is launched in a similar manner, and if any of them crash, the testing harness gets notified. Also, once the tests are done, I can shutdown each process cleanly, all under program control. I want this to be a simple run-me type command that does everything.

During the testing of the testing program, it is nice to be able to see the output of the programs being tested. Sure, I have any output from the programs going to a file, but the problem with that is that it's hard to watch the output in real time. Upon startup (at least under Unix) if stdout (the normal output stream) is a terminal, the output appears a line at a time; otherwise, the output is “fully buffered”—meaning it's only actually written when there's around 4K or 8K worth of output, and if the programs aren't that chatty, you could be waiting a while if you're constantly checking the output files.

But there is a trick—this being Unix, you can redirect the output to another terminal (or in this modern age, a terminal window). I open up a spare terminal window (it's easy enough), and run the w command to find its device entry:

 20:31:32 up 15 days, 6 min,  3 users,  load average: 0.00, 0.00, 0.00
USER     TTY      FROM              LOGIN@   IDLE   JCPU   PCPU WHAT
spc      pts/0    marvin.roswell.a 20:06   17.00s  0.28s  0.27s joe 2
spc      pts/1    marvin.roswell.a 20:15   15:50   0.03s  0.02s vi process.c
spc      pts/2    marvin.roswell.a 20:31    0.00s  0.01s  0.00s w

Here, I can see that the w command is being run on terminal device /dev/pts/2 (under Linux, the “/dev/” portion isn't listed). So all I need to do is redirect stdout and stderr to /dev/pts/2 and the output will appear in that window, in real time.

So why do it in this roundabout way? Well, remember, I have several programs running. By opening up multiple terminal windows and directing the output of each program to these windows, the output from each program is kept separated and I can see what's going on. Then, when the testing program is working, I can then go back to writing the output to a file.

Oh, and under Mac OS-X:

20:40  up 21 days,  1:20, 8 users, load averages: 0.01 0.05 0.08
USER     TTY      FROM              LOGIN@  IDLE WHAT
spc      console  -                14Jan15 21days -
spc      s000     -                18:48      32 -ssh XXXXXXXXXXXXXXXXXX
spc      s001     -                20:07      23 -bash
spc      s002     -                14Jan15 21days syslogintr
spc      s003     -                20:07       - w
spc      s004     -                20:07       - -ssh lucy
spc      s005     -                20:16       7 -ssh lucy
spc      s006     -                20:32       - -ssh lucy

The “s003” now becomes /dev/ttys003.

Of course, statistics has little to say about Murphy's Law

Everyone knew it was coming. Second-and-1 on the 1-yard line. Marshawn Lynch was waiting in the backfield, poised to do what he was put on this Earth to do: Get a touchdown—this touchdown. The football gods had telegraphed how they wanted the game to end, directing a floating ball straight into Jermaine Kearse's hands. Beast Mode was going to drag the New England team kicking and screaming into the end zone if he had to. But the play call came in, Russell Wilson attempted a doomed pass that Malcolm Butler intercepted, and it was Seattle that punched and screamed its way off the field.

That's right. On the 1-yard line, QBs threw 66 touchdowns with no interceptions prior to Wilson's errant toss.3 Not mentioned: They also scored four touchdowns on scrambles (which Wilson is pretty good at last I checked). That's a 60.9 percent success rate.

Just for comparison's sake, here's how more than 200 runs fared this year in the same situation:

So overall, runs do a bit worse than passes (57.1 percent vs. 60.9 percent).

Via Robert Anstett on MyFaceGooglePlusSpaceBook, A Head Coach Botched The End Of The Super Bowl, And It Wasn’t Pete Carroll | FiveThirtyEight

I don't watch much football (if at all), but even I knew that last Seahawks play was not the right call. But actually, it may not have been the most idiotic thing for the Seahawks to do. The article goes deep into the math behind Pete Carroll's call.

Obligatory Picture

[“I am NOT a number, I am … a Q-CODE!”]

Obligatory Contact Info

Obligatory Feeds

Obligatory Links

Obligatory Miscellaneous

You have my permission to link freely to any entry here. Go ahead, I won't bite. I promise.

The dates are the permanent links to that day's entries (or entry, if there is only one entry). The titles are the permanent links to that entry only. The format for the links are simple: Start with the base link for this site:, then add the date you are interested in, say 2000/08/01, so that would make the final URL:

You can also specify the entire month by leaving off the day portion. You can even select an arbitrary portion of time.

You may also note subtle shading of the links and that's intentional: the “closer” the link is (relative to the page) the “brighter” it appears. It's an experiment in using color shading to denote the distance a link is from here. If you don't notice it, don't worry; it's not all that important.

It is assumed that every brand name, slogan, corporate name, symbol, design element, et cetera mentioned in these pages is a protected and/or trademarked entity, the sole property of its owner(s), and acknowledgement of this status is implied.

Copyright © 1999-2024 by Sean Conner. All Rights Reserved.