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

[Bernhard Eversberg]

Am 05.07.2012 13:27, schrieb 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
>
> _______________________________________________
> Allegro mailing list
> Allegro at biblio.tu-bs.de
> http://sun250.biblio.etc.tu-bs.de/mailman/listinfo/allegro