Dlaczego wywoływanie zagnieżdżonego pliku wsadowego bez uprzedniego wywołania "call" do wiersza kończy macierzysty plik wsadowy?

rozumiem jak zadzwonić zagnieżdżone pliki wsadowe od wewnątrz pliku nadrzędnego używając komendy call, gdyż istnieje wiele zasobów na tym:Dlaczego wywoływanie zagnieżdżonego pliku wsadowego bez uprzedniego wywołania "call" do wiersza kończy macierzysty plik wsadowy?

Jednak nie rozumiem, , dlaczego wywoływanie innego pliku wsadowego z innego kończy rodzica.

Dla mniej abstrakcyjny przykład, załóżmy, że mam plik wsadowy „linki” razem oddzielnych plikach wsadowych i błędnie nie dokleja call do każdej linii:

foo.bat 
bar.bat

To byłoby wykonać tylko foo .bat, a następnie wyjść. Aby poprawnie wykonać oba polecenia, musiałbym przed każdym stwierdzeniem wywołać połączenie:

call foo.bat 
call bar.bat

Dlaczego pierwsza funkcjonalność nadal istnieje? Dlaczego to się nie zmieniło? Zauważyłem, że call został wprowadzony w MS-DOS 3.3, który został wydany pod koniec lat 80., więc czy ta funkcjonalność jest tutaj nadal kompatybilna z odwrotnością? Nie mogę wymyślić jakichś (praktycznych) zastosowań, ale być może jestem zbyt przyzwyczajony do "nowych" technik programowania.

Źródło

2012-07-24 Brandon Amos

DOS stosować proste przetwarzanie tekstów (z powrotem, kiedy trzeba było rzeczy jak FILES=20 w config.sys aby umożliwić uchwyty plików), więc otworzył plik, przeczytać następną linię, zamknął plik, a następnie wykonywany wiersz po prostu czytać . Jeśli plik o nazwie inny, to przetwarzanie było kontynuowane z tym plikiem, więc do pliku wsadowego byłby wymagany tylko jeden uchwyt pliku.

Dopóki Microsoft nie wprowadził komendy call, nie było możliwości powrotu do oryginalnego pliku (bez użycia sztuczek, takich jak podanie nazwy poprzedniego pliku jako parametru, oraz użycie plików tymczasowych, aby umożliwić poznanie oryginalnego pliku wsadowego miał trochę przetwarzania, a następnie mógł następną część pliku).

Źródło

2012-07-24 21:08:58 SeanC

Okay, więc początkowa funkcjonalność została po prostu pominięta? "call" zostało zaimplementowane, ponieważ ludzie często używali obejść zgodnie z opisem? Nie zastąpiły początkowej funkcjonalności po prostu dla zgodności wstecznej? –

w prawo. Kompatybilność wsteczna pozwala na to, że wiele programów w wersji 3.0 nadal działa przy wygranej 7. Wówczas zakończyłem pisanie niektórych funkcji w asemblerze, aby był to program i mógł wrócić do pliku wsadowego - co jest teraz 'wyborem ', Zaimplementowałem za pomocą prostego programu, który ustawia poziom błędu na wartość ASCII wciśniętego znaku. – SeanC

Na marginesie, funkcja czytania linii, jej wykonywania, czytania innej linii itp. Oznacza, że możesz mieć samodzielnie modyfikujące pliki wsadowe. Nigdy nie robiłem tego celowo - ale jeśli masz plik wsadowy, który sam pobiera (nową wersję) z kontroli wersji, możesz uzyskać dziwne wyniki, gdy wykonuje wersję 1, aż do linii, która wykonuje wyszukiwanie, a następnie kontynuuje z wersją 2. – yoyo

Call mówi po prostu "wykonaj ten drugi plik wsadowy, a następnie wróć tutaj i kontynuuj". Jest tam od czasu DOS 3.3, a jeśli zostałby usunięty, złamałby całą wsteczną kompatybilność (dlatego ludzie wciąż używają skryptów wsadowych). Może być również używany do rozgałęzienia do lokalizacji :link.

Dla informacji na temat stosowania i składni (dla wykorzystania w przyszłości dla innych), można zobaczyć ten MS TechNet link

Jeśli potrzebujesz nowej funkcjonalności, należy CMD skryptów lub skrypty PowerShell zamiast.

Źródło

2012-07-24 20:40:02

Dzięki za odpowiedź, ale to nie jest to, o co prosiłem. Powielono również informacje, które podałem w moim pytaniu. Rozumiem, jak działa "call" i istnieje wiele odniesień dla osób, które tego nie robią. Zastanawiam się, kiedy w inny sposób (nie używając 'call') byłby praktycznie używany w skryptach wsadowych. Dlaczego ktoś chciałby, aby rodzic zatrzymał się bez względu na to, czy plik wsadowy jest zagnieżdżony w innym? –

Utrzymanie stosu miejsca, w którym zostało przerwane, zwiększyłoby rozmiar segmentu pamięci rezydentnej, co ograniczyłoby maksymalny rozmiar programu, który można uruchomić. Po podjęciu tej decyzji nie można jej zmienić, ponieważ spowoduje to, że istniejące pliki wsadowe przestaną działać. –

Jak pisał Sean Cheshire, jest to konieczne ze względu na kompatybilność wsteczną.

Ale uruchomienie pliku wsadowego z pliku wsadowego bez użycia CALL nie kończy rodzica!
Wygląda to tak, ponieważ rodzic zwykle nie wykonuje więcej po wyjściu z drugiej partii.
Jednak użycie połączenia przed rozpoczęciem drugiego pliku .bat spowoduje, że pierwsza partia nie zostanie zakończona.

parent.bat

echo parent.bat 
call :myLabel 
echo back in parent.bat main 
exit /b 

:myLabel 
second.bat & echo back in parent.bat 
exit /b

second.bat

echo second.bat 
exit /b

używam tu w secpond.bat & echo back ... aby uniknąć kolejnego błędu/cechę cmd.exe.
Jeśli użyjesz second.bat bez żadnych dodatków, rozpocznie się second.batI przeskocz na etykietę :myLabel w second.bat!

Źródło

2012-07-25 08:46:02 jeb

Chciałbym zauważyć, że '/ B' został wprowadzony w NT 4 - wcześniej, dostępne były tylko okropne sztuczki programistyczne – SeanC

Dlaczego wywoływanie zagnieżdżonego pliku wsadowego bez uprzedniego wywołania "call" do wiersza kończy macierzysty plik wsadowy?

Odpowiedz

Powiązane problemy