[Allegro] Schmerzloser Umstieg vom alten update auf update.job

[Sibylle Koczian]

Lieber Herr Eversberg, liebe Liste,

Am 05.07.2012 12:36, schrieb Bernhard Eversberg:
> Am 05.07.2012 11:33, schrieb Fischer, Thomas:
>>
>> 1. Das neue Update braucht einen Parameter -k, in dem der
>> Konfigurationsbuchstabe angegeben wird. (Ich weiß nicht, warum update
>> den raten konnte und acon nicht.)
>>
> Fehlendes -kX hat Default -ka zur Folge. Das macht nicht upd.exe
> oder update.job, sondern acon. Oder kriegen Sie eine Fehlermeldung,
> wenn Sie -k weglassen, und wenn ja, wie lautet sie?
>
Ich glaube, wesentlich ist hier die Änderung vom alten zum neuen Update: 
hat Update.exe die Konfiguration ggf. der Umgebungsvariablen entnommen 
und tut acon bzw. update.job eben dies nicht mehr? Denn mit einem ganz 
und gar fehlenden -k hätte doch auch das alte Update die A-Konfiguration 
zugrundegelegt, oder etwa nicht?

>
>> 3. Die Auswertung den Datenquellenparameter ist wahrscheinlich schon
>> immer problematisch gewesen, vielleicht kann hier ja ein wenig
>> (sanft) aufgeräumt werden. Ich finde durchgängig die "Erklärung am
>> Beispiel" nicht so hilfreich wie eine etwas formalere Beschreibung.
> Ihr Hang zur Abstraktion wird nicht allgemein geteilt. Von mir auch nicht.
>
Da möchte ich mich Herrn Fischer anschließen: zwar können formale 
Beschreibungen ohne Beispiele schwer oder gar nicht verständlich sein, 
bei Beispielen ohne abstrakte Erklärung wird aber meistens das 
Verallgemeinern schwierig und fehlerträchtig. Eine munter sprudelnde 
Quelle für falsche Analogiebildungen.

Im konkreten Fall der Erklärungen für -d und -e im Systemhandbuch fehlt 
mir allerdings höchstens der Hinweis, dass Verzeichnisnamen immer auch 
absolute Verzeichnisse sein können (und dann, wenn ich nicht irre, unter 
Windows zwingend auch die Laufwerksangabe brauchen).

>> Ich rufe die ganzen Programme über eine Batchdatei auf:
>>
>> C:\Windows\System32\cmd.exe
>  > C:\Windows\System32>M:
>  > M:\>cd LIST
>> M:\LIST>PRD
>>
>> Die ruft dann eine weitere Batchdatei auf und los geht's. Wieso dann
>> wieder etwas in C:\Windows\System32 landet ist, mir schleierhaft,
> Nun, vermutlich weil der ganze Prozeß dort seinen Anfang nahm.
>

Frage: was ist "der ganze Prozeß"? Vor dem Aufruf von PRD wurden 
aktuelles Laufwerk und aktuelles Verzeichnis explizit gewechselt. Also 
muss doch PRD in M:\LIST ausgeführt oder jedenfalls gestartet werden und 
nicht woanders. Ich kann mir höchstens vorstellen, dass innerhalb von 
PRD bzw. in der zweiten aufgerufenen Batchdatei etwas schief läuft.

Beste Grüße,
Koczian