Gegenstück zum delphi TApplication

[braunbär]

Bei Delphi gibt es die Klasse TAppication mit einem globalen Singleton Application, dort lassen sich so Dinge wie das Handle der Anwendung, der Name des EXE-Files und vieles andere abfragen. In Lazarus/Free Pascal habe ich nichts gefunden, was dem entsprechen würde.
Jetzt würde ich gerade gerne den Dateinamen des Exe-Files abfragen, finde ihn aber nicht. Aber auch andere Properties der Application-Instanz brauche ich gelegentlich. Wo findet man diese Dinge in Free Pascal?

[Warf]

Die TApplication Klasse mit der Globalen Variable Application (also kein richtiger Singelton) gibt es in der Unit Forms.

Sie enthält aber viele Sachen nicht die es in Delphi gibt, die einfach nicht Cross Plattform verfügbar sind. Das Handle einer Application z.B. exsistiert in der Form gar nicht in *nix. Genauso mit dem namen der Executable. In Windows ist das einfach da der erste Param (ParamStr(0)) immer den Vollen Pfad zur Executable gibt. Unter *nix ist das der Pfad mit dem die Exec gestartet wurde (z.b. nur der exec name wenn es im Suchpfad liegt, oder der Absolute oder relative pfad, je nachdem was exec übergeben wurde). Unter Linux kann man den Vollständigen pfad auslesen indem man den Symlink /proc/self/exec auflöst, das geht aber wiederum nicht unter Mac OS (auch ein POSIX system). Nach dem POSIX standard muss es nichtmal eine möglichkeit geben die echte Exec abzufragen, daher ist es nicht in der LCL

[braunbär]

Ok, danke. An paramstr(0) habe ich gar nicht mehr gedacht, das ist natürlich unter Windows die Lösung.

Das ist dann wohl das mühsame an einer Cross-Platform-Entwicklungsumgebung, dass sie alle Mängel von allen in Frage kommenden Zielplattformen kombiniert.

[wp_xyz]

Die TApplication Klasse mit der Globalen Variable Application (also kein richtiger Singelton) gibt es in der Unit Forms.

Sie enthält aber viele Sachen nicht die es in Delphi gibt, die einfach nicht Cross Plattform verfügbar sind. Das Handle einer Application z.B. exsistiert in der Form gar nicht in *nix. Genauso mit dem namen der Executable. In Windows ist das einfach da der erste Param (ParamStr(0)) immer den Vollen Pfad zur Executable gibt. Unter *nix ist das der Pfad mit dem die Exec gestartet wurde (z.b. nur der exec name wenn es im Suchpfad liegt, oder der Absolute oder relative pfad, je nachdem was exec übergeben wurde). Unter Linux kann man den Vollständigen pfad auslesen indem man den Symlink /proc/self/exec auflöst, das geht aber wiederum nicht unter Mac OS (auch ein POSIX system). Nach dem POSIX standard muss es nichtmal eine möglichkeit geben die echte Exec abzufragen, daher ist es nicht in der LCL

Soll das heißen, dass Application.ExeName und ParamStr(0) unter Linux nicht funktionieren? Das deckt sich nicht mit den Ergebnissen des Tests, den ich eben gemacht habe.

[theo]

Soll das heißen, dass Application.ExeName und ParamStr(0) unter Linux nicht funktionieren? Das deckt sich nicht mit den Ergebnissen des Tests, den ich eben gemacht habe.

Auch mit einem Aufruf via Symlink getestet?

[Warf]

Soll das heißen, dass Application.ExeName und ParamStr(0) unter Linux nicht funktionieren? Das deckt sich nicht mit den Ergebnissen des Tests, den ich eben gemacht habe.

Gibt es Application.ExeName unter Linux? Ich hab gestern kurz in die TApplication Definition in der Forms Unit angeschaut und da kein ExeName gefunden (hab aber nur kurz überflogen).

Paramstr(0) muss nicht den namen der Exec enthalten. z.B.:

Code: Alles auswählen

$ testapp arg1
paramstr> testapp arg1
$ ../testapp arg1
paramstr> ../testapp arg1
$ symlinkauftestapp arg1
paramstr> symlinkauftestapp arg1
$ /home/user/testapp arg1
paramstr> /home/user/testapp arg1

Ganz dumm gesagt, es ist immer das erste argument was man als erstes in die Kommandozeile eintippt, da das an execve übergeben wird. Unter Windows ist es immer der absolute Pfad zur Exe. Wie gesagt nach dem POSIX standard müssen die Betriebsysteme keine Möglichkeit bereitstellen die Orginal Exe zu finden. Linux und Mac OS erlauben es trozdem, es kann aber gut sein das es unter BSD z.B. nicht möglich wäre (ich kenn BSD nicht, weiß nur das es sich an den POSIX standard hält).

Richtig verrückt wirds wenn man einfach mal den starndard bricht und execve nicht den dateinamen übergibt:

Code: Alles auswählen

execl("/path/to/app", "irgendeinkomplettanderername", NULL)

Dann ist paramstr(0) von app einfach irgendeinkomplettanderername. Auch wenn das offiziell nicht definiert ist schluckt das sowohl Linux als auch Mac OS

[wp_xyz]

Auch mit einem Aufruf via Symlink getestet?

Ja, funktioniert auch. Nur bei einem Hard-Link kommt das Pfad zum Hardlink, aber das hätte ich auch genauso erwartet, und das gilt auch für Hardlinks unter Windows.

[wp_xyz]

Gibt es Application.ExeName unter Linux?

Ja, steht allerdings beim Vorfahren TCustomApplication - krux der Vererbung... Und wenn man weiterschaut, ruft der Getter der Eigenschaft ExeName, GetExeName, nichts anderes als ParamStr(0) auf!

Das ist alles etwas seltsam:
TCustomApplication.GetExeName --> ParamStr(0) (wenn nicht "Darwin" definiert ist)
TApplication.GetExeName --> ParamStrUTF8(0) (klar, wegen UTF8-Unterstützung der LCL), aber GetExeName ist nicht virtuell

[Warf]

Ja, funktioniert auch. Nur bei einem Hard-Link kommt das Pfad zum Hardlink, aber das hätte ich auch genauso erwartet, und das gilt auch für Hardlinks unter Windows.

Äußerst interresant, das ist eine eigenheit vom FPC.

C:

Code: Alles auswählen

#include <stdio.h>
 
int main(const int argc, const char** argv) {
  for (int i=0; i<argc; printf("%s\n", argv[i++]);
  return 0;
}

Pascal:

Code: Alles auswählen

Program Test;
{$Mode ObjFPC}{$H+}
var i: Integer;
begin
  for i:=0 to ParamCount do WriteLn(ParamStr(0));
end.

Ergebnis:

Code: Alles auswählen

$ ./printArgsC
./printArgsC
$ ./printArgsPas
/home/user/printArgsPas