On Thu, Jun 10, 2010 at 2:07 PM, Mark J. Reed <markjr...@gmail.com> wrote:
> But open is already overloaded in p5, with pipes etc.  We don't want
> to repeat the mistakes of the past, and the fact that open(FH, $foo)
> could run an arbitrary shell command was arguably a mistake, but
> transparent access to storage where possible  is the way to go.

I think that 3 argument open fixed that issue for perl 5: with it you
would have to be way more explicit about wanting to open. I think
something similar would work for me in this case too, a flag like

> We can provide a way to limit the behavior when you want - a pragma,
> option to open(), or just sticking "file://" in front of a value to
> force its interpretation as a plain pathname - but even then, who
> knows what Fuse filesystem might be mounted and doing strange things
> with your innocuous-looking file access?  I'd rather have that
> flexibility directly supported in the language.

For me that sounds like the wrong default, mostly because I'm worried
about remote file inclusion vulnerabilities.

> Of course, different types of storage have different features; there's
> no completely unified interface.  But to the extent that a cloud disk
> system or document database functions as a collection of data blobs
> accessed by a pathlike key, enabling the standard filesystem access
> pattern for it (in addition to whatever specific functionality it
> needs) makes sense, IMHO.

I fully agree with that.


Reply via email to