Verzeichnis fuer Dateien des Benutzers

[Stefan Ram]

Nehmen wir einmal an, ein Benutzer will zum ersten Mal mit
einem bestimmten Editor einen Text abspeichern. Welches
Verzeichnis sollte der Editor vorschlagen? Ich denke, es
sollte "~" sein, das Heimatverzeichnis des Benutzers.

Der Chatbot hat für mich jetzt die folgende Funktion geschrieben:

def get_document_path():
"""Returns the path for documents based on the operating system."""
if platform.system() == 'Windows':
return Path.home() / 'Documents' # Corresponds to %UserProfile%\Documents
elif platform.system() in ['Linux', 'Darwin']: # Linux and macOS
return Path.home() / 'Documents' # Common location for documents
else:
raise NotImplementedError("Unsupported operating system")

. Wie man sieht, schlägt er da für "Linux" das Unterverzeichnis
"Documents" im Heimatverzeichnis vor. Das zweite
" / 'Documents'" würde ich dann also in der obenstehenden
Funktionsdefinition löschen, weil man unter Linux normalerweise
ja nicht solch ein Unterverzeichnis "Documents" verwendet.

Bei "Darwin" bin ich mir nicht sicher.

Bitte um Hinweise, falls jemand Fehler entdeckt oder mehr über
Darwin weiß!

TIA!

[Frank Miller]

Post by Stefan Ram
Nehmen wir einmal an, ein Benutzer will zum ersten Mal mit
einem bestimmten Editor einen Text abspeichern. Welches
Verzeichnis sollte der Editor vorschlagen? Ich denke, es
sollte "~" sein, das Heimatverzeichnis des Benutzers.

Ich denke nicht.
[..snip..] Bullshit [..snip..]

Post by Stefan Ram
. Wie man sieht, schlägt er da für "Linux" das Unterverzeichnis
"Documents" im Heimatverzeichnis vor. Das zweite
" / 'Documents'" würde ich dann also in der obenstehenden
Funktionsdefinition löschen, weil man unter Linux normalerweise
ja nicht solch ein Unterverzeichnis "Documents" verwendet.

Schau mal in deinem Linux unter ~/.config in die Dateien "user-dirs.dirs" und
"user-dirs.locale".

[Ralph Aichinger]

Post by Stefan Ram
Nehmen wir einmal an, ein Benutzer will zum ersten Mal mit
einem bestimmten Editor einen Text abspeichern. Welches
Verzeichnis sollte der Editor vorschlagen? Ich denke, es
sollte "~" sein, das Heimatverzeichnis des Benutzers.

Ich bin mir nicht sicher. Eventuell wäre auch das working dir,
in dem die Shell gerade ist, aus der der Editor gestartet wurde,
eine besseres Option.

Also natürlich nicht das, in dem das Binary liegt.

Also wenn der Editor "fooditor" heißt würde ich

# cd /etc
# fooditor hosts
[ save ]
[ saving to /etc/hosts ]

als Verhalten erwarten.

/ralph

[Dietrich Clauss]

Post by Ralph Aichinger

Post by Stefan Ram
Nehmen wir einmal an, ein Benutzer will zum ersten Mal mit
einem bestimmten Editor einen Text abspeichern. Welches
Verzeichnis sollte der Editor vorschlagen? Ich denke, es
sollte "~" sein, das Heimatverzeichnis des Benutzers.

Ich bin mir nicht sicher. Eventuell wäre auch das working dir,
in dem die Shell gerade ist, aus der der Editor gestartet wurde,
eine besseres Option.

Exakt so ist es richtig. Jedes Programm, das es nicht irgendwie besser
wissen will (und schlechter macht), macht das auch so.

Post by Ralph Aichinger
Also natürlich nicht das, in dem das Binary liegt.
Also wenn der Editor "fooditor" heißt würde ich
# cd /etc
# fooditor hosts
[ save ]
[ saving to /etc/hosts ]
als Verhalten erwarten.

Ersetze fooditor durch vim, emacs, joe, nano, ..., und da wird das auch
genauso passieren.

Gruß,
- Dietrich

[Stefan Reuther]

Post by Stefan Ram
"""Returns the path for documents based on the operating system."""
return Path.home() / 'Documents' # Corresponds to %UserProfile%\Documents
elif platform.system() in ['Linux', 'Darwin']: # Linux and macOS
return Path.home() / 'Documents' # Common location for documents
raise NotImplementedError("Unsupported operating system")

Das heißt, es gibt genug Leute, die entsprechend stümpern, so dass der
Chatbot das so gelernt hat. Aber korrekt ist das für keins der beiden
Betriebssysteme.

Für Linux:
- https://specifications.freedesktop.org/basedir-spec/latest/
- https://www.freedesktop.org/wiki/Software/xdg-user-dirs/

Für Windows:
-
https://learn.microsoft.com/en-us/windows/win32/api/shlobj_core/nf-shlobj_core-shgetfolderpatha
-
https://learn.microsoft.com/en-us/windows/win32/api/shlobj_core/nf-shlobj_core-shgetknownfolderpath

(Da Microsoft weiß, dass Entwickler stümpern, alleine schon, weil
Microsoft es den Entwicklern unnötig schwer macht, indem sie immer mal
die API ändern, wird das wie oben vermutlich trotzdem funktionieren, da
es einen Symlink namens 'Documents' gibt, der auf den korrekt
internationalisierten Namen zeigt.)


Stefan

[Marc Olschok]

Post by Stefan Ram
Nehmen wir einmal an, ein Benutzer will zum ersten Mal mit
einem bestimmten Editor einen Text abspeichern. Welches
Verzeichnis sollte der Editor vorschlagen? Ich denke, es
sollte "~" sein, das Heimatverzeichnis des Benutzers.

Nicht sehr angenehm, wenn ich in den Editor in einem Unterverzeichnis
gestartet habe, die neue Datei urplötzlich im ~ auftaucht und ich sie
nicht mehr dort vorfinde, wo ich sie brauche.

v.G.

[Stefan Ram]

Post by Marc Olschok

Post by Stefan Ram
Nehmen wir einmal an, ein Benutzer will zum ersten Mal mit
einem bestimmten Editor einen Text abspeichern. Welches
Verzeichnis sollte der Editor vorschlagen? Ich denke, es
sollte "~" sein, das Heimatverzeichnis des Benutzers.

Nicht sehr angenehm, wenn ich in den Editor in einem Unterverzeichnis
gestartet habe, die neue Datei urplötzlich im ~ auftaucht und ich sie
nicht mehr dort vorfinde, wo ich sie brauche.

Stimmt! Ich dachte an einen GUI-Editor, und da spielt das aktuelle
Verzeichnis nach meinem Empfinden weniger eine Rolle. Aber
wenn ich einen Editor auf der Kommandozeile aufrufe, dann sollte
dieser zunächst tatsächlich das aktuelle Verzeichnis vorschlagen.

[Helmut Waitzmann]

Post by Stefan Ram

Post by Marc Olschok

Post by Stefan Ram
Nehmen wir einmal an, ein Benutzer will zum ersten Mal mit
einem bestimmten Editor einen Text abspeichern. Welches
Verzeichnis sollte der Editor vorschlagen? Ich denke, es
sollte "~" sein, das Heimatverzeichnis des Benutzers.

Nicht sehr angenehm, wenn ich in den Editor in einem
Unterverzeichnis gestartet habe, die neue Datei urplötzlich im
~ auftaucht und ich sie nicht mehr dort vorfinde, wo ich sie
brauche.

Stimmt! Ich dachte an einen GUI-Editor, und da spielt das aktuelle
Verzeichnis nach meinem Empfinden weniger eine Rolle. Aber
wenn ich einen Editor auf der Kommandozeile aufrufe, dann sollte
dieser zunächst tatsächlich das aktuelle Verzeichnis vorschlagen.

Genauer:  Er sollte überhaupt kein Verzeichnis vorschlagen:  Wenn
der Anwender dann einen Dateinamen, der keine „/“ enthält,
eintippt, landet die Datei im Arbeitsverzeichnis.


Der Editor sollte auch nicht das Verzeichnis, das im Shell in der
Variablen „PWD“ vermerkt ist oder mit dem Kommando „pwd“
ausgegeben wird, vorschlagen, denn diese beiden geben immer nur
die augenblickliche, nach Ermittlung sofort veraltete,
möglicherweise bereits nicht mehr gültige Vorstellung, die das
Shell (oder der Editor) vom Ort des Arbeitsverzeichnisses hat,
wieder.


Um zu verdeutlichen, was ich meine, probiere das folgende
Shell‐Kommando in einem leeren Verzeichnis aus.  Es erzeugt darin
das Unterverzeichnis „Versuch“ und darin weitere
Unterverzeichnisse und löscht nach getanem Werk alles wieder:


(
mkdir -- Versuch &&
{
n=1 &&
mkdir -p -- Versuch/"$n"/AV &&
{
while
sleep 1 &&
mv -- "$n"/ "$((n+1))"/ &&
n="$((n+1))"
do
:
done &
} &&
pid="$!" &&
{
(
CDPATH= cd -- Versuch/"$n"/AV &&
exec "$SHELL"
)
kill -s INT -- "$pid"
}
sleep 1
rm -R -- Versuch
}
)


Das Kommando legt die Unterverzeichnisse „Versuch/1“ und
„Versuch/1/AV“ an und startet einen Unterprozess, der, im
Hintergrund laufend, nach 1 Sekunde das Verzeichnis „Versuch/1/“
nach „Versuch/2/“, nach einer weiteren Sekunde nach „Versuch/3/“
umbenennt und so, den Unterverzeichnamen hochzählend, fortfährt,
bis man es beendet.


Gleichzeitig startet das Kommando im Vordergrund ein interaktives
(Sub‐)Shell („"$SHELL"“) (anstelle eines Editors), das als
Arbeitsverzeichnis das Verzeichnis „Versuch/1/AV“ hat und in dem
der Anwender Kommandos eintippen kann.  Wenn er dort „exit“
eintippt, kommt es zu Ende.  Dann schickt das Kommando dem
Hintergrundprozess ein INT‐Signal und entfernt das Verzeichnis
„Versuch/“ mitsamt allen darin enthaltenen Unterverzeichnissen. 
Zum Schluss kommt es selbst zu Ende.


Dem gestarteten „"$SHELL"“ wird durch den Hintergrundprozess jede
Sekunde das Arbeitsverzeichnis auf einen neuen Platz im
Dateisystem bewegt, ohne es ihm mitzuteilen (Wie sollte das auch
gehen?).


Im gestarteten interaktiven „"$SHELL"“ kann man jetzt wiederholt
etwa jede Sekunde die Kommandos


pwd -P

pwd -L

oder

cd .

eintippen und beobachten, ob sie weiterhin immer denselben
(veralteten, nicht mehr gültigen) Platz des Arbeitsverzeichnisses
ausgeben oder dem gewechselten Platz folgen.


Ein Editor, gestartet in einem Arbeitsverzeichnis, das ihm „unter
dem Hintern“ woanders hinbewegt wird, wird davon in der Regel
eher nichts mitbekommen und bei seinem Vorschlag, als
Dateispeicherort das von ihm beim Start ermittelte dem
Arbeitsverzeichnis entsprechende absolut angegebene Verzeichnis
zu verwenden, auf die Schnauze fallen, weil er dann versucht, die
Datei in ein nicht vorhandenes Verzeichnis zu speichern.


Über den Ort des Arbeitsverzeichnisses weiß also allenfalls der
Anwender, der den Editor startet, bescheid.  In der Regel wird
der Anwender das Arbeitsverzeichnis eher nicht bewegen, aber
darauf darf sich der Editor nicht verlassen.


Fazit:  Arbeitsverzeichnisse können prinzipiell jederzeit ohne,
dass der davon betroffene Prozess das weiß, ihren Platz im
Dateisystem wechseln.  Die Annahme, ein Prozess könne für sein
Arbeitsverzeichnis verlässlich einen absoluten Dateipfad
bestimmen, muss fallengelassen werden.


Es bleibt nur die Aussage:  Das Arbeitsverzeichnis ist das
Verzeichnis, in dem Dateien stehen, die mit einem Dateinamen, der
am Anfang 0mal oder öfter den Teil „./“, aber keine weiteren „/“
enthält, angefasst werden können.  Desweiteren bezeichnet auch
der Dateiname „./“ immer das Arbeitsverzeichnis, egal, wo es
gerade ist.

[Sieghard Schicktanz]

Hallo Helmut,

Post by Helmut Waitzmann

Post by Stefan Ram
wenn ich einen Editor auf der Kommandozeile aufrufe, dann sollte
dieser zunächst tatsächlich das aktuelle Verzeichnis vorschlagen.

Genauer:  Er sollte überhaupt kein Verzeichnis vorschlagen:  Wenn
der Anwender dann einen Dateinamen, der keine „/“ enthält,
eintippt, landet die Datei im Arbeitsverzeichnis.

Was ist ein "Arbeitsverzeichnis"? Ich wüßte da keine gute Antwort darauf.
Insbes. nicht im Fall des erwähnten Gooey^WGUI-Editors, "wo" der gestartet
wird weiß ggfs. der Fenster- oder ein anderer "Manager".

[Nettes Beispiel eines Verwirrungsgenerators gelöscht]
Schreibst Du öfter mal solche netten Spaßprogramme?

Post by Helmut Waitzmann
Fazit:  Arbeitsverzeichnisse können prinzipiell jederzeit ohne,
dass der davon betroffene Prozess das weiß, ihren Platz im
Dateisystem wechseln.  ...

...

Post by Helmut Waitzmann
Es bleibt nur die Aussage:  Das Arbeitsverzeichnis ist das
Verzeichnis, in dem Dateien stehen, die mit einem Dateinamen, der
am Anfang 0mal oder öfter den Teil „./“, aber keine weiteren „/“

Das passt aber auch nicht ganz. Mehrere "./" sind mehr oder weniger
witzlos, aber Unterverzeichnisse davon müssen dann schon einen einfachen
"/" als Kennung erhalten.

Post by Helmut Waitzmann
enthält, angefasst werden können.  Desweiteren bezeichnet auch
der Dateiname „./“ immer das Arbeitsverzeichnis, egal, wo es
gerade ist.

Was dann auch leicht "ins Auge gehen" kann, wenn der Editor "in" einem
"fremden" oder System-Verzeichnis gestartet wird, wie das z.B. bei einem
Goo^WGUI gern der Fall ist - "/etc/xdg" oder sowas vielleicht?
Sag' das also besser mal den GUI- (jetzt hab' ich's richtig) -Leuten...

[Dietrich Clauss]

Post by Sieghard Schicktanz
Hallo Helmut,

Post by Helmut Waitzmann

Post by Stefan Ram
wenn ich einen Editor auf der Kommandozeile aufrufe, dann sollte
dieser zunächst tatsächlich das aktuelle Verzeichnis vorschlagen.

Genauer:  Er sollte überhaupt kein Verzeichnis vorschlagen:  Wenn
der Anwender dann einen Dateinamen, der keine „/“ enthält,
eintippt, landet die Datei im Arbeitsverzeichnis.

Was ist ein "Arbeitsverzeichnis"? Ich wüßte da keine gute Antwort darauf.

/proc/self/cwd

Post by Sieghard Schicktanz
Insbes. nicht im Fall des erwähnten Gooey^WGUI-Editors, "wo" der gestartet
wird weiß ggfs. der Fenster- oder ein anderer "Manager".

Richtig. Meist laufen diese Manager im Homeverzeichnis des Benutzers
und geben das auch weiter an die Programme, die sie starten.

Ein Dateimanager kann aber bspw. bei Rechtsklick auf ein Verzeichnis den
Punkt "Editor hier öffnen" anbieten. Dann startet er den Editor mit
diesem CWD. Damit das funktioniert, sollte der Editor auch das CWD
anbieten und nicht irgendwas anderes.

Post by Sieghard Schicktanz
Was dann auch leicht "ins Auge gehen" kann, wenn der Editor "in" einem
"fremden" oder System-Verzeichnis gestartet wird, wie das z.B. bei einem
Goo^WGUI gern der Fall ist - "/etc/xdg" oder sowas vielleicht?

Sowas ist mir noch nicht untergekommen, und wenn, dann wäre das ein Bug.

Post by Sieghard Schicktanz
Sag' das also besser mal den GUI- (jetzt hab' ich's richtig) -Leuten...

Wenn es wirklich passiert, sicher gern, die freuen sich über Bugreports.

Gruß,
- Dietrich

[Sieghard Schicktanz]

Hallo Dietrich,

Post by Dietrich Clauss

Post by Sieghard Schicktanz
Was ist ein "Arbeitsverzeichnis"? Ich wüßte da keine gute Antwort darauf.

/proc/self/cwd

Hmm. Da krieg' ich für ein "rxvt" einen Link auf "/proc/<Prozeßnummer>",
und dort rekursiv dasselbe beliebig oft. Naja, vielleicht ein Problem des
"rxvt"?
Ok, anders, file manager probiert. Ok, der liefert was "anständiges", einen
Link auf mein home-Verzeichnis. Na gut.
Anderer file manager, Fremdprodukt, "double commander". Da schaut's wieder
wie beim rxvt aus - war wohl nix.
Einen hätte ich noch, der liefert wieder das "home, sweet home".
So also nicht. GUI-Editor ("leafpad"). Mit File im Aufruf bietet er brav
dessen "Lagerplatz" als Speicherziel an. Aus dem Fenster-Manager-Menü
aufgerufen bietet er _nichts_ als Ziel an, ein Speicherversuch bringt den
Hinweis "Please select a folder below". Ok, er verlangt eine Angabe.

Post by Dietrich Clauss

Post by Sieghard Schicktanz
Insbes. nicht im Fall des erwähnten Gooey^WGUI-Editors, "wo" der
gestartet wird weiß ggfs. der Fenster- oder ein anderer "Manager".

Richtig. Meist laufen diese Manager im Homeverzeichnis des Benutzers
und geben das auch weiter an die Programme, die sie starten.

Aber nicht alle dieser Programme benutzen das halt auch. Man muß sich schon
mal orientieren, was das benutzte so grade macht. Ich habe da auch kein
Problem damit, es scheint aber auch Leute zu geben, die eins haben.

Post by Dietrich Clauss
Ein Dateimanager kann aber bspw. bei Rechtsklick auf ein Verzeichnis den
Punkt "Editor hier öffnen" anbieten. Dann startet er den Editor mit
diesem CWD. Damit das funktioniert, sollte der Editor auch das CWD
anbieten und nicht irgendwas anderes.

Ja, sicher - so _kann_ das laufen. Du _kannst_ ja auch mal in einer
Lotterie gewinnen, wenn Du ein Los kaufst (auch wenn das "nicht ganz"
paßt). Es gibt halt eben _keinen_ "Standard", nicht mal eine einigermaßen
durchgängige Konvention. Und danach war doch original gefragt?

Oder vielleicht doch? Das home-Verzeichnis scheint ja recht gängig zu sein,
das geht auch recht einfach. Gibt halt wieder eine große Müllhalde...

[Helmut Waitzmann]

Post by Sieghard Schicktanz

Post by Helmut Waitzmann

Post by Stefan Ram
wenn ich einen Editor auf der Kommandozeile aufrufe, dann sollte
dieser zunächst tatsächlich das aktuelle Verzeichnis vorschlagen.

Genauer:  Er sollte überhaupt kein Verzeichnis vorschlagen: 
Wenn der Anwender dann einen Dateinamen, der keine „/“
enthält, eintippt, landet die Datei im Arbeitsverzeichnis.

Was ist ein "Arbeitsverzeichnis"? Ich wüßte da keine gute
Antwort darauf.

Das Arbeitsverzeichnis ist genau das Verzeichnis, in dem die
Dateinamen sind oder hineinkommen, deren Name außer den
Pfadkomponenten „.“ (auch mehrmals) keine weiteren
Pfadkomponenten enthält.

Post by Sieghard Schicktanz
Insbes. nicht im Fall des erwähnten Gooey^WGUI-Editors, "wo"
der gestartet wird weiß ggfs. der Fenster- oder ein anderer
"Manager".

Ja, das ist ein Problem,  und ich frage mich schon lange, warum
solche Fenstersysteme beim Start eines Programms keine
Möglichkeit bieten, ein Arbeitsverzeichnis oder eine
Voreinstellung dafür zu wählen.  Das wäre spätestens im Fall,
dass das gestartete Programm mit einem Core‐Dump abstürzt,
wirklich wichtig:  Der Core‐Dump kommt ins Arbeitsverzeichnis.


Da gibt es allerdings häufig Programme, die, einmal gestartet,
als Server leben bleiben können:  Bei weiteren Startversuchen
nimmt dann die neu gestartete Instanz zur Server‐Instanz Kontakt
auf und übergibt ihre Parameterliste an die Server‐Instanz. 
Beispiele sind Gimp, Firefox oder auch die Kombination aus Emacs
und Emacs‐Client.


Da zumindest im traditionellen Unix kein Programm einem
beliebigen anderen (außer seinen Prozess‐Kindern) einen
geöffneten Dateizugriffspfad übergeben kann, gibt es keine
Möglichkeit für den Client, dem Server verlässlich sein
Arbeitsverzeichnis mitzuteilen.  Als Krücke benutzt er dann einen
absoluten Dateipfad, der im Augenblick zum Arbeitsverzeichnis
führt.  Das fällt dann natürlich auf die Schnauze, wenn dem
Client das Arbeitsverzeichnis vom Platz bewegt oder umbenannt
wird.


Dadurch wird der Mechanismus des Arbeitsverzeichnisses für den
Anwender nahezu unbrauchbar.


(Das ist einer der Gründe, warum ich Desktop‐Systeme nicht mag: 
Ich starte alle meine GUI‐Programme mit Server‐Funktion nicht
durch Klicken im Desktop‐System sondern als Hintergrund‐Jobs aus
einem interaktiven Shell im „xterm“, wo ich mein
Arbeitsverzeichnis selber wählen kann.)

Post by Sieghard Schicktanz
[Nettes Beispiel eines Verwirrungsgenerators gelöscht]
Schreibst Du öfter mal solche netten Spaßprogramme?

Wenn's der Wahrheitsfindung dient.

Post by Sieghard Schicktanz

Post by Helmut Waitzmann
Fazit:  Arbeitsverzeichnisse können prinzipiell jederzeit
ohne, dass der davon betroffene Prozess das weiß, ihren Platz
im Dateisystem wechseln.  ...

...

Post by Helmut Waitzmann
Es bleibt nur die Aussage:  Das Arbeitsverzeichnis ist das
Verzeichnis, in dem Dateien stehen, die mit einem Dateinamen,
der am Anfang 0mal oder öfter den Teil „./“, aber keine
weiteren „/“

Das passt aber auch nicht ganz. Mehrere "./" sind mehr oder
weniger witzlos, aber Unterverzeichnisse davon müssen dann
schon einen einfachen "/" als Kennung erhalten.

Ja sicher, aber das sind dann ja auch nicht mehr (unbedingt) das
Arbeitsverzeichnis (sondern Unterverzeichnisse von ihm).

Post by Sieghard Schicktanz

Post by Helmut Waitzmann
enthält, angefasst werden können.  Desweiteren bezeichnet
auch der Dateiname „./“ immer das Arbeitsverzeichnis, egal,
wo es gerade ist.

Was dann auch leicht "ins Auge gehen" kann, wenn der Editor
"in" einem "fremden" oder System-Verzeichnis gestartet wird,
wie das z.B. bei einem Goo^WGUI gern der Fall ist - "/etc/xdg"
oder sowas vielleicht?

Ein Entwickler, der sein GUI das Arbeitsverzeichnis hinter dem
Rücken des Anwenders wechseln lässt, ohne zumindest dem Anwender
zu ermöglichen, das Arbeitsverzeichnis vor dem Start des Editors
zu wählen (s. o.), hat seine Hausaufgaben nicht gemacht.


Meiner Meinung nach gehört das Arbeitsverzeichnis[1] wie auch alle
anderen bereits geöffneten File‐Descriptors einer Prozessumgebung
zu den Eigenschaften, die (nicht nur) für ein GUI heilige Kühe sein
müssen:  Daran hat niemand hinter dem Rücken des Anwenders
herumzufummeln: kein GUI, kein Window‐Manager, kein
Terminal‐Emulator, und ich gehe sogar so weit, zu fordern: auch
kein Programm‐Starter, der die Benutzerkennung wechselt („su“,
„sudo“, u. a.)


[1] Dass das Arbeitsverzeichnis so etwas ähnliches wie ein
bereits geöffneter File‐Descriptor (auf eben das
Arbeitsverzeichnis) ist, sieht man spätestens mit dem Aufkommen
der „…at(2)“‐Systemaufrufe:  Sie erhalten als zusätzlichen
Parameter einen Datei‐Descriptor, der auf ein geöffnetes
Verzeichnis verweist, oder einen speziellen Datei‐Descriptor, der
das Arbeitsverzeichnis bezeichnet (siehe beispielsweise im
Manual‐Page „openat(2)“ den im Vergleich zu „open(2)“ vorhandenen
Extra‐Parameter „dirfd“ (in der deutschen Fassung des
Manual‐Pages: „Verzdd“) und das file status flag „O_PATH“).


Aus dem deutschen Manual‐Page „openat(2)“:


Der Systemaufruf openat() arbeitet genau wie open(), außer den
hier beschriebenen Unterschieden.


Falls der in Pfadname angegebene Pfadname relativ ist, dann wird
er relativ zu dem Verzeichnis interpretiert, auf das der
Dateideskriptor Verzdd verweist (statt relativ zu dem aktuellen
Arbeitsverzeichnis des aufrufenden Prozesses, wie es bei open()
für einen relativen Pfadnamen erfolgt).


Falls Pfadname relativ ist und Verzdd den speziellen Wert
AT_FDCWD enthält, dann wird Pfadname relativ zum aktuellen
Arbeitsverzeichnis des aufrufenden Prozesses interpretiert (wie
open()).


Falls Pfadname absolut ist, wird Verzdd ignoriert.


Soweit das Zitat.


Ein Beispiel, welche heiligen Kühe man nicht schlachten soll: 
Angenommen, ich möchte die Ausgaben (stdout und stderr) eines
Programms der Übersicht halber getrennt in zwei
Terminals (oder Terminal‐Emulatoren) sehen können.


Mit dem Terminal‐Emulator „xterm“ geht das so:


Ich starte in einem Terminal(‐Emulator), in dem ein interaktives
Shell läuft, das folgende Kommando:


xterm -e sh -c 'exec 1>&3 3>&- "$@"' sh mein_Programm 3>&1


Das bewirkt, dass die Daten, die „mein_Programm“ nach stdout
schreibt, in dem Terminal zu sehen sind, in dem ich das Kommando
eingetippt habe, während die Daten, die „mein_Programm“ nach
stderr schreibt, in dem neu geöffneten „xterm“ zu sehen sind.


Vor Jahren habe ich dasselbe mit einem Gnome‐Terminal anstelle
eines „xterm“ probiert und bin damit gescheitert:  Das
Gnome‐Terminal hat sich erdreistet, den File‐Descriptor 3, den
ich ihm geöffnet mitgegeben habe, ungefragt zu schließen.


Wie heißt es so schön?  Provide mechanism, not policy!

Post by Sieghard Schicktanz
Sag' das also besser mal den GUI- (jetzt hab' ich's richtig)
-Leuten...

[Peter J. Holzer]

Post by Helmut Waitzmann

Post by Sieghard Schicktanz
Insbes. nicht im Fall des erwähnten Gooey^WGUI-Editors, "wo"
der gestartet wird weiß ggfs. der Fenster- oder ein anderer
"Manager".

Ja, das ist ein Problem,  und ich frage mich schon lange, warum
solche Fenstersysteme beim Start eines Programms keine
Möglichkeit bieten, ein Arbeitsverzeichnis oder eine
Voreinstellung dafür zu wählen.

Vermutlich, weil das beim Start des Programms wirklich lästig wäre. Wenn
man ein Programm in ein Menü einträgt, kann man das Working-Directory
bei vielen Systemen dort eintragen (ich weiß nicht, ob das bei allen so
ist, und es interessiert mich nicht ausreichend, um das auch nur auf den
üblichsten auszuprobieren).

Post by Helmut Waitzmann
  Das wäre spätestens im Fall, dass das gestartete Programm mit einem
Core‐Dump abstürzt, wirklich wichtig:  Der Core‐Dump kommt ins
Arbeitsverzeichnis.

Wenn ich mir den wirklich ansehen will, finde ich ihn auch im $HOME
(oder ~/Desktop oder was auch immer das Programm als Arbeitsverzeichnis
auserkoren hat). Das ist ein eher schwaches Argument für die Wichtigkeit
des Arbeitsverzeichnisses.

(Thunar (der Filemanager von XFCE) startet übrigens Programme im
Directory das Files, das man öffnet.)

Post by Helmut Waitzmann
Da zumindest im traditionellen Unix kein Programm einem
beliebigen anderen (außer seinen Prozess‐Kindern) einen
geöffneten Dateizugriffspfad übergeben kann, gibt es keine
Möglichkeit für den Client, dem Server verlässlich sein
Arbeitsverzeichnis mitzuteilen.  Als Krücke benutzt er dann einen
absoluten Dateipfad, der im Augenblick zum Arbeitsverzeichnis
führt.  Das fällt dann natürlich auf die Schnauze, wenn dem
Client das Arbeitsverzeichnis vom Platz bewegt oder umbenannt
wird.
Dadurch wird der Mechanismus des Arbeitsverzeichnisses für den
Anwender nahezu unbrauchbar.

Wie oft benennst Du Verzeichnisse um, in denen sich ein File befindet,
das Du gerade editierst? Ich mache das vielleicht alle paar Jahre,
obwohl das bei meiner terminal-zentrierten Arbeitsweise kein Problem
wäre. Der typische GUI-User sicher seltener. Ein Verhalten, das alle
paar Jahre mal zu 30 Sekunden Verwirrung führt, als "nahezu unbrauchbar"
zu bezeichnen, halte ich für ziemlich realitätsfremd.

hp

[Sieghard Schicktanz]

Hallo Helmut,

Post by Helmut Waitzmann

Post by Sieghard Schicktanz
Was ist ein "Arbeitsverzeichnis"? Ich wüßte da keine gute
Antwort darauf.

Das Arbeitsverzeichnis ist genau das Verzeichnis, in dem die
Dateinamen sind oder hineinkommen, deren Name außer den
Pfadkomponenten „.“ (auch mehrmals) keine weiteren
Pfadkomponenten enthält.

Ja, das ist die phänomenologische Beschreibung. Gesucht war aber eine
definitorische.

Post by Helmut Waitzmann

Post by Sieghard Schicktanz
Insbes. nicht im Fall des erwähnten Gooey^WGUI-Editors, "wo"
der gestartet wird weiß ggfs. der Fenster- oder ein anderer
"Manager".

Ja, das ist ein Problem,  und ich frage mich schon lange, warum
solche Fenstersysteme beim Start eines Programms keine
Möglichkeit bieten, ein Arbeitsverzeichnis oder eine
Voreinstellung dafür zu wählen.  ...

Ich nehme an, um die Belästigungen des Benutzers nicht noch weiter ins
Extrem zu treiben - er soll den Editor ja schließlich benutzen.

Post by Helmut Waitzmann
Voreinstellung dafür zu wählen.  Das wäre spätestens im Fall,
dass das gestartete Programm mit einem Core‐Dump abstürzt,
wirklich wichtig:  Der Core‐Dump kommt ins Arbeitsverzeichnis.

Nicht ins Startverzeichnis? (D.h. das Verzeichnis, das das
Arbeitsverzeichnis des startenden Programms zum Startzeitpunkt war.)

...

Post by Helmut Waitzmann
Da zumindest im traditionellen Unix kein Programm einem
beliebigen anderen (außer seinen Prozess‐Kindern) einen
geöffneten Dateizugriffspfad übergeben kann, ...

Das mag im "traditionellen" (Ur-?) Unix so sein, aber es gibt doch,
wenigstens inzwischen, Funktionen, die solche Möglichkeiten implementieren.

....

Post by Helmut Waitzmann
Client das Arbeitsverzeichnis vom Platz bewegt oder umbenannt
wird.
Dadurch wird der Mechanismus des Arbeitsverzeichnisses für den
Anwender nahezu unbrauchbar.

Und das passiert natürlich laufend? Meiner Erfahrung nach sind solche
Strukturen eher recht statisch, und vieles darin ist sogar gegen
unerwartete Änderungen gesichert. Da muß dann schon ein root-Dämon Amok
laufen....

Post by Helmut Waitzmann
(Das ist einer der Gründe, warum ich Desktop‐Systeme nicht mag: 
Ich starte alle meine GUI‐Programme mit Server‐Funktion nicht
durch Klicken im Desktop‐System sondern als Hintergrund‐Jobs aus
einem interaktiven Shell im „xterm“, wo ich mein
Arbeitsverzeichnis selber wählen kann.)

Was dem gestarteten Programm dann gleich egal sein kann, wenn es das selber
neu einstellt.

...

Post by Helmut Waitzmann
Meiner Meinung nach gehört das Arbeitsverzeichnis[1] wie auch alle
anderen bereits geöffneten File‐Descriptors einer Prozessumgebung
zu den Eigenschaften, die (nicht nur) für ein GUI heilige Kühe sein
müssen:  Daran hat niemand hinter dem Rücken des Anwenders
herumzufummeln: ...

So recht "heilig" braucht das nicht zu sein, wenn es der Benutzer einfach
erfahren und auch selber ändern kann. Die "kritische Stelle" ist halt dort,
wo es zum ersten Mal zum dauerhaften Speichern von Daten benutzt wird, und
das _auch dann_, wenn es sich dabei "nur" um Zwischen- oder Sicherungsdaten
handelt. Die sollten IMHO tunlichst _nicht_ an willkürlichen Stellen im
Dateisystem als Datenmüll liegenbleiben können.

[Peter J. Holzer]

Post by Sieghard Schicktanz

Post by Helmut Waitzmann
Das wäre spätestens im Fall, dass das gestartete Programm mit einem
Core‐Dump abstürzt, wirklich wichtig:  Der Core‐Dump kommt ins
Arbeitsverzeichnis.

Nicht ins Startverzeichnis? (D.h. das Verzeichnis, das das
Arbeitsverzeichnis des startenden Programms zum Startzeitpunkt war.)

Warum sollte sich das Betriebssystem das Startverzeichnis eines
Prozesses merken, nur um den Coredump dorthin schreiben zu können?

hp

[Sieghard Schicktanz]

Hallo Peter,

Post by Peter J. Holzer

Post by Sieghard Schicktanz

Post by Helmut Waitzmann
Core‐Dump abstürzt, wirklich wichtig:  Der Core‐Dump kommt ins
Arbeitsverzeichnis.

Nicht ins Startverzeichnis? (D.h. das Verzeichnis, das das
Arbeitsverzeichnis des startenden Programms zum Startzeitpunkt war.)

Warum sollte sich das Betriebssystem das Startverzeichnis eines
Prozesses merken, nur um den Coredump dorthin schreiben zu können?

Ja, schon, ist 'ne Frage, aber warum sollte es nicht?
Ein Argument dafür wäre eventuell, daß das Startverzeichnis sicher bekannt
sein müßte, das aktuelle Arbeitsverzeichnis aber möglicherweise nicht.

[Peter J. Holzer]

Post by Sieghard Schicktanz

Post by Peter J. Holzer

Post by Sieghard Schicktanz

Post by Helmut Waitzmann
Core‐Dump abstürzt, wirklich wichtig:  Der Core‐Dump kommt ins
Arbeitsverzeichnis.

Nicht ins Startverzeichnis? (D.h. das Verzeichnis, das das
Arbeitsverzeichnis des startenden Programms zum Startzeitpunkt war.)

Warum sollte sich das Betriebssystem das Startverzeichnis eines
Prozesses merken, nur um den Coredump dorthin schreiben zu können?

Ja, schon, ist 'ne Frage, aber warum sollte es nicht?
Ein Argument dafür wäre eventuell, daß das Startverzeichnis sicher bekannt
sein müßte, das aktuelle Arbeitsverzeichnis aber möglicherweise nicht.

Und eines dagegen, dass es eine Anwendung daran hindern würde, das Ziel
für Coredumps selbst zu bestimmen (bei Apache kann man das z.B.
konfigurieren).

Ist aber egal, ob das theoretisch sinnvoll wäre oder nicht. Linux (oder
soweit ich weiß irgendein anderes Unix) merkt sich das Startdirectory
nicht. Zum Zeitpunkt des Coredumps ist die Information also schlicht
nicht vorhanden.

hp

[Ralph Aichinger]

Post by Sieghard Schicktanz
Was ist ein "Arbeitsverzeichnis"? Ich wüßte da keine gute Antwort darauf.

Das Arbeitsverzeichnis oder "Working Directory" ist das Verzeichnis in
dem der Editor gestartet wird:

https://de.wikipedia.org/wiki/Arbeitsverzeichnis

Post by Sieghard Schicktanz
Insbes. nicht im Fall des erwähnten Gooey^WGUI-Editors, "wo" der gestartet
wird weiß ggfs. der Fenster- oder ein anderer "Manager".

Da es zum Übergeben des Arbeitsverzeichnisses überall Mechanismen gibt,
ist es leicht das rauszufinden. Vermutlich nach GUI und Betriebssystem
leicht unterschiedlich.

/ralph

[Peter J. Holzer]

Post by Ralph Aichinger

Post by Sieghard Schicktanz
Was ist ein "Arbeitsverzeichnis"? Ich wüßte da keine gute Antwort darauf.

Das Arbeitsverzeichnis oder "Working Directory" ist das Verzeichnis in

Beim Programmstart. Der Editor kann natürlich sein Arbeitsverzeichnis
wechseln, entweder durch explizite Benutzeranweisung (im vim mittels
»:chdir«) oder weil der Programmierer das für sinnvoll erachtet hat.

Außerdem verschiebt diese Definition nur die Frage: In welchem Directory
wird ein (GUI-)Editor gestartet?

Richtiger (aber vielleicht für User weniger verständlich):

Das Arbeitsverzeichnis ist eine Eigenschaft jedes Unix-Prozesses.
Es gibt den Startpunkt für die Auflösung relativer Pfadnamen an.
Ein Prozess erbt das Arbeitsverzeichnis von seinem Parent-Prozess und
kann es ändern.

hp

[Ralph Aichinger]

Post by Peter J. Holzer
Beim Programmstart. Der Editor kann natürlich sein Arbeitsverzeichnis
wechseln, entweder durch explizite Benutzeranweisung (im vim mittels
»:chdir«) oder weil der Programmierer das für sinnvoll erachtet hat.

Klar.

Post by Peter J. Holzer
Außerdem verschiebt diese Definition nur die Frage: In welchem Directory
wird ein (GUI-)Editor gestartet?

Natürlich, das ganze Konzept des Arbeitsverzeichnisses ist für CLIs
ungleich relevanter und intuitiv nachvollziehbarer als bei GUIs.
Eventuell sollte man bei den meisten GUI-Programmen das Konzept des
Arbeitsverzeichnisses gleich wieder vergessen und in den UI-Guidelines
nachsehen wie sich ein in die jeweilige GUI gut einfügendes Programm
richtigerweise verhalten soll.

Immer wieder mal begegnen mir Programme, die diesbezüglich ein
unintuitives Verhalten haben, z.B. hab ich vor 3 Wochen irgendwas
im Verzeichnis XY vom Projekt Z abgespeichert, und heute mach ich das
Programm auf, Projekt Z ist schon lange vergessen und abgeschlossen, und
das Programm will immer noch dorthin speichern, anstatt z.B. in "Dokumente"
oder "Downloads" in meinem Home. Wobei das halt auch eine Gratwanderung
ist, vielleicht ist für manche obiges Verhalten das gewünschte.

Besonders nervig ist, wenn das ganze ohne Nachfrage und Interaktion
passiert, machst seit 3 Wochen das erste mal auf, drückst Ctrl-S (oder
Cmd-S), der Cursor ändert kurz die Form, und du hast "irgendwo", wo du
sie nicht mehr findest, eine Datei liegen ;)

Post by Peter J. Holzer
Das Arbeitsverzeichnis ist eine Eigenschaft jedes Unix-Prozesses.
Es gibt den Startpunkt für die Auflösung relativer Pfadnamen an.
Ein Prozess erbt das Arbeitsverzeichnis von seinem Parent-Prozess und
kann es ändern.

Das ist natürlich sehr viel besser formuliert.

/ralph

[Peter J. Holzer]

Post by Ralph Aichinger
Immer wieder mal begegnen mir Programme, die diesbezüglich ein
unintuitives Verhalten haben, z.B. hab ich vor 3 Wochen irgendwas
im Verzeichnis XY vom Projekt Z abgespeichert, und heute mach ich das
Programm auf, Projekt Z ist schon lange vergessen und abgeschlossen, und
das Programm will immer noch dorthin speichern, anstatt z.B. in "Dokumente"
oder "Downloads" in meinem Home. Wobei das halt auch eine Gratwanderung
ist, vielleicht ist für manche obiges Verhalten das gewünschte.

Ich finde das einigermaßen sinnvoll, wenn das Programm nicht mit
einem erkennbaren anderen Zieldirectory gestartet wurde. Dass ich der
Stelle weiterarbeiten will, wo ich beim letzten mal aufgehört habe,
ist eine plausible Annahme (auch nach 3 Wochen, eher nicht mehr nach
3 Jahren). Hingegen ist "Dokumente" oder "Downloads" bei mir *immer*
falsch. Diese Directorys verwende ich nie absichtlich, dort sammelt sich
nur Schrott an, wenn ich nicht aufpasse oder das Programm gar nicht erst
nachfragt (Chrome, I'm looking at you!).

Recht intelligent finde ich die Art, wie Firefox Downloads managt. Bei
einem Browser macht "aktuelles Arbeitsverzeichnis" ja ganz offensichtlich
keinen Sinn. Stattdessen merkt er sich für jede Website, wohin man beim
letzten Mal gespeichert hat. Das ist dann fast sicher auf der Ort, wo ich
den nächsten Download von dieser Website haben will, denn klarerweise
will ich OECD-Daten und Lohnzettel nicht im gleichen Directory haben
(schon gar nicht in ~/Downloads).

hp

[Stefan+ (Stefan Froehlich)]

Post by Ralph Aichinger
Immer wieder mal begegnen mir Programme, die diesbezüglich ein
unintuitives Verhalten haben, z.B. hab ich vor 3 Wochen irgendwas
im Verzeichnis XY vom Projekt Z abgespeichert, und heute mach ich
das Programm auf, Projekt Z ist schon lange vergessen und
abgeschlossen, und das Programm will immer noch dorthin speichern,
[...]
Besonders nervig ist, wenn das ganze ohne Nachfrage und
Interaktion passiert, machst seit 3 Wochen das erste mal auf,
drückst Ctrl-S (oder Cmd-S), der Cursor ändert kurz die Form, und
du hast "irgendwo", wo du sie nicht mehr findest, eine Datei
liegen ;)

Sofern es den Menüpunkt "speichern unter" gibt, kann man den
aufrufen und sieht dort meistens eben dieses Verzeichnis als Default
eingestellt. Geht schneller als ein find(1) über das gesamte
Homeverzeichnis.

Servus,
Stefan

[Sieghard Schicktanz]

Hallo Ralph,

Post by Ralph Aichinger

Post by Sieghard Schicktanz
Was ist ein "Arbeitsverzeichnis"? Ich wüßte da keine gute Antwort darauf.

Das Arbeitsverzeichnis oder "Working Directory" ist das Verzeichnis in

Das ist das _Start_verzeichnis. Ich meinte das Verzeichnis, das das
Programm verwendet, wenn es im Betrieb eine Datei ohne Angabe eines
Verzeichnisses speichert, also das, was ein "pwd" liefern würde, wenn das
ausgeführt würde, wenn es ausgeführt werden könnte.

...

Post by Ralph Aichinger
Da es zum Übergeben des Arbeitsverzeichnisses überall Mechanismen gibt,
ist es leicht das rauszufinden. ...

Ja, "klar" - fragt sich nur wie, wenn das Programm da nix liefert.
Im "/proc" rumwühlen ist _nicht_ kompatibel mit "leicht".

[Ralph Aichinger]

Post by Sieghard Schicktanz

Post by Ralph Aichinger
Da es zum Übergeben des Arbeitsverzeichnisses überall Mechanismen gibt,
ist es leicht das rauszufinden. ...

Ja, "klar" - fragt sich nur wie, wenn das Programm da nix liefert.
Im "/proc" rumwühlen ist _nicht_ kompatibel mit "leicht".

Für fast jede Programmiersprache wirst du mit einer Minute Googeln
Beispielcode dafür finden.

Python:

https://www.linode.com/docs/guides/python-get-current-directory/

C/C++

https://pubs.opengroup.org/onlinepubs/007904975/functions/getcwd.html

Java:

https://stackoverflow.com/questions/4871051/how-to-get-the-current-working-directory-in-java

Rust:

https://doc.rust-lang.org/stable/std/env/fn.current_dir.html#

/ralph

[Peter J. Holzer]

Post by Ralph Aichinger

Post by Sieghard Schicktanz

Post by Ralph Aichinger
Da es zum Übergeben des Arbeitsverzeichnisses überall Mechanismen gibt,
ist es leicht das rauszufinden. ...

Ja, "klar" - fragt sich nur wie, wenn das Programm da nix liefert.
Im "/proc" rumwühlen ist _nicht_ kompatibel mit "leicht".

In Helmuts Beispiel ging es um *kooperierende* Prozesse (z.B. Emacs und
Emacs-Client oder Gimp-Instanzen). Da liefert die der Prozess natürlich,
wenn das für das Funktionieren wichtig ist. Da muss niemand in /proc
herumwühlen.[1]

Post by Ralph Aichinger
Für fast jede Programmiersprache wirst du mit einer Minute Googeln
Beispielcode dafür finden.
https://www.linode.com/docs/guides/python-get-current-directory/
C/C++
https://pubs.opengroup.org/onlinepubs/007904975/functions/getcwd.html
https://stackoverflow.com/questions/4871051/how-to-get-the-current-working-directory-in-java
https://doc.rust-lang.org/stable/std/env/fn.current_dir.html#
/ralph

All diese Methoden liefern das CWD des Prozesses, der sie aufruft. Nicht
das eines anderen Prozesses. Dieses dann an einen anderen Prozess zu
übergeben ist etwas anderes (da man aber in den genannten Fällen ohnehin
irgendeine Art von Interprozesskommunikation braucht, kann man über
diesen Kanal natürlich auch das CWD schicken.

hp


[1] Ich vermute[2] aber, dass manche Terminalemulatoren (z.B.
xfce4-terminal) das machen, um das Working-Directory der Shell
herauszufinden. Zumindest fällt mir kein direkterer Weg ein.

[2] Jaja, ich weiß: Use the source, Luke ...

[Sieghard Schicktanz]

Hallo Ralph,

Post by Ralph Aichinger

Post by Sieghard Schicktanz

Post by Ralph Aichinger
Da es zum Übergeben des Arbeitsverzeichnisses überall Mechanismen
gibt, ist es leicht das rauszufinden. ...

Ja, "klar" - fragt sich nur wie, wenn das Programm da nix liefert.
Im "/proc" rumwühlen ist _nicht_ kompatibel mit "leicht".

Für fast jede Programmiersprache wirst du mit einer Minute Googeln
Beispielcode dafür finden.

Ja, richtig schön, wenn der Benutzer vor dem Monitor sitzt und weiß, daß
der Programmierer das einfach abfragen kann, aber er keine Möglichkeit hat,
das vo dem seinen (!) Programm zu erfahren.
Du verwechselst da nicht zufällig die Beziehungen zwischen Software und
Anwender?

[Peter J. Holzer]

Post by Sieghard Schicktanz

Post by Ralph Aichinger

Post by Sieghard Schicktanz

Post by Ralph Aichinger
Da es zum Übergeben des Arbeitsverzeichnisses überall Mechanismen
gibt, ist es leicht das rauszufinden. ...

Ja, "klar" - fragt sich nur wie, wenn das Programm da nix liefert.
Im "/proc" rumwühlen ist _nicht_ kompatibel mit "leicht".

Für fast jede Programmiersprache wirst du mit einer Minute Googeln
Beispielcode dafür finden.

Ja, richtig schön, wenn der Benutzer vor dem Monitor sitzt und weiß, daß
der Programmierer das einfach abfragen kann, aber er keine Möglichkeit hat,
das vo dem seinen (!) Programm zu erfahren.

Deine Gedankensprünge sind schwer nachvollziehbar.

hp

[Sieghard Schicktanz]

Hallo Peter,

Post by Peter J. Holzer

Post by Sieghard Schicktanz
Ja, richtig schön, wenn der Benutzer vor dem Monitor sitzt und weiß, daß
der Programmierer das einfach abfragen kann, aber er keine Möglichkeit
hat, das vo dem seinen (!) Programm zu erfahren.

Deine Gedankensprünge sind schwer nachvollziehbar.

Achso, für Dich ist der Benutzer (und da ging's zumindest _auch_ um solche,
die mit ooey^WGUI arbeiten) entweder gleich dem Programmierer oder ein
irrelevantes Detail der Programmerstellung?
Also wenn ich ein Programm schreibe, dann bin ich da der _Benutzer_ des
Editors und der weiteren benötigten Programme, und da möchte ich schon ein
wenig Beachtung vom Programmierer erfahren.

[Jens Schuessler]

Post by Sieghard Schicktanz
Hallo Helmut,

Post by Helmut Waitzmann

Post by Stefan Ram
wenn ich einen Editor auf der Kommandozeile aufrufe, dann sollte
dieser zunächst tatsächlich das aktuelle Verzeichnis vorschlagen.

Genauer:  Er sollte überhaupt kein Verzeichnis vorschlagen:  Wenn
der Anwender dann einen Dateinamen, der keine „/“ enthält,
eintippt, landet die Datei im Arbeitsverzeichnis.

Was ist ein "Arbeitsverzeichnis"? Ich wüßte da keine gute Antwort darauf.

Wie kann man jahrelang so tun als ob man *nix mit der Muttermilch
eingeatmet hat aber nicht wissen ws ein Work dir ist?
Clown oder Troll, das ist hier die Frage. Die Antwort ist auf jeden
Fall ein plonkender Kellerboden

[Sieghard Schicktanz]

Hallo Jens,

Post by Jens Schuessler

Post by Sieghard Schicktanz
Was ist ein "Arbeitsverzeichnis"? Ich wüßte da keine gute Antwort darauf.

Wie kann man jahrelang so tun als ob man *nix mit der Muttermilch
eingeatmet hat aber nicht wissen ws ein Work dir ist?
Clown oder Troll, das ist hier die Frage. Die Antwort ist auf jeden
Fall ein plonkender Kellerboden

Ah! Endlich jemand, der sich richtig auskennt! Kannst Du das mal kurz
herschrieben? Danke im Voraus!

[Sieghard Schicktanz]

Hallo Marc,

Post by Marc Olschok

Post by Stefan Ram
Verzeichnis sollte der Editor vorschlagen? Ich denke, es
sollte "~" sein, das Heimatverzeichnis des Benutzers.

Nicht sehr angenehm, wenn ich in den Editor in einem Unterverzeichnis
gestartet habe, die neue Datei urplötzlich im ~ auftaucht und ich sie
nicht mehr dort vorfinde, wo ich sie brauche.

Tja. Das ist bei einem Textmode-Editor noch einigermaßen übersichtlich, der
wird ja "in" einem, vom Aufrufer bestimmten, definierten Verzeichnis
gestartet und kann das dann auch benutzen, wenn ihm kein anderes vorgegeben
wird. Ein - hier ja ebenfalls erwähnter - Gooey^WGUI-Editor _hat_ aber kein
definiertes Startverzeichnis, bzw. das Verzeichnis, das bei seinem Start
aktuell war, kann ein beliebiges sein. Der _muß_ eins anbieten, falls der
Benutzer keins angibt - oder das Speichern verweigern. Deswegen "merken"
sich solche Editoren ja auch meistens - naja, öfters, manchmal - auch das
letzte benutzte Verzeichnis und geben das beim nächstenmal als Anfangspunkt
wieder vor. Manchmal halt auch nicht, was dann "gerne" dazu führt, daß
"nicht so technik-affine" Benutzer reihenweise zum einen ihre Dateien nicht
mehr finden und zum anderen "irgendwelche komischen" Dateien in völlig
unpassenden Verzeichnissen rumliegen haben...

[Sieghard Schicktanz]

Hallo Diedrich,

Du schriebst am Wed, 04 Sep 2024 22:30:30 +0200:

[GUI-Editor]

Dazu müßte er aber "wissen", daß eraus einem Terminal gestartet wurde.
Das geht zwar im Prinzip, aber ob das irgendwo gemacht wird?

Nö- Dazu muss er eine Umgebungsvariable auswerten.

Schon, aber _tut_ er das auch? (Bzw. hat das der Programmierer eingebaut?)

der Aufruf meist "gui-editor directory/filename" oder so heißem.

Oder einfach "gui-editor filename" . Oder noch einfacher "gui-editor".
Den Dateinamen muß man sich doch erst zum Speichern ausdenken.

Ja, wenn man eine neue Datei erstellt. Bei mir ist der häufigere Fall,
dass ich eine bestehende Datei ändere.

Und da rufst Du den _GUI_-Editor auseinem Terminal auf? Geht natürlich,
aber können da auch _alle_ einen Parameter (Arbeitsdatei) auswerten?

[Arbeitsverzeichnis "im" Icon]

Ist bei jedenfalls bei xfce üblich.

Standardmäßig, oder für den Benutzer möglich?

...

Wer redet von festlegen? Es geht um Default-Werte - also wo eine Datei
landet, wenn der Name nicht mit / beginnt.

Äh, ja. "Default"-Wert heißt ja _voreingestellter_, also im Programm
festgelegter, Wert.

Man kann seinen Desktop in verschiedenartiger Weise organisieren ...

Sicher, das ist effektiv jedem selber überlassen, der den Aufwand dafür
treiben will (und kann). AFAIK kommen halt "heute" alle Gooe^WGUIs mit
(entgegen meiner falschen Meinung im letzten Posting) Voreinstellung für
"dokumentenzentriertes" Arbeiten, wie von Microsoft propagiert. Und dann
läuft das halt so wie in Deinem zweiten Szenario dargestellt.
...

wenn man sie dort aufruft. Und eben dort sollten neue Dokumente oder
Kopien dort auch im Defauklt abgelegt werdebn.

Und genau das kann dann deutliche Probleme machen, wenn es eben nicht mehr
möglich ist, zu unterscheiden, was von der Installation kommt und was dem
Benutzer gehört. Der überschreibt dann schon auch mal die "leere Datei" mit
einem wichtigen Dokument und wundert sich, wo das geblieben ist...

[Peter J. Holzer]

Post by Sieghard Schicktanz

Oder einfach "gui-editor filename" . Oder noch einfacher "gui-editor".
Den Dateinamen muß man sich doch erst zum Speichern ausdenken.

Ja, wenn man eine neue Datei erstellt. Bei mir ist der häufigere Fall,
dass ich eine bestehende Datei ändere.

Und da rufst Du den _GUI_-Editor auseinem Terminal auf? Geht natürlich,
aber können da auch _alle_ einen Parameter (Arbeitsdatei) auswerten?

Ich weiß nicht, ob das *alle* können, aber das Öffnen einer Datei aus
der graphischen Shell ist eine Standard-Operation. Dazu muss die
Applikation mit der gewünschten Datei als Parameter aufgerufen werden.
Also können das in erster Näherung fast alle.

Post by Sieghard Schicktanz
[Arbeitsverzeichnis "im" Icon]

Ist bei jedenfalls bei xfce üblich.

Standardmäßig, oder für den Benutzer möglich?

Was soll hier "standardmäßig" heißen? Welches Directory sollte hier
"standardmäßig" eingetragen werden?

hp

[Peter J. Holzer]

Entweder wird dieser GUI-Editor aus einem Terminal gestartet. Dann
würde ich erwarten, dass er Dateinamen relativ zu dem zum
Startzeitpunkt aktuellen $PWD interpretiert. Aus einem Terminal
heraus dürfte ohnehin

Dazu müßte er aber "wissen", daß eraus einem Terminal gestartet wurde.
Das geht zwar im Prinzip, aber ob das irgendwo gemacht wird?

Nö- Dazu muss er eine Umgebungsvariable auswerten.

Müssen nicht. Es gibt auch andere Kriterien. Die Existenz eines
nutzbaren Controlling Terminal würde ich beispielsweise für
zielführender erachten.

der Aufruf meist "gui-editor directory/filename" oder so heißem.

Oder einfach "gui-editor filename" . Oder noch einfacher "gui-editor".
Den Dateinamen muß man sich doch erst zum Speichern ausdenken.

Ja, wenn man eine neue Datei erstellt. Bei mir ist der häufigere Fall,
dass ich eine bestehende Datei ändere.

Dann ist es aber einfach, weil der User ja schon ein File angegeben hat.
Der Default sollte dann sein, genau dieses File zu überschreiben. Und
wenn der User das File unter anderem Namen speichern will, ist das
Directory des angegebenen Files wahrscheinlich kein schlechter
Startpunkt.

Man kann seinen Desktop in verschiedenartiger Weise organisieren - als
Sammlung von Funktionen (zB Textsystem, Spreadsheet, Browser,
Mailclient, Newsclient, Editor usw.). Dabei wäre aus meiner Sicht ein
sinnvolles Default-Arbeitsverzeichnis sinnvoll. Oder man kann es auch
dokumentmäßig organisieren, also die Dokumente, die man gerade
bearbeitet -. Briefe, Spreadsheets, Bilder, Videos, Programme,
wasauchimmer - , auf dem Desktop und außerdem je ein leeres Dokument
(neuer Brief, neues Spreadsheet, leerer Ordner) und die
Dokumente/Dateitypen mit einer "Methode", einem Programm, um sie zu
bearbeiten, assoziieren. Dann würden Programme, um solche Dokumente zu
bearbneiten, sinnvollerweise in ~/Desktop gestartet, wenn ein Dokumenrt
auf dem Desktop bearneitet wird, und in einem Ordner , einem Directory,
wenn man sie dort aufruft. Und eben dort sollten neue Dokumente oder
Kopien dort auch im Defauklt abgelegt werdebn.

Du vergisst eine dritte Möglichkeit, die IMHO wesentlich sinnvoller ist
als diese beiden: Nämlich, dass Dateien *thematisch* gruppiert werden.
Also z.B. alle Dateien für ein bestimmtes Projekt in einem Directory. Da
können dann schon mal ein Spreadsheet, ein Script und eine Graphik im
gleichen Directory landen, und es wäre völlig unsinnig, alle
Spreadsheets in einem Directory, alle Scripts in einem zweiten und alle
Graphiken in einem Dritten zu speichern. Von "alles in ~/Desktop" ganz
abgesehen.

hp

[Diedrich Ehlerding]

Post by Peter J. Holzer
Du vergisst eine dritte Möglichkeit, die IMHO wesentlich sinnvoller
ist als diese beiden: Nämlich, dass Dateien *thematisch* gruppiert
werden. Also z.B. alle Dateien für ein bestimmtes Projekt in einem
Directory

Ja klar - dann liegt auf dem Desktop ein Folder (also ein Directory),
und in dem die zusammenengehörenden Dokumente (oder weitere Folder), um
das weiter zu untergliedern. Das habe ich doch auch beschrieben, in den
letzten zwei Sätzen, die du zitiert hattest.

[Peter J. Holzer]

Post by Diedrich Ehlerding

Post by Peter J. Holzer
Du vergisst eine dritte Möglichkeit, die IMHO wesentlich sinnvoller
ist als diese beiden: Nämlich, dass Dateien *thematisch* gruppiert
werden. Also z.B. alle Dateien für ein bestimmtes Projekt in einem
Directory

Ja klar - dann liegt auf dem Desktop ein Folder (also ein Directory),
und in dem die zusammenengehörenden Dokumente (oder weitere Folder), um
das weiter zu untergliedern. Das habe ich doch auch beschrieben, in den
letzten zwei Sätzen, die du zitiert hattest.

Ich habe das als Teil des gleichen Szenarios gelesen, das mit

| Oder man kann es auch dokumentmäßig organisieren, also die Dokumente,
| die man gerade bearbeitet -. Briefe, Spreadsheets, Bilder, Videos,
| Programme, wasauchimmer - , auf dem Desktop und außerdem je ein
| leeres Dokument (neuer Brief, neues Spreadsheet, leerer Ordner) und
| die Dokumente/Dateitypen mit einer "Methode", einem Programm, um sie
| zu bearbeiten, assoziieren. Dann würden Programme [...]

anfängt.

Für mich ist "alle Dokumente, die man gerade bearbeitet, auf em Desktop"
aber eine total andere Arbeitsweise als "ich habe eine Ordnerstruktur
und arbeite jeweils in dem relevanten Ordner".

Ich war so fasziniert von der Vorstellung, dass jemand Dokumente auf den
Desktop verschiebt, um sie zu bearbeiten und nach getaner Arbeit den
"Schreibtisch" wieder aufräumt und alles in den "Aktenschrank"
verschiebt, dass ich die beiläufige Erwähnung des letzteren als Variante
des ersteren nicht wahrgenommen habe.

hp

[Diedrich Ehlerding]

Post by Peter J. Holzer
Ich war so fasziniert von der Vorstellung, dass jemand Dokumente auf
den Desktop verschiebt, um sie zu bearbeiten und nach getaner Arbeit
den "Schreibtisch" wieder aufräumt und alles in den "Aktenschrank"
verschiebt, dass ich die beiläufige Erwähnung des letzteren als
Variante des ersteren nicht wahrgenommen habe.

Mir gings nur um den UNterscghied "funktiopnsorientierte" vs.,
"objektorientierte" Desktopstrukktur. Also darum, ob man auf ein
Programm klickt (zB ein Spreadsheet-Programm) und dann eine
entsprechende Datei aufmacht, oder ob man eine Datei sucht und
findet(ggf. in einer Aktoenordner/Folder/drectoy-Struktur) und sie dann
mit einer geeigenten Methode bearbeitet (ggf. auch eine leere DDatei,
oder eine leere Datei pro Dokumentvorlage, von der man sich bei Bedarf
eine Kopie macht und dann die Kopie zur Bearbeitung ion enen
geeigneten Folder schiebt)

Letzterer Ansatz ist für eine Umgebung, in der Dokumente berbeitet und
weitelgeleitet werden, ggf. der interessantere. Da lähge dann
vielleicht auf dem Desktop auch ein "Eingangskorb", i8n dem automatisch
einlaufende Maile liegen, und ein Ausgangskorb, in den man seine
Dokumente legt, wobei man beim Hineinlegen den Adressaten eintragen
muss.

Nur - wie bildet man in so einem Modell sowas wie einen Newsreader ab?
Als Folder mit den interessierenden Newsgroups als Subfolder? Und gibt
es Newsreader, sie so ein Miodell unterstützen?

[Marc Olschok]

Post by Sieghard Schicktanz
Hallo Marc,

Post by Marc Olschok

Post by Stefan Ram
Verzeichnis sollte der Editor vorschlagen? Ich denke, es
sollte "~" sein, das Heimatverzeichnis des Benutzers.

Nicht sehr angenehm, wenn ich in den Editor in einem Unterverzeichnis
gestartet habe, die neue Datei urplötzlich im ~ auftaucht und ich sie
nicht mehr dort vorfinde, wo ich sie brauche.

Tja. Das ist bei einem Textmode-Editor noch einigermaßen übersichtlich, der
wird ja "in" einem, vom Aufrufer bestimmten, definierten Verzeichnis
gestartet und kann das dann auch benutzen, wenn ihm kein anderes vorgegeben
wird. Ein - hier ja ebenfalls erwähnter - Gooey^WGUI-Editor _hat_ aber kein
definiertes Startverzeichnis, bzw. das Verzeichnis, das bei seinem Start
aktuell war, kann ein beliebiges sein. Der _muß_ eins anbieten, falls der
Benutzer keins angibt - oder das Speichern verweigern.

Ja, ich hatte nicht daran gedacht, dass viele Leute graphische Editoren
auch aus dem Mausmenu oder per Desktop-Icon starten. Mache ich selber
nie, weil ich fast immer bereits existierende Dateien bearbeite und mir
dann die Sequenz "starten+öffnen" zu aufwendig ist.

Post by Sieghard Schicktanz
Deswegen "merken"
sich solche Editoren ja auch meistens - naja, öfters, manchmal - auch das
letzte benutzte Verzeichnis und geben das beim nächstenmal als Anfangspunkt
wieder vor. Manchmal halt auch nicht, was dann "gerne" dazu führt, daß
"nicht so technik-affine" Benutzer reihenweise zum einen ihre Dateien nicht
mehr finden und zum anderen "irgendwelche komischen" Dateien in völlig
unpassenden Verzeichnissen rumliegen haben...

In den meisten Fällen habe ich beim Speichern aus graphischen
Programmen immer so eine Dateianzeige präsentiert bekommen, über die
ich dann im Verzeichnisbaum navigieren konnte. Dann ist es schon egal,
was als erstes angeboten wird. Die Datei stillschweigend ohne diese
Information irgendwo zu speichern geht nur bei der Bearbeitung bereits
vorhandener Dateien und da weiß man ja vorher, wo sie liegen.

v.G.

[Dietrich Clauss]

Post by Sieghard Schicktanz
Hallo Marc,

Post by Marc Olschok

Post by Stefan Ram
Verzeichnis sollte der Editor vorschlagen? Ich denke, es
sollte "~" sein, das Heimatverzeichnis des Benutzers.

Nicht sehr angenehm, wenn ich in den Editor in einem Unterverzeichnis
gestartet habe, die neue Datei urplötzlich im ~ auftaucht und ich sie
nicht mehr dort vorfinde, wo ich sie brauche.

Tja. Das ist bei einem Textmode-Editor noch einigermaßen übersichtlich, der
wird ja "in" einem, vom Aufrufer bestimmten, definierten Verzeichnis
gestartet und kann das dann auch benutzen, wenn ihm kein anderes vorgegeben
wird. Ein - hier ja ebenfalls erwähnter - Gooey^WGUI-Editor _hat_ aber kein
definiertes Startverzeichnis,

Das eine hat mit dem anderen nichts zu tun. Man kann einen
Textmode-Editor aus einer Shell starten. Man kann auch einen GUI-Editor
aus der Shell starten. Und man kann beides auch aus einem Menü heraus
starten. Ein definiertes Startverzeichnis ist in jedem Fall vorhanden.

Post by Sieghard Schicktanz
bzw. das Verzeichnis, das bei seinem Start
aktuell war, kann ein beliebiges sein.

Nein. Es ist das, was der den Editor startende Prozeß ihm mitgegeben
hat. Ob das nun eine Shell war oder ein Windowmanager oder ein
Dateimanager, spielt wiederum keine Rolle.

Post by Sieghard Schicktanz
Der _muß_ eins anbieten, falls der
Benutzer keins angibt - oder das Speichern verweigern.

"keins" gibt es nicht. Jeder Prozeß hat ein "current working
directory", und das ist genau dafür da.

Post by Sieghard Schicktanz
Deswegen "merken"
sich solche Editoren ja auch meistens - naja, öfters, manchmal - auch das
letzte benutzte Verzeichnis und geben das beim nächstenmal als Anfangspunkt
wieder vor. Manchmal halt auch nicht, was dann "gerne" dazu führt, daß
"nicht so technik-affine" Benutzer reihenweise zum einen ihre Dateien nicht
mehr finden und zum anderen "irgendwelche komischen" Dateien in völlig
unpassenden Verzeichnissen rumliegen haben...

Andersherum wird ein Schuh daraus. Dieses "Merken" ist eine Unsitte,
das manche, zum Glück nur wenige Programme aus anderen (kaputten)
Systemen Übernommen haben. Davon wird es aber nicht besser. Ich gehe
in ein Projektverzeichnis, starte dort den Editor, speichere eine Datei,
und - auf einmal liegt die Datei in einem anderen Projekt, das ich
letztens.. irgendwann einmal vielleicht bearbeitet habe. Nein, so bitte
nicht. Der Editor soll das aktuelle Arbeitsverzeichnis verwenden, dafür
wurde das schließlich erfunden.

Gruß,
- Dietrich