[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: Status of lposix?
- From: Miles Bader <miles@...>
- Date: Fri, 29 May 2009 15:59:15 +0900
Joshua Jensen <firstname.lastname@example.org> writes:
>> Also, the "slash" and "backslash" methods seem very kludgey; I don't
>> think users of (more or less) portable filename library should really be
>> thinking at that level.
> I've always found a need to convert between the two. Windows, for
> instance, accepts both forward slash and backslash filenames.
Sure, maybe it needs to be done in some cases, but it's a very peculiar
operation. I think really what you have is a particular external format
-- call it "windows-with-backslashes", and in some cases you'd like to
convert that external format to/from the more canonical internal format.
I'm not sure exactly what operations you'd want but they do seem to
belong to a system-dependent extension, rather than in the generic
>> os.filename.with_extension(filename, extension)
> This is certainly an interesting idea. As I stated above, many of the
> names are derived from the shlwapi calls.
Ugh.... anyway, if that's a C interface, it seems somewhat likely that
in that case, the calls actually are destructive, whereas obviously in
Lua's case, they never are (since strings in Lua are immutable).
>>> * os.path.append(leftPath, rightPath): Appends leftPath and rightPath
>>> together, adding a slash between the two path components. If rightPath
>>> is an absolute path, it is not appended to leftPath and is returned
>>> * os.path.combine(leftPath, rightPath): Combines leftPath and rightPath,
>>> adding a slash between the two path components and simplifying the path
>>> by collapsing . and .. directories. If rightPath is an absolute path, it
>>> is not appended to leftPath and is returned directly.
>> These seem slightly confusing, as they sort of refer to the physical
>> composition of the filename, rather than the abstract operation that's
>> happening (making a _truly_ portable filename library is pretty hard,
>> but I think it's good to try and at least operate at a slightly higher
>> level of abstraction than talking about slashes etc).
> The os.path functions work on Windows, Mac OS X, and Unix platforms.
> Forward slashes can be used as directory separators on all.
> What common platforms did you have in mind?
The historical example which usually gets dragged up in such
conversations is something like VMS.
Maybe you don't care about that, but if it's possible to specify a more
abstract operation that can support such OSes, without being harder to
understand/use, that's a good thing (and if it's actually _easier_ to
understand/use, even better).
Anyway, I guess all I really want to say is that it seems better to
think of it in "logical" terms, than with a long fiddly explanation in
terms of slashes and string operations.
Also, it seems the above two calls are confusingly non-orthogonal --
one is "combine two pathnames", the other is "combine two pathnames and
also do syntactic simplications". Why not instead just have a "combine
two pathnames" and a "simplify" function, which could be used in
conjunction if desired?
>> There are many escape syntaxes, and which one to use depends on the
>> context; this method seems out of place.
> What makes the most sense here? If I'm building a command line, I can do:
> myExecutable = '/dirA/dir with spaces/dirB/myexe'
> -- Unix: /dirA/dir\ with\ spaces/dirB/myexe
> -- Windows: "dirA/dir with spaces/dirB/myexe"
Such an escape function is useful, but it doesn't seem to have anything
to do with pathnames (except tangentially, in that the strings it gets
used on will often be pathnames).
What are you going to do with the "command line"? If you're gonna pass
it to a system() function, for instance, then maybe it would be useful
to have an "escape_argument_for_system" function in the os interface,
which is logically paired with a "system" function in the same interface.
Everywhere is walking distance if you have the time. -- Steven Wright