[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: unoconv listener in an automake file?

From: Alan D. Salewski
Subject: Re: unoconv listener in an automake file?
Date: Sat, 13 Aug 2011 11:36:28 -0400
User-agent: Mutt/1.5.20 (2009-06-14)

Hi Paul,

On Sat, Aug 13, 2011 at 03:55:24AM -0500, Paul Elliott spake thus:
> unoconv is a program that converts openoffice any other documents to 
> different 
> formats. Its man page says it can use a listener: Example:
> > unoconv --listener &
> > unoconv -f pdf some-document.odt
> > unoconv -f doc other-document.odt
> > unoconv -f jpg some-image.png
> > unoconv -f xsl some-spreadsheet.csv
> > kill -15 %-
> If the kill is left off, the listener continues even after the make completes
> and  if debuild has started the make, it will hang untill someone kills the 
> listener. ps -f shows that the listener has made the  ppid=1 after the make 
> completes.
> unoconv man page says that you can omit creating a listener in which case 
> unoconv will create its own. I have never gotten this to work, and it will 
> still have the problem of killing the listener afterwards.
> In the example, the kill command uses the bash job control concept "%-". Is 
> this a legal concept in the concept of a

Anything you can put in a Makefile is legit to put in a, so
sure, you could use '%-' in there.

With that said, using '%-' limits the portability of your to
platforms that have a shell that supports it (bash, ksh, probably
others), and compensating for that requires additional feature checking
on the platform and steps to ensure that the found shell is the one
being used when your Makefile gets run (as opposed to /bin/sh, which
cannot be relied upon to be either bash or ksh).

Instead of '%-', you could capture the pid of the backgrounded 'unoconv'
listener and then use that to explicitly send signals to that process.

> You would probably have 
> to insure that you were in the same shell as the one that started the 
> listener.

To use '%-' you certainly would, but not strictly true if you capture
the backgrounded pid using '$!'. Here's an (untested) example of what
that might look like in a Makefile rule:

        unoconv --listener & \
        ucpid=$! ;\
        unoconv -f pdf some-document.odt  && \
        unoconv -f doc other-document.odt && \
        unoconv -f jpg some-image.png     && \
        unoconv -f xsl some-spreadsheet.csv ;\
        kill -15 $ucpid

One could store the pid value of the backgrounded 'unconv --listener'
process to a file, but since that's gross in this context I won't say
anything more about now that I've menioned that it's possible.

The trailing backslash-newline sequences cause 'make' to invoke a single
shell for all of that, which is required to preserve the $ucpid binding
supplied to 'kill'. Note that the successive 'unoconf -f ...' commands
only execute if the previous invocation succeeds, but the 'kill' command
is always run.

> What is the official, recommended way of handling unoconv listeners in a 
> automake file?

The above is neither official nor (necessarily) recommended -- but (it
is hoped) still useful ;-)

>From a reliability perspective, there are still a number of problems
with the above example.

For starters, the above snippet does not ensure that the SIGTERM
actually caused the backgrounded listener to go away; you'd have to cook
up some fancier mojo to ensure that using increasingly nasty and strong
signals (SIGQUIT, then SIGKILL).

Also, the 'unoconv --listener' invocation will fail if something
(perhaps another 'unoconv --listener' process) is already listening on
what unoconv(1) documents as the default port: 2002.

Finally, unless you're using a new enough 'unoconv', the '&&' chaining
won't actually short-circuit the invocations of the 'unoconv -f ...'
invocations. This is due to an error propagation bug in unconv versions
prior to 0.4 (released 2010-10-20).

Not related to reliability, but the above example is also untidy in that
it would leave the generated pdf, doc, jpg, and xsl documents laying
around. It's conceivable that that could cause successive 'make'
invocations to behave differently.

> Thank You.

You're welcome.

> -- 
> Paul Elliott                               1(512)837-1096
> address@hidden               PMB 181, 11900 Metric Blvd Suite J
>   Austin TX 78758-3117


a l a n   d.   s a l e w s k i                   address@hidden
1024D/FA2C3588 EDFA 195F EDF1 0933 1002  6396 7C92 5CB3 FA2C 3588

reply via email to

[Prev in Thread] Current Thread [Next in Thread]