open() enhancements

<muse>

The open() function doesn't provide for security, sharing modes, and lots of OS-specific hints and modes.

I remember the (pre-standard) C language adding an sopen that took sharing-mode parameters, but that isn't elegant.

I think what Perl needs, in the spirit of Perl, is text-based options inside the filename parameter, just like the cool stuff that's there already. As well as > < | & and whatever else, it could take platform-dependant flags, too.

So if we use ++>> as the delimiter, perhaps open (FH, "<foo.out ++>> sequential) would be used to indicate that the file was going to be used for sequential access (not random access) if that "hint" is possible to the underlying OS.

Since it's part of the string, I'm not too broken up about having platform-dependant stuff in there.

</muse>

—John

Comment on open() enhancements Select or Download Code

Replies are listed 'Best First'.
Re: open() enhancements by RMGir (Prior) on Aug 21, 2002 at 19:53 UTC
Interesting; but why not use the existing (in 5.8) IO Layers? -- Mike PS: Those would have been `[perldoc://]` links, if perldoc had 5.8 docs yet...	[reply] [d/l]
Re: Re: open() enhancements by John M. Dlugosz (Monsignor) on Aug 21, 2002 at 20:00 UTC
You mean simply implement these flags in the PerlIO back-end? Hmm, "layers" is the new name for "disciplines". OK, that won't work because the discipline is applied after the file is opened. The new name "layer" makes the distinction clear. Hmm², `open( $fh, "<:encoding(iso-8859-7)", $pathname );` indeed looks like what I'm talking about. And since :scalar exists, it must be processed early enough. It's not just for `binmode` anymore! Great.	[reply] [d/l] [select]
Re: Re: Re: open() enhancements by RMGir (Prior) on Aug 21, 2002 at 20:08 UTC
Not really; the scalar layer lets you use a scalar as if it were a file, and the mmap layer tells perl to use mmap to open the file. There are also stdio and unix (read/write/lseek/close) layers. If you can do all that, you can do what you'd need for sharing and such too, looks like... -- Mike	[reply]
Re: open() enhancements by tadman (Prior) on Aug 21, 2002 at 22:02 UTC
This convention of using a string to specify not only the file to open, but the how you want it open is thankfully on the way out. Here's an example where there's no string interpolation required to simply open a file: `open($foo, '<', $foo_file);` Throwing in extra syntax could start a sort of file-handle mini-language. Anything that makes Perl look more like line-noise is probably a bad idea. For any odd parameters, maybe something like DBI, such as in this hypothetical example: `open($foo, '<', $foo_file, { sequential => 1 });` This could even be used to cram in permission bits, temporary flags, or what have you.	[reply] [d/l] [select]
Re: Re: open() enhancements by John M. Dlugosz (Monsignor) on Aug 22, 2002 at 23:40 UTC
Two-arg open considered dangerous; syntax on the way out; etc. I've also read in Perl books how great it is, so that a script that takes a "file name" argument can actually do all that stuff. I do like the 4th argument as a hash. There can be universal "well known" names, and OS or FS specific flags that are only respected if applicable, such as `{ WIN32::tempfile => 1 }` which would use the native temp file flag which may be somewhat different in meaning from a Linux temp file flag, etc. That is, by using a namespace-like syntax, flags can keep out of each other's way and not pollute the option space.	[reply] [d/l]
Re3: open() enhancements by blakem (Monsignor) on Aug 23, 2002 at 02:27 UTC
I've also read in Perl books how great it is, so that a script that takes a "file name" argument can actually do all that stuff. The two don't really relate that strongly... For security's sake you need to parse and verify the filename param to the script before handing it to `open` anyway. A design making it easy to pass unverified user input to potentially destructive syscalls is just inviting trouble. But then, I think we agree for the most part. We both seem to like the 4th argument hash idea. ;-) -Blake	[reply] [d/l]
Re: Re: Re: Re: open() enhancements by John M. Dlugosz (Monsignor) on Aug 23, 2002 at 02:32 UTC
Re: open() enhancements by Aristotle (Chancellor) on Aug 21, 2002 at 21:12 UTC
I'm not sure I like the idea of embedding the parameters in a string. Another way might be to make open understand a hashref in place of the filename string, so you can use the old fashioned `open FH, "$mode_char$filename"` style but optionally write, f.ex `open FH, { name => "filename", sequential => 1, mode => "R" };` or something in that vein. Makeshifts last the longest.	[reply] [d/l]
Re: open() enhancements by blakem (Monsignor) on Aug 22, 2002 at 09:36 UTC
You might want to read Two-arg open() considered dangerous before going down that path too far... -Blake	[reply]
Re: open() enhancements by dada (Chaplain) on Aug 22, 2002 at 10:20 UTC
So if we use ++>> as the delimiter, perhaps `open (FH, "<foo.out ++>> sequential")` sounds really dangerous to me, since on my plaftorm (Win32) I can have a file named `"foo.out ++"`. cheers, Aldo King of Laziness, Wizard of Impatience, Lord of Hubris	[reply]


Perl-Sensitive Sunglasses
	PerlMonks