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 :remote. > 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. Leon
