Ellen Spertus wrote:
> At 09:57 PM 5/18/2001 -0500, Joi Ellis wrote:
> >Lynx is writing the rendered text to stdout, which you're reading and
> >throwing away. Why not read it and write it to the file yourself?
>
> I thought doing it with redirection would be simpler, but apparently
> not. I re
At 09:57 PM 5/18/2001 -0500, Joi Ellis wrote:
>Lynx is writing the rendered text to stdout, which you're reading and
>throwing away. Why not read it and write it to the file yourself?
I thought doing it with redirection would be simpler, but apparently
not. I rewrote it so my program grabs the
At 03:31 PM 5/18/2001 -0500, you wrote:
>Yes, I noticed the redirection. Have you actually LOOKED at 94.text-plain
>when you invoke this command string manually?
It generates the right output when I can lynx directly but not when I pass
it through a shell. I hadn't realized that lynx would beh
On Fri, 18 May 2001, Ellen Spertus wrote:
> Thanks for the reply.
>
> >Lynx isn't a shell script, you can invoke it directly in the exec() call.
>
> The reason I don't invoke lynx directly is because I am redirecting its
> output to a file, which of course requires a shell. I think that was
Thanks for the reply.
>Lynx isn't a shell script, you can invoke it directly in the exec() call.
The reason I don't invoke lynx directly is because I am redirecting its
output to a file, which of course requires a shell. I think that was
obscured by some bad line breaks in my original message
On Fri, 18 May 2001, Ellen Spertus wrote:
> Sometimes, when I create a process with Runtime.exec, waitFor never
> returns, even though I'm clearing the error and output streams. Here is
> my code, with important lines starred:
>
[snip]
> String[] commandArray = {"/bin/sh", "-c", command
