Ergebnis 1 bis 12 von 12

Thema: [Java] Plattformunabhängig Installationsverzeichnis speichern (o.ä.)

Hybrid-Darstellung

Vorheriger Beitrag Vorheriger Beitrag   Nächster Beitrag Nächster Beitrag
  1. #1
    Zitat Zitat von drunken monkey Beitrag anzeigen
    Edit: Hm, bist du sicher, dass das auch mit Java klappt? Oder ist der folgende Code dafür falsch?
    Code:
    private static final File INI_DEST = new File("%APPDATA%\\commands.ini");
    Ich weiß nicht, ob Java in der Lage ist, Windows-Variablen aufzulösen. Kann sein, daß du noch %APPDATA% von Hand auflösen darfst...

  2. #2
    Zitat Zitat von wry Beitrag anzeigen
    @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:

    Code:
    private static final File INI_DEST = new File("commands.ini");
    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 Zitat von Crash-Override Beitrag anzeigen
    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 Zitat von Jesus_666 Beitrag anzeigen
    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. <____<''

  3. #3
    Google, erstes Ergebnis:

    Sun Developer Network - Retrieving the path where the app is started - Letzter Post
    Zitat Zitat
    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());

  4. #4
    So, das hier wäre eine rudimentäre plattformabhängige Lösung. Immerhin kann man in Java automatisiert bis zum Homeverzeichnis des Users kommen.

    Code:
    String homedir = System.getProperty("user.home");
    String osname = System.getProperty("os.name");
    String pathsep = System.getProperty("path.separator");
    String configpath;
    
    
    // Achtung, inkompatibel mit Multiuser-9x.
    // user.home evaluiert unter 9x meistens zu ?:\WINDOWS, nur nicht in Muliusersystemen, wo es zu ?:\WINDOWS\PROFILES\<Username> evaluiert.
    if ("Windows 95" == osname || "Windows 98" == osname)
      configpath = methodPostedByDFYX().toString() + pathsep + "myapp.ini";
    // Keine Ahnung, wie Vista heißt. "Windows Vista" klingt plausibel.
    // Achtung, dieser Code muß für jede Locale angepaßt werden, weil Microsoft die Ordnernamen übersetzt!
    if ("Windows NT" == osname || "Windows 2000" == osname || "Windows XP" == osname)
      configpath = homedir + pathsep + "Dokumente und Einstellungen" + pathsep + "myapp" + pathsep + "myapp.ini";
    elseif ("Mac OS" == osname) // Wir ignorieren Mac OS 9 und früher.
      configpath = homedir + pathsep + "Library" + pathsep + "Preferences" + pathsep + "myapp.ini;"
    else // Wir gehen davon aus, daß alle anderen OSe *nix sind
      configpath = homedir + pathsep + ".myapp" + pathsep + "myapp.ini";

    Achtung, user.home hat unter Windows einen Bug.

  5. #5
    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:
    Code:
    String[] pathDirs = System.getProperty("java.library.path").split("\\" + File.pathSeparator + "+");
    File f = null;
    boolean ini = false;
    
    for (String dir : pathDirs) {
        if (!dir.endsWith(File.separator)) {
            dir += File.separator;
        }
        f = new File(dir + "commands.ini");
        if (f.exists()) {
            break;
        }
    }
    INI_LOC = f;

    Geändert von drunken monkey (13.06.2007 um 13:12 Uhr)

  6. #6
    Zitat Zitat von drunken monkey Beitrag anzeigen
    Echt? o_O' Nach was hast du gesucht?
    Nach Java app path

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •