I have batch script that take variable length of arguments as the
input
set BIN_HOME=c:\BIN
set MYSH="d:\files\myarchive*.zip"
%BIN_HOME%\bin\run_my_job.bat -t 556537451 -j "%SH%" -e
mym...@example.com
Contents of run_my_job.bat
REM set some variable class path etc
PERL %BIN_HOME%\bin\run_two_job %*
REM End of script
where %BIN_HOME%\bin\run_two_job is perl script that is expecting the
MYSH as c:\files\myarchive*.zip then it will expand it based on some
internal pattern matching[the content of d:\files would files like
myarchive1.zip,myarchive2.zip etc.,]
the issue here is that the %* is already expanding the d:\files
\myarchive*.zip to all the possible matching files like d:\files
\myarchive1.zip d:\files\myarchive2.zip etc., my run_my_job.bat
option -j expect only one argument terminated by a space. Hence only
d:\files\myarchive1.zip is sent as a input to the perl script (but it
expects d:\files\myarchive*.zip) hence it fails to perform the
correct action.
I see the problem is due to the wildcard expansion by %* , I tried
escaping the * with ^(caret) and \ but nothing seems to be working
my environment is windows 2008 x64 perl 5.8 on cmd.exe
I am looking for some means to get past this issue.
thanks in advance
indira
:: 1.cmd
@echo off
for %%i in (1 2 3) do cd.>test%%i.txt
set args="%~dp0test*.txt"
2.cmd %args%
:: 2.cmd
@echo off
echo %*
echo %args%
del %args%
Output is:
"C:\Full\Path\test*.txt"
"C:\Full\Path\test*.txt"
indira, I also can't reproduce your problem.
I do notice that you are referencing %SH% and not %MYSH% in the batch file
and %BIN_HOME%\bin\run_two_job will resolve to c:\bin\bin\run_two_job
Is that right?
One more issue is that %* in the output below is doubled quoted
""d:\files\myarchive*.zip""
Here are the files I tested it with (replacing %SH% with %MYSH%):
:: my_job.bat
@echo off
set BIN_HOME=c:\BIN
set MYSH="d:\files\myarchive*.zip"
dir /b /s %mysh%
dir /b /s %BIN_HOME%\bin
pause
%BIN_HOME%\bin\run_my_job.bat -t 556537451 -j "%MYSH%" -e
mym...@example.com
:: run_my_job.bat
@echo off
REM set some variable class path etc
echo PERL %BIN_HOME%\bin\run_two_job %*
REM End of script
pause
and the output, also showing that the files exist
d:\files\myarchive1.zip
d:\files\myarchive2.zip
d:\files\myarchive3.zip
c:\BIN\bin\run_my_job.bat
Press any key to continue . . .
PERL c:\BIN\bin\run_two_job -t 556537451 -j
""d:\files\myarchive*.zip"" -e mym...@example.com
Press any key to continue . . .
I'm surprised that Khvatkin and Mic weren't able to reproduce this
because I've experienced it many times. I don't recall what I did to
bypass the problem but it might have involved setting "%*" into a
variable and passing that variable's contents on the command line.
Experiment with different versions of these sort of things:
Set "var=%*"
PERL %BIN_HOME%\bin\run_two_job %var%
For %%a in ('Echo=%*') Do Set "var=%%a"
PERL %BIN_HOME%\bin\run_two_job %var%
Frank
>>Set "var=%*"
>>PERL %BIN_HOME%\bin\run_two_job %var%
But that's another story, is not it? In your example variable was
expanded at first. Originally:
I'm not sure what you mean, but I think you are indicating that the
expansion is being done in both cases so the problem is not solved.
With the solution I worked out long ago the expansion was not performed
and I was able to pass the original string. CMD does not expand %*
everytime it sees it, so the solution is just to find a situation where
it does not and copy the string. From faded memory I'm fairly certain
that expansion is performed in FOR's execution chamber in this
configuration (%*) but possibly not in this ("%*") or this ('Echo=%*')
configuration. I think ('Echo=%*') is more likely. In the case you
quoted above (Set "var=%*") I have no idea if it will work but it is the
simplest form so it is worth trying.
Frank
I think I've tripped over terms so I'll clarify. In this topic there is
replacement -- replacement of the token with the string it represents --
and expansion -- expansion of the wildcards in the variable's string
into filenames existing at the path. I was using expansion for both.
Replacement is normally called expansion but I think here it needs to be
temporarily renamed.
Replacement is always performed and I think expansion is sometimes not
performed.
Frank
Hmm ??? I suppose I misunderstood something.
In my opinion a filename (wildcards) expansion isn't performed in
assignments, echo's, batch executions, only in a for-loop.
It is independent of any %* or other parameters.
Expamle:
foo.bat mytext*.txt
--
echo %*
shows mytext*.txt, but never 'mytext1.txt mytext2.txt mytext3.txt'
The variable expansion of any parameter or variable never expands
wildcards.
The only other problem, I can imagine is the "double" expansion of
special characters.
foo.bat ^^#"^
--- foo.bat
echo foo-a= --%1--
echo foo-b="--%1--"
bar.bat %1
-- bar.bat
echo bar-a= --%1--
echo bar-b="--%1--"
--- Output ---
foo-a= --#"^--
foo-b="--^#"--"
bar-a= --#"^--
bar-b="--#"--"
As a result, in bar.bat in %1 is only #"^ left, instead of the
original string of ^#"^
regards
jeb
> set BIN_HOME=c:\BIN
> set MYSH="d:\files\myarchive*.zip"
> %BIN_HOME%\bin\run_my_job.bat -t 556537451 -j "%SH%" -e
> mym...@example.com
>
> Contents of run_my_job.bat
>
> REM set some variable class path etc
> PERL %BIN_HOME%\bin\run_two_job %*
> REM End of script
Apparently your problem is that the variable "SH" was defined in your
console before you ran the first script. The first script sets the
desired file pattern in "MYSH" then calls the sceond script with the
variable "SH".
Another problem you'll experience when you fix the above problem is that
you are double quoting the file pattern string. With
set MYSH="d:\files\myarchive*.zip"
and
%BIN_HOME%\bin\run_my_job.bat -t 556537451 -j "%MYSH%" -e
the string on the command line becomes
c:\BIN\bin\run_my_job.bat -t 556537451 -j
"d:\files\myarchive*.zip"" -e mym...@example.com
Try it this way instead:
set "MYSH=d:\files\myarchive*.zip"
%BIN_HOME%\bin\run_my_job.bat -t 556537451 -j "%MYSH%" -e
The lead quote of the SET statement was moved to the front of the
variable name.
Frank
> Hmm ??? I suppose I misunderstood something.
I think you misunderstood my understanding. But your misunderstanding
caused me to examine my understanding enough to see that I was incorrect
in my understanding of the behavior of the wildcards. Your message
seemed to be accurate so my memory must have been flawed. Since my
memory was flawed I read the problem again and found what might be the
error.
Thanks again for your well informed input.
Frank
Hmm - seems about right to me.
Let's just hope OP's understanding is no longer misunderstood.