os.path

477 views
Skip to first unread message

linuxhacker

unread,
Jan 7, 2010, 4:47:25 PM1/7/10
to golang-nuts
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 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.

Michael Hoisie

unread,
Jan 7, 2010, 5:23:46 PM1/7/10
to golang-nuts
There's already a package called 'path' that does exactly what you
need:

http://golang.org/pkg/path/

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

Marcin 'Qrczak' Kowalczyk

unread,
Jan 9, 2010, 5:33:36 AM1/9/10
to Michael Hoisie, golang-nuts
2010/1/7 Michael Hoisie <hoi...@gmail.com>:

> 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

Russ Cox

unread,
Jan 9, 2010, 12:57:19 PM1/9/10
to Marcin 'Qrczak' Kowalczyk, Michael Hoisie, golang-nuts
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.

If you'd rather connect "a/b" and ".." and get "a/b/.." there is always
"a/b"+"/"+".." instead of Join("a/b", "..").  "/" works as a path separator
on every OS that Go runs on, even Windows.

Russ

SnakE

unread,
Jan 9, 2010, 4:54:00 PM1/9/10
to r...@golang.org, Marcin 'Qrczak' Kowalczyk, Michael Hoisie, golang-nuts
2010/1/9 Russ Cox <r...@golang.org>

I usually expect that Join() would at least protect from double-slash in a resulting path if the first part ended with a slash; and that it would drop the first part if the second part were absolute.  It's a bit more than just plus-plus-plus.
Reply all
Reply to author
Forward
0 new messages