handling the spaces of file paths in batch file that read out from a file

I am reading the path of files over a file paths.lst in a for loop and looking for a 'Value' parameter to be replaced in particular xml files.

The content of the paths.lst file is as follows:

C:\Users\ect\doc doc\test dir\conf\{testdir1}\test.xml
C:\Users\ect\doc doc\test dir\conf\{testdir2}\test.xml
C:\Users\ect\docdoc\testdir\conf\{testdir3}\test.xml

@echo off

for /f %%i in (paths.lst) do call :$change %%i
REM exit

:$change
set filePath='%1'
echo Value changed for:'%filePath%'
set fold='Value=\"0\"'
set fnew='Value=\"1\"'
powershell -Command "(gc %filePath%) -replace %fold%, %fnew% | Out-File %filePath% -encoding utf8"

The first and second paths can not be read out, due to empty spaces, but the script works for the third path C:\Users\ect\docdoc\testdir\conf\{testdir3}\test.xml

You need to:

• replace for /f %%i with for /f "delims=" %%i so as to read each whole line (otherwise the default delimiters are tab and space)
• replace call :$change %%i with call :$change "%%i" so as to pass quoted filenames to your subroutine
• within the subroutine you might need to replace %1 with "%~1". With the tilde you strip any double quotes if they existed, and then you add new ones.

<!-- language-all: sh -->

Mike Nakis' helpful answer covers the cmd.exe side of things well.

Let me address the PowerShell side of things:

• { and } are metacharacters in PowerShell, so a file path such as C:\Users\ect\doc doc\test dir\conf\{testdir1}\test.xml is not taken literally if used unquoted as a command argument in PowerShell code.

  • Therefore, gc %filePath% will fail with such paths.

• PowerShell's initial command-line parsing removes the \ from \" sequences, so that 'Value=\"0\"' is seen as verbatim 'Value="0"' when the PowerShell code executes.

  • It just so happens that in the context of a regex (as used by -replace) that is specified via a PowerShell '...' string literal, these two values are equivalent (" chars. don't require escaping in regexes, though escaping them does no harm), but it is something to be aware of.

• A simple way to avoid quoting and escaping headaches is to rely on the fact that cmd.exe's variables (created with set) are invariably also environment variables, which PowerShell therefore inherits; e.g., the value of fold (%fold%) can be accessed via $env:fold in the PowerShell code. This indirect way of referencing the value provides robust access to its verbatim value.

• You can then focus on setting the variable values without needing to use '...' quoting for the benefit of PowerShell.

  • The most robust way to set arbitrary values in a cmd.exe SET statement is to enclose the name, =, and value in "..." overall; e.g., to make fold contain verbatim Value=\"0\", use set "fold=Value=\"0\""
  • As noted, the ~ in %~1 removes any enclosing " that are part of the value, so that set "filePath=%~1" robustly stores the unquoted path in filePath.

To put it all together:

@echo off & setlocal

:: Note the "delims=" and the %%i enclosed in "..."
for /f "delims=" %%i in (paths.lst) do call :$change "%%i"
goto :EOF

:$change
  :: Note the "..." around the name, "=", and the value *overall*.
  :: No need for '...' quoting.
  set "filePath=%~1"
  set "fold=Value=\"0\""
  set "fnew=Value=\"1\""
  :: Note the $env: references to the variables defined above.
  powershell -Command "(gc $env:filePath) -replace $env:fold, $env:fnew | Out-File $env:filePath -encoding utf8"
  echo Value changed for: "%filePath%"
goto :EOF