Problem with variable names with embedded period

[Steve Fabian]

It seems that under many circumstances the parser considers a period
embedded in the name of an environment variable as a name terminator. Some
instances I found are:

[c:]set setcolor.lst=aa bb cc
[c:]set setcolor=xxx

1/ using the VariableExpand key in the command line

[c:]xyz %setcolor.lst

displays

[c:]xyz xxx.lst

2/ ECHO

[c:]echo %setcolor.lst
xxx.lst

3/ In a batch file the command

do %x in /l %setcolor.lst
echo %x
enddo

displays .lst



IF DEFINED works correctly, i.e., if SETCOLOR is not defined, IF DEFINED
SETCOLOR.LST is true.

The behavior goes back at least to V6. I never observed it, because I only
use a few such variable names, and those only with IF DEFINED tests (not
counting executable extensions).
--
Steve

 

[Charles Dye]

It seems that under many circumstances the parser considers a period embedded in the name of an environment variable as a name terminator. Some instances I found are:

The preferred characters for variable names are alphanumerics, dollar sign, and underscore. Adding the period to the list would wreak havoc on a large number of batch files....

 

[Steve Fabian]

Charles Dye wrote:
| ---Quote (Originally by Steve Fábián)---
| It seems that under many circumstances the parser considers a period
| embedded in the name of an environment variable as a name terminator.
| Some instances I found are: ---End Quote---
| The preferred characters for variable names are alphanumerics, dollar
| sign, and underscore. Adding the period to the list would wreak
| havoc on a large number of batch files....

You are correct that the period is NOT listed as a "standard" character, and
HELP topic "environment.htm" specifies that period and other characters can
be used in variable names that are expected to be expanded by enclosing the
names in brackets, which I failed to do. I failed to RTFM...

However, though rarely used nowadays, PKZIP.EXE uses the variable PKZIP.CFG
to find the directory where its configuration file is, even in the
COMMAND.COM environment. Defining executable extensions also requires
variable names starting with period. I never had trouble defining and using
them, but none of these variables are normally expanded at the command line
or in batch programs.
--
Steve

 

[rconn]

Steve Fábián wrote:

> It seems that under many circumstances the parser considers a period
> embedded in the name of an environment variable as a name terminator.

It goes back to v1 -- a period is not and never has been a valid
character in a variable name.

If you're really determined (and don't mind breaking most of the batch
files in existence), you can force it with the %[] syntax.

Rex Conn
JP Software

 

[Steve Fabian]

rconn wrote:
| Steve Fábián wrote:
|
|
| ---Quote---
|| It seems that under many circumstances the parser considers a period
|| embedded in the name of an environment variable as a name terminator.
| ---End Quote---
| It goes back to v1 -- a period is not and never has been a valid
| character in a variable name.
|
| If you're really determined (and don't mind breaking most of the batch
| files in existence), you can force it with the %[] syntax.

I already admitted that I did not RTFM before posting the original message,
and that there are no problems in 4NT or TCC operation. However, as a
theoretical issue, if you consider period to be invalid in variable names,
why does the syntax defining executable extensions require the creation of
variables with period as first character of their name?
--
Steve

 

[rconn]

Steve Fábián wrote:

> rconn wrote:
> | Steve Fábián wrote:
> |
> |
> | ---Quote---
> || It seems that under many circumstances the parser considers a period
> || embedded in the name of an environment variable as a name terminator.
> | ---End Quote---
> | It goes back to v1 -- a period is not and never has been a valid
> | character in a variable name.
> |
> | If you're really determined (and don't mind breaking most of the batch
> | files in existence), you can force it with the %[] syntax.
>
> I already admitted that I did not RTFM before posting the original message,
> and that there are no problems in 4NT or TCC operation. However, as a
> theoretical issue, if you consider period to be invalid in variable names,
> why does the syntax defining executable extensions require the creation of
> variables with period as first character of their name?

So that they couldn't possibly be confused with an environment variable.
(Just like the current working directory variables, which begin with a
'=' and are hidden from view.)

Rex Conn
JP Software

 

[vefatica]

On Wed, 19 Nov 2008 20:59:12 -0600, Steve Fábián <> wrote:

>rconn wrote:
>| Steve Fábián wrote:
>|
>|
>| ---Quote---
>|| It seems that under many circumstances the parser considers a period
>|| embedded in the name of an environment variable as a name terminator.
>| ---End Quote---
>| It goes back to v1 -- a period is not and never has been a valid
>| character in a variable name.
>|
>| If you're really determined (and don't mind breaking most of the batch
>| files in existence), you can force it with the %[] syntax.
>
>I already admitted that I did not RTFM before posting the original message,
>and that there are no problems in 4NT or TCC operation. However, as a
>theoretical issue, if you consider period to be invalid in variable names,
>why does the syntax defining executable extensions require the creation of
>variables with period as first character of their name?

I don't think it's "invalid"; it's just special (and thus may need the %[]
treatment). That's for a very good reason ... so you can do the likes of
"%basename.txt". You wouldn't want to be required to say "%[basename].txt",
would you?

As for variables whose first character is "." they're special (in a way); what
precedes the "." is an empty string and an empty string can't be the name of an
environment variable.

These are trade-offs for ease of use and I think 4NT does a pretty good job
here.