=over =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 function with the parameters FILENAME, MODE, PERMS. The possible values and flag bits of the MODE parameter are system-dependent; they are available via the standard module C. However, for historical reasons, some values are universal: zero means read-only, one means write-only, and two means read/write. If the file named by FILENAME does not exist and the C call creates it (typically because MODE includes the C flag), then the value of PERMS specifies the permissions of the newly created file. If you omit the PERMS argument to C, Perl uses the octal value C<0666>. These permission values need to be in octal, and are modified by your process's current C. The C value is a number representing disabled permissions bits--if your C were C<027> (group can't write; others can't read, write, or execute), then passing C C<0666> would create a file with mode C<0640> (C<0666 &~ 027> is C<0640>). If you find this C talk confusing, here's some advice: supply a creation mode of C<0666> for regular files and one of C<0777> for directories (in C) and executable files. This gives users the freedom of choice: if they want protected files, they might choose process umasks of C<022>, C<027>, or even the particularly antisocial mask of C<077>. Programs should rarely if ever make policy decisions better left to the user. The exception to this is when writing files that should be kept private: mail files, web browser cookies, I<.rhosts> files, and so on. In short, seldom if ever use C<0644> as argument to C because that takes away the user's option to have a more permissive umask. Better to omit it. The C module provides a more object-oriented approach, if you're into that kind of thing. =back