Welcome!

By registering with us, you'll be able to discuss, share and private message with other members of our community.

SignUp Now!

Documentation Topic: Batch File Parameters

May
3,515
5
Suggest improvements below.

1/ At end of 3rd paragraph, after the phrase "will be interpreted as an empty string", insert "and the conditional expression "DEFINED %n" will be TRUE if n is any number in the range 0 ... 4095.

2/ Reorganize the table showing parameter formats and values by showing the effect of the SHIFT command in a separate column as shown in the post.htm file included in the attachment.
 

Attachments

  • post.zip
    1.8 KB · Views: 230
Did you really mean DEFINED %n or rather DEFINED n ?
BTW here neither of
Code:
if defined %0 echo yes
if defined 0 echo yes
outputs yes.
 
Stefano, you are right, I got mixed up! Doubly! The correct suggestion should be:

Add a paragraph before the table stating "The conditional expression DEFINED N - where N is a parameter number - cannot be used to determine whether or not parameter N was passed to the batch file. If parameter N was passed to the batch file, %* will not be smaller than N, nor - if SHIFT has not been used - will %# be smaller."
 
Stefano, you are right, I got mixed up! Doubly! The correct suggestion should be:

Add a paragraph before the table stating "The conditional expression DEFINED N - where N is a parameter number - cannot be used to determine whether or not parameter N was passed to the batch file. If parameter N was passed to the batch file, %* will not be smaller than N, nor - if SHIFT has not been used - will %# be smaller."

You've completely lost me here. Why would I mention DEFINED at all, given that DEFINED only refers to environment variables, not batch file parameters?
 
You are correct that batch file parameters are not listed as entities testable by DEFINED where DEFINED is defined, Yet they look like variables (named 0...) even though they are not.

When applicable, DEFINED is the simplest test for its purpose. For all entities other than environment variables evaluated using the percent mark (%) prefix it would be nice if the DEFINED test were applicable - internal variables, alias and batch file parameters, GOSUB variables...
 
You are correct that batch file parameters are not listed as entities testable by DEFINED where DEFINED is defined, Yet they look like variables (named 0...) even though they are not.

They are variables. They just aren't defined in the environment.
 
You are correct that batch file parameters are not listed as entities testable by DEFINED where DEFINED is defined, Yet they look like variables (named 0...) even though they are not.

When applicable, DEFINED is the simplest test for its purpose. For all entities other than environment variables evaluated using the percent mark (%) prefix it would be nice if the DEFINED test were applicable - internal variables, alias and batch file parameters, GOSUB variables...

Absolutely not! That would be a compatibility disaster -- DEFINED is there (solely) for compatibility with CMD, which emphatically does NOT support anything other than environment variables with IF DEFINED.
 
I'm going to stick my two cents in here: The expression If "%1" != "" ... will test if "%1" is anything. The problem with this if parameter one is not coded, no later parameters can be coded, either.

However, the test If "%@UnQuoteS[%1]" != "" ... will allow a null value to effectively be specified for the first parameter (by specifying an empty double-quoted string) while still being able to specify parameters 2, 3, 4, etc. If the value of a parameter is needed without double quotes (such as a numeric value, for instance), unquoting it with "@UnQuoteS" will do it before use if the user for some (strange) reason placed it in double quotes; automatically double quoting a file name is harmless; and if you specifically want to test for the value "" (just double quotes, for whatever strange reason(s)) the test If "%@UnQuoteS[%1]" != """" (that's double-quoted double quotes on the other side of the "If") will get the job done just fine.

One might think that the internal variable "%_CmdLine" would completely allow you to bypass all of the issues and decode the command-line parameters yourself essentially from scratch; but for whatever reason(s) (and only Rex would know what those reasons are) it only returns the first parameter listed after the command name in TCC 13.04.61. (Rex, is this right? The documentation at least appears to state otherwise ("_CMDLINE returns the current command line"); and I would basically swear that I've used it for this purpose in the past...)

- Dan
 
I'm going to stick my two cents in here: The expression If "%1" != "" ... will test if "%1" is anything. The problem with this if parameter one is not coded, no later parameters can be coded, either.

If parameter 1 is not coded but parameter 2 is, then by definition parameter 2 is parameter 1. The only way I know of to pass an empty parameter is to use back quotes.

Code:
foo.btm:
echo args=%#
do i=1 to %# (echo arg%i="%[%i]")
 
 
[R:] foo 1 2
args=2
arg1="1"
arg2="2"
 
[R:] foo ,2
args=1
arg1="2"
 
[R:] foo `` 2
args=2
arg1=""
arg2="2"
 
[R:] foo ``, 2
args=2
arg1=""
arg2="2"
 
[R:] foo 1,,2
args=2
arg1="1"
arg2="2"
 
Scott, I'm a little bit surprised that you took the time to do that because of course I knew that but I just didn't take the time to state what I thought was obvious - if if there is no parameter 1 (at all, as opposed to an "empty" parameter 1, however you decide to allow that to be coded/how it is specified), then, by definition, there is no parameter 2, no parameter3, ...; there are no parameters at all. As far as back quotes go, I knew that but I tend to prefer the use of the plain old double quotes for whatever reason(s) - maybe my finger knows where they are without me really having to think about it; and the whole situation involved doesn't come up often enough (for me, at any rate) to be an issue. And, I will note, if the expression testing for the existence of parameter 1 is "%@UnQuoteS[%1]" == "" (the bold font is to avoid the issue of (double) quoting a string that contains double quotes in the context of these postings) coding either "" or `` works equally well. (There are no situations in my batch files where an empty doubly-quoted string would be expected/valid - although code I write does not assume that if the above test comes up true that there are no further positional parameters (see the last point in this posting) - the previous would then be reported as an error in some manner; and as a general rule I use what were at least once known as keyword parameters in these kinds of situations: /paramtername...whatever. When a parameter may be "missing", it shouldn't be a "positional" parameter in the first place as far as I am concerned.) Finally, in those situations where I am iterating through the parameters, I always use the "construction" Do While %# != 0 (with, of course, a Shift in the loop), and the test "%@UnQuoteS[%1]" == "" meets my needs perfectly.

- Dan
 
1/ Backquotes do allow passing an empty string as a parameter; this prevents detecting when SHIFT has processed all parameters by checking for an empty one (likewise, looping through parameters until an empty one may also be erroneous) - you must control through the use of the %# or the %* pseudovariables to insure processing all parameters.

2/ Just as the status tests include DEFINED, ISALIAS, ISFUNCTION, ISINTERNAL, ISPLUGIN to determine whether or not a specific string is the name of an environment variable, alias, user defined function, internal command or a plugin-defined feature, resp., it would be useful to have similar tests for internal variables (some of which may or may not be defined at different times depending on conditions even within a single instance of TCC) and for alias, function and batch file parameters by their number. The test could be named ISPARAMETER not to avoid overloading the test DEFINED.
 
Steve, as far as I can tell your #1 essentially says exactly the same thing as I said. If an empty string is not (and never will be) valid for a parameter, there is no practical difference between "%@UnQuoteS[%n]" and what you suggest. And I will note that I specifically said that I used "%#", which, of course, counts "empty" parameters; and I do not "look for" "empty" parameters; writing code that worked that way would go very deeply against my basic "instincts" when writing code - or, to say it another way, I would absolutely never do it by looking for an "empty" string under any circumstances whatsoever. (What possible "advantage" to doing it that way could there be, anyway? Typing "%#" is actually fewer keystrokes than doing it any other possible way unless you have a bias against hitting the "#" key! ;))

- Dan
 
Dan:
When positional parameters are used, an empty one may have significance, whether or not you ever code such programs. I don't usually do it, either. A pair of quotation marks, however, is NOT a null parameter, unless so agreed between the user and the coder. As already reported, a pair of backticks does create an empty parameter. Your method does not distinguish between these cases. As long as you are both the coder and the user, anything is permissible. BTW, I did reportedly mentioned that %# or %* are the only reliable methods of detecting end of command line.

Regardless, this discussion now has nothing to do with my OP - a suggested documentation enhancement, which Rex already rejected as unnecessary.
 
Steve, I don't at all disagree with anything that you say above. However, since I am both the user and coder, that is a complete non-issue for me (as I think you'll agree).

And BTW, I just said that I actually use "%#" and "%*" and nothing else.

So the bottom line is simply "do whatever you are happiest with" and these are the ways you can do it.

- Dan
 

Similar threads

Back
Top