On Mon, Nov 06, 2000 at 01:29:52PM +0000, Alex Waugh wrote:
>
> Hi
>
> I have had a problem reported from someone using a Perl cgi script with
> WebJames. They are trying to read data from a HTML form (using post),
> using read(STDIN, $buffer, $ENV{'CONTENT_LENGTH'}).
> However this hangs the machine, until either return or escape is pressed.
>
> After a bit of investigating, I have found that this happens when WebJames
> invokes the script with RISC OS style redirection, eg
> scriptname { < scrapfilein > scrapfileout }
> but when Unix style is used
> scriptname < scrapfilein > scrapfileout
> then the script does not hang, and produces the correct output.
I'm pretty sure that this is what's happening (waiting forever for a newline
from the "terminal". The Unixlib code in unix.c.unix initially "opens"
STDIN/OUT/ERR to "/dev/tty", and then processes any Unix style redirection
on the command line. "/dev/tty" creates file handles that read using
OS_ReadC and write using OS_WriteC (rather than OS_GPBP calls on a RISC OS
handle).
> So it seems that when RISC OS style redirection is used, Perl (or
> UnixLib?) is buffering stdin, and is waiting for a newline.
>
> Does anyone have any idea how to fix this?
> I don't really want to change the style of redirection that WebJames uses,
> as that would not work with for example BASIC scripts.
I've got drafted a longer reply which I was about to send but then
remembered something. I don't have an Acorn here to test things with.
This could be a core perl bug to do with EOF not being spotted correctly
on terminals (IIRC innards of perl do message tricks with ungetc to spot
EOF "reliably" on some platforms that have broken stdio). That bug was
fixed. Or it might be something Unixlib related.
I have a couple of ideas of how to fix it, but they differ depending on
what the cause actually is!
Nicholas Clark
