Rectangle 27 0

batch file (' findstr b "URL=" "%~1" ') not working with ö,ä,ü in path or filename?


@echo off
for /F "usebackq tokens=1* delims==" %%a in ("%~1") do (
    if /I "%%a"=="URL" (
        set "URL=%%b"
        goto FoundURL
    )
)
echo No URL found.
goto :EOF

:FoundURL
echo URL found: %URL%
@echo off
set "URL="
for /F "delims=" %%a in ('%SystemRoot%\System32\findstr.exe /b "URL=" "%~1" 2^>nul') do set "URL=%%a"

if "%URL%"=="" goto Chrome

rem Remove URL= from string value.
set "URL=%URL:~4%"

echo URL found: %URL%
goto :EOF

:Chrome
echo No URL found.
D:\4all\reisen\istanbul\verkehr\fhren\Bosp_eminn_2h_14h30_12tl_SehirHatlari.url
URL=https://stackoverflow.com/
for /f "delims=" %%a in ('findstr /b "URL=" "%~1"') do set URL="%%a"
echo. %URL% | FIND /I "URL=">Nul || (set URL=""&goto chrome)
set "variable=value with spaces"
set variable="value with spaces"

Can it be that windows passes parameters differently depending on whether it calls .bat or .exe?

Edit after questioner provided additional information about how batch file is called.

  • and lots of other web pages and documentations.

"%1" in a file association is a placeholder for an argument, usually the name of a file or directory.

"%L" can be used instead of "%1" for a file association in HKEY_CLASSES_ROOT in Windows registry if Windows should pass a file or directory name always in long format and never in short format to an application. This is sometimes needed if an application is a hybrid like a C/C++ console application compiled with DJGPP which is a 16-bit application, but supports nevertheless long ANSI encoded file names because of special startup code.

A string in double quotes is parsed by default directly when using for with parameter /F. But for this task a file with full path specified in double quotes must be parsed. Therefore usebackq is used to change for behavior on string parsing to get file name with path in double quotes interpreted as name of a file to parse.

ANSI strings use an array of type char in C/C++ coded applications for Windows while an array of type wchar_t is used for Unicode strings. Details for C/C++ programmers for Windows can be found

But back to the question: Yes, of course, Windows passes file and directory names differently to a batch file or an executable depending on header of the executable, i.e. which type of application it is and which type of strings it supports.

But in console windows by default OEM code page 850 is used in German countries.

Command chcp means change code page and can be therefore used to switch the code page for active command prompt.

In German countries the code page used on GUI for non Unicode strings is Windows-1252.

In case of for loop finishes normally, there is no line in *.url file starting with URL= in any case. Then the result is an appropriate information message before batch file is exited with goto :EOF (EOF - end of file - a nowadays always existing because predefined label).

It can be seen on comparing the two tables that the German umlauts have different byte values in those two code pages which explains what you see.

It looks like the used bat to exe converter creates a 64-bit console application which is Unicode aware. So this application must convert correct the Unicode string to an ANSI string using the system locale of the user account on passing file and directory names and other arguments to the command finally running the embedded batch file. And it looks like this converter makes this Unicode to ANSI conversion task or the creation of the command line to run the batch file not 100% correct.

Much easier to read and faster on execution would be:

Next this batch file is only interested in the line:

Otherwise the found URL is output before also exiting this demo batch file.

Removing URL= case-insensitive is now much easier as the double quotes are not part of string value assigned to variable URL because of quoting value assignment to variable right.

Run in a command prompt window for /? for help on this command.

So delims== is used to split up each line into strings with using equal sign as delimiter.

THX for your detailed answer ! Do you know a converter doing the conversion right in this case ?

The *.url file is parsed now directly by command line interpreter with for instead of using findstr.

The code page used by default in console windows can be seen by opening a command prompt window and run there either command chcp without any parameter or command mode without any parameter. In both cases the used code page is output in console window.

The correct positioning of first double quote is:

There are now 3 possibilities for Windows to pass a directory or file name to an application:

Therefore I suggest a much easier batch solution for this task:

This assigns "value with spaces" and everything else up to end of line like trailing spaces to variable.

This assigns just value with spaces to variable independent on trailing spaces or tabs on this line.

This batch file called within a command prompt window with

Wanted is the string left to first equal sign and everything right of first equal sign which of course could contain also 1 or more equal signs. We get exactly that split behavior with tokens=1*. The string left to first equal sign is token 1 which is assigned to loop variable a while everything else after first equal sign is token 2 which is assigned to loop variable b.

What you have to do in the batch file depends on which encoding is used for file name string passed as parameter to the batch file.

With a case-insensitive comparison of string left to equal sign with string URL a check is made if line of interest is found in the file. In this case token 2 being the URL string is assigned to environment variable URL and the loop is exited with a jump to a label as there is no need to further parse the remaining lines of the file.

findstr is not needed for this task. Usage of findstr just makes the batch file slower and more complex than necessary.

or from Windows Explorer has no problem to open the file with the German umlauts and parse it.

Note
Rectangle 27 0

batch file (' findstr b "URL=" "%~1" ') not working with ö,ä,ü in path or filename?


@echo off
for /F "usebackq tokens=1* delims==" %%a in ("%~1") do (
    if /I "%%a"=="URL" (
        set "URL=%%b"
        goto FoundURL
    )
)
echo No URL found.
goto :EOF

:FoundURL
echo URL found: %URL%
@echo off
set "URL="
for /F "delims=" %%a in ('%SystemRoot%\System32\findstr.exe /b "URL=" "%~1" 2^>nul') do set "URL=%%a"

if "%URL%"=="" goto Chrome

rem Remove URL= from string value.
set "URL=%URL:~4%"

echo URL found: %URL%
goto :EOF

:Chrome
echo No URL found.
D:\4all\reisen\istanbul\verkehr\fhren\Bosp_eminn_2h_14h30_12tl_SehirHatlari.url
URL=https://stackoverflow.com/
for /f "delims=" %%a in ('findstr /b "URL=" "%~1"') do set URL="%%a"
echo. %URL% | FIND /I "URL=">Nul || (set URL=""&goto chrome)
set "variable=value with spaces"
set variable="value with spaces"

Can it be that windows passes parameters differently depending on whether it calls .bat or .exe?

Edit after questioner provided additional information about how batch file is called.

  • and lots of other web pages and documentations.

"%1" in a file association is a placeholder for an argument, usually the name of a file or directory.

"%L" can be used instead of "%1" for a file association in HKEY_CLASSES_ROOT in Windows registry if Windows should pass a file or directory name always in long format and never in short format to an application. This is sometimes needed if an application is a hybrid like a C/C++ console application compiled with DJGPP which is a 16-bit application, but supports nevertheless long ANSI encoded file names because of special startup code.

A string in double quotes is parsed by default directly when using for with parameter /F. But for this task a file with full path specified in double quotes must be parsed. Therefore usebackq is used to change for behavior on string parsing to get file name with path in double quotes interpreted as name of a file to parse.

ANSI strings use an array of type char in C/C++ coded applications for Windows while an array of type wchar_t is used for Unicode strings. Details for C/C++ programmers for Windows can be found

But back to the question: Yes, of course, Windows passes file and directory names differently to a batch file or an executable depending on header of the executable, i.e. which type of application it is and which type of strings it supports.

But in console windows by default OEM code page 850 is used in German countries.

Command chcp means change code page and can be therefore used to switch the code page for active command prompt.

In German countries the code page used on GUI for non Unicode strings is Windows-1252.

In case of for loop finishes normally, there is no line in *.url file starting with URL= in any case. Then the result is an appropriate information message before batch file is exited with goto :EOF (EOF - end of file - a nowadays always existing because predefined label).

It can be seen on comparing the two tables that the German umlauts have different byte values in those two code pages which explains what you see.

It looks like the used bat to exe converter creates a 64-bit console application which is Unicode aware. So this application must convert correct the Unicode string to an ANSI string using the system locale of the user account on passing file and directory names and other arguments to the command finally running the embedded batch file. And it looks like this converter makes this Unicode to ANSI conversion task or the creation of the command line to run the batch file not 100% correct.

Much easier to read and faster on execution would be:

Next this batch file is only interested in the line:

Otherwise the found URL is output before also exiting this demo batch file.

Removing URL= case-insensitive is now much easier as the double quotes are not part of string value assigned to variable URL because of quoting value assignment to variable right.

Run in a command prompt window for /? for help on this command.

So delims== is used to split up each line into strings with using equal sign as delimiter.

THX for your detailed answer ! Do you know a converter doing the conversion right in this case ?

The *.url file is parsed now directly by command line interpreter with for instead of using findstr.

The code page used by default in console windows can be seen by opening a command prompt window and run there either command chcp without any parameter or command mode without any parameter. In both cases the used code page is output in console window.

The correct positioning of first double quote is:

There are now 3 possibilities for Windows to pass a directory or file name to an application:

Therefore I suggest a much easier batch solution for this task:

This assigns "value with spaces" and everything else up to end of line like trailing spaces to variable.

This assigns just value with spaces to variable independent on trailing spaces or tabs on this line.

This batch file called within a command prompt window with

Wanted is the string left to first equal sign and everything right of first equal sign which of course could contain also 1 or more equal signs. We get exactly that split behavior with tokens=1*. The string left to first equal sign is token 1 which is assigned to loop variable a while everything else after first equal sign is token 2 which is assigned to loop variable b.

What you have to do in the batch file depends on which encoding is used for file name string passed as parameter to the batch file.

With a case-insensitive comparison of string left to equal sign with string URL a check is made if line of interest is found in the file. In this case token 2 being the URL string is assigned to environment variable URL and the loop is exited with a jump to a label as there is no need to further parse the remaining lines of the file.

findstr is not needed for this task. Usage of findstr just makes the batch file slower and more complex than necessary.

or from Windows Explorer has no problem to open the file with the German umlauts and parse it.

Note