Mam which.bat na Windows 7,
@echo off
REM This bat searches a file in PATH list to see whether a file can be found.
REM If found, it shows the file's full path.
REM which.bat gcc.exe
REM shows
REM gcc.exe is found: D:\GMU\MinGW2\bin\gcc.exe
REM
REM Note: Filename extension is significant in the search. E.g. If you run
REM which.bat gcc
REM gcc.exe will not be matched.
IF "%1" == "" goto END
IF "%~$PATH:1" == "" (
echo %1 is not found in any directories from PATH env-var.
) ELSE (
echo %1 is found: %~$PATH:1
)
:END
ten bat działa dobrze, dopóki nie znajdę dziwne zachowanie dzisiaj.
Jest plik O:\temp\pfiles (x86)\mystuff.txt
i PATH ma zawartość:
PATH=O:\temp\pfiles (x86);D:\CmdUtils
Running which mystuff.txt
, mam bardzo dziwne wyjściowe:
\mystuff.txt was unexpected at this time.
po pewnym wywiercenie , Uważam, że nazwa katalogu (x86)
powoduje, że th e problem. Aby obejść ten problem, muszę dodać cytaty do echo
, tak:
echo %1 is found: "%~$PATH:1"
Wadą takiego dostrojenia jest oczywista: Cytaty są drukowane na ekranie, co nie zawsze jest pożądane w opinii programisty.
Czy ktoś może pomóc wyjaśnić to dziwne zachowanie?
Problem ten znajduję, ponieważ w moim prawdziwym środowisku mam ścieżki takie jak C:\Program Files (x86)\Common Files\NetSarang
w PATH, które wykazują dokładnie ten sam objaw.
Dziękuję za poinformowanie mnie. '' where.exe'' jest świetny. Używam which.bat od Windows XP, gdzie nie ma jeszcze '' where.exe''. –
dobre informacje ... ale jeśli szukasz "pliku wykonywalnego" i nie zapewniasz rozszerzenia, to nie działa ... użyj "where.exe", a następnie ... lub "które" jeśli jesteś w systemie Linux ... lub wystarczy zainstalować Cygwin i użyć "co" ... działa świetnie !!! – ZEE