The python docs are at http://docs.python.org/library/os.path.html
Go would have a different versions of this package depending on the
operating system. Each of them would have the same functions, just
some functions would need different implementations.
ex. path.Join("a", "path", "of", "directories")
if you are on linux, freebsd, ect, the output would be a/path/of/
directories
on windows, the output would be a\path\of\directories
path.Abs(apath)
This would not need different implementations because it would
join(os.getcwd, apath).
Tell me what you think about this.
On Jan 7, 1:47 pm, linuxhacker <linuxhacker...@gmail.com> wrote:
> I would like to know everyone else's opinion on implementing something
> like python's os.path. Python's os.path makes it much easier to manage
> paths and create cross platform programs.
>
> The python docs are athttp://docs.python.org/library/os.path.html
> There's already a package called 'path' that does exactly what you
> need:
>
> http://golang.org/pkg/path/
The Clean function includes:
“3. Eliminate each inner .. path name element (the parent directory)
along with the non-.. element that precedes it.”
and there is an URL to Rob Pike’s “Lexical File Names in Plan 9 or
Getting Dot-Dot right,”
http://plan9.bell-labs.com/sys/doc/lexnames.html, which says:
“The meaning of .. is straightforward if the directory is in a locally
hierarchical part of the name space, but if we ask what .. should
identify when the current directory is a mount point or union
directory or multiply symlinked spot (which we will henceforth call
just a mount point, for brevity), there is no obvious answer. Name
spaces have been part of Plan 9 from the beginning, but the definition
of .. has changed several times as we grappled with this issue. In
fact, several attempts to clarify the meaning of .. by clever coding
resulted in definitions that could charitably be summarized as ‘what
the implementation gives.’
Frustrated by this situation, and eager to have better-defined names
for some of the applications described later in this paper, we
recently proposed the following definition for ..:
The parent of a directory X, X/.., is the same directory that would
obtain if we instead accessed the directory named by stripping away
the last path name element of X.
For example, if we are in the directory /a/b/c and chdir to .., the
result is exactly as if we had executed a chdir to /a/b.”
So this what they wish “..” meant. But this is not what is means in
Linux and probably other Unices; using Clean on a path may change what
it refers to when interpreted by the Linux kernel.
I’m not sure if it is a good idea to provide a supposedly cleaning
function with a semantics which disagrees with the host system. If a
programming language passes paths to the OS unmodified, it is not the
language which defines the semantics of paths but the OS.
--
Marcin Kowalczyk
So this what they wish “..” meant. But this is not what is means in
Linux and probably other Unices; using Clean on a path may change what
it refers to when interpreted by the Linux kernel.
I’m not sure if it is a good idea to provide a supposedly cleaning
function with a semantics which disagrees with the host system. If a
programming language passes paths to the OS unmodified, it is not the
language which defines the semantics of paths but the OS.