Thanks tye. I think I'm getting confused...must be age senility. I appreciate your patience and attempt to help me and appologize in advance for not letting this drop...but I am confused.

I thought the author of the book was trying to show me a way to *not* create a real file (i.e., to *not* create the &SDTOUT file)...only create the log file...but still effectively re-direct SDTOUT without using the select($logfile) which only works as long as the programmer doesn't do an explicit print to SDTOUT (e.g., print SDTOUT "Hello, world\n" which would would not print to the log file, but rather would print to SDTOUT).

But if the open creates &SDTOUT then the programmer has to invest in additional code to delete that file...which seems like that would defeat the intentions...IMHO.

But in addition, based upon what you wrote, I'm still confused about why the 2-arguent version of open *without* the space between the direction and the & would *not* create the file, but with the space it does. Why does the lack of the space prevent the creation of the file?

I think I'm also confused about the purpose of the anpersand (i.e., the &)...I thought it was a special symbol or prefix...that wouldn't get interpreted as a part of the filename, but rather was necessary to *prevent* the interpretation of SDTOUT as a file name. So...since I obviously don't understand the true nature of the & symble, can you enlighten me as to what *is* it's purpose.

">&STDOUT" is interpretted as ">& STDOUT" while "> &STDOUT" means something quite different. That is

open SAVEOUT, ">&STDOUT"
# is the same as
open SAVEOUT, ">& STDOUT"
# is the same as
open SAVEOUT, ">&", STDOUT
[download]

They all make SAVEOUT point to whatever output destination that the STDOUT file handle already points to. This is what the author was trying to teach you despite how it appeared in print. But

open SAVEOUT, "> &STDOUT"
# is the same as
open SAVEOUT, ">", "&STDOUT"
[download]

They both (try to) create a file called "&STDOUT" and have nothing to do with the STDOUT file handle.

The last example in each of those sets is different if you have a pretty old version of Perl that doesn't support "three-argument open", of course.

- tye        

Ah! Thanks, tye...and parv, too...you both gave that excellent feedback. Now I understand...though I believe the author may have had a typo. But what you presented makes perfect sense...and reflects accurately exactly what happened. Learning things is great...especially when a mis-step leads to a much deeper appreciation of what's going on.

Thanks again to you both.

Sorry it took so long for me to get back to this...I only get an occasional chance, at work, to go out here and see how the Monestary is doing. I just discovered how to find all my previous nodes...that helps. This such an awesome monestary.

ack Albuquerque, NM

(Same as elsewhere in the thread, nothing new.)

still confused about why the 2-argu[m]ent version of open *without* the space between the direction and the & would *not* create the file, but with the space it does. Why does the lack of the space prevent the creation of the file?

The >& construct duplicates the following filehandle or file descriptor (taken from Bourne shell). Otherwise, as in > &, output is directed to some file whose name begins with "&", nothing special.

So >&STDOUT duplicates the STDOUT file handle, while > &STDOUT generates the "&STDOUT" file.