Re: [Groff] option to set output file name

[Michail Vidiassov]

Dear Ralph,

>> Output redirection is no problem in shell scripts, but if groff is to
>> be spawned from another program it becomes a problem, either you spawn a
>> shell runing a script or spawn groff and have to bother with piping
>> output. You can not just fire off groff and forget about it.
>
> When you say "spawn a shell runing a script" I assume you know you can
> give the shell a command to execute with the -c option without a script
> file needing to exist on disc?  For example, in C,
>
> ret = system("groff foo.tr >foo.ps");
>
> will cause sh(1) to be execve(2)'d with
>
> execve("/bin/sh", ["sh", "-c", "groff foo.tr >foo.ps"], [/* 55 vars */])
>
> So yes, that does involve a shell being started just to run groff, but
> then you're wanting the shell's I/O redirection syntax to be interpreted.
> As I think you're saying, you could avoid this by manually
> forking and setting up file descriptor 0 to be writing to foo.ps before
> execing groff but it's hassle and system() is just easier.

One platform with a large market share is unfortunately "sh" and "fork"
challenged...
And groff supports that platform in native mode, without CygWin.
But due to the lack of "outputname" argument calling groff has to be
platform-specific (sh or CMD involved).

Anyway, I see your point. My problem came from configuring an existing
program that does not just use "system" to call external typesetter but
does some trickery resulting in "execvp". May be the design of that
program is after all not that portable and is to blame for configuration
hassles.

            Sincerely, Michail


               Sincerely, Michail