@drunken monkey
Würde es nicht reichen wenn die Datei im selben Verzeichnis, indem auch das Programm liegt, abgespeichert bzw. erstellt würde? Man könnte dann ja imo zb so drauf zugreifen:
...
Das würde wie gesagt nur funktionieren, wenn man das Programm immer aus dem gleichen Verzeichnis aus starten würde. Wenn's allerdings im Path (oder, im Fall von Java, im Classpath) liegt, kann man es auch von jedem anderen Verzeichnis aus starten, und dann würde es in eben diesem verzeichnis nach "commands.ini" suchen - erfolgslos, höchstwahrscheinlich.
Zitat von Crash-Override
Außerdem würde kein vernünftiger nicht-XP-Nutzer auf so eine Idee haben, da du in keinem System abgesehen von XP (und niedriger) Schreibrechte im Anwendungsverzeichnis haben solltest (außer das System ist schlecht konfiguriert oder du hast die Anwendung z.B. auf dem Desktop).
...
Schreibrechte brauche ich auch gar nicht, ich will sie bloß einlesen. Nur der Benutzer muss die Datei ändern können. Daher würde mir das Verzeichnis des Programms eigentlich schon genügen.
Zitat von Jesus_666
Ich weiß nicht, ob Java in der Lage ist, Windows-Variablen aufzulösen. Kann sein, daß du noch %APPDATA% von Hand auflösen darfst...
...
Das schöne Wort "GNAARRRRGGHHRL!" liegt mir auf der Zunge. o_O'
Ich glaube, ich verwende einfach "user.home", das scheint mir noch das Sinnvollste zu sein. <____<''
This method will get the path to the jar or class file no-matter where the jar is called from.
// Get the applications path.
File appPath = new File(System.getProperty("java.class.path"));
try
{
appPath = appPath.getCanonicalFile().getParentFile();
}
catch (IOException e)
{
// TODO Auto-generated catch block
e.printStackTrace();
}
System.out.println("Path: " + appPath.toString());
Echt? o_O' Nach was hast du gesucht?
Aber so geht's, zumindest bei mir, nicht, in "java.class.path" ist der gesamte Classpath drinnen, und nicht nur ein Verzeichnis, daher kann man daraus kein File-Objekt erzeugen, zumindest kein sinnvolles.
Allerdings hast du mich auf eine andere Idee gebracht: man könnte "java.class.path" oder (noch besser) "java.library.path" aufteilen und jedes dieser Verzeichnisse nach der INI-Datei durchsuchen. Dann müsste der User nur noch entweder die Datei in ein Verzeichnis im Path verschieben, oder das Verzeichnis mit der Datei zum Path hinzufügen. Klingt für mich sinnvoll.
Oder ist nur unter Windows in "java.library.path" der OS-Path drin?
@ J: Ja, das wäre auch eine akzeptable Lösung, wollte ich schon machen, aber die jetzt mit dem Path gefällt mir eigentlich noch besser. Ich hätte mir vorher schon die System-Properties von Java genauer anschauen sollen. <____<'' Ach, eine Schande, wieviele dieser *jammer, jammer*-Bitte-helft-mir-Threads eigentlich unnötig wären.
Aber bist du dir überhaupt sicher, dass die Zeile bei Win 9x wirklich klappt? Hat bei den beiden OSs "java.class.path" noch eine/n andere/n Bedeutung/Inhalt?
Und weißt du zufällig, ob der Bug in 6.0 schon behoben wurde?
Edit: Meine (hoffentlich) endgültige Lösung:
--
A human is a system for converting dust billions of years ago into dust billions of years from now via a roundabout process which involves checking email a lot.
Geändert von drunken monkey (13.06.2007 um 13:12 Uhr)