Thank you, I thought that might be the case but I wasn't sure. I'll take a look at the various links offered. I have encountered STDOUT but I guess I don't fully understand how it works, since in other occasions STDOUT seems to apply to command line output. I take it that STDOUT is dynamic and if the script is being called via CGI it knows to output to CGI and if being called via command line knows to output to command line? | [reply] |
This is a reasonable thing to wonder about. Here is a high-level summary of what generally happens: a CGI program will be spawned off by the HTTP server as a separate process which is expected to send its results (valid web content, HTML etc, if all went well) to stdout. The HTTP server collects that, does a bit of post-processing on it and then slings it all back to the source of the original HTTP request.
| [reply] |
Erm, "output to command line" . . . where to start.
STDOUT is, as the name would imply, the, erm, standard output filehandle. Processes get 3 handles: STDIN, STDOUT, and STDERR. What those actually are hooked up to depends on how whatever forks the process hooks them up to. In the interactive case where you're running something from a shell, they'll all usually be hooked up to a TTY device of some sort. When run as a CGI, the webserver will provide a STDOUT which goes back (after some processing in most cases) to the browser making the request.
In Perl the default filehandle for print will be STDOUT unless you use select (or reopen STDOUT somewhere else). Any output to that handle will go to whatever that file descriptor's hooked to.
| [reply] |
You mixed a genuinely helpful reply with a heaping helping of derision, for what reason I'm not really certain. "Erm ... where to start." seems to indicate that you believe you are addressing a gibbering monkey instead of somebody politely asking a question about something that puzzled him.
| [reply] |
fork? That's not how processes happen to come to life in Windows (at least most of the time, the perl fork() builtin included!) which is in all likelihood what PockMonk uses. In either case even under Windows is is the process that starts another process who decides where do the STDOUT, STDERR and STDIN point to (if anywhere at all). In case of a process started by the cmd.exe (the "command line" or "command prompt" or "shell" (for the unix folk)) then the STDOUT and STDERR point to whereever cmd.exe needs them to to display them in its window. In case of CGI scripts, they point to whereever the web server needs them to point to so that it can process the stuff a bit and forward it to the browser.
Though definitely no fork()s and no TTYs are involved. The whole world doesn't run Unix Fletch.
| [reply] |