how to pass commandline arguments that with blank space to a batch file?
thinktwice
contains blank space.
at first i thought maybe i could add quote around the arguments, but
it proved to be failed.
mybatch.bat "D:\some folder\sub folder"
i get this error "folder\sub was unexpected at this time". how to get
round this? thanks in advance
foxidrive
wrote:
>i need to pass a folder path to a batch file ,as we know it may
>contains blank space.
>
>at first i thought maybe i could add quote around the arguments, but
>it proved to be failed.
>
>mybatch.bat "D:\some folder\sub folder"
That is correct.
>i get this error "folder\sub was unexpected at this time". how to get
>round this? thanks in advance
We'd have to see your batch file to analyse where the problem is.
thinktwice
> On Wed, 4 Jun 2008 04:15:21 -0700 (PDT), thinktwice <memorial...@gmail.com>
> wrote:
>
> >i need to pass a folder path to a batch file ,as we know it may
> >contains blank space.
>
> >at first i thought maybe i could add quote around the arguments, but
> >it proved to be failed.
>
> >mybatch.bat "D:\some folder\sub folder"
>
> That is correct.
>
> >i get this error "folder\sub was unexpected at this time". how to get
> >round this? thanks in advance
>
> We'd have to see your batch file to analyse where the problem is.
sorry, haven't logged in for server days.
seems i can't add quote around the parameter.
if "%1" == "" @echo Usage: check_dir Path
billious
Batch interprets space, comma and semicolon as separators where the argument
string is unquoted.
Try
if "%*"=="" echo .....
foxidrive
wrote:
Also try this.
if "%~1"=="" @echo Usage: check_dir Path
Todd Vargo
> billious wrote:
> >thinktwice wrote:
> >>
> >> seems i can't add quote around the parameter.
> >> if "%1" == "" @echo Usage: check_dir Path
> >
> >Batch interprets space, comma and semicolon as separators where the
argument
> >string is unquoted.
> >
> >Try
> >
> >if "%*"=="" echo .....
> >
>
> Also try this.
>
> if "%~1"=="" @echo Usage: check_dir Path
And this.
if (%~1)==() @echo Usage: check_dir Path
--
Todd Vargo
(Post questions to group only. Remove "z" to email personal messages)
foxidrive
wrote:
>foxidrive wrote:
>> billious wrote:
>> >thinktwice wrote:
>> >>
>> >> seems i can't add quote around the parameter.
>> >> if "%1" == "" @echo Usage: check_dir Path
>> >
>> >Batch interprets space, comma and semicolon as separators where the
>argument
>> >string is unquoted.
>> >
>> >Try
>> >
>> >if "%*"=="" echo .....
>> >
>>
>> Also try this.
>>
>> if "%~1"=="" @echo Usage: check_dir Path
>
>And this.
>
>if (%~1)==() @echo Usage: check_dir Path
That will fail if %1 contains spaces etc Todd.
Todd Vargo
I forgot to remove the tilde.
Dean Wells (MVP)
news:uJHbABY0...@TK2MSFTNGP05.phx.gbl...
... it'll still fail under the same condition.
--
Dean Wells [MVP / Directory Services]
MSEtechnology
[[ Please respond to the Newsgroup only regarding posts ]]
R e m o v e t h e m a s k t o s e n d e m a i l
Dean Wells (MVP)
news:eTO7dTY...@TK2MSFTNGP06.phx.gbl...
My mistake ... didn't think that through sufficiently; that'll work.
Al Dunbar
Yes, when comparing to a null string such as ().
But in the general case where a parameter could be supplied by dragging and
dropping a file, this does not account for the fact that double quotes will
be added only when required. I prefer the "%~1" method because it strips the
double quotes that may be present, relieving me from having to remember
whether or not the double quotes are required to the string literal being
compared.
/Al
Dean Wells (MVP)
news:eWhCSNp...@TK2MSFTNGP06.phx.gbl...
... try that in Vista; pooooof, where'd that feature go.
Todd Vargo
...
Quoted or not quoted is irrelevant in this case. The problem (as OP found)
comes in when you try enclosing a quoted string in quotes. Personally, I do
not have a preference toward either method. My preference is to understand
how each method works so either can be used.
If command given is: file.bat "foo bar"
%1 will expand as follows...
if ""foo bar""=="" <-- This will error
if ("foo bar")==() <-- this will not error
However, %~1 will expand as follows...
if "foo bar"=="" <-- This will not error
if (foo bar)==() <-- but this will error
OTOH, %~1 only strips outer quotes, so all bets are off with strings with
nested quotes.
Herb Martin
"Todd Vargo" <tlv...@sbcglobal.netz> wrote in message
I have been lurking, fascinated by this discussion and trying to
understand where it will solve some problems I have experienced
so first:
THANK YOU
Ignoring nexted quotes -- where will the following go wrong?
@echo off
echo %1
echo %~1
echo "%1"
echo "%~1"
if ("%~1")==("") echo blank
if /i ("%~1")==("help me") echo Help me Help me
Al Dunbar
"Herb Martin" <ne...@learnquick.com> wrote in message
news:OkdSs1y0...@TK2MSFTNGP05.phx.gbl...
the simple answer is that the below code will not go wrong, but do precisely
what it was intended to do - assuming that it was coded as intended... ;-)
First, I'd suggest using "echo/" instead of "echo", because if the value to
be displayed could possibly be null or blank, the output will not be a blank
line, but one containing either "ECHO is on." or "ECHO is off." this applies
to the first two lines, but I include the "/" exclusively so I do not have
to do the mental gymnastics required to figure out when it is for sure not
needed.
>
> @echo off
> echo %1
see above
> echo %~1
see above
> echo "%1"
no problem, but if the passed parameter is quoted, this output will be
double-quoted.
> echo "%~1"
no problem, assuming it will echo the way you want it to.
> if ("%~1")==("") echo blank
no problem for the simple case of arguments like these:
call sub
call sub ""
call sub a
call sub "a"
call sub "a b"
That said, I expect that there might be some values with which this might
choke, for example:
call sub "a "b"
Personally, I find I have fewer problems if I leave off the parens on both
sides, but others seem to disagree.
> if /i ("%~1")==("help me") echo Help me Help me
seems no more useful to me than:
if /i "%~1"=="help me" echo Help me Help me
/Al
Al Dunbar
I did not know that, thanks. I guess that when I eventually start using
Vista, much of my batch scripting will be converted over to powershell, so I
won't have to worry too much about such incompatible annoyances ;-)
/Al
Al Dunbar
"Todd Vargo" <tlv...@sbcglobal.netz> wrote in message
> Al Dunbar wrote:
> ...
<snip>
>> Yes, when comparing to a null string such as ().
>>
>> But in the general case where a parameter could be supplied by dragging
> and
>> dropping a file, this does not account for the fact that double quotes
> will
>> be added only when required. I prefer the "%~1" method because it strips
> the
>> double quotes that may be present, relieving me from having to remember
>> whether or not the double quotes are required to the string literal being
>> compared.
>
> Quoted or not quoted is irrelevant in this case. The problem (as OP found)
> comes in when you try enclosing a quoted string in quotes.
Agreed that, yes, that is a problem. Which is why I strip them (i.e. the
outer ones) using "%~1".
> Personally, I do
> not have a preference toward either method. My preference is to understand
> how each method works so either can be used.
Fair enough. But I have been able to accomplish everything I need to in
terms of parameter handling (or any other string comparisons) using double
quotes exclusively and never parentheses. Given that I use one method over
the other, I am less likely to run into the quirks of the one I am somewhat
less comfortable with.
Of course, if I was in a position where supporting others' code was a
requirement, I might have to expand my understanding and comfort level
beyond where it is located now... ;-)
>
> If command given is: file.bat "foo bar"
>
> %1 will expand as follows...
>
> if ""foo bar""=="" <-- This will error
>
> if ("foo bar")==() <-- this will not error
Conclusion: avoid "%1".
> However, %~1 will expand as follows...
>
> if "foo bar"=="" <-- This will not error
>
> if (foo bar)==() <-- but this will error
Conclusion: avoid (%~1).
> OTOH, %~1 only strips outer quotes, so all bets are off with strings with
> nested quotes.
Agreed. But this will never happen (as far as I can tell) when a file is
dragged onto a batch script.
Also, "nested quotes" is, to me, a misnomer. I would have said "internal
quotes". Given that this is handled poorly and possibly inconsistently by
batch, one would seem foolish to expect batch code dealing with complicated
string expressions that push the boundaries from ever being fully understood
or adequately debugged.
In some languages doubling double quotes within a literal string is a
standard way to represent a single double quote. For example, in vbscript:
qstring = "a word in ""quotes"""
wscript.echo "[" & qstring & "]"
will produce this output: [a word in "quotes"]. The batch language seems to
lack this level of sophistication and consistency, such that the actual or
intended meaning of a string containing a variety of double quotes is in
question in the first place.
/Al
Dean Wells (MVP)
Vista and Powershell huh? The reality is that they're not quite as
hand-in-hand as you seem to imply ... at least to date ... but that's a
much, much longer topic of discussion ...
Herb Martin
"Al Dunbar" <Alan...@hotmail.com.nospaam> wrote in message
>
> "Herb Martin" <ne...@learnquick.com> wrote in message
> news:OkdSs1y0...@TK2MSFTNGP05.phx.gbl...
>>
>> "Todd Vargo" <tlv...@sbcglobal.netz> wrote in message
>> news:%232aMSKy...@TK2MSFTNGP04.phx.gbl...
>>> Al Dunbar wrote:
>>> ...
>>> the
>>>> >>>> >argument
>>>> >>>> >> >string is unquoted.
>>>> >>>> >> >
>>>> >>>> >> >Try
>>>> >>>> >> >
>>>> >>>> >> >if "%*"=="" echo .....
>>>> >>>> >> >
>>>> >>>> >>
>>>> >>>> >> Also try this.
>>>> >>>> >>
>>>> >>>> >> if "%~1"=="" @echo Usage: check_dir Path
>>>> >>>> >
>>>> >>>> >And this.
>>>> >>>> >
>>>> >>>> >if (%~1)==() @echo Usage: check_dir Path
>>>> >>>>
>>>> >>>> That will fail if %1 contains spaces etc Todd.
>>>> >>>
>>>> >>> I forgot to remove the tilde.
>>>> >>>
>>>> >>> --
>>>> >>> Todd Vargo
>>>> >>> (Post questions to group only. Remove "z" to email personal
>>>> >>> messages)
>>>> >>
>>>> >> ... it'll still fail under the same condition.
>>>> dropping a file, this does not account for the fact that double quotes
Ok -- good advice and I will use it -- here though they were just display
for debugging test purposes...
>> @echo off
>> echo %1
> see above
>> echo %~1
> see above
>> echo "%1"
> no problem, but if the passed parameter is quoted, this output will be
> double-quoted.
>> echo "%~1"
> no problem, assuming it will echo the way you want it to.
>> if ("%~1")==("") echo blank
> no problem for the simple case of arguments like these:
>
> call sub
> call sub ""
> call sub a
> call sub "a"
> call sub "a b"
>
> That said, I expect that there might be some values with which this might
> choke, for example:
>
> call sub "a "b"
Not a problem -- I just want something that works reliably in the fairly
normal cases of:
simple argument
multiple arguments
quoted (enclosed once) arguments
no arguments (blan)
> Personally, I find I have fewer problems if I leave off the parens on both
> sides, but others seem to disagree.
The parens were a new idea to me so I put them in by copying
the previous discussion without fully understanding the intent,
advantages or disadvantages.
>> if /i ("%~1")==("help me") echo Help me Help me
> seems no more useful to me than:
>
> if /i "%~1"=="help me" echo Help me Help me
>
> /Al
The main thing was to use your ~trick to get rid of the
existing quotes to allow for the additiona of new (safety)
quotes.
Todd Vargo
"Al Dunbar" <Alan...@hotmail.com.nospaam> wrote in message
>
> "Todd Vargo" <tlv...@sbcglobal.netz> wrote in message
> news:%232aMSKy...@TK2MSFTNGP04.phx.gbl...
> > OTOH, %~1 only strips outer quotes, so all bets are off with strings
with
> > nested quotes.
>
> Agreed. But this will never happen (as far as I can tell) when a file is
> dragged onto a batch script.
Agreed, OP that started this thread did not state draging was the mode of
usage. People do type commands at the prompt, drag files and folders or even
paste into the prompt and can easily lose track quoting, especially when a
command at the prompt spans multiple lines.
>
> Also, "nested quotes" is, to me, a misnomer. I would have said "internal
> quotes". Given that this is handled poorly and possibly inconsistently by
> batch, one would seem foolish to expect batch code dealing with
complicated
> string expressions that push the boundaries from ever being fully
understood
> or adequately debugged.
>
> In some languages doubling double quotes within a literal string is a
> standard way to represent a single double quote. For example, in vbscript:
>
> qstring = "a word in ""quotes"""
> wscript.echo "[" & qstring & "]"
>
> will produce this output: [a word in "quotes"]. The batch language seems
to
> lack this level of sophistication and consistency, such that the actual or
> intended meaning of a string containing a variety of double quotes is in
> question in the first place.
You are preaching to the choir. ;-)
Al Dunbar
"Todd Vargo" <tlv...@sbcglobal.netz> wrote in message
>
> "Al Dunbar" <Alan...@hotmail.com.nospaam> wrote in message
> news:uyHLEHz0...@TK2MSFTNGP02.phx.gbl...
>>
>> "Todd Vargo" <tlv...@sbcglobal.netz> wrote in message
>> news:%232aMSKy...@TK2MSFTNGP04.phx.gbl...
> ...
>> > OTOH, %~1 only strips outer quotes, so all bets are off with strings
> with
>> > nested quotes.
>>
>> Agreed. But this will never happen (as far as I can tell) when a file is
>> dragged onto a batch script.
>
> Agreed, OP that started this thread did not state draging was the mode of
> usage. People do type commands at the prompt, drag files and folders or
> even
> paste into the prompt and can easily lose track quoting, especially when a
> command at the prompt spans multiple lines.
Understood. Technically, one should probably consider writing one's code to
process only valid input, and flag the invalid as such. Given the
clunkiness/weakness of batch scripting when it comes to string processing, I
generally keep the parameter validating code to a minimum, and just let it
display whatever ugly errors cmd.exe can think up. I also generally avoid
requiring the user to type in syntactically complicated parameters, making
this a bit less likely to happen.
/Al