• Interesting quirk of Windows on how it handles the "echo." command

    From Marion@3:633/280.2 to All on Sun Aug 24 15:52:20 2025
    Interesting quirk of Windows on how it handles the "echo." command.

    1. I was getting errors from "echo." only in some batch circumstances.
    2. The "echo." works fine when the batch file is run from the RunBox.
    3. But the "echo." erred when the batch file is run from the cmd line.
    'echo.' is not recognized as an internal or external command,
    operable program or batch file.

    HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\proxy.exe Default=C:\sys\bat\proxy.bat

    When I ran proxy from the RunBox using the App Paths key, Windows treated proxy.bat as if it's an executable, not a batch script. This causes it to
    be launched via cmd.exe /c, but without the usual batch file context and
    that changed how certain commands behave.

    The command "echo." is a common way to print a blank line in batch scripts.
    But when the batch file is run as if it's an executable, quirks emerge.

    Apparently "echo." is interpreted literally as a command named echo. (with
    a dot), which doesn't exist.

    Normally, cmd.exe understands echo. as a special syntax for a blank line,
    but this behavior can break when the batch file is launched outside of a
    proper batch context.

    To confirm how the script was being launched, I added this line:
    echo %cmdcmdline%

    That showed how cmd.exe is invoking the script.
    Win+R > proxy
    C:\Windows\system32\cmd.exe /c ""C:\sys\bat\proxy.bat" "

    Note that it's wrapped in extra quotes.
    ""C:\data\sys\bat\proxy.bat" "
    That's a subtle but critical problem.
    The double quotes (""..."") confused cmd.exe.

    So how do I fix it?

    This won't work in the App Paths registry key as it treats the entire
    line as the name of the file.
    Option 1: Use cmd /c in App Paths
    Default = cmd.exe /c "C:\sys\bat\proxy.bat"

    That's because the App Paths key is designed to map a command name (like
    proxy) to a full executable path, not to a command line with arguments or a shell invocation like cmd.exe /c.

    Option 2: This should work but then I'd have to modify the batch file.
    Replace echo. with echo(

    Option 3: So I just renamed the .bat file to a .cmd file.
    Windows treats .cmd files more consistently as command scripts.

    And then I created a shortcut pointing to that .cmd file.
    C:\sys\lnk\proxy.lnk
    TARGET C:\Windows\System32\cmd.exe /c "C:\sys\cmd\proxy.cmd"

    But it inherited batch window modifications so I had to set the properties
    on the shortcut to be a different color, position & font which was easy,
    such as "Let system position window".

    Voila!
    Now the "proxy" batch script (now a cmd script) works perfectly no matter
    how it's run, whether from the command line or from the Runbox via the App Paths key!

    Here's the full proxy.cmd script (previously named proxy.bat).

    =====< cut below for proxy.cmd (previously proxy.bat) >=====
    @echo off
    echo %cmdcmdline%
    REM proxy.cmd 20250820 v1.3 (previously named proxy.bat)
    REM Use model: "Win+R > proxy" (proxy import if WinHTTP is unset)
    REM Unified Windows proxy diagnostic tool with WinHTTP sync safeguard
    REM "Win+R > proxy /sync imports WinINET proxy directly into WinHTTP
    REM Reports: WinINET manual proxy, WinHTTP proxy, PAC/AutoDetect
    REM HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\proxy.exe
    REM Default=C:\sys\lnk\proxy.lnk
    REM TARGET=C:\Windows\System32\cmd.exe /c "C:\sys\cmd\proxy.cmd"
    REM (previously Default=C:\sys\bat\proxy.bat )
    REM That App Paths key creates the convenient "Win+R > proxy" command
    REM
    setlocal

    :: --- Quick /sync mode ---
    if /i "%~1"=="/sync" (
    echo Syncing WinINET proxy into WinHTTP...
    netsh winhttp import proxy source=ie
    echo Done.
    pause
    exit /b
    )

    set KEY="HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings"

    echo ==============================================
    echo WINDOWS PROXY CONFIGURATION SET/CHECK/FIX
    echo ==============================================

    REM --- WinINET (manual proxy) ---
    echo.
    echo [1] WinINET / Internet Settings
    for /f "tokens=2,* skip=2" %%A in ('reg query %KEY% /v ProxyEnable
    nul') do set ProxyEnable=%%B
    for /f "tokens=2,* skip=2" %%A in ('reg query %KEY% /v ProxyServer
    nul') do set ProxyServer=%%B
    if "%ProxyEnable%"=="0x1" (
    echo Proxy is ENABLED
    echo Proxy server: %ProxyServer%
    ) else (
    echo Proxy is DISABLED
    )

    REM --- WinHTTP proxy ---
    echo.
    echo [2] WinHTTP proxy (system/background services)

    REM Get current WinHTTP proxy setting
    for /f "tokens=1,* delims=:" %%A in ('netsh winhttp show proxy ^| findstr
    /R /C:"Proxy Server(s)"') do set curWinHTTP=%%B

    REM Trim leading/trailing spaces
    set curWinHTTP=%curWinHTTP:~1%

    if "%curWinHTTP%"=="" (
    echo No WinHTTP proxy set - importing from WinINET...
    netsh winhttp import proxy source=ie >nul 2>&1
    ) else (
    echo WinHTTP proxy already set - leaving as is.
    )

    REM Show current WinHTTP proxy after check/import
    netsh winhttp show proxy

    REM --- PAC (Proxy Auto-Config) & AutoDetect ---
    echo.
    echo [3] PAC / AutoDetect
    for /f "tokens=2,* skip=2" %%A in ('reg query %KEY% /v AutoConfigURL
    nul') do set PACurl=%%B
    for /f "tokens=2,* skip=2" %%A in ('reg query %KEY% /v AutoDetect 2^>nul')
    do set AutoDetect=%%B

    if defined PACurl (
    echo PAC script set: %PACurl%
    ) else (
    echo No PAC script URL found.
    )

    if "%AutoDetect%"=="0x1" (
    echo Auto-detect is ENABLED
    ) else (
    echo Auto-detect is DISABLED
    )

    echo.
    echo ==============================================
    echo Windows proxy set/check/fix complete.
    echo ==============================================

    endlocal
    pause

    =====< cut above for proxy.cmd (previously proxy.bat) >=====

    --- MBSE BBS v1.1.2 (Linux-x86_64)
    * Origin: BWH Usenet Archive (https://usenet.blueworldho (3:633/280.2@fidonet)
  • From R.Wieser@3:633/280.2 to All on Mon Aug 25 16:49:21 2025
    Subject: Re: Interesting quirk of Windows on how it handles the "echo." command

    Arlen,

    3. But the "echo." erred when the batch file is run from the
    cmd line.
    'echo.' is not recognized as an internal or external command,
    operable program or batch file.

    Have you checked if that command is actually the culprit ?

    You should get the same error message when "echo." is the only line in the batchfile. If not than something else is going on.

    This causes it to be launched via cmd.exe /c, but without
    the usual batch file context and that changed how certain
    commands behave.

    What is, according to you, a "batch file context" ?

    Also, the "echo" command is an internal one. As long as cmd.exe is
    executing the batch file its available.

    Furthermore, its possible that although "echo." is mentioned as the culprit the actual error is in one of the lines just before it.

    Have you tried to place a space between "echo" and "." ? What happens ?
    What happens when you put another command ("echo [%comspec%]", "dir *.*", etc.) just before the "echo." commands in your batchfile ?

    iow, you have found a work-around for the problem, but you have not found
    the problem itself. It could hit you again at any time.

    Regards,
    Rudy Wieser

    p.s.
    I wrote "[%comspec%]" and ment it that way, including the brackets. If the enclosed variable doesn't contain anything you should /at least/ get two brackets. In the case it contains one (or more!) spaces you will see that too.



    --- MBSE BBS v1.1.2 (Linux-x86_64)
    * Origin: A noiseless patient Spider (3:633/280.2@fidonet)