[Allegro] import.exe hat ein problem mit (überlangen) pfaden: hier die %temp-variable

[Thomas Berger]

Hallo Herr Lehmann,

> ich arbeite sehr gerne mit der variable %temp% und %tmp% .
> man braucht sich keine gedanken zu machen, wo der temporäre müll 
> verbleibt.
> 
> hier der aufruf:
> c:\allegro\import -f5 -dc:\zdb\%year%%week%.mrc -imarc21 -ka -epa-zdb1/%temp%\%year%%week%titelgesamt.alg
> 
> 
> diesen ausdruck findet import.exe NICHT lustig. 
> er verschwindet, wenn die aufgelöste variable %temp (normal) lang ist:
> z.b. so:
> temp=C:\dokumente und einstellungen\admin\lokale 
> einstellungen\temp
> 
> 
> wenn ich das da oben eintrage, wird jeder erkennen, was das für ein 
> ungetüm an langem pafd ist:
> 
> 
> c:\allegro\import -f5 -dc:\zdb\%year%%week%.mrc -imarc21 -ka -epa-zdb1/C:\dokumente und einstellungen\admin\lokale 
> einstellungen\temp\%year%%week%titelgesamt.alg
> = bitte als EINE zeile lesen.

ich erkenne vor allem, dass da Leerzeichen im Pfadnamen sind und
der Export daher in die Datei c:\dokumente gehen soll (das ist
vermutlich noch unproblematisch, aber der Schmutz der dann auf
der Kommandozeile folgt macht moeglicherweise den groesseren Aerger).

Ich weiss allerdings nicht genau, was Sie da treiben: Auf meinen
noch uebrigen XP-Maschinen sind TEMP und TMP jeweils auf die
Variante "kurze Dateinamen" reduziert. Ich erinnere mich aber
vage, dass es vor Jahren tatsaechlich Aerger mit den Leerzeichen
in den Umgebungsvariablen gab (man musste also immer darauf
achten, "%TEMP%" in Anfuehrungszeichen zu setzen), evtl. hat
erst SP3 da Abhilfe geschaffen.

Oder kann es sein, dass Sie die Variablen irgendwie nachtraeglich
explizit setzen?


> die situation wird bei vista/windows7 und windows8 etwas entschärft: 
> aus "C:\dokumente und einstellungen" ist "c:\Users" geworden. und 
> "lokale einstellungen" wird zu "appdate\local" ... naja....

Dass Windows XP kein von Microsoft mehr unterstuetztes Betriebssystem
ist und allegro darauf nur noch rein zufaellig laeuft, hat sich aber
zu Ihnen durchgesprochen?


> für mich die einzige lösung derzeit: ich schaffe mit eine %temp%-variable, 
> die auf was SEHR kurzes zeigt. z.b. c:\tmp
> also set temp=c:\tmp

Den einzigen Hinweis auf ein lokales Verzeichnis, in das der aktuelle
Benutzer garantiert Schreibzugriff hat zu verwerfen, ist hoechst riskant.
Erfahrungsgemaess gibt es eine Vielzahl von Problemen, wenn sich mehrere
Benutzer ein TEMP-Verzeichnis teilen.

Ich bin meist damit klargekommen, vor solchen Operationen ins TEMP-
Verzeichnis zu wechseln ("ich" als .bat-Datei) und dann einfach ins
aktuelle Verzeichnis zu exportieren. Notfalls kann man sich das Ergebnis
nach dem Zurueckwechseln ins eigentliche Arbeitsverzeichnis ja herbei-
kopieren. Das hat natuerlich Grenzen, wenn die Ergebnisse in den
Groessenbereich hunderter von Megabytes wachsen muss man sich bei dem
Ansatz ploetzlich mehr Gedanken ueber die Dimensionierung der
jeweiligen Dateisysteme machen und was wo auf welchem Netzlaufwerk liegt,
als einem lieb sein kann.


> also: 
> ist es möglich, daß import.exe wieder(?) sehr lange befehlsaufrufe bekommt?
> das wäre schön.....

die 16bit-Programme krankten daran, dass im 16bit-Teilsystem die Kommandozeile
insgesamt nur 126 Zeichen lang sein durfte (war es laenger, starteten die
Programme gar nicht), d.h. jeder nicht maximal verkuerzte Pfadname war eine
Garantie fuer Probleme. Den Teil fuer die Ausgabedatei bei Schalter -e
ohne jeglichen Pfadnamen zu notieren (also ins aktuelle Verzeichnis exportieren
zu lassen) und am besten in eine Datei "x" zu exportieren, die anschliessend
erst umbenannt wurde, stellte die einfachste und naheliegenste Methode zum
Kurzhalten der Kommandozeile dar...

Den 32bit-Programmen kann man vorwerfen, dass sie nicht die betriebssystem-
eigenen Datenstrukturen fuer Pfade nutzen (und denen wiederum, dass es
gewisse Dateizugriffe gibt, die laengere Pfade erlauben als in diese passt),
m.W. sind aber allegroseitig durchgehend 128 Zeichen vorgesehen, das ist
meist ausreichend.

viele Gruesse
Thomas Berger