if "!" lss "" (echo.TRUE) else (echo.FALSE)
if "#" lss "" (echo.TRUE) else (echo.FALSE)
For space and exclamation it's TRUE, for another char it's FALSE.
Don't know has it been recorded in any FAQ, but quite funny anyway.
It's people who assign a special meaning to "
From CMD's point of view, the " simply suspends ITS special meaning of SPACE
as a separator until a matching " is found. The syntax
string compare-op string is then validated and the string 22H21H22H or
22H20H22H compared againgst 22H22H.
But certainly another trap for young players - and perhaps for those with
excess blood in their alcohol system.
It does an ascii string compare with it's not purely numerical.
--
Regards,
Mic
>> Type in the command prompt:
>>
>> if "!" lss "" (echo.TRUE) else (echo.FALSE)
>>
>> if "#" lss "" (echo.TRUE) else (echo.FALSE)
>>
>> For space and exclamation it's TRUE, for another char
>> it's FALSE.
>>
>> Don't know has it been recorded in any FAQ, but quite
>> funny anyway.
And the similar story with the bracket.
Eg "if [\] lss []" and then "if [^] lss []".
> It's people who assign a special meaning to "
>
> From CMD's point of view, the " simply suspends ITS
> special meaning of SPACE as a separator until a matching
> " is found. The syntax
> string compare-op string is then validated and the string
> 22H21H22H or 22H20H22H compared againgst 22H22H.
CMD is free to have its view, from user's view such
view is just inconvenient and buggy, since it doesn't
fit to common habitual expectation.
Quite, but the quirks with poison characters are well-known. Thus the
behavior is not entirely unexpected, even if strange, in batch
programming. Furthermore the lss comparison to a null string seems a bit
of an artificial construct.
All the best, Timo
--
Prof. Timo Salmi mailto:t...@uwasa.fi ftp & http://garbo.uwasa.fi/
Hpage: http://www.uwasa.fi/laskentatoimi/english/personnel/salmitimo/
Department of Accounting and Finance, University of Vaasa, Finland
Useful CMD script tricks http://www.netikka.net/tsneti/info/tscmd.php
>> Type in the command prompt:
>> if "!" lss "" (echo.TRUE) else (echo.FALSE)
>> if "#" lss "" (echo.TRUE) else (echo.FALSE)
>> For space and exclamation it's TRUE, for another char
>> it's FALSE. Don't know has it been recorded in any FAQ,
>> but quite funny anyway.
>
> Quite, but the quirks with poison characters are
> well-known. Thus the behavior is not entirely unexpected,
> even if strange, in batch programming. Furthermore the
> lss comparison to a null string seems a bit of an
> artificial construct.
It becomes less artificial if one want to compare strings
with some common prefix (e.g. filenames, which in general
case may embed some "poison" characters and thus must be
enquoted) naturally expecting a substring to be logically
"less then" its any cover.
In case of filenames right padding with TAB may help:
if "%VarA% " lss "%VarB% " goto :eof
rem | |
rem +-- ASCII 9 here --+
Where is a null-string? The ""-string is not a null, a pair of double
commas signs
> It becomes less artificial if one want to compare strings
> with some common prefix (e.g. filenames, which in general
> case may embed some "poison" characters and thus must be
> enquoted) naturally expecting a substring to be logically
> "less then" its any cover.
>
> In case of filenames right padding with TAB may help:
>
> if "%VarA% " lss "%VarB% " goto :eof
> rem | |
> rem +-- ASCII 9 here --+
:) But no way, tab if greater than space (but less than !).
If you enclose a string in quotes in programming, do you hence consider
the quotes part of the string?
In batch in "if-condition" I think yes:
if not "%value%"==""
if not [%value%]==[]
if not .%value%==.
But not:
if not "%value%=="
In this case:
if not ^"%value%==^"
No. However in this case they are.
It's documented behaviour where the text is treated as a string if it's
not completely numeric.
--
Regards,
Mic
It language-dependent.
In BASIC, '=' is an assignment-operator; in Pascal, it's a
comparison-operator.
In BATCH, the quotes DO form part of the string. Without the 'complication'
of the instances raised by OP, you must in batch use
if "%var%"=="string"
not
if %var%=="string"
- and the same goes for the other 'obvious' delimiters raised.
set "var1=%1"
set "var2="
if !var1! lss !var2! (
echo is Less
) ELSE (
echo is equal or greater
)
It's because after the delayed expansion no more special characters
are processed, and the tokens !var1! and !var2! works independent of
their content.
Regards,
jeb
Is this what you meant, jeb
@echo off
setlocal enabledelayedexpansion
set "var1=%1"
set "var2=%2"
if !var1! lss !var2! (
echo is Less
) ELSE (
echo is equal or greater
)
pause
I tried this and got an error so special characters are processed, or
did you mean something else?
BATCH.BAT "abc>" a
--
Regards,
Mic
set "var2="
It simply removes the variable %var2%. And we'll get an error in the
compare operation. Because the existing variable will be compared to
nothing:
if !var1! lss !var2!
Note that the %~1 and %~2 tokens are used here too:
@echo off
setlocal enabledelayedexpansion
set "var1=%~1"
set "var2=%~2"
if !var1! lss !var2! (
echo is Less
) ELSE (
echo is equal or greater
)
pause
> I tried this and got an error so special characters are processed, or
> did you mean something else?
> BATCH.BAT "abc>" a
It doesn't error. When I used quotes in "abc>" with this line it caused
that issue:
set "var1=%1"
Thanks for the tip, jeb.
--
Regards,
Mic
Ok I forgot the line
setlocal EnableDelayedExpansion EnableExtensions
Yes and no!
It expands to nothing, but it doesn't result in an error,
because the tokenizer take the !var1! as one token.
The expansion does not change this, even with quotes,
because the special character expansion is before the DelayedExpansion
parser phase.
The example "abc>" fails not in ... if !var1! ...
It fails in the line set "var1=%1"
It's a problem of getting command line parameters, (this can be really
tricky, if you want to solve it generally)
You can try
setlocal DisableDelayedExpansion
set "var1=%~1"
set "var2=%~2"
setlocal EnableDelayedExpansion
set var
if !var1! EQU !var2! (
echo EQUAL
) ELSE (
echo false
)
goto :eof
This works with empty strings like
batch.bat "" ""
or with
batch.bat "space it" "special chars like > < & % !xy! "quote""
jeb
> if "!" lss "" (echo.TRUE) else (echo.FALSE)
I'm on Linux so I can't see what is happening, but have you considered
that '!' might be disappearing with delayed expansion? Have you tried
this with and without delayed expansion?
Frank
The "!" doesn't unexpectedly disappears, sometimes it is expanded to
<nothing> because the !variable is not defined, like here
echo hello!
But in the case of (delayed) expanding a variable no more expanding
occurs, so the "!" are safe.
So the only problem is the line
set "var1=%~1"
If in %1 is an exclamation mark it "disappears", but therefore I
disable the delayedExpansion just before.
Ok, there are still problems of getting the content of %1, but that's
another story...
jeb
It was simplest example to show the quote is part of compared string.
But yes it seems the only way to compare arbitrary strings reliably is to do
that without quotes using variables under delayed expansion (as Jeb already
marked), also with a left padding to prevent numerical interpretation.
@echo off
setlocal enableextensions disabledelayedexpansion
set "varA=>|&<!temp"
set "varB=>|&<!temp!"
if "%varA%" lss "%varB%" (echo.TRUE) else (echo.FALSE)
setlocal enableextensions enabledelayedexpansion
if o!varA! lss o!varB! (echo.TRUE) else (echo.FALSE)
echo.varA=!varA!
echo.varB=!varB!
endlocal
endlocal
> Frank