DosTips.com

Is there a way to reliably get the count of arguments a batch file was called with, safe against odd inputs, and preferably without invoking external programs or temp files?

Some test cases which fail most naive counting approaches would be...

• " --- expected count 1
• "" a --- 2
• a " b --- 2

...and others involving the usual poison characters.

Thanks,
Liviu

Don't think there is much you could do about a string not being closed quoted correctly. If you just have a set of empty quotes then you can check to see if it is empty.
So given your example of "" a ---
This code would correctly count it as 2.

Liviu wrote:Is there a way to reliably get the count of arguments a batch file was called with, safe against odd inputs, and preferably without invoking external programs or temp files?

I'm afraid the answer is NO.
REM is the only command that is able to catch the arguments %* as is.

Regards
aGerman

Squashman wrote:Don't think there is much you could do about a string not being closed quoted correctly. If you just have a set of empty quotes then you can check to see if it is empty.
So given your example of "" a ---

I should have made it more clear that the "---" was part of my comment, not part of the arguments. So for example I expect "" a --- to be counted as 3 arguments, and "" a as just 2. Sorry for the confusion.

aGerman wrote:I'm afraid the answer is NO.
REM is the only command that is able to catch the arguments %* as is.

I am aware of the REM redirection trick to get %*. In fact, I was wondering if I could get the count in advance, so that I could then get the individual %1, %2 etc arguments as well in one shot, as opposed to (re)using a temp file for each.

Guess my original question can be reduced to how to check whether %1 is present or not, in a way safe against odd input like single ", ^", ^& etc. Since that's a lighter requirement than literally retrieving %1 itself, I was hoping there might be some easier workaround.

Thanks,
Liviu

I'm not sure whether this would work in each case:

Regards
aGerman

aGerman wrote:I'm not sure whether this would work in each case:

Nice! and appears to be doing just what I was looking for, thank you.

Side comment: it's even kind of obvious in hindsight now, isn't it Guess I didn't think at it becaused of the reflex don't set "x=%1" when %1 may contain quotes or unquoted &<>|etc since it's going to be a pain to use later. Of course, just checking that 'x' is empty or not happens to be one case when those special characters don't matter.

Variation on the same theme...

The above looks at %1 instead of %*. Off topic somewhat, but it is possible that %1 is not present, but %* is still not empty, for example when passing a separators-only command line such as ;,=.

Thanks,
Liviu

Liviu wrote:The above looks at %1 instead of %*. Off topic somewhat, but it is possible that %1 is not present, but %* is still not empty, for example when passing a separators-only command line such as ;,=.

Yeah, that's exactly the reason why I used %* instead. (You told that you need to look at all odd "poison" characters )
I'm not sure whether you need the hash character. I used it to make sure that a caret would not escape the quotation mark but it was useless in my tests...

Regards
aGerman

Edit:
It's still not exactly foolproof

Example argument (jeb):
one^&two"&three

simplified:
"& or "&"

It however detects the character(s) in front of &. For that reason it would probably be sufficient to redirect the error message of the SET line. But it is potentially dangerous since the command in argument
"& command &"
would be executed

Regards
aGerman

Not only is it susceptible to command injection, it can also completely miss the parameter.

"one&rem " (quotes included) will be reported as no argument, and it executes the REM command. The one is stripped because it occurs after the last quote, and the rem command could just as easily be something destructive.

I really don't think it is possible to safely test for 1 or more arguments without using the REM echoed to a file trick.

Here is a clean looking script that safely loads all of the arguments into an arg "array" using the REM trick. There is a space at the end of the temp file that protects against stripping trailing control characters from the argument. I think the only limitation is each argument must be <=1015 bytes long.


Edited to guard against following corner cases:
/?
^ at end (entered as ^^)
%a
%~a %~dpa %~path:a etc.


Dave Benham

I agree with Dave.

That's my attempt:

The hash character is to protect you from the multi line effect with ^.

Regards
aGerman

aGerman wrote:It's still not exactly foolproof

Example argument (jeb):
one^&two"&three

simplified:
"& or "&"

Thanks for that. Somehow thought it couldn't be that easy And it takes down any following parameters as well.

Now, I don't think that'd be much of a problem in my particular use-case, though it's surely disappointing in a more academical sense. What I am actually after is basically "tokenize" the _beginning_ of the %* line in order to simulate an %* "shift" (since the built-in one only shifts the individual %1, %2, etc arguments, but not %* itself). Suppose I wanted to write a simple loggedrun.cmd which would save one line per run to a designated logfile, to be invoked like

loggedrun «logfile» «program-to-run» «program-arguments»

In a different better world, loggedrun.cmd could contain just

@setlocal
@set "logfile=%~1"
@rem _but_ 'shift' doesn't affect %*
@shift
@echo >>"%logfile%" %date% %time% starting: %*
@%*
@echo >>"%logfile%" %date% %time% done: %*
@endlocal

But of course this wouldn't work as such in the cmd world. Firstly, shift doesn't update %*, and then cmd has its own parsing rules which are different from everybody else's. In my example, what comes before «program-to-run» is obviously intended for the batch file, and would follow the cmd rules. However the «program-arguments» part would be under the control of the target program command-line-parsing logic, and it would need to be literally passed as such by the batch file.

Hope here was that combining the REM redirection trick for %*/%1/etc with some time-saving trick to extract the first "cmd-compliant" arguments would then allow me to remove those parts from %* and pass the rest thorugh unchanged.

Since my particular case only involves the first parameters which are largely under my/user's control, I could rule out "pathological" values for those parameters, and make it work under that assumption. That said, it would obviously be more "academically satisfying" if there was a general solution to that, more efficient than one temp file per %1/%2/etc argument.

Thanks again for all responses,
Liviu

dbenham wrote:Here is a clean looking script that safely loads all of the arguments into an arg "array" using the REM trick.

Not sure I fully follow the part about exiting and reentrying the doubly redirected () block, yet, but it looks as if it's internally equivalent to individual per-argument redirections. It's working otherwise, thank you, only nitpick is that "rem %1" should probably be "rem [ %1 ]" or such (and the ~5,-1 offsets adjusted accordingly) in order to handle oddities like /?, ^^.

Thanks,
Liviu

Now I understand why jeb had that # in his REM statement, to protect against /?

I've edited my previous post to compensate.

Thanks

dbenham wrote:Now I understand why jeb had that # in his REM statement, to protect against /?

I've edited my previous post to compensate.

Pretty sure I've seen this noted before, though I can't find a reference handy now... One other corner case is that the 'for' loop would save the incorrect %1 when passed %a or similar as an argument, presumably because of some loop variable name clash. Didn't look into it much yet, but for whatever reason replacing it with

appears to work better under xp.sp3 at least. Again, not fully understood or tested on my part.

Liviu

Thanks

You were correct - an argument of %a was being reported as 1.

Code has been edited

Dave Benham