Re: g_spawn_async_with_pipes

[Craig Bakalian <craigbakalian verizon net>]

On Sat, 2011-02-12 at 20:52 +0100, David NeÄas wrote:
> On Sat, Feb 12, 2011 at 01:31:18PM -0500, Dad wrote:
> > If I am going to run the following command line prompt from my
> > application run-time ->
> >
> > echo '\version "2.12" \relative {\clef "alto" c4 d e f g a b c}'
> > | /usr/bin/lilypond --output=myscale.png -
> >
> > using g_spawn_async_with_pipes() how on earth do I set the input of
> > lilypond to suck up the output of echo (notice the pipe)?  Am I thinking
> > incorrectly here?
>
> Well, yes, you do; g_spawn_async_with_pipes() runs a program (similarly
> to execve()).  It does not invoke the shell.  The pipes in its name
> indicate that *your program* will communicate with the subprocess using
> pipes, not that you pass a shell pipeline.
>
> So, to use g_spawn_async_with_pipes() you should obtain the subprocess'
> standard input â from argument standard_input â and send the input there
> from your program instead of echoing it.
>
> I am not aware of GLib wrapper that would work like system(), i.e.
> invoke a shell (there was some in libgnome, IIRC).
>
> Anyway I find it all a bit awkward: if you don't *have to* pass the data
> to the standard input of lilypond isn't creating a temporary file with
> the entire input simpler?
>
> Yeti


Hi Yeti,

Well yes, it is simpler.  And, you are correct, it is awkward.  I just
had this vision of two g_spawn_async_with_pipes() hooked together.
Running echo output &echo_out directly into lilypond's input &echo_out
as if they "may" share &echo_out.  I will need to test/hack this.  I
hate hacking.  I wish we had more examples here in linux land!

I just thought it would be more efficient and quicker to send data
directly to lilypond instead of a file location.  

Craig Bakalian