Pfadnamen - groß oder klein geschrieben?

[DonLucio]

Ich frage mich, ob ich einen Bug in meiner rexx.dll habe. Oder ist das Folgende normal?

Ich habe ein Verzeichnis auf e: namens 'DATA' mit Unterverzeichnis 'staroffice'. Folglich sehe ich im WPS-Dateiobject, drive e:, diesen Eintrag:
DATA\staroffice

In einer Kommandozeile gebe ich ein:

Code: Alles auswählen

c:>e:
E:>cd data
E:\data>cd StarOffice
E:\data\StarOffice

Dort habe ich ein Rexx-Script namens 'test.cmd' mit diesem Befehl:
say "Aktuelles Verzeichnis:" directory();

Ich starte test.cmd und erhalte:

Code: Alles auswählen

Aktuelles Verzeichnis:" E:\data\StarOffice

Ich kann den Test beliebig wiederholen, z.B. mit
E:>cd DaTa\StaroffICE

und erhalte von der directory()-Funktion entsprechend

Code: Alles auswählen

Aktuelles Verzeichnis:" E:\DaTa\StaroffICE

Also kurz gesagt: Die directory()-Funktion liefert immer das, was der User der Kommandozeile gerade zuvor eingetippt hat.
Ich halte das für einen Fehler, denn der tatsächliche Name lautet DATA\staroffice.

Aber vielleicht liegt der Fehler auch in der Shell? Dort sollte eigentlich schon als Antwort auf meinen 'cd <directory>'-Befehl der korrekte Name zurückgegeben werden:

Code: Alles auswählen

E:>cd data\Staroffice
E:>DATA\staroffice

So ist es aber nicht!
Oder sehe ich irgendwas falsch?

Lutz W.

[ThomasFrey]

Hallo Lutz

Bei REXX musst Du am Beginn immer eine REM-Zeile schreiben:

/* Test */
say "Aktuelles Verzeichnis:" directory();

So sollte es funktionieren.

[LotharS]

Also kurz gesagt: Die directory()-Funktion liefert immer das, was der User der Kommandozeile gerade zuvor eingetippt hat.
Ich halte das für einen Fehler, denn der tatsächliche Name lautet DATA\staroffice.

Aber vielleicht liegt der Fehler auch in der Shell? Dort sollte eigentlich schon als Antwort auf meinen 'cd <directory>'-Befehl der korrekte Name zurückgegeben werden:

Selbst wenn etwa mit dem dir-Kommando die "echten" Namen angezeigt werden (oder auch mittels Rexx-SysFileTree()), scheint Rexx-directory() bloß zeitsparend zu übernehmen was gerade per cd als "aktuell" definiert wurde. Solange OS/2 Datei- und Verzeichnisnamen generell case-insensitiv behandelt, sollte die Schreibweise praktisch egal sein, ganz nach Vorliebe. Ebenso auf Win oder Dos. Auf *nix-Systemen muss man dagegen genau unterscheiden.

[aschn]

(Ich hab jetzt erst die Überschrift gelesen, also nochmal:)

Code: Alles auswählen

E:>cd DaTa\StaroffICE

und erhalte von der directory()-Funktion entsprechend

Code: Alles auswählen

Aktuelles Verzeichnis:" E:\DaTa\StaroffICE

Also kurz gesagt: Die directory()-Funktion liefert immer das, was der User der Kommandozeile gerade zuvor eingetippt hat.

Ich halte das für einen Fehler, denn der tatsächliche Name lautet DATA\staroffice.

Ja, das hat mich schon mehrmals genervt. Mit REXX erhälst Du den richtigen und vollständigen Pfad mit SysFileTree, leider nur für das jeweils letzte Segment. Also in einer Schleife aufrufen:

Code: Alles auswählen

/* ----------------------------------------------------------------------- */
/* Gets the real case of a file system object. Returns the input if it     */
/* doesn't exist.                                                          */
/* DosFind* for a filename or dirname returns the correct case, but only   */
/* for the last segment. To get the correct case for the entire string, it */
/* must be processed segment-wise.                                         */
GetRealCase:

DO 1
   PARSE ARG FileMask

   fFile = 0
   fDir  = 0
   rc = 0

   /* Process only full file specs */
   IF SUBSTR( FileMask, 2, 1) <> ':' THEN
      LEAVE

   /* Check if dir or file to call the correct proc for the last segment */
   SELECT
      WHEN FileExist( FileMask) THEN
         fFile = 1
      WHEN DirExist( FileMask) THEN
         fDir  = 1
      /* Handle drive only */
      WHEN RIGHT( FileMask, 1) = ':' THEN
      DO
         FileMask = TRANSLATE( FileMask)
         LEAVE
      END
   OTHERWISE
      /* Process only existing file specs */
      LEAVE
   END

   Rest = FileMask
   NewFileMask = ''
   DO WHILE Rest <> ''
      PARSE VALUE Rest WITH Next'\'Rest
      IF Next = '' THEN
         ITERATE

      /* Drive */
      IF RIGHT( next, 1) = ':' THEN
      DO
         NewFileMask = NewFileMask''TRANSLATE( Next)
         /* For root dir: append '\' here, because no more segemnt exists */
         IF RIGHT( FileMask, 2) = ':\' THEN
            NewFileMask = NewFileMask'\'
         ITERATE
      END

      IF Rest = '' THEN
      DO
         /* Last segment */
         SELECT
            WHEN fFile THEN
            DO
               NewFileMask = NewFileMask'\'Next
               Found. = ''
               Found.0 = 0
               rcx = SysFileTree( NewFileMask, 'Found.', 'FO')
               IF Found.0 > 0 THEN
                  NewFileMask = Found.1
            END
            WHEN fDir THEN
            DO
               NewFileMask = NewFileMask'\'Next
               Found. = ''
               Found.0 = 0
               rcx = SysFileTree( NewFileMask, 'Found.', 'DO')
               IF Found.0 > 0 THEN
                  NewFileMask = Found.1
            END
         END
      END
      ELSE
      DO
         /* Other segments */
         NewFileMask = NewFileMask'\'Next
         Found. = ''
         Found.0 = 0
         rcx = SysFileTree( NewFileMask, 'Found.', 'DO')
         IF Found.0 > 0 THEN
            NewFileMask = Found.1
      END

   END  /* DO WHILE Rest <> '' */

   SAY 'FileMask = 'FileMask', NewFileMask = 'NewFileMask
   FileMask = NewFileMask

END

RETURN FileMask

/* ----------------------------------------------------------------------- */
FileExist: PROCEDURE EXPOSE (GlobalVars)
   rc = 0

   PARSE ARG Filename

   IF FileName = '' THEN
      RETURN( 0)
   ELSE
      RETURN( STREAM( Filename, 'C', 'QUERY EXISTS') <> '')

/* ------------------------------------------------------------------------- */
DirExist: PROCEDURE EXPOSE (GlobalVars)
   rc = 0

   PARSE ARG Dirname

   Found.0 = 0
   rcx = SysFileTree( Dirname, 'Found.', 'DO')

   RETURN( Found.0 > 0)

(Außer GlobalVars sollte eigentlich alles dabeisein. Falls noch was fehlt, bitte melden.)

Ich verwende das zum Packen mit echtem Case und um den XWP-Kontextmenüpfad, der immer als vollständig großgeschrieben für Kontextmenüobjekte, also auch für Befehlszeilen, ausgegeben wird, zu korrigieren. Die von Linux portierten Werkzeuge verlangen nämlich zum Teil die tatsächliche Groß- und Kleinschreibung, z.B. SVN. Alleine mit XWP aus dem Kontextmenü heraus funktioniert also SVN nicht für einen Pfad, der dann vollständig in Großschrift umgewandelt wurde.

[DonLucio]

Mit REXX erhälst Du den richtigen und vollständigen Pfad mit SysFileTree,

Etwas umständlich, aber immerhin: Der Tip ist gut.

Danke,
Lutz W.

[aschn]

Ich häng die eine Datei noch mal an. Die Variante, die den XWP-Kontextmenüpfad korrigiert, ist in E (also für EPM, REXX-ähnlich) implementiert und hat zuerst existiert.

[DonLucio]

Ich häng die eine Datei noch mal an.

Danke.

Ich dachte zuerst, den Pfad mit SysFileTree() zu ermitteln (deine Idee) ließe sich mit einem Zweizeiler lösen. Bis ich dann dieselbe Erfahrung machen durfte, die du auch schon beschrieben hast:
"... returns the correct case, but only for the last segment."
Wie bescheuert ist das denn!

Tja, man muß wohl tatsächlich einen aufwendigen Code schreiben, so wie du es dargestellt hast.
Zum Glück gibt es nur wenige Situationen wo man die komplette *korrekte* Case-Schreibweise benötigt. Bei mir war es nach über zwanzig Jahren OS/2-Praxis das erste Mal

Gruß,
Lutz W.

[erdmann]

Das, was du da versuchst, ist streng genommen unter DOS, Windows und OS/2 nicht definiert.

Du kannst dich nicht darauf verlassen, dass ein Dateisystem für diese Plattformen die Gross- und Kleinschreibung beibehält. Dem Dateisystem wäre sogar erlaubt, alle Dateinamen in Kleinbuchstaben umzusetzen.

Es wäre also ok, wenn JFS für OS/2 alle Dateinamen in Kleinschreibung umsetzt, das JFS für Linux hingegen darf das nicht.

Und aus diesem Grund ergibt es eben keinen Sinn, dass Applikationen oder Systemkomponenten die Gross/Kleinschreibung bei Pfadnamen/Dateinamen in irgendeiner Weise berücksichtigen. Da kann man "SysFileTree" halt keinen Vorwurf machen.

[LotharS]

Es wäre also ok, wenn JFS für OS/2 alle Dateinamen in Kleinschreibung umsetzt

Das verhüte die Community!
Dann wäre z.B. ein Filetransfer von Linux in Richtung DOS-Win-OS/2 unbrauchbar, wo "Datei" und datei" völlig zweierlei wären.

Und aus diesem Grund ergibt es eben keinen Sinn, dass Applikationen oder Systemkomponenten die Gross/Kleinschreibung bei Pfadnamen/Dateinamen in irgendeiner Weise berücksichtigen

Für _interne_ Weiterbearbeitung in OS/2-Applikationen sehe ich das genauso. Mir fallen bislang drei äußerliche Szenarien ein:
(i) ein "Dritter" z.B. Webserver erwartet per Konvention nur kleingeschriebenen upload. Dann erzeuge ich halt eine "kleine.zip" und/oder benenne einzeln um (innerhalb der zip egal oder je nachdem), notfalls als Kopie.
(ii) der User-an-sich erwartet in einer _externen_ Listen-Darstellung eigentlich "datei1" und "Datei2" irgendwie freundlich beieinander einsortiert. Geht auch mit Rexx, allerdings mit extra zu bastelnder Sortier-Routine mehr oder weniger performant. Je nachdem wie weit so wichtig/häufig.
(iii) Das Verhalten von directory() und SysFileTree() halte ich nicht für einen "Fehler": Aktuelles Verzeichnis bzw. Startmaske wird halt flott(!) genauso übernommen wie vom Programmierer (un)bewusst so eingetippt, für intern reicht's ja. Soll allerdings der _User_ unbedingt den echten vollen Pfad sehen, so gehe ich halt selber tricky zwischendurch hoch zum Laufwerksbuchstaben (GROSS:\ ) und von dort wieder runter. Habe ähnliches (und die o.a. Sortiererei) selbst mühsam in meiner App üben dürfen.

@Lutz:
Sicher hattest Du einen konkreten Anlass unzufrieden zu sein. Doch wie immer mit OS/2: Gibt keine Probleme, sondern nur Herausforderungen
REXX.DLL ändert eh' niemand mehr.

[DonLucio]

Du kannst dich nicht darauf verlassen, dass ein Dateisystem für diese Plattformen die Gross- und Kleinschreibung beibehält. Dem Dateisystem wäre sogar erlaubt, alle Dateinamen in Kleinbuchstaben umzusetzen.

Es wäre also ok, wenn JFS für OS/2 alle Dateinamen in Kleinschreibung umsetzt, das JFS für Linux hingegen darf das nicht.

Das fände ich keinesfalls ok. Nirgendwo in den OS/2-Systemspezifikationen ist das festgelegt. Afaik lautet die Systemspezifikation so: GroßKleinSchreibung ist "egal", in dem Sinne, dass eine Datei "xyz.txt" auch gefunden wird, wenn sie mit "XYz.Txt" angesprochen wird. Von eigenmächtigem Glattbügeln steht da nichts. Gottseidank!

Und aus diesem Grund ergibt es eben keinen Sinn, dass Applikationen oder Systemkomponenten die Gross/Kleinschreibung bei Pfadnamen/Dateinamen in irgendeiner Weise berücksichtigen. Da kann man "SysFileTree" halt keinen Vorwurf machen.

Hmm ... das sehe ich komplett anders.
Von Systemfunktionen erwarte ich, dass sie sich an die Wirklichkeit halten und nicht - mit welcher Motivation auch immer - mir Unwahrheiten präsentieren. Denn ja: Es gibt eine objektive Wirklichkeit, und das ist die Speicherung im Dateisystem.

Die Art der GroßKleinschreibung hat ja der User bewußt gewählt, zumindest räumt das OS ihm diese Freiheit ein. Und in meinem Fall: Ich habe mein Verzeichnis bewußt "DATA" genannt und das Unterverzeichnis "StarOffice". Und in den meisten Fällen respektiert das OS/2 auch diese Tatsache. Z.B. auf der Kommandozeile der DIR-Befehl: Zeigt mir sauber die Wirklichkeit an.

Dass die directory()-Funktion mir das nicht anzeigt, muß man andererseits nicht unbedingt als Fehler einstufen. Die Funktion zeigt an, wie der User zuvor ein gegebenes Verzeichnis benannt hat: Wenn ich mich mit "c:>cd Data" in das Verzeichnis einlogge, wird mir ein Rexx-Skript mit der directory-Funktion "Data" anzeigen. Das ist korrekt, weil die Semantik von directory() sich immer auf das aktuelle Dir bezieht.

Bei SysFileTree() sehe ich das anders. Ich erwarte von dieser Funktion die Anzeige der *tatsächlichen* Wirklichkeit, so, wie sie im Dateisystem gespeichert ist. Und dort ist nun mal "DATA" gespeichert und nicht "Data" oder "data".

Aber ich sehe ein, dass diese Argumentaion müßig ist, denn wie LotharS schon treffend bemerkt hat: "REXX.DLL ändert eh' niemand mehr." Und das gilt genauso für RexxUtil.dll

Schade eigentlich

Gruß,
Lutz W.

[aschn]

Ich glaube man muss unterscheiden zwischen dem, wie ein Dateisystemobjekt gespeichert wird (Groß-/Kleinschrift) und was bei einer Suche gefunden wird.

Bei dem Namen, der in bestimmter Form für ein Dateisystem angelegt wird, wird dies ja eindeutig, mit Ausnahme von FAT16 und darunter, unterschieden. (Mit OS/2 gibt es dort aber das .LONGNAME EA. Nur weil diese EAs nur von einigen Datei- und Betriebssystemen unterstützt werden, kann man sie dort nicht so verwenden als wären sie auf Nicht-FAT16-Dateisystemen abgelegt.)

Es fehlt anscheinend nur eine Funktion, die den Namen des Dateisystemobjekts so ausgibt, wie er auch abgelegt wurde. Dass SysFileTree wenigstens das letzte Segment wie im Original anzeigt, ist wohl ein Gücksfall. (Wird natürlich direkt von den C-Suchfunktionen kommen.) SysFileTree ist ein Programm zum Suchen.

[DonLucio]

Es fehlt anscheinend nur eine Funktion, die den Namen des Dateisystemobjekts so ausgibt, wie er auch abgelegt wurde.

So sieht's wohl aus.

SysFileTree() könnte aber so ein Programm (Funktion) sein.

Oder ein zusätzlicher Parameter in directory(). Man wird ja noch mal träumen dürfen...

Aber ok, es ist, wie es ist ...

[aschn]

SysFileTree() könnte aber so ein Programm (Funktion) sein.

Nein, das nutzt nur u.a. die DosFind*-Funktionen. Entweder Finden und Dateisystymeigenschaften anzeigen oder eine ganz andere Funktion. (Ich halte SysFiletree schon für viel zu voll gestopft.)

Oder ein zusätzlicher Parameter in directory().

Die REXX-Funktionen bilden nur teilweise das ab, was auch vom System bereitgestellt wird. Diese Funktion fehlt natürlich auch dort. Zunächst müsste das dort mal verfügbar sein.

[erdmann]

Um es noch mal anders zu sagen:

ein OS/2 Dateisystemtreiber (IFS) beinhaltet eine Funktion "FS_PROCESSNAME", die jedesmal vom Kernel aufgerufen wird, BEVOR andere Funktionen aufgerufen werden, die Dateinamen übergeben bekommen. Diese Funktion bekommt den Dateinamen übergeben, damit man ihn eben abändern kann. In dieser Funktion kann der IFS dann durchaus alle Großbuchstaben in Kleinbuchstaben umsetzen, solange der erzeugte Pfad/Dateiname den OS/2 Konventionen entspricht (keine Sonderzeichen, kein '/' und '\' weil die als Pfadtrenner dienen etc.). Und ja, es ist in der OS/2 Systemspezifikation für IFS festgelegt, das Pfad- und Dateinamen "case insensitive" sind.
Dieses Feature wird nur von den wenigsten IFS benutzt, aber womöglich gibt es Dateisysteme die, aus welchen Gründen auch immer, deutsche Umlaute nicht verarbeiten/benutzen können. Da würde FS_PROCESSNAME also z.B. ein "ä" durch ein "ae" ersetzen.

OS/2 folgt da DOS, so ist es nun mal. Damit muss man rechnen, ob es einem nun gefällt oder nicht.

Wenn ein Webserver nun Dateinamen nur in Großbuchstaben erwartet, muss halt die Applikation den vom Dateisystem übergebenen Namen in Großbuchstaben umsetzen. Beim tatsächlichen Zugriff auf das Dateisystem spielt das dann ja keine Rolle, das ist ja "case insensitive".

[DonLucio]

Es fehlt anscheinend nur eine Funktion, die den Namen des Dateisystemobjekts so ausgibt, wie er auch abgelegt wurde. Dass SysFileTree wenigstens das letzte Segment wie im Original anzeigt, ist wohl ein Gücksfall.

Ich glaube, hier hat sich eine Menge Verwirrung eingeschlichen. SysFileTree() *ist* genau diese Funktion.

Ich hatte zuvor der Aussage "nur das letzte Segment" werde korrekt ausgegeben, zugestimmt. Das trifft aber nicht zu, wie neuere Forschungen ergeben haben:

Code: Alles auswählen

Call SysFileTree "E:\","dirs.","DSO");
do i = 1 to dirs.0
   say dirs.i;
end;

zeigt alle Verzeichnisse auf Laufwerk E: in korrekter Groß-/Kleinschreibung
z.B.:

Code: Alles auswählen

E:\DATA
E:\DATA\StarOffice
E:\DATA\StarOffice\Archiv
E:\DATA\StarOffice\Geschäftlich
E:\DATA\StarOffice\Privat

Wenn ich allerdings so codiere:

Code: Alles auswählen

Call SysFileTree "E:\data","dirs.","DSO");

dann kommt auch nur "E:\data ... " heraus. Nach der guten alten Weisheit: "garbage in - garbage out"

Also, ich betrachte das Problem nun als gelöst.

Gruß,
Lutz W.

[LotharS]

Wenn ich allerdings so codiere:

Code: Alles auswählen

Call SysFileTree "E:\data","dirs.","DSO");

dann kommt auch nur "E:\data ... " heraus. Nach der guten alten Weisheit: "garbage in - garbage out"

Nach Spaziergang in den Orbit ...

Code: Alles auswählen

/* REXX        */
/* casedir.cmd */
call RxFuncAdd 'SysLoadFuncs', RexxUtil, 'SysLoadFuncs'
call SysLoadFuncs

curdir0 = directory()
drive0  = translate(left(curdir0,3))

attr   = '*+***'       /* ADHRS */
drop subtree
rc = SysFileTree(drive0,'subtree','DSO',attr)
if subtree.0 < 1 then nop   /* das ist auch korrekt! */
say 'Hier Verzeichnisse unter' drive0 '=' subtree.0

curdir1 = drive0
curdirx = translate(curdir0) 
treffer = 0
j = 1
do while (j < subtree.0 & treffer = 0)
   if (translate(subtree.j) = curdirx ) then do
	curdir1 = subtree.j
	treffer = 1
	end
   else j = j + 1
   end
say 'Arbeitsverzeichnis getippt =' curdir0
say 'Arbeitsverzeichnis echt    =' curdir1
return

.. könnten Landungen so ausgehen:

Code: Alles auswählen

[C:\os2\dll]casedir
Hier Verzeichnisse unter C:\ = 4283
Arbeitsverzeichnis getippt = C:\os2\dll
Arbeitsverzeichnis echt    = C:\OS2\DLL

[G:\projekte\QT4]casedir
Hier Verzeichnisse unter G:\ = 107
Arbeitsverzeichnis getippt = G:\projekte\QT4
Arbeitsverzeichnis echt    = G:\Projekte\qt4

[DonLucio]

Nach Spaziergang in den Orbit ...

Und was beweist das?

Doch nur, dass directory() bestechlich ist, was SysFileTree() nicht ist.

[LotharS]

Und was beweist das?
Doch nur, dass directory() bestechlich ist, was SysFileTree() nicht ist.

Irrtum: SysFileTree() mit Start "c:\os2\dll" oder nur "c:\" lieferte Baum mit "oberem Pfadsegment" wie eingetippt klein, nur "unten" case-echt.
In Praxis wäre mir das aber egal, weil ich mich eh' für irgendwas aus dem "unteren Baum" interessieren würde, sonst hätte ich's halt anders vorgegeben. Warum auch sollte Rexx unnötig Performance mit "meinem" o.a. Umweg verlieren.
Und mit "directory(<neudir>)" mal das Verzeichnis wechseln, um auf Daten _darunter_ eleganter zugreifen zu können, hab' ich schon öfters begangen

Nachtrag: am besten noch im Script als vorletztes einfügen ...

Code: Alles auswählen

call directory '\'
call directory curdir1

... und die "Bestechung" erscheint perfekt auch im Prompt. Was immer das helfen mag...

[aschn]

In meinem Fall wird tatsächlich nur das letzte Segment richtig ausgegeben. Oben der vollstndige Pfadname, wie er auch gesichert ist, im Beispiel darunter in Großschrift umgewandelt:

Code: Alles auswählen

epm: {0}[C:\] G:\dev\REXX\TestSysFileTreeCase.cmd F:\Apps\NEPMD\myepm\macros\stdctrl.e
In : F:\Apps\NEPMD\myepm\macros\stdctrl.e
Out: F:\Apps\NEPMD\myepm\macros\stdctrl.e

epm: {0}[C:\] G:\dev\REXX\TestSysFileTreeCase.cmd F:\APPS\NEPMD\MYEPM\MACROS\STDCTRL.E
In : F:\APPS\NEPMD\MYEPM\MACROS\STDCTRL.E
Out: F:\APPS\NEPMD\MYEPM\MACROS\stdctrl.e

epm: {0}[C:\]