Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

if compares quote with enquoted

27 views
Skip to first unread message

Oleg Smirnov

unread,
Nov 13, 2010, 10:45:44 PM11/13/10
to
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.

billious

unread,
Nov 13, 2010, 11:27:31 PM11/13/10
to

"Oleg Smirnov" <ve...@gde.ru> wrote in message
news:ibnm37$dii$1...@os.motzarella.org...

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.


foxidrive

unread,
Nov 13, 2010, 11:32:57 PM11/13/10
to
On 14/11/2010 14:45, Oleg Smirnov wrote:
> 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.

It does an ascii string compare with it's not purely numerical.


--
Regards,
Mic

Oleg Smirnov

unread,
Nov 14, 2010, 12:23:57 AM11/14/10
to
billious, news:78SdnVGra-Kl-ELR...@westnet.com.au

> "Oleg Smirnov" <ve...@gde.ru> wrote in message

>> 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.

Timo Salmi

unread,
Nov 14, 2010, 7:25:25 AM11/14/10
to

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

Oleg Smirnov

unread,
Nov 14, 2010, 9:29:59 AM11/14/10
to
Timo Salmi, news:4cdfd535$0$14531$9b53...@news.fv.fi

> On 14.11.2010 05:45 Oleg Smirnov wrote:

>> 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 --+

01MDM

unread,
Nov 14, 2010, 9:32:01 AM11/14/10
to
> Furthermore the lss comparison to a null string seems a bit
of an artificial construct.

Where is a null-string? The ""-string is not a null, a pair of double
commas signs

Oleg Smirnov

unread,
Nov 14, 2010, 10:43:50 AM11/14/10
to
Oleg Smirnov, news:ibors7$855$1...@os.motzarella.org
> Timo Salmi, news:4cdfd535$0$14531$9b53...@news.fv.fi

> 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 !).

Timo Salmi

unread,
Nov 14, 2010, 1:44:29 PM11/14/10
to

If you enclose a string in quotes in programming, do you hence consider
the quotes part of the string?

01MDM

unread,
Nov 14, 2010, 2:15:16 PM11/14/10
to
> 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%==^"

foxidrive

unread,
Nov 14, 2010, 2:18:09 PM11/14/10
to
On 15/11/2010 05:44, Timo Salmi wrote:
> On 14.11.2010 16:32 01MDM wrote:
>>> Furthermore the lss comparison to a null string seems a bit
>> of an artificial construct.
>>
>> Where is a null-string? The ""-string is not a null, a pair of double
>> commas signs
>
> If you enclose a string in quotes in programming, do you hence consider
> the quotes part of the string?

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

billious

unread,
Nov 14, 2010, 8:26:13 PM11/14/10
to

"Timo Salmi" <t...@uwasa.fi> wrote in message
news:4ce02e0c$0$32136$9b53...@news.fv.fi...

> On 14.11.2010 16:32 01MDM wrote:
>>> Furthermore the lss comparison to a null string seems a bit
>> of an artificial construct.
>>
>> Where is a null-string? The ""-string is not a null, a pair of double
>> commas signs
>
> If you enclose a string in quotes in programming, do you hence consider
> the quotes part of the string?
>
> All the best, Timo

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.


jeb

unread,
Nov 15, 2010, 5:19:21 AM11/15/10
to
The best solution is to use delayed expansion, then quotes inside the
vars are safe and also compares against empty works find.

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

foxidrive

unread,
Nov 15, 2010, 6:46:13 AM11/15/10
to


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

01MDM

unread,
Nov 15, 2010, 9:56:19 AM11/15/10
to

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!

foxidrive

unread,
Nov 15, 2010, 10:31:10 AM11/15/10
to
On 15/11/2010 22:46, foxidrive wrote:
> On 15/11/2010 21:19, jeb wrote:
>> The best solution is to use delayed expansion, then quotes inside the
>> vars are safe and also compares against empty works find.
>>
>> 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.
>
>
> Is this what you meant, jeb

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

jeb

unread,
Nov 15, 2010, 10:47:43 AM11/15/10
to

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

Frank Westlake

unread,
Nov 15, 2010, 11:40:49 AM11/15/10
to
Oleg Smirnov wrote:

> 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

jeb

unread,
Nov 15, 2010, 1:28:13 PM11/15/10
to
On Nov 15, 5:40 pm, Frank Westlake <frank.westl...@gmail.com> wrote:
> 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

Oleg Smirnov

unread,
Nov 16, 2010, 4:29:17 AM11/16/10
to
Frank Westlake,
news:7d6924d6-bf33-458c...@n32g2000pre.googlegroups.com

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

0 new messages