Config files

[drsc...@gmail.com]

Is there a way to determine the standard location for application data?
I would like to store some of the configuration options in the user's
application data directory so the user does not have to enter them each
time they run the script. Hopefully, the solution will be platform
independent.

DrS

[Arjen Markus]

I am afraid that _is_ platform-dependent.

Of old, UNIX-like systems have used files like .tclshrc in the home
directory to store initialisation data and on Windows it is common
to use either the Application Data directory under the home directory
of the user or the registry.

Perhaps you can use the strategy of tclshf for this.

From the manual page:
... If there exists a file .tclshrc (or tclshrc.tcl on the Windows
platforms) in the home directory of the user, interactive tclsh
evaluates the file as a Tcl script just before reading the first
command from standard input.

Also the Wiki may have more to say on this.

Regards,

Arjen

[Konstantin Khomoutov]

On Nov 19, 6:50 pm, drscr...@gmail.com wrote:

> Is there a way to determine the standard location for application data?

No easy way, unfortunately, with the most tricky part being Windows.

Below is the code that Tkabber uses.
It works like this:
1) Check if the TKABBER_HOME environment variable exists;
if it does, use what it contains as the data directory,
otherwise guess it depending on the OS.
2) For Windows, the APPDATA env. variable is first checked,
then the Explorer's registry entry;
otherwise rely on Tcl's idea about ~ on this platform.
3) For Mac OS X, use ~/Library/Application Support/Tkabber.
4) For other Unices, use ~/.tkabber

Note that:
1) The way it works for Windows does not require anything beyond
core packages, but not that: a) APPDATA might be absent or
contain an incorrect value; b) reading the registry key is
deprecated since Vista. The true way on Windows is to create
a package that will call SHGetSpecialFolderPath (deprecated
since Windows 2000) or SHGetSpecialFolderPath.
2) On recent Linux platforms, there's a shift to create one additional
level of FS hierarchy under ~, so that applications are supposed
to keep user-specific data not under ~/.appname, but rather
under ~/.local/appname, so take your pick.

The code sets the global variable "configdir" for use by other code,
including plugins.

global configdir

namespace eval config {}

# Deduces the location of the "Application Data" directory
# (in its wide sense) on the current Windows platform.
# See: http://ru.tkabber.jabe.ru/index.php/Config_dir
proc config::appdata_windows {} {
global env

if {[info exists env(APPDATA)]} {
return $env(APPDATA)
}

if {![catch {package require registry}]} {
set key {HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows
\CurrentVersion\Explorer\Shell Folders}
if {![catch {registry get $key AppData} dir]} {
return $dir
}
}

return {}
}

if {![info exists env(TKABBER_HOME)]} {
switch -- $tcl_platform(platform) {
unix {
if {$tcl_platform(os) == "Darwin"} {
set configdir [file join ~ Library "Application Support"
Tkabber]
} else {
set configdir ~/.tkabber
}
}
windows {
set dir [config::appdata_windows]
if {$dir != {}} {
set configdir [file join $dir Tkabber]
} else {
# Fallback default (depends on Tcl's idea about ~):
set configdir [file join ~ .tkabber]
}
}
}

set env(TKABBER_HOME) $configdir
} else {
set configdir $env(TKABBER_HOME)
}

if {$tcl_version >= 8.4} {
set configdir [file normalize $configdir]
}

[drsc...@gmail.com]

Konstantin Khomoutov wrote:
> The code sets the global variable "configdir" for use by other code,
> including plugins.

Thanks to both of you. I will check out the code and see what works best.

DrS

[Donal K. Fellows]

On 24 Nov, 17:23, Konstantin Khomoutov <khomou...@gmail.com> wrote:
> 2) On recent Linux platforms, there's a shift to create one additional
>    level of FS hierarchy under ~, so that applications are supposed
>    to keep user-specific data not under ~/.appname, but rather
>    under ~/.local/appname, so take your pick.

There's also gconf. You do not want to know in detail what's going on
there (think what you might get if you breed the Registry with XML in
the most incestuous way possible...)

Donal.

[Konstantin Khomoutov]

On Nov 25, 1:26 am, drscr...@gmail.com wrote:

> > The code sets the global variable "configdir" for use by other code,
> > including plugins.
> Thanks to both of you. I will check out the code and see what works best.

One correction: the "recent" Windows API function to get names of
special places is SHGetFolderPath -- I mentioned the name of the now
deprecated function twice.

[Konstantin Khomoutov]

On Nov 25, 2:14 am, "Donal K. Fellows"
<donal.k.fell...@manchester.ac.uk> wrote:

>> 2) On recent Linux platforms, there's a shift to create one additional
>> level of FS hierarchy under ~, so that applications are supposed
>> to keep user-specific data not under ~/.appname, but rather
>> under ~/.local/appname, so take your pick.
> There's also gconf. You do not want to know in detail what's going on
> there (think what you might get if you breed the Registry with XML in
> the most incestuous way possible...)

Good point. But this creates the dependency on GNOME and hence it's
not
going to work for all other DEs as well as setups not using DEs at
all.

The good thing is that it seems that the settings can be read just by
calling a program (gconftool-2) with certain parameters
and parsing what it writes to its stdout (which appears to be a
simple "key: value" list of strings as per [1]).

1. http://projects.gnome.org/gconf/