On Tue, 15 Aug 2000, Nathan Wiger wrote: > Chaim Frenkel wrote: > > > > You forget that open() handles all the magic. "| ...", " ...|", and > > the rest of the family. Sysopen specifically doesn't. So one could > > easily (and does) use open to do the magic, and then uses sysread/syswrite > > to handle the dirty details of playing with a pipe. > > Yeah, I agree. Unless there's any objections, for the moment I'm going > to take the socket stuff and the sysopen stuff out of the main part of > the RFC and list it under a "possible extensions" section. > > The more I've looked at sysopen(), the more it looks like pipe() than > open() to me. Same with socket(). Filehandle-returning or not. However, > I would recommend that anything returning a fileobject should use the > new open() syntax: >From perldoc: =item sysopen FILEHANDLE,FILENAME,MODE =item sysopen FILEHANDLE,FILENAME,MODE,PERMS Opens the file whose filename is given by FILENAME, and associates it with FILEHANDLE. If FILEHANDLE is an expression, its value is used as the name of the real filehandle wanted. This function calls the underlying operating system's C<open> function with the parameters FILENAME, MODE, PERMS. etc so I don't see what the problem is. > > $socket = socket ... > $file = sysopen ... > > However, open() shouldn't be the replacement for every operator in Perl. > :-) I think making it an extensible and fileobject-oriented version of > what's there is a good enough improvement. > The above is fine if they return fileobjects. The issue is probably that the socket() and sysopen() commands would probably end up in modules (aka IO::Socket and IO::Sysopen). -- Tim Jenness JCMT software engineer/Support scientist http://www.jach.hawaii.edu/~timj
