Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Hamster Action vergisst gelegentlich den Übergabeparameter
7 views
Skip to first unread message
Ulrich F. Heidenreich
Dec 16, 2011, 7:19:17 AM12/16/11
to
Hallo!
Hoffentlich bin ich hier von wegen weil .hsc und so richtig.
Ich hätte da gerne mal folgendes Problem:
Des Hamsters Mail-In-Action
mail.in.exec=E:\hamster\mail-in.bat
mail.in.pars="%1"
verweist auf genannte Batchdatei unter Anderem des Inhalts:
find "eg...@egal.example" %1|find "To:"
Ab und an scheint der Hamster die Übergabe des %1 zu verschludern,
mit dem "Erfolg", daß der erste Find nicht in der Maildatei sondern
in StdIn sucht. Damit habe ich dann je nach Mailaufkommen etliche
DOS-Fenster offen, die alle per CTRL-Z geschlossen werden wollen #-(
Erst ein kompletter Neustart des Hamsters behebt dieses Problem.
Wo sollte ich IYO nach dem Übeltöter suchen?
CU!
Ulrich
Hoffentlich bin ich hier von wegen weil .hsc und so richtig.
Ich hätte da gerne mal folgendes Problem:
Des Hamsters Mail-In-Action
mail.in.exec=E:\hamster\mail-in.bat
mail.in.pars="%1"
verweist auf genannte Batchdatei unter Anderem des Inhalts:
find "eg...@egal.example" %1|find "To:"
Ab und an scheint der Hamster die Übergabe des %1 zu verschludern,
mit dem "Erfolg", daß der erste Find nicht in der Maildatei sondern
in StdIn sucht. Damit habe ich dann je nach Mailaufkommen etliche
DOS-Fenster offen, die alle per CTRL-Z geschlossen werden wollen #-(
Erst ein kompletter Neustart des Hamsters behebt dieses Problem.
Wo sollte ich IYO nach dem Übeltöter suchen?
CU!
Ulrich
Alfred Peters
Dec 16, 2011, 1:44:34 PM12/16/11
to
Es schrieb einmal Ulrich F. Heidenreich:
'echo Parameter %1' oder so)? Oder ist das nur eine Vermutung?
> mit dem "Erfolg", daß der erste Find nicht in der Maildatei sondern
> in StdIn sucht. Damit habe ich dann je nach Mailaufkommen etliche
> DOS-Fenster offen, die alle per CTRL-Z geschlossen werden wollen #-(
> Erst ein kompletter Neustart des Hamsters behebt dieses Problem.
Verstehe ich das richtig: Wenn es auftritt, tritt es danach immer auf?
Bleibt die Frage, wie häufig passiert das denn?
> Wo sollte ich IYO nach dem Übeltöter suchen?
Dass das am Hamster liegt, will ich erstmal nicht glauben. O:-)
Mit KorrNews läuft das schließlich seit Jahren problemlos.
Ist der Haken bei "Auf das Ende des Programms warten" gesetzt?
Kann es sein, dass etwas anderes vorher die Parameter zerschießt (z.Bsp.:
'shift')?
Warum das dann Permanent passieren sollte, kann ich nicht sagen. Dazu
müsste ich die ganze BAT sehen.
Ich lasse hier mal eine Log-Bat mitlaufen. Vielleicht kann ich es ja
reproduzieren.
Alfred
--
11955.7
> Hallo!
>
> Hoffentlich bin ich hier von wegen weil .hsc und so richtig.
> Ich hätte da gerne mal folgendes Problem:
>
> Des Hamsters Mail-In-Action
>
> mail.in.exec=E:\hamster\mail-in.bat
> mail.in.pars="%1"
>
> verweist auf genannte Batchdatei unter Anderem des Inhalts:
>
> find "eg...@egal.example" %1|find "To:"
>
>
> Ab und an scheint der Hamster die Übergabe des %1 zu verschludern,
Ist es ersichtlich, dass der Parameter leer ist (z.Bsp.:
>
> Hoffentlich bin ich hier von wegen weil .hsc und so richtig.
> Ich hätte da gerne mal folgendes Problem:
>
> Des Hamsters Mail-In-Action
>
> mail.in.exec=E:\hamster\mail-in.bat
> mail.in.pars="%1"
>
> verweist auf genannte Batchdatei unter Anderem des Inhalts:
>
> find "eg...@egal.example" %1|find "To:"
>
>
> Ab und an scheint der Hamster die Übergabe des %1 zu verschludern,
'echo Parameter %1' oder so)? Oder ist das nur eine Vermutung?
> mit dem "Erfolg", daß der erste Find nicht in der Maildatei sondern
> in StdIn sucht. Damit habe ich dann je nach Mailaufkommen etliche
> DOS-Fenster offen, die alle per CTRL-Z geschlossen werden wollen #-(
> Erst ein kompletter Neustart des Hamsters behebt dieses Problem.
Bleibt die Frage, wie häufig passiert das denn?
> Wo sollte ich IYO nach dem Übeltöter suchen?
Mit KorrNews läuft das schließlich seit Jahren problemlos.
Ist der Haken bei "Auf das Ende des Programms warten" gesetzt?
Kann es sein, dass etwas anderes vorher die Parameter zerschießt (z.Bsp.:
'shift')?
Warum das dann Permanent passieren sollte, kann ich nicht sagen. Dazu
müsste ich die ganze BAT sehen.
Ich lasse hier mal eine Log-Bat mitlaufen. Vielleicht kann ich es ja
reproduzieren.
Alfred
--
11955.7
Ulrich F. Heidenreich
Dec 17, 2011, 4:03:26 AM12/17/11
to
Alfred Peters in <news:9l1hsc...@mid.individual.net>:
>Es schrieb einmal Ulrich F. Heidenreich:
StdIn. Aber 'echo Parameter %1' ist nicht unübel. Werd's mal einsetzen
und warten. Manchmal sogar wochenlang ....
>> mit dem "Erfolg", daß der erste Find nicht in der Maildatei sondern
>> in StdIn sucht. Damit habe ich dann je nach Mailaufkommen etliche
>> DOS-Fenster offen, die alle per CTRL-Z geschlossen werden wollen #-(
>> Erst ein kompletter Neustart des Hamsters behebt dieses Problem.
>
>Verstehe ich das richtig: Wenn es auftritt, tritt es danach immer auf?
Jepp. Der Mailabruf geht über einen Schedular-Eintrag. Beim nächsten Run
habe ich wieder den Effekt. Allerdings bin ich mir jetzt nicht mehr so
ganz sicher, ob tatsächlich ein Restart des Hamsters notwendig ist oder
schon ein stoppen und starten des Scripts ausreichte.
>Bleibt die Frage, wie häufig passiert das denn?
Zu selten, um das vernünftig debuggen zu können. Wochenlang die Logs auf
debug und detail zu stellen, habe ich eigentlich nicht vor.
>> Wo sollte ich IYO nach dem Übeltöter suchen?
>
>Dass das am Hamster liegt, will ich erstmal nicht glauben. O:-)
>Mit KorrNews läuft das schließlich seit Jahren problemlos.
>
>Ist der Haken bei "Auf das Ende des Programms warten" gesetzt?
Ägypten? Taxi? Helgoland?
>Kann es sein, dass etwas anderes vorher die Parameter zerschießt (z.Bsp.:
>'shift')?
Nö.
>Warum das dann Permanent passieren sollte, kann ich nicht sagen. Dazu
>müsste ich die ganze BAT sehen.
Das wird Dir nichts nutzen:
find "loca...@domain.example" %1|find "To:"
if errorlevel==1 goto noAldi
d:\gsar\bin\gsar -s=0D:x0D -r:x0D -o %1
noAldi
>Ich lasse hier mal eine Log-Bat mitlaufen. Vielleicht kann ich es ja
>reproduzieren.
Danke. Ich hoffte allerdings eher auf einen Aha-Effekt.
CU!
Ulrich
--
In 0 Monaten und 8 Tagen ist Weihnachten
SQIFH 7RC3X HJUKZ X5JOF 0YCI2 6J23V EL25M LT1P7 P0IX7
Stellt euch vor, es ist Samstag und keiner geht hin!
>Es schrieb einmal Ulrich F. Heidenreich:
>> mail.in.exec=E:\hamster\mail-in.bat
>> mail.in.pars="%1"
>> mail.in.pars="%1"
>> find "eg...@egal.example" %1|find "To:"
>> Ab und an scheint der Hamster die Übergabe des %1 zu verschludern,
>
>Ist es ersichtlich, dass der Parameter leer ist (z.Bsp.:
>'echo Parameter %1' oder so)? Oder ist das nur eine Vermutung?
Rückschluß aus dem Verhalten des FIND. Ohne Parameter wirkt der halt auf
>> Ab und an scheint der Hamster die Übergabe des %1 zu verschludern,
>
>Ist es ersichtlich, dass der Parameter leer ist (z.Bsp.:
>'echo Parameter %1' oder so)? Oder ist das nur eine Vermutung?
StdIn. Aber 'echo Parameter %1' ist nicht unübel. Werd's mal einsetzen
und warten. Manchmal sogar wochenlang ....
>> mit dem "Erfolg", daß der erste Find nicht in der Maildatei sondern
>> in StdIn sucht. Damit habe ich dann je nach Mailaufkommen etliche
>> DOS-Fenster offen, die alle per CTRL-Z geschlossen werden wollen #-(
>> Erst ein kompletter Neustart des Hamsters behebt dieses Problem.
>
>Verstehe ich das richtig: Wenn es auftritt, tritt es danach immer auf?
habe ich wieder den Effekt. Allerdings bin ich mir jetzt nicht mehr so
ganz sicher, ob tatsächlich ein Restart des Hamsters notwendig ist oder
schon ein stoppen und starten des Scripts ausreichte.
>Bleibt die Frage, wie häufig passiert das denn?
debug und detail zu stellen, habe ich eigentlich nicht vor.
>> Wo sollte ich IYO nach dem Übeltöter suchen?
>
>Dass das am Hamster liegt, will ich erstmal nicht glauben. O:-)
>Mit KorrNews läuft das schließlich seit Jahren problemlos.
>
>Ist der Haken bei "Auf das Ende des Programms warten" gesetzt?
>Kann es sein, dass etwas anderes vorher die Parameter zerschießt (z.Bsp.:
>'shift')?
>Warum das dann Permanent passieren sollte, kann ich nicht sagen. Dazu
>müsste ich die ganze BAT sehen.
find "loca...@domain.example" %1|find "To:"
if errorlevel==1 goto noAldi
d:\gsar\bin\gsar -s=0D:x0D -r:x0D -o %1
noAldi
>Ich lasse hier mal eine Log-Bat mitlaufen. Vielleicht kann ich es ja
>reproduzieren.
CU!
Ulrich
--
In 0 Monaten und 8 Tagen ist Weihnachten
SQIFH 7RC3X HJUKZ X5JOF 0YCI2 6J23V EL25M LT1P7 P0IX7
Stellt euch vor, es ist Samstag und keiner geht hin!
Alfred Peters
Dec 17, 2011, 12:17:44 PM12/17/11
to
Es schrieb einmal Ulrich F. Heidenreich:
> Alfred Peters in <news:9l1hsc...@mid.individual.net>:
>> Es schrieb einmal Ulrich F. Heidenreich:
> Alfred Peters in <news:9l1hsc...@mid.individual.net>:
>> Es schrieb einmal Ulrich F. Heidenreich:
>> Ist es ersichtlich, dass der Parameter leer ist (z.Bsp.:
>> 'echo Parameter %1' oder so)? Oder ist das nur eine Vermutung?
>
> Rückschluß aus dem Verhalten des FIND. Ohne Parameter wirkt der halt auf
> StdIn. Aber 'echo Parameter %1' ist nicht unübel. Werd's mal einsetzen
Meine Log-Batch sieht so aus:
>> 'echo Parameter %1' oder so)? Oder ist das nur eine Vermutung?
>
> Rückschluß aus dem Verhalten des FIND. Ohne Parameter wirkt der halt auf
> StdIn. Aber 'echo Parameter %1' ist nicht unübel. Werd's mal einsetzen
| set resTmp=CMDresult.ini
| echo ### %date% %time% ## >> "%resTmp%"
| echo "%1" >> "%resTmp%"
| find "freenet" %1|find "To:" >> "%resTmp%"
Damit hatte ich schon gestern zwei Einträge mit der selben Dos-Zeit. Die
Auflösung von 1/100 Sekunde ist nun nicht besonders berauschend. Dennoch
könnten nach...
> und warten. Manchmal sogar wochenlang ....
Command-Shell von Win95 (richtig?) das verträgt. Allerdings wüste ich
nicht, wieso dann ein Hamster-Neustart helfen sollte.
> ganz sicher, ob tatsächlich ein Restart des Hamsters notwendig ist oder
> schon ein stoppen und starten des Scripts ausreichte.
>>> Wo sollte ich IYO nach dem Übeltöter suchen?
>>
>> Dass das am Hamster liegt, will ich erstmal nicht glauben. O:-)
>> Mit KorrNews läuft das schließlich seit Jahren problemlos.
>>
>> Ist der Haken bei "Auf das Ende des Programms warten" gesetzt?
>
> Ägypten? Taxi? Helgoland?
Einstellungen -> Automatische Abläufe -> /Aktionen\
=> [-] E-Mails
[-] Verarbeitung
[-] Eingehender E-Mails
=> Starte Anwendung: [ <Programm> ]
Und dort gibt es die obige Option. Den INI-Eintrag dafür habe ich nicht im
Kopf.
> Das wird Dir nichts nutzen:
> Danke. Ich hoffte allerdings eher auf einen Aha-Effekt.
Als Workaround könntest Du das als HSC-Skript lösen:
- Die E-Mail in ein Artikel-Objekt laden.
- Mit Re-Match den oder die Header abklopfen (Dein Find-Konstrukt findet
hier auch "Reply-To:" und "Delivered-To:"-Header).
- Und das "gsar" per execute() aufrufen.
HTH
Alfred
--
11958.3
Alfred Peters
Apr 1, 2012, 12:33:57 PM4/1/12
to
Es schrieb einmal Ulrich F. Heidenreich:
> Des Hamsters Mail-In-Action
>
> mail.in.exec=E:\hamster\mail-in.bat
> mail.in.pars="%1"
>
> mail.in.exec=E:\hamster\mail-in.bat
> mail.in.pars="%1"
> Ab und an scheint der Hamster die Übergabe des %1 zu verschludern,
> mit dem "Erfolg", daß der erste Find nicht in der Maildatei sondern
> in StdIn sucht. Damit habe ich dann je nach Mailaufkommen etliche
Ja, hier gibt es tatsächlich ein Problem. Ich hatte in meinem Log den
> mit dem "Erfolg", daß der erste Find nicht in der Maildatei sondern
> in StdIn sucht. Damit habe ich dann je nach Mailaufkommen etliche
Fall, dass die Skriptzeilen normal ausgeführt wurden, aber das Skript-File
nicht.
Wahrscheinlichsten gibt es eine Kollision beim Auslesen der Werte aus der
Hamster.ini. Um das auszuschließen, habe ich den Zugriff jetzt
thread-sicher gemacht.
<http://home.arcor.de/al-peters/hamster2101524.7z>
| - Bugfix: [config] {AP2}
| - Lesender und schreibender Zugriff auf die Hamster.ini erfolgt nun
| thread-sicher
Alfred
--
12250.7
Ulrich F. Heidenreich
Apr 1, 2012, 12:52:27 PM4/1/12
to
Alfred Peters in <news:9treep...@mid.individual.net>:
>Es schrieb einmal Ulrich F. Heidenreich:
>
>> Des Hamsters Mail-In-Action
>>
>> mail.in.exec=E:\hamster\mail-in.bat
>> mail.in.pars="%1"
>
>> Ab und an scheint der Hamster die Übergabe des %1 zu verschludern,
>> mit dem "Erfolg", daß der erste Find nicht in der Maildatei sondern
>> in StdIn sucht. Damit habe ich dann je nach Mailaufkommen etliche
>
>Ja, hier gibt es tatsächlich ein Problem.
Was ich bisher (leider?) nie wieder reproduzieren konnte.
><http://home.arcor.de/al-peters/hamster2101524.7z>
Ich werfe ihn mal an und beobachte …
CU!
Ulrich
--
In 8 Monaten und 24 Tagen ist Weihnachten
JN7XK 1IK6U 85HF1 WZWOB DKEA2 FH66W 5TFDO 8FWOJ RO0Q6
Stellt euch vor, es ist Sonntag und keiner geht hin!
>Es schrieb einmal Ulrich F. Heidenreich:
>
>> Des Hamsters Mail-In-Action
>>
>> mail.in.exec=E:\hamster\mail-in.bat
>> mail.in.pars="%1"
>
>> Ab und an scheint der Hamster die Übergabe des %1 zu verschludern,
>> mit dem "Erfolg", daß der erste Find nicht in der Maildatei sondern
>> in StdIn sucht. Damit habe ich dann je nach Mailaufkommen etliche
>
>Ja, hier gibt es tatsächlich ein Problem.
><http://home.arcor.de/al-peters/hamster2101524.7z>
Ich werfe ihn mal an und beobachte …
CU!
Ulrich
--
In 8 Monaten und 24 Tagen ist Weihnachten
JN7XK 1IK6U 85HF1 WZWOB DKEA2 FH66W 5TFDO 8FWOJ RO0Q6
Stellt euch vor, es ist Sonntag und keiner geht hin!
Ulrich F. Heidenreich
Apr 2, 2012, 5:53:03 AM4/2/12
to
>| - Bugfix: [config] {AP2}
>| - Lesender und schreibender Zugriff auf die Hamster.ini erfolgt nun
>| thread-sicher
Kann der einen Seiteneffekt auf den execute-Befehl gehabt
>| - Lesender und schreibender Zugriff auf die Hamster.ini erfolgt nun
>| thread-sicher
haben? Irgendwie habe ich das dumpfe Gefühl, (mindestens)
ein
|execute ("e:\hamster\call5er.bat","",0,False)
wird nicht mehr ausgeführt.
CU!
Ulrich
Alfred Peters
Apr 2, 2012, 2:43:15 PM4/2/12
to
Es schrieb einmal Ulrich F. Heidenreich:
> Kann der einen Seiteneffekt auf den execute-Befehl gehabt
> haben? Irgendwie habe ich das dumpfe Gefühl, (mindestens)
> ein
Nein, das ist älter:
> haben? Irgendwie habe ich das dumpfe Gefühl, (mindestens)
> ein
| V2.1.0.1521 (nightly snapshot {AP2})
| - Change: [HSC]
| Die HS2-Funktion "Execute()" hat zwei neue optionale Parameter, in denen
| der Interpreter eine HS2-Variable erwartet, um darin die Konsolenausgabe
| des gestarteten Programms zu speichern (<wait> MUSS TRUE sein):
| execute( [...], <wait>, <exitcode>, <stringOutput>, <stringError>)
| Wenn <stringError> verwendet wird, enthält die Variable die Fehler-
| Ausgaben, und <stringOutput>-Variable die Standard-Ausgaben. Andernfalls
| nimmt die <stringOutput>-Variable beide Ausgaben auf. {AP2}
>| execute ("e:\hamster\call5er.bat","",0,False)
>
> wird nicht mehr ausgeführt.
Im Gegensatz zu normalen Programmen werden Batch-Dateien scheinbar sofort
wieder beendet, wenn der Hamster nicht auf das Programmende wartet. Muss
ich mir nochmal ansehen.
Mit wait= True sollte der Aufruf funktionieren.
Alfred
--
12253.7
Alfred Peters
Apr 2, 2012, 4:30:55 PM4/2/12
to
Es schrieb einmal Alfred Peters:
| Shell( "e:\hamster\call5er.bat","",0,"open")
Alfred
--
12253.9
> Es schrieb einmal Ulrich F. Heidenreich:
>>| execute ("e:\hamster\call5er.bat","",0,False)
>>
>> wird nicht mehr ausgeführt.
>>
>> wird nicht mehr ausgeführt.
> Mit wait= True sollte der Aufruf funktionieren.
Oder besser gleich:
| Shell( "e:\hamster\call5er.bat","",0,"open")
Alfred
--
12253.9
Wolfgang Jäth
Apr 3, 2012, 12:36:09 AM4/3/12
to
Am 02.04.2012 22:30, schrieb Alfred Peters:
> Es schrieb einmal Alfred Peters:
>> Es schrieb einmal Ulrich F. Heidenreich:
>
>>>| execute ("e:\hamster\call5er.bat","",0,False)
>>>
>>> wird nicht mehr ausgeführt.
Entgegen landläufiger Ansicht sind Batch-Dateien eben *keine* (direkt
ausführbaren) Programmdateien, sondern reine Datendateien aka Skripte,
welche an den Komandozeilenprozessor (früher command.com, heute cmd.exe)
als Interpreter (und *eigentliches* Programm) übergeben werden müssen
(s. u.). Der Betriebssystem-Kern selbst kann mit einer Batch-Datei genau
so wenig anfangen wie mit einer TXT-Datei; /der/ versteht *nur*
Maschinensprache aka EXE oder COM.
>> Mit wait= True sollte der Aufruf funktionieren.
>
> Oder besser gleich:
>
> | Shell( "e:\hamster\call5er.bat","",0,"open")
keine Ausgabe (und wenn, würde ich eigentlich auch fast eher erwarten,
daß die Datei mit einen Texteditor geöffnet wird).
Funktionieren tut aber auf alle Fälle die klassische Variante
| execute ("cmd.exe /Ce:\hamster\call5er.bat", "", 1, true )
bzw.
| execute ("cmd.exe /Ccall5er.bat", "e:\hamster\", 1, true )
Wolf 'und die haben zudem noch den Vorteil, daß man ggf. sogar Parameter
angeben kann' gang
--
Ulrich F. Heidenreich
Apr 3, 2012, 4:08:52 AM4/3/12
to
|*#Alfred Peters in <<9tuaac...@mid.individual.net>:
>Es schrieb einmal Ulrich F. Heidenreich:
>> Alfred Peters in <news:9treep...@mid.individual.net>:
>>
>>>| - Bugfix: [config] {AP2}
>
>> Kann der einen Seiteneffekt auf den execute-Befehl gehabt
>> haben? Irgendwie habe ich das dumpfe Gefühl, (mindestens)
>> ein
>
>Nein, das ist älter:
Habe ich inzwischen auch gemerkt. Zurück zur .1513 ging alles wieder.
>| V2.1.0.1521 (nightly snapshot {AP2})
>
>| - Change: [HSC]
>| Die HS2-Funktion "Execute()" hat zwei neue optionale Parameter, in denen
¯¯¯¯¯¯¯¯¯!?
>Du immer mit deinen Batch-Dateien. ;-)
Eine solche ist halt die trivialste Möglichkeit, um ein
"In %xmasmonth% %Monate% und %xmasday% %Tage% ist es Weihnachten"
in D:\Agent\sig.text hineinzubekommen ;-)
>Im Gegensatz zu normalen Programmen werden Batch-Dateien scheinbar sofort
>wieder beendet,
Eher: Erst gar nicht gestartet?
>wenn der Hamster nicht auf das Programmende wartet. Muss
>ich mir nochmal ansehen.
>
>Mit wait= True sollte der Aufruf funktionieren.
Mal schauen. Erstmal lasse ich den .1513 am Start.
CU!
Ulrich
--
Test Erstellungszeitpunkt sig.txt: 03.04.2012 10:02:23
In 8 Monaten und 22 Tagen ist Weihnachten
CQIRX FNC7T 536GR TLNOR GE0E6 YBEFB I52HQ LTDTN DSI5N
Stellt euch vor, es ist Dienstag und keiner geht hin!
>Es schrieb einmal Ulrich F. Heidenreich:
>> Alfred Peters in <news:9treep...@mid.individual.net>:
>>
>>>| - Bugfix: [config] {AP2}
>
>> Kann der einen Seiteneffekt auf den execute-Befehl gehabt
>> haben? Irgendwie habe ich das dumpfe Gefühl, (mindestens)
>> ein
>
>Nein, das ist älter:
>| V2.1.0.1521 (nightly snapshot {AP2})
>
>| - Change: [HSC]
>| Die HS2-Funktion "Execute()" hat zwei neue optionale Parameter, in denen
>| der Interpreter eine HS2-Variable erwartet, um darin die Konsolenausgabe
>| des gestarteten Programms zu speichern (<wait> MUSS TRUE sein):
>| execute( [...], <wait>, <exitcode>, <stringOutput>, <stringError>)
>| Wenn <stringError> verwendet wird, enthält die Variable die Fehler-
>| Ausgaben, und <stringOutput>-Variable die Standard-Ausgaben. Andernfalls
>| nimmt die <stringOutput>-Variable beide Ausgaben auf. {AP2}
>
>
>>| execute ("e:\hamster\call5er.bat","",0,False)
>>
>> wird nicht mehr ausgeführt.
Und zwar wohl kommentarlos ohne jegliche Fehlermeldung.
>| des gestarteten Programms zu speichern (<wait> MUSS TRUE sein):
>| execute( [...], <wait>, <exitcode>, <stringOutput>, <stringError>)
>| Wenn <stringError> verwendet wird, enthält die Variable die Fehler-
>| Ausgaben, und <stringOutput>-Variable die Standard-Ausgaben. Andernfalls
>| nimmt die <stringOutput>-Variable beide Ausgaben auf. {AP2}
>
>
>>| execute ("e:\hamster\call5er.bat","",0,False)
>>
>> wird nicht mehr ausgeführt.
>Du immer mit deinen Batch-Dateien. ;-)
"In %xmasmonth% %Monate% und %xmasday% %Tage% ist es Weihnachten"
in D:\Agent\sig.text hineinzubekommen ;-)
>Im Gegensatz zu normalen Programmen werden Batch-Dateien scheinbar sofort
>wieder beendet,
>wenn der Hamster nicht auf das Programmende wartet. Muss
>ich mir nochmal ansehen.
>
>Mit wait= True sollte der Aufruf funktionieren.
CU!
Ulrich
--
Test Erstellungszeitpunkt sig.txt: 03.04.2012 10:02:23
In 8 Monaten und 22 Tagen ist Weihnachten
CQIRX FNC7T 536GR TLNOR GE0E6 YBEFB I52HQ LTDTN DSI5N
Stellt euch vor, es ist Dienstag und keiner geht hin!
Ulrich F. Heidenreich
Apr 3, 2012, 4:30:11 AM4/3/12
to
|*#Wolfgang Jäth in <<jle5oq...@ID-4636.user.dfncis.de>:
>Am 02.04.2012 22:30, schrieb Alfred Peters:
>> Es schrieb einmal Alfred Peters:
>>> Es schrieb einmal Ulrich F. Heidenreich:
>>
>>>>| execute ("e:\hamster\call5er.bat","",0,False)
>>>>
>>>> wird nicht mehr ausgeführt.
>
>Das wurde es noch *nie*.
Ach neeee.
>Entgegen landläufiger Ansicht sind Batch-Dateien eben *keine* (direkt
>ausführbaren) Programmdateien, sondern reine Datendateien aka Skripte,
>welche an den Komandozeilenprozessor (früher command.com, heute cmd.exe)
>als Interpreter (und *eigentliches* Programm) übergeben werden müssen
Ohne jetzt in den Quelltext zu schauen, dürfte es der Hamster genauso
mit Batchdateien halten (Zumindest bis mindestens der .1513. Ob Alfred
danach das geändert hat, weiß er selbst wohl besser). Täte er das nicht,
ginge hier fast gar nichts.
CU!
Ulrich
--
Test Erstellungszeitpunkt sig.txt: 03.04.2012 10:22:23
>Am 02.04.2012 22:30, schrieb Alfred Peters:
>> Es schrieb einmal Alfred Peters:
>>> Es schrieb einmal Ulrich F. Heidenreich:
>>
>>>>| execute ("e:\hamster\call5er.bat","",0,False)
>>>>
>>>> wird nicht mehr ausgeführt.
>
>Das wurde es noch *nie*.
>Entgegen landläufiger Ansicht sind Batch-Dateien eben *keine* (direkt
>ausführbaren) Programmdateien, sondern reine Datendateien aka Skripte,
>welche an den Komandozeilenprozessor (früher command.com, heute cmd.exe)
>als Interpreter (und *eigentliches* Programm) übergeben werden müssen
mit Batchdateien halten (Zumindest bis mindestens der .1513. Ob Alfred
danach das geändert hat, weiß er selbst wohl besser). Täte er das nicht,
ginge hier fast gar nichts.
CU!
Ulrich
--
Test Erstellungszeitpunkt sig.txt: 03.04.2012 10:22:23
In 8 Monaten und 22 Tagen ist Weihnachten
GVAD7 PRUOV USKRX 1UZC3 A7T54 5KSOK N8L4M 0S33A 73DZI
Alfred Peters
Apr 3, 2012, 12:03:58 PM4/3/12
to
Es schrieb einmal Wolfgang Jäth:
bei mir und offensichtlich auch bei Ulrich.
Das es im .1521 - .1524 nicht mehr geht, hat eine andere Ursache.
> Entgegen landläufiger Ansicht sind Batch-Dateien eben *keine* (direkt
> ausführbaren) Programmdateien, sondern reine Datendateien aka Skripte,
> welche an den Komandozeilenprozessor (früher command.com, heute cmd.exe)
> als Interpreter (und *eigentliches* Programm) übergeben werden müssen
> (s. u.). Der Betriebssystem-Kern selbst kann mit einer Batch-Datei genau
> so wenig anfangen wie mit einer TXT-Datei; /der/ versteht *nur*
> Maschinensprache aka EXE oder COM.
Richtig. Selbst auf den MS-Seiten[1] wird zur Ausführung von Batch-Dateien
auf cmd.exe verwiesen. Aber: "Und Sie dreht sich doch ..."
>>> Mit wait= True sollte der Aufruf funktionieren.
>>
>> Oder besser gleich:
>>
>>| Shell( "e:\hamster\call5er.bat","",0,"open")
>
> Bist Du Dir sicher, daß das funktioniert?
Ja. Shell() ist eine ganz andere Geschichte. Execute() arbeitet mit
CreateProcess(), während Shell() die Windows-Funktion ShellExecute()
benutzt. Und die wiederum benutzt die Registry-Einstellungen unter:
"HKEY_CLASSES_ROOT\.bat" bzw. "HKEY_CLASSES_ROOT\batfile" und dort dann
die Angaben für "shell\open" oder eben "shell\edit". Das entspricht dann
dem Parameter beim Shell()-Aufruf.
> Ich bekomme damit /überhaupt/
> keine Ausgabe (und wenn, würde ich eigentlich auch fast eher erwarten,
> daß die Datei mit einen Texteditor geöffnet wird).
Die Parameter sind auch noch falsch. In der Hilfe steht:
| Shell( <filename>, <modus>, <path>, <oprtn> )
Es ist aber nicht nur, wie von mir vermutet, <modus> und <path>
vertauscht, es fehlt auch noch ein Parameter. Richtig muss es heißen:
| Shell( <filename>, <parameter>, <modus>, <path>, <oprtn> )
Und Ulrichs Aufruf somit:
# Shell( "e:\hamster\call5er.bat", "", 0, "", "open")
> Funktionieren tut aber auf alle Fälle die klassische Variante
>
>| execute ("cmd.exe /Ce:\hamster\call5er.bat", "", 1, true )
Mit <wait>=True sowieso. Und mit <wait>=False geht auch das aktuell nicht.
Aber das hat, wie gesagt, eine andere Ursache.
> Wolf 'und die haben zudem noch den Vorteil, daß man ggf. sogar Parameter
> angeben kann' gang
Ja, aber das kann Shell auch. Siehe oben.
Alfred
[1]<http://msdn.microsoft.com/en-us/library/windows/desktop/ms682425%28v=vs.85%29.aspx>
--
12256.1
> Am 02.04.2012 22:30, schrieb Alfred Peters:
>> Es schrieb einmal Alfred Peters:
>>> Es schrieb einmal Ulrich F. Heidenreich:
>>
>>>>| execute ("e:\hamster\call5er.bat","",0,False)
>>>>
>>>> wird nicht mehr ausgeführt.
>
> Das wurde es noch *nie*.
Doch, irgendwie scheint es zu tatsächlich zu funktionieren. Zumindest hier
>> Es schrieb einmal Alfred Peters:
>>> Es schrieb einmal Ulrich F. Heidenreich:
>>
>>>>| execute ("e:\hamster\call5er.bat","",0,False)
>>>>
>>>> wird nicht mehr ausgeführt.
>
> Das wurde es noch *nie*.
bei mir und offensichtlich auch bei Ulrich.
Das es im .1521 - .1524 nicht mehr geht, hat eine andere Ursache.
> Entgegen landläufiger Ansicht sind Batch-Dateien eben *keine* (direkt
> ausführbaren) Programmdateien, sondern reine Datendateien aka Skripte,
> welche an den Komandozeilenprozessor (früher command.com, heute cmd.exe)
> als Interpreter (und *eigentliches* Programm) übergeben werden müssen
> (s. u.). Der Betriebssystem-Kern selbst kann mit einer Batch-Datei genau
> so wenig anfangen wie mit einer TXT-Datei; /der/ versteht *nur*
> Maschinensprache aka EXE oder COM.
auf cmd.exe verwiesen. Aber: "Und Sie dreht sich doch ..."
>>> Mit wait= True sollte der Aufruf funktionieren.
>>
>> Oder besser gleich:
>>
>>| Shell( "e:\hamster\call5er.bat","",0,"open")
>
> Bist Du Dir sicher, daß das funktioniert?
CreateProcess(), während Shell() die Windows-Funktion ShellExecute()
benutzt. Und die wiederum benutzt die Registry-Einstellungen unter:
"HKEY_CLASSES_ROOT\.bat" bzw. "HKEY_CLASSES_ROOT\batfile" und dort dann
die Angaben für "shell\open" oder eben "shell\edit". Das entspricht dann
dem Parameter beim Shell()-Aufruf.
> Ich bekomme damit /überhaupt/
> keine Ausgabe (und wenn, würde ich eigentlich auch fast eher erwarten,
> daß die Datei mit einen Texteditor geöffnet wird).
| Shell( <filename>, <modus>, <path>, <oprtn> )
Es ist aber nicht nur, wie von mir vermutet, <modus> und <path>
vertauscht, es fehlt auch noch ein Parameter. Richtig muss es heißen:
| Shell( <filename>, <parameter>, <modus>, <path>, <oprtn> )
Und Ulrichs Aufruf somit:
# Shell( "e:\hamster\call5er.bat", "", 0, "", "open")
> Funktionieren tut aber auf alle Fälle die klassische Variante
>
>| execute ("cmd.exe /Ce:\hamster\call5er.bat", "", 1, true )
Aber das hat, wie gesagt, eine andere Ursache.
> Wolf 'und die haben zudem noch den Vorteil, daß man ggf. sogar Parameter
> angeben kann' gang
Alfred
[1]<http://msdn.microsoft.com/en-us/library/windows/desktop/ms682425%28v=vs.85%29.aspx>
--
12256.1
Wolfgang Jäth
Apr 3, 2012, 5:36:00 PM4/3/12
to
Am 03.04.2012 18:03, schrieb Alfred Peters:
>>>>>| execute ("e:\hamster\call5er.bat","",0,False)
>>>>>
>>>>> wird nicht mehr ausgeführt.
>>
>> Das wurde es noch *nie*.
>
> Doch, irgendwie scheint es zu tatsächlich zu funktionieren. Zumindest hier
> bei mir und offensichtlich auch bei Ulrich.
Wäre mir neu.
>>>>>| execute ("e:\hamster\call5er.bat","",0,False)
>>>>>
>>>>> wird nicht mehr ausgeführt.
>>
>> Das wurde es noch *nie*.
>
> Doch, irgendwie scheint es zu tatsächlich zu funktionieren. Zumindest hier
> bei mir und offensichtlich auch bei Ulrich.
> Das es im .1521 - .1524 nicht mehr geht, hat eine andere Ursache.
des Betriebssystems; der Interpreter für Batchdateien *ist* nun mal im
Komandozeilenprozessor eingebaut.
Wolfgang
--
Ulrich F. Heidenreich
Apr 4, 2012, 4:40:58 AM4/4/12
to
|*#Alfred Peters in <<9tuaac...@mid.individual.net>:
>Mit wait= True sollte der Aufruf funktionieren.
Tut es wohl. Allerdings meldet mir jetzt der "Ham" ab und an einen
Ausnahmefehler. Reproduzierbar ist aber noch nichts. Auch den
genauen Meldungswortlaut habe ich mir leider noch nicht gemerkt.
CU!
Ulrich
--
Test Erstellungszeitpunkt sig.txt: 04.04.2012 10:33:29
In 8 Monaten und 21 Tagen ist Weihnachten
G6T36 9FJ8O JIA30 948D4 OKCQZ EYD7E P4SV3 P6CW7 E4UFJ
Stellt euch vor, es ist Mittwoch und keiner geht hin!
>Mit wait= True sollte der Aufruf funktionieren.
Ausnahmefehler. Reproduzierbar ist aber noch nichts. Auch den
genauen Meldungswortlaut habe ich mir leider noch nicht gemerkt.
CU!
Ulrich
--
Test Erstellungszeitpunkt sig.txt: 04.04.2012 10:33:29
In 8 Monaten und 21 Tagen ist Weihnachten
G6T36 9FJ8O JIA30 948D4 OKCQZ EYD7E P4SV3 P6CW7 E4UFJ
Stellt euch vor, es ist Mittwoch und keiner geht hin!
Ulrich F. Heidenreich
Apr 4, 2012, 4:34:46 AM4/4/12
to
|*#Wolfgang Jäth in <<jlg1h1...@ID-4636.user.dfncis.de>:
Schaut doch mal bitte jemand in den Quelltext, ob der Hamster nicht
genau dieses macht, wenn Execute eine Batchdatei vorgesetzt bekommt.
Sonst trollt der Herr Jäth noch tagelang weiter so rum.
Wenn er das nämlich nicht täte, ginge hier so ziemlich gar nichts mehr.
Mein ganzes Hamster/UUCP-Gerüst steht nämlich auf einigen Batch-Beinen.
genau dieses macht, wenn Execute eine Batchdatei vorgesetzt bekommt.
Sonst trollt der Herr Jäth noch tagelang weiter so rum.
Wenn er das nämlich nicht täte, ginge hier so ziemlich gar nichts mehr.
Mein ganzes Hamster/UUCP-Gerüst steht nämlich auf einigen Batch-Beinen.
Ulrich F. Heidenreich
Apr 4, 2012, 4:52:21 AM4/4/12
to
|*#Alfred Peters in <<9tuaac...@mid.individual.net>:
>Mit wait= True sollte der Aufruf funktionieren.
wirklich durch die neue Hamsterversion ausgelöst ist aber noch nichts.
>Mit wait= True sollte der Aufruf funktionieren.
Tut es wohl. Allerdings meldet mir jetzt der "Ham" ab und an einen
Ausnahmefehler: <http://invalid.de/hamex.png>. Reproduzierbar und ob
wirklich durch die neue Hamsterversion ausgelöst ist aber noch nichts.
Alfred Peters
Apr 4, 2012, 1:43:29 PM4/4/12
to
Es schrieb einmal Ulrich F. Heidenreich:
>| *#Wolfgang Jäth in <<jlg1h1...@ID-4636.user.dfncis.de>:
> Schaut doch mal bitte jemand in den Quelltext, ob der Hamster nicht
> genau dieses macht, wenn Execute eine Batchdatei vorgesetzt bekommt.
Alfred
--
12259.0
Alfred Peters
Apr 4, 2012, 1:42:33 PM4/4/12
to
Es schrieb einmal Wolfgang Jäth:
> Am 03.04.2012 18:03, schrieb Alfred Peters:
>> Doch, irgendwie scheint es zu tatsächlich zu funktionieren. Zumindest hier
>> bei mir und offensichtlich auch bei Ulrich.
>
> Wäre mir neu.
Deshalb schreibe ich es Dir ja.
>> Doch, irgendwie scheint es zu tatsächlich zu funktionieren. Zumindest hier
>> bei mir und offensichtlich auch bei Ulrich.
>
> Wäre mir neu.
>> Das es im .1521 - .1524 nicht mehr geht, hat eine andere Ursache.
>
> Das hat mit der Hamsterversion nix zu tun,
woran es gelegen hat.
> sondern ist eine Geschichte
> des Betriebssystems; der Interpreter für Batchdateien *ist* nun mal im
> Komandozeilenprozessor eingebaut.
sich hier die Bat-Dateien direkt mit execute() starten lassen. Ich kann
für Dich ja ein ein Bild davon machen ...
Hmm, nö, kann ich nicht. 1. hält die Bat nicht bei 'Pause' (vermutlich,
weil ich keine Eingabe-Pipe angegeben habe). Und 2. sieht man zwar ein
Fenster, aber das bleibt schwarz, weil ich die Ausgabe des Skripts über
die Ausgabe-Pipes absauge.
Nur kann es daran auch nicht liegen, denn ist dieser Kode ist in Ulrichs
altem .1513 noch gar nicht drin. Den habe ich grade nicht da, aber mit
einem .1501 geht es hier auch schon.
Aber falls es das schwarze Fenster ist, was Dich zweifeln lässt, probiere
bitte folgendes:
Bat-Datei: "test.bat"
echo Hello World
echo Para 1: %1
pause
echo ende
Skript: test.hsc
varset( $output, "" )
execute( "test.bat p1", <pfad zur Bat>, 0, 1, , $output)
varset( $outlist, ListAlloc() )
ListSetText( $outlist, $output )
varset($len, ListCount($outlist)-1 )
varset($i,0)
for($i,0,$len)
Print( ListGet($outlist,$i) )
endfor
ListFree( $outlist )
Ok, doch noch ein Bild. Aber mit einem korrigierten .1524-Hamster:
<https://www.dropbox.com/sh/xb8as5d5darh24a/jaypFFTIkm/bat.png>
Offensichtlich startet Windows automatisch die cmd.exe.
Alfred
--
12259.0
Ulrich F. Heidenreich
Apr 5, 2012, 3:28:55 AM4/5/12
to
Alfred Peters in <news:9u3fib...@mid.individual.net>:
>Es schrieb einmal Ulrich F. Heidenreich:
>
an Stelle von "Command /c foo.bat"? Und ja, Herr Jäth, es klappt.
CU!
Ulrich
--
In 8 Monaten und 20 Tagen ist Weihnachten
79FOW XM251 Q5F08 DJ0RG FNESD KFGDD 5YU7F 3MQD7 7A6WP
Stellt euch vor, es ist Donnerstag und keiner geht hin!
>Es schrieb einmal Ulrich F. Heidenreich:
>
>> Schaut doch mal bitte jemand in den Quelltext, ob der Hamster nicht
>> genau dieses macht, wenn Execute eine Batchdatei vorgesetzt bekommt.
>
>Nein, Macht er *nicht*.
Interessant. Warum klappt dann die einfache Übergabe eines foo.bat
>> genau dieses macht, wenn Execute eine Batchdatei vorgesetzt bekommt.
>
>Nein, Macht er *nicht*.
an Stelle von "Command /c foo.bat"? Und ja, Herr Jäth, es klappt.
CU!
Ulrich
--
In 8 Monaten und 20 Tagen ist Weihnachten
79FOW XM251 Q5F08 DJ0RG FNESD KFGDD 5YU7F 3MQD7 7A6WP
Stellt euch vor, es ist Donnerstag und keiner geht hin!
Ulrich F. Heidenreich
Apr 5, 2012, 3:38:22 AM4/5/12
to
|*#Alfred Peters in <<9u3fib...@mid.individual.net>:
>Ja, das weiß ich. Und trotzdem lässt sich nunmal nicht wegdiskutieren, das
>sich hier die Bat-Dateien direkt mit execute() starten lassen. Ich kann
>für Dich ja ein ein Bild davon machen ...
>
>Hmm, nö, kann ich nicht. 1. hält die Bat nicht bei 'Pause' (vermutlich,
>weil ich keine Eingabe-Pipe angegeben habe). Und 2. sieht man zwar ein
>Fenster, aber das bleibt schwarz, weil ich die Ausgabe des Skripts über
>die Ausgabe-Pipes absauge.
Und 3. will ich ja von der Batchdatei gar nichts sehen. Deswegen habe
ich ja den "Show"-Parameter auf 0. Und warten, bis sie fertig ist, soll
der Hamster eigentlich auch nicht, deswegen wait=false.
Im konkreten Fall arbeitete
|echo -- >D:\agent\sigfile.txt
|echo %leftx% %xmasday% %Tage% ist Weihnachten>>D:\agent\sigfile.txt
|5er >>D:\agent\sigfile.txt
|ewl Stellt euch vor, es ist %dayname% und keiner geht hin!>>D:\agent\sigfile.txt
nicht mehr, wenn der wait-Parameter auf "false" stand. Könnte es sein,
daß man den seit der von Dir genannten Änderung gar nicht mehr auf
"false" stellen darf?
CU!
Ulrich
P.S.: Nur der Vollständigkeit halber: 'ewl' ist eine kleine Exe, die ein
"echo without linefeed" veranstaltet.
>Ja, das weiß ich. Und trotzdem lässt sich nunmal nicht wegdiskutieren, das
>sich hier die Bat-Dateien direkt mit execute() starten lassen. Ich kann
>für Dich ja ein ein Bild davon machen ...
>
>Hmm, nö, kann ich nicht. 1. hält die Bat nicht bei 'Pause' (vermutlich,
>weil ich keine Eingabe-Pipe angegeben habe). Und 2. sieht man zwar ein
>Fenster, aber das bleibt schwarz, weil ich die Ausgabe des Skripts über
>die Ausgabe-Pipes absauge.
ich ja den "Show"-Parameter auf 0. Und warten, bis sie fertig ist, soll
der Hamster eigentlich auch nicht, deswegen wait=false.
Im konkreten Fall arbeitete
|echo -- >D:\agent\sigfile.txt
|echo %leftx% %xmasday% %Tage% ist Weihnachten>>D:\agent\sigfile.txt
|5er >>D:\agent\sigfile.txt
|ewl Stellt euch vor, es ist %dayname% und keiner geht hin!>>D:\agent\sigfile.txt
nicht mehr, wenn der wait-Parameter auf "false" stand. Könnte es sein,
daß man den seit der von Dir genannten Änderung gar nicht mehr auf
"false" stellen darf?
CU!
Ulrich
P.S.: Nur der Vollständigkeit halber: 'ewl' ist eine kleine Exe, die ein
"echo without linefeed" veranstaltet.
--
In 8 Monaten und 20 Tagen ist Weihnachten
5JMQJ P3IZ2 L4FU4 Q2ZDB AJRU0 73WLN FX7S6 PP9JV 0FFJV
In 8 Monaten und 20 Tagen ist Weihnachten
Alfred Peters
Apr 5, 2012, 1:04:46 PM4/5/12
to
Es schrieb einmal Ulrich F. Heidenreich:
> nicht mehr, wenn der wait-Parameter auf "false" stand. Könnte es sein,
> daß man den seit der von Dir genannten Änderung gar nicht mehr auf
> "false" stellen darf?
Ja, das ist ein Bug im .1524. In der nächsten Version sollte es auch
> daß man den seit der von Dir genannten Änderung gar nicht mehr auf
> "false" stellen darf?
wieder mit "false" gehen. Stay tuned.
Alfred
--
12261.7
Wolfgang Jäth
Apr 5, 2012, 12:52:10 AM4/5/12
to
Am 04.04.2012 19:42, schrieb Alfred Peters:
>
> Offensichtlich startet Windows automatisch die cmd.exe.
Ja; scheint so. :-/
>
> Offensichtlich startet Windows automatisch die cmd.exe.
BTW, zu Deinem Vorposting: Der Shell-Befehl muss genau genommen
shell ("e:\hamster\call5er.bat", "", 1, "", "open")
^^^
lauten; '0' ist 'kein Fenster' (und dann braucht man sich auch nicht
wundern, wenn keines kommt <g>).
Wolfgang
--
Ulrich F. Heidenreich
Apr 6, 2012, 4:49:28 AM4/6/12
to
Alfred Peters in <news:9u62bl...@mid.individual.net>:
Siehmaleinerguckmalda.
Bis dahein kann ich aber auch mit "true" leben; es schadet ja nichts,
sondern entspricht nur nicht meinem "Schönheitsempfinden", den Hamster
auf die Beendigung eines Programmes warten zu lassen, auf dessen Ende
er eigentlich™ gar nicht zu warten braucht.
CU!
Ulrich
--
In 8 Monaten und 19 Tagen ist Weihnachten
HUOA4 V0J3I S9SP2 YBDUB CIZSV NMU48 8YTEH CX3A0 EQIC5
Stellt euch vor, es ist Freitag und keiner geht hin!
Bis dahein kann ich aber auch mit "true" leben; es schadet ja nichts,
sondern entspricht nur nicht meinem "Schönheitsempfinden", den Hamster
auf die Beendigung eines Programmes warten zu lassen, auf dessen Ende
er eigentlich™ gar nicht zu warten braucht.
CU!
Ulrich
--
In 8 Monaten und 19 Tagen ist Weihnachten
HUOA4 V0J3I S9SP2 YBDUB CIZSV NMU48 8YTEH CX3A0 EQIC5
Stellt euch vor, es ist Freitag und keiner geht hin!
Alfred Peters
Apr 9, 2012, 9:54:13 AM4/9/12
to
Es schrieb einmal Alfred Peters:
> Es schrieb einmal Ulrich F. Heidenreich:
>>| execute ("e:\hamster\call5er.bat","",0,False)
>>
>> wird nicht mehr ausgeführt.
>>
>> wird nicht mehr ausgeführt.
> Im Gegensatz zu normalen Programmen werden Batch-Dateien scheinbar sofort
> wieder beendet, wenn der Hamster nicht auf das Programmende wartet. Muss
> ich mir nochmal ansehen.
Sollte hiermit [1] wieder funktionieren.
> wieder beendet, wenn der Hamster nicht auf das Programmende wartet. Muss
> ich mir nochmal ansehen.
Alfred
[1] <http://home.arcor.de/al-peters/hamster2101525.7z>
| V2.1.0.1525 (nightly snapshot {AP2})
|
| - [HSC] Funktion: Execute() {AP2}
| - Bugfix: Teilweise wurde bei <wait>=FALSE das auszuführenden Programm
| vorzeitig beendet.
| - Change:
| Der Parameter <wait> kann nun auch einen nummerischen Wert annehmen:
| <wait> = 0 / FALSE : wartet nicht auf das Programmende.
| <wait> = 1 / TRUE : wartet bis zum Programmende.
| <wait> = 2 - 2147483647 : wartet maximal <wait> ms auf das Programmende.
|
--
12272.3
Ulrich F. Heidenreich
Apr 12, 2012, 5:27:57 AM4/12/12
to
>Wahrscheinlichsten gibt es eine Kollision beim Auslesen der Werte aus der
>Hamster.ini. Um das auszuschließen, habe ich den Zugriff jetzt
>thread-sicher gemacht.
>
><http://home.arcor.de/al-peters/hamster2101524.7z>
>
>| - Bugfix: [config] {AP2}
>| - Lesender und schreibender Zugriff auf die Hamster.ini erfolgt nun
>| thread-sicher
Zwar Danke für Deine Mühen, das war's aber wohl leider doch nicht. Erst
>Hamster.ini. Um das auszuschließen, habe ich den Zugriff jetzt
>thread-sicher gemacht.
>
><http://home.arcor.de/al-peters/hamster2101524.7z>
>
>| - Bugfix: [config] {AP2}
>| - Lesender und schreibender Zugriff auf die Hamster.ini erfolgt nun
>| thread-sicher
heute hat er wieder zugeschlagen und dies unter der .1525. Inhalt der
betreffenden Batchdatei, jetzt mit Debug-Ausgabe:
|echo Parameter %1
|find "abcde...@domain.examle" %1|find "To:"
|if errorlevel==1 goto noAldi
|d:\gsar\bin\gsar -s=0D:x0D -r:x0D -o %1
|noAldi
Ergebnis:
|d:\gsar\bin\gsar -s=0D:x0D -r:x0D -o %1
|noAldi
|E:\hamster>echo Parameter
|Parameter
|
|E:\hamster>find "abcde...@domain.examle" |find "To:"
Eindeutig geht der Übergabeparamater der Action
|[Actions]
|
|mail.out.exec=E:\hamster\mail-out.bat
|mail.out.pars="%1"
verschütt. Nur FYI. Zu finden sein wird der Fehler wohl kaum; vielleicht
verschludert auch der Teil von Windows, der auch *.BAT-Dateien ausführt,
wenn sie ihm vom Hamster übergeben werden - auch wenn Herr Jäth meint,
dies ginge gar nicht - ab und an den Parameter. Also nur drum kümmern,
wenn Dein Ehrgeiz Dich quält. Wegen mir braucht's nicht unbedingt.
CU!
Ulrich
--
Eigenwillige Empfehlungen: http://invalid.de/Amazon/
In 8 Monaten und 13 Tagen ist Weihnachten
1D5QV IEFK3 MNPWY AHMGP 5CL4D L4XD2 27RQA 7BL3A VUSR8
0 new messages