Zakładając, że istnieje plik wsadowy (wywołujący), który wykonuje inny plik wsadowy (adresat), należy użyć polecenia call, aby powrócić do wywołującego po zakończeniu wywołania. Oto przykład:Dlaczego nie ma potrzeby "wywołania", aby powrócił z wywołanego skryptu wsadowego, który jest zaangażowany w potok?
caller.bat:
echo Calling another script...
call callee.bat
echo Returned from callee...
callee.bat (w tym samym miejscu) :
echo Being called from caller...
wyjście będzie to (pomijając echo poleceń) , pokazując, że wykonanie zostało zwrócone zgodnie z oczekiwaniami:
Calling another script... Being called from caller... Returned from callee...
Jeśli komenda call został odwołany w rozmówcy, wyjście będzie:
Calling another script... Being called from caller...
Ale jak tylko wywoływany jest zaangażowany w rurze (|), nie ma różnicy w tym, czy użyto polecenia call. Na przykład:
caller.bat (wywoływany pozostaje niezmieniony) :
echo Calling another script...
break | callee.bat
echo Returned from callee...
wyjście będzie to, choć nie ma polecenia call.
Calling another script... Being called from caller... Returned from callee...
Co jest powodem takiego zachowania, co powoduje wykonanie, aby powrócić do rozmówcy tutaj?
Pytanie do mnie, czy istnieje jakaś różnica między 'break | command' i' call command'? Sprawdź także to 'set a = b'; 'set b = c'; 'break | echo %%% a %%%'. I ... wyjście to "c". W obu przypadkach tworzysz nowy podkontekst cmd. Może być jakiś stan pliku cmd zachowany, gdy użyte jest 'call'? – npocmaka
Oh. 'REM',' IF' i 'FOR' zachowują się odmiennie, gdy są potokowane i gdy są wywoływane, ale jest to rahter dla analizy. – npocmaka
Hmm ... poza transferem danych _STDOUT_ do _STDIN_ rur, wydaje się, że nie ma żadnej różnicy; nawet 'cmd/C callee.bat' wraca do wywołującego; tak, 'rem',' if' i 'for' są specjalne, ponieważ pamiętam, że są rozpoznawane wcześniej niż inne polecenia podczas procesu parsowania ... – aschipfl