Page 1 of 1

Can SET be filled by a command?

Posted: 29 Apr 2020 06:46
by Shohreh
Hello,

I was wondering if SET can be filled by the output of a command?

I tried this, without success:

Code: Select all

SET count=myapp.exe input.pdf
echo %count
Thank you.

Re: Can SET be filled by a command?

Posted: 29 Apr 2020 07:41
by npocmaka_
the common way is to use for /f:

Code: Select all

for /f "tokens=* delims=" %%# in ('myapp.exe input.pdf') do set "count=%%#"
echo %count%

Re: Can SET be filled by a command?

Posted: 29 Apr 2020 11:17
by dbenham
Yes, FOR /F is generally how it is done.

The only other option is to redirect the output of your command to a temp file, and then read the result with SET /P using redirected input.

Code: Select all

>temp.txt echo Example command output
<temp.txt set /p var=
del temp.txt
echo var=%var%
You might think you could pipe the output of your command into SET /P like so:

Code: Select all

echo This does NOT work|set /p var=
But the pipe doesn't do any good because each side of the pipe is executed in its own temporary cmd.exe process. So although the variable gets set in the child process, the variable disappears as soon as the pipe terminates - there is no way to bring the value back to the parent batch process.


Dave Benham

Re: Can SET be filled by a command?

Posted: 29 Apr 2020 14:05
by Shohreh
Thank you!

Re: Can SET be filled by a command?

Posted: 29 Apr 2020 15:01
by Shohreh
Actually, in the same vein, I also need to call a command that expects a list of files at the end:

Code: Select all

myapp.exe file1.png file2.png etc.
I tried the following, but it's not obviously full of data I don't need.

Code: Select all

FOR /F "delims=" %%a IN ('dir *.png') DO set "name=%%a" & echo %name%
What's a good way to build a list of files?

Re: Can SET be filled by a command?

Posted: 29 Apr 2020 19:04
by Eureka!
Something like this? (not tetsed)

Code: Select all

setlocal enabledelayedexpansion
for %%x in (%__CD__%*) do set LIST=!LIST! "%%x"

echo LIST = %LIST%

Re: Can SET be filled by a command?

Posted: 30 Apr 2020 08:36
by Shohreh
Thanks, it worked.

But it displays 1) the fully qualified filenames (I don't need the path) and 2) it starts by displaying "!LIST! "%__DIR"".

The following gets rid of the path:

Code: Select all

for %%x in (%__dir__%*) do set LIST=!LIST! "%%x"
The following doesn't work, although I need to filter files:

Code: Select all

for %%x in (%__dir *.pdf__%*) do set LIST=!LIST! "%%x"
Do I need to use a for loop, append the output to a text file, and use findstr to read them out?

Code: Select all

for %%# in (*.pdf) do echo %%# >> list.txt
----
Edit: Found this elsewhere:

Code: Select all

SETLOCAL EnableDelayedExpansion
cd /D %~dp0
set _filelist=
for /f "delims=|" %%f in ('dir /b *.pdf') do (
  set "_filelist=!_filelist!%%f "
)
set _filelist=%_filelist:,,=%
echo %_filelist%

Re: Can SET be filled by a command?

Posted: 06 Jun 2021 14:34
by Djann
dbenham wrote:
29 Apr 2020 11:17
Yes, FOR /F is generally how it is done.

The only other option is to redirect the output of your command to a temp file, and then read the result with SET /P using redirected input.

Code: Select all

>temp.txt echo Example command output
<temp.txt set /p var=
del temp.txt
echo var=%var%
You might think you could pipe the output of your command into SET /P like so:

Code: Select all

echo This does NOT work|set /p var=
But the pipe doesn't do any good because each side of the pipe is executed in its own temporary cmd.exe process. So although the variable gets set in the child process, the variable disappears as soon as the pipe terminates - there is no way to bring the value back to the parent batch process.


Dave Benham
Isn't the newly discovered way in use?

Code: Select all

cmd /c "exit 0" 0>&3 4>&3 6>&1 | break
break 0>&6 3>&6
:# This leaves behind: &0=Orig&0, &1=Orig&1, &2=Orig&2, &3=PipeIn, &4=PipeOut, &6=Orig&0

>&4 echo From another child		&:# Write to pipe
<&3 set /p "READ="			&:# Read value from pipe
echo Read on pipe: %READ%
Re: Directly reading from pipe by the parent CMD process

As I understood, the need to determine free pipe handles was the main reason why the new way wasn't discussed here