[Allegro] dir-Befehl bei Win'7 ?

[Bernhard Eversberg]

Thomas Berger schrieb:
> 
> Ihr *I*DE muesste doch eine *i*ntegrierte Dokumentation haben (oder
> beziehen Sie die Compiler inzwischen von ALA Publishing ;-)
> 
Eine Doku zu shell-Befehlen gibt es da so wenig wie bei ALA.

Man muß natürlich als Entwickler ein Bedenkenträger von schwerem
Kaliber sein.
Diese Ihre Bedenken hatten wir deshalb alle schon bedacht:
> 
> 
> Solche Sachen (absetzen von Kommandos in eigenen Shells) sind
> 
Dieses Mittel setzen wir ja nur sparsam und bedachtvoll ein.
(Für Sie nicht sparsam genug, schon klar)

> - - wegen der Sprachabhaengigkeit wie erwaehnt fragil,
Die ist in diesem Fall gering, und es sind uns noch keine Probleme
damit zu Ohren gekommen.

> 
> - - ggfls. auch instabil (System unter Last, Kommando hat Timeout)
> 
solches wurde beim Befehl "dir" noch nie beobachtet, wenn er denn
überhaupt geht - und nur das wollte ich wissen.

> - - schlecht kontrollierbar (kein vernuenftiger Exit-Status weil
>   Lfw. nicht erreichbar oder Pfad nicht existiert)
> 
Solche Fälle treten in der betr. Sache nicht auf.

> - - nicht portierbar (u.U. schon bei der naechsten Windows-Version,
>   daher Ihre Nachfrage), vgl. auch acon, wo beim flex/job-internal
>   "dir" auch U**X als Plattform zu beachten ist
> 
Ja, deshalb die Frage, und sie ist erledigt. Da sagt nichts über
andere Shell-Befehle, aber sobald sich Probleme zeigen, gehen wir
sie an. U**X ist nicht betroffen in diesem Fall.

> - - ein Krampf (Verzeichnisnamen mit Leerzeichen/Umlauten muessen erst
>   einmal fuer die Shell aufbereitet werden, die Resultate zurueck-
>   codiert)
> 
Solche Namen klappen, sowohl für Ordner wie für Dateien.

> - - Jeder Aufruf eines Kommandointerpreters ist ein potentielles
>   Sicherheitsrisiko, d.h. zusaetzlich zum vorigen Punkt *muessen*
>   Sie vorab umfaengliche Kontrollen auf Zeichen vornehmen, die
>   fuer die Shell eine Bedeutung haben koennten
Hier werden nur Zeichen auftreten, die sich aus den existierenden
Datei- und Verzeichnisnamen ergeben, daher besteht keine solche
Gefahr und ist kein umfängliches Kontroll-Overhead erforderlich.

> 
> das ist das, was mir auf die Schnelle dazu einfaellt.
> 
Na gut, wir haben weiterhin ein offenes Ohr.

B.Eversberg