In last month's column, we explained how scripting languages can manage subprocesses written in C. We explained that the examples we offered were indifferent to language, and we demonstrated how to wrap a program written in C++, Fortran, or any other language with a fresh GUI face. In fact, with typical scripted pipes, you don't even have to know what language your legacy application was written in. All that matters is its interface behavior as a command-line application, which communicates through the standard input-output channels.

That's an important realization. Students of reuse theory recognize that the best, least expensive, and safest components are those defined through their interfaces, not by their internal mechanisms. For an existing program, the difference between having to make zero changes to prepare it for wrapping and having to make even one can be enormous.

Reader Katja Cremer points out one common pitfall of pipes. Several scripting languages with UNIX heritages emphasize the parallelism of pipes and conventional files by using open to launch the former. They mark the difference with a subtle syntax that's easy for a beginner to overlook. In Perl, for example:

     open(CHANNEL, "program");

reads the contents of the file program, while

     open(CHANNEL, "program |");

launches program as a subprocess and reads its output.

Sometimes it's necessary to break open black boxes such as program. Our last column showed that pipes are a response to the complaint, "It's working, but it waits and prints all the results at once." Even with proper pipes set up, developers sometimes observe that a GUI shows intermediate but spastic results -- nothing at first, then 20 lines, then another pause, and so on.

That symptom usually hints at output buffering. It is easiest to see with a small example written in C:

     #include 
     #include 
     int main()
     {
		  int i;

		  for (i = 0; i < 100; i++) {
		      printf("%i\n", i);
		      sleep(1);
         }
     }

If you generate an executable from that source and run it from the command line, you'll see it evenly count to 99, with each integer printed on a separate line after only a second's delay.

Launch that as a subprocess from a scripting language, though, and you might get bursts of results after delays of dozens of seconds. The OS thinks that a machine process is observing the count rather than your eyes, and so it tries to make the operation more economical by buffering the data transfer through the pipe.

What can you do about that? It's almost beyond the ability of the scripting process. In many cases, managing the pipe with a scripting extension from the Expect family convinces the OS that it shouldn't

• Email
• Print
• Share
  • Slashdot
  • Digg
  • Stumble
  • Reddit
  • Newsvine