What's the perfect (OS independent) way of storing filepaths ?

S

Stef Mientki

hello,

I (again) wonder what's the perfect way to store, OS-independent,
filepaths ?
I can think of something like:
- use a relative path if drive is identical to the application (I'm
still a Windows guy)
- use some kind of OS-dependent translation table if on another drive
- use ? if on a network drive

I'm interested what you all use for this kind of problem.
And I wonder why there isn't a standard solution / library in Python
available.

thanks,
Stef Mientki
 
D

drobinow

I (again) wonder what's the perfect way to store, OS-independent,
filepaths ?

I don't think there is any such thing. What problem are you trying to
solve?
 
S

Steven D'Aprano

hello,

I (again) wonder what's the perfect way to store, OS-independent,
filepaths ?

"Perfect"? I can't imagine any scheme which will work on every imaginable
OS, past present and future.

However, in practice I think there are two common forms still in use:
Posix paths, and Windows paths. I believe that OS/2 can deal with Windows
pathnames, and Mac OS X uses Posix paths (I think...). If you have to
support Classic Mac OS or other non-Posix systems, then your life will
become interesting and complicated.

And let's not even consider Unicode issues...

You might find this page useful:
http://en.wikipedia.org/wiki/Path_(computing)

Note that raw strings are for regular expressions, not Windows paths. Raw
strings can't end in a backslash, so you can't do this:

r'C:\My Documents\'

Instead, you can avoid having to escape backslashes by taking advantage
of the fact that Windows will accept forward slashes as well as
backslashes as path separators, and write 'C:/My Documents/' instead.

I assume you're familiar with the path-manipulation utilities in os.path?
('C:\\\\', 'My Documents\\My File.txt')

I had to fake the above output because I'm not running Windows, so excuse
me if I got it wrong.

But honestly, I think your biggest problem isn't finding a platform-
independent way of storing paths, but simply translating between each
OS's conventions on where files should be stored.

In Linux, config files should go into:

~/.<appname>/ or /etc/<appname>/

In Windows (which versions?) then should go into the Documents And
Settings folder, where ever that is.

There's no single string which can represent both of these conventions!
 
E

Eric Wertman

I (again) wonder what's the perfect way to store, OS-independent,
I'm in agreement that perfect probably isn't applicable. If I were
doing this myself, I might store the information in a tuple:

base = 'some root structure ('/' or 'C')
path = ['some','set','of','path','names']
filename = 'somefile.ext'

pathdata = (root,path,filename)

and write a couple of simple functions to reconstruct them based on the os.
 
S

Stef Mientki

Eric said:
I'm in agreement that perfect probably isn't applicable. If I were
doing this myself, I might store the information in a tuple:

base = 'some root structure ('/' or 'C')
path = ['some','set','of','path','names']
filename = 'somefile.ext'

pathdata = (root,path,filename)

and write a couple of simple functions to reconstruct them based on the os.
Eric, I like your idea.
It looks like a workable technique,
the user should initial define the roots once and everything works.
It should even work for network drives and websites.

Duncan, in windows it's begin to become less common to store settings in
Docs&Settings,
because these directories are destroyed by roaming profiles (a big
reason why I can't run Picassa ;-(
It's more common to follow the portable apps approach, store them in the
application directory.

Drobinow, I want to distribute an application with a large number of
docs and examples.
Now for this application I can put everything in subpaths of the
main-application,
but you triggered me to put a warning in my code if I go outside the
application path.
Another application I've in mind, is a data manager (now written in Delpi),
in which I organize all my information: docs, websites, measurement data
etc.

Others, thank you for the ideas, you learende me some new os.path functions.

cheers,
Stef
 
A

Aaron Brady

Duncan said:
The first of those should do nicely for both Linux and Windows:

'C:\\Documents and Settings\\Duncan\\.appname'

A tuple of path elements, I would think.

You'll want a subclass too, which has a file for the last name, instead
of just folders.

If '..' and '~' aren't universally, recognized, you'll want special
flags.
(DirUp, 'src')

As for rendering them, 'win', 'unix', and 'mac' could be methods.
 
S

Steven D'Aprano

The first of those should do nicely for both Linux and Windows:

'C:\\Documents and Settings\\Duncan\\.appname'


Except Windows users will be wondering why they have a directory starting
with '.' in their home directory. Dot to make files hidden is not AFAIK
supported by Windows.
 
S

Steven D'Aprano

Duncan, in windows it's begin to become less common to store settings in
Docs&Settings,
because these directories are destroyed by roaming profiles

Isn't *everything* destroyed by roaming profiles? *wink*

Seriously, I don't know anyone who has anything nice to say about roaming
profiles.

(a big
reason why I can't run Picassa ;-(
It's more common to follow the portable apps approach, store them in the
application directory.

User config files in a global directory? That bites.
 
S

Steven D'Aprano

Duncan, in windows it's begin to become less common to store settings in
Docs&Settings,
because these directories are destroyed by roaming profiles (a big
reason why I can't run Picassa ;-(
It's more common to follow the portable apps approach, store them in the
application directory.

What do you do when users don't have write permission for the application
directory?
 
R

Ross Ridge

Stef said:
Duncan, in windows it's begin to become less common to store settings in
Docs&Settings,
because these directories are destroyed by roaming profiles (a big
reason why I can't run Picassa ;-(
It's more common to follow the portable apps approach, store them in the
application directory.

Steven D'Aprano said:
What do you do when users don't have write permission for the application
directory?

Use the application data directory (if you want it to roam), or the
local application data directory (if not). However, the normal place
to store settings on Windows is in the registry.

Ross Ridge
 
S

Steven D'Aprano

The leading dot doesn't make the files hidden on Windows, but there's no
reason why you can't create files/folders with a leading dot and many
programs do just that. On the machine I'm on right now, 'dir .*' shows
me:
[snip]

And 75% [1] of average Windows users will either delete the file, move it
to a more convenient[2] location, or edit the file name to remove the dot.

I'm not saying you can't use files with a leading period under Windows.
You can name all your config files using Morse code if you want. I'm
saying it breaks the expected Windows file location guidelines, and it
displays a shameful lack of care by the programmer. Windows users are
more forgiving of badly behaved programs than Macintosh users, but even
so, it's pretty shoddy to ignore a platform's standard file locations.
Unix/Linux coders would rightly be annoyed if some tool created a
directory "/Program Files" instead of using the appropriate /bin
directory. This is no different.





[1] Based on my experience of the typical Windows user. YMMV.

[2] And they are right to do so. Programs that dump config files and
directories, hidden or not, in the top level of the user's home directory
are incredibly rude. It may have been a Unix standard for as long as
there has been a Unix, but it's still the programming equivalent of
coming into somebody's house and throwing your tools all over their
living room floor.
 
C

Cousin Stanley

[2] And they are right to do so. Programs that dump config files and
directories, hidden or not, in the top level of the user's home directory
are incredibly rude. It may have been a Unix standard for as long as
there has been a Unix, but it's still the programming equivalent of
coming into somebody's house and throwing your tools all over their
living room floor.

Personally, I feel the same way about dumping files
into the python site-package directory ....

For example, I've never understood why kde and qt packages
don't use a sub-dir to house their xxxx.so libs ....

Moving the xxxx.egg-info files into sub-dirs or their own tree
would also clean up the site-packages dir ....
 
B

Bruno Desthuilliers

Eric Wertman a écrit :
I'm in agreement that perfect probably isn't applicable. If I were
doing this myself, I might store the information in a tuple:

base = 'some root structure ('/' or 'C')

make it "C:\"
path = ['some','set','of','path','names']
filename = 'somefile.ext'

pathdata = (root,path,filename)

and write a couple of simple functions to reconstruct them based on the os.

like, err, os.path.join ?
 
S

Stef Mientki

Bruno said:
Eric Wertman a écrit :

make it "C:\"
wouldn't " C:/" be more universal and therefor better ?
path = ['some','set','of','path','names']
filename = 'somefile.ext'

pathdata = (root,path,filename)

and write a couple of simple functions to reconstruct them based on
the os.

like, err, os.path.join ?
Yes (because these functions don't function correctly with i.e pdb,
which might be due to bugs in pdb).
cheers,
Stef
 
S

Steven D'Aprano

wouldn't " C:/" be more universal and therefor better ?


Do you really think there are Linux or Mac systems with a C: drive?

This whole question is based on the ludicrous assumption that general
file system paths can be platform-independent. That's a bit like trying
to write code that is programming language-independent.
 
E

Eric Wertman

Do you really think there are Linux or Mac systems with a C: drive?
This whole question is based on the ludicrous assumption that general
file system paths can be platform-independent. That's a bit like trying
to write code that is programming language-independent.


That's sort of where I was going originally... just pick a way to
store the path elements and write some simple functions (yes, many of
them will just be os.path calls) to reconstruct them based on the
actual needs of the application. If your root element is in
ascii.letters then it's most likely windows machine, so adding a ':'
and using os.path.join would be appropriate in the function.
 
L

Lawrence D'Oliveiro

Steven D'Aprano said:
Do you really think there are Linux or Mac systems with a C: drive?

And what about files on Dimdows systems kept on a drive other than C?
This whole question is based on the ludicrous assumption that general
file system paths can be platform-independent.

There is supposed to be a POSIX-compliant layer somewhere underneath all the
Dimdows crud. You could write to that.
 
L

Lawrence D'Oliveiro

Steven D'Aprano said:
And 75% [1] of average Windows users will either delete the file, move it
to a more convenient[2] location, or edit the file name to remove the dot.

Doesn't seem very likely to me. Experienced Dimdows users would well know
that stuffing around with files they don't understand is liable to break
some application or another, so they shouldn't do it.
[2] And they are right to do so. Programs that dump config files and
directories, hidden or not, in the top level of the user's home directory
are incredibly rude. It may have been a Unix standard for as long as
there has been a Unix, but it's still the programming equivalent of
coming into somebody's house and throwing your tools all over their
living room floor.

Hmm, actually you have a point there. There's also the security issue, in
that other users can tell what apps you've been using based on the dotfiles
present in your home directory.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,906
Latest member
SkinfixSkintag

Latest Threads

Top