<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

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]
      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.

      Hmm2, 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]
        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]
      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]
        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: 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
[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]

Back to Meditations