TopicMaps

Using STDIN, STDOUT and Pipes < The Trick is To Keep Breathing < < Home

Using STDIN, STDOUT and Pipes

As the TM infrastructure also understands the special files STDIN and STDOUT, UNIXavistas would also suspect that these can be used as well. And indeed

my $tm = new TM ('io:stdin');
...

will - at the time the constructor is invoked - consume all content from STDIN. Behold, this only works if the map content is in some given, specific binary format which can be directly interpreted as map. It does not work with textual notations such as XTM or AsTMa= as the driver would not know which it is. With the overriding mechanism from previous section we can handle this, though:

my $tm = new TM ('io:stdin { TM::Materialized::LTM }');
...

We still use io:stdin to specify our source, but this time use the LTM driver to interpret the data stream.

What works well for STDIN, also works for STDOUT

my $tm = new TM ('io:stdout');

will be interpreted as

my $tm = new TM ('> io:stdout');

Again, if you do not want the output to be some strange binary data stream, you can use a different file driver. Also in the good UNIX tradition you may want to open a reading pipe

my $tm = new TM ('someprocess |');

where another process is run which is expected to deliver TM content. The above is interpreted as

my $tm = new TM ('someprocess | io:stdio');

so no one can stop you to write a filter like this

{
   my $tm = new TM ('someprocess | io:stdin > io:stdout');
   ...
   # let's modify the map
} # here the current state will be flushed onto STDOUT

Similarily, you may want to define a process as a data 'sink':

my $tm = new TM ('| someprocess');

or - if you need a specific output format - using a driver override

my $tm = new TM ('> io:stdout { TM::Materialized::XTM} | xsltproc html.xslt - > somefile.html');

Here we assume that the XSLT sheet html.xslt creates an HTML version which is then stored in somefile.html.