After trying to post helpful responses on various topics involving redirection, I realize that there is a subtlety I do not understand.

Running in a terminal, it is intuitively obvious that stdin and stdout are both the terminal. If you--eg--say "cat file > newfile" then the output is redirected to the newfile.
If you have the identical command in a script (no terminal open), the result is the same --ie the data goes to newfile.
But what if there is no re-direction? In a script, say "cat file". Where does the output go?

Similarly, what is stdin when running a script with no terminal open?

This was triggered by a question on how to send a command to an ftp session from within a script.

Another related question would be how to cause a script to open a new terminal and then read and/or write from the new terminal.

any command, like your example of cat, will by default send the output of it's command to that console's stdout stream. (and any errors to stderr too) these by deafult appear on your terminal screen but in reality could go off in many different directions. the > then intercepts that stdout and subverts it into a file, which you basically know already i guess. so whatever way it's used, cat still just uses stdout, and it's bash or whatever shell that command is running under that either provides the output as visible to the end user in a console or redirects to a file or another command via a pipe etc... cat has no idea at any level where it's output has gone. if however you have a command liek say, curl, to which you pass a "-o file.txt" argument then this WILL know about it and open the text file output itself and write to it instead of writing to stdout, which would be it's default action.

if a script is running without a terminal then bash (or whatever other interpreter) is still left with the stdout data, and if it get's to the end of the command sequence and is left with data in stdout then it's dropped, presumably to /dev/null but i'm not sure if it actually does require a destination, it may well just delte the data from memory, that does seem more likely actaully. As for stdin, i'm a little less sure, i would be tempted to say that there is no form of stdin at all, and opening that socket will cause anythign to stall. although somethign like bash is bound to wrap that eventuality for anythign running inside it.