WAD DIR.BTM?

[vefatica]

What's up with this?

I can successfully execute a BTM named DIR.BTM without parameters.

v:\> type dir.btm
echo foo

v:\> dir.btm
foo

I cannot execute it with parameters.

v:\> dir.btm parameter

 Volume in drive V is DATA         Serial number is 6e8a:6d1f
TCC: (Sys) The system cannot find the file specified.
 "V:\.btm"
                   0 bytes in 0 files and 0 dirs
     506,751,782,912 bytes free

 Volume in drive V is DATA         Serial number is 6e8a:6d1f
TCC: (Sys) The system cannot find the file specified.
 "V:\parameter"
                   0 bytes in 0 files and 0 dirs
     506,751,782,912 bytes free

 

[rconn]

WAD (30-year old behavior).

First, don't do that!

Second, this is an ancient kludge because users are unable to use the correct syntax and insert whitespace after the command name (i.e. "dir/w" etc.). In your first example, the parser checks to see if the command is an executable file, and if so it runs that file. In the second example, the command is interpreted as "dir" + ".btm" + "parameter".

 

[vefatica]

WAD (30-year old behavior).

First, don't do that!

Second, this is an ancient kludge because users are unable to use the correct syntax and insert whitespace after the command name (i.e. "dir/w" etc.). In your first example, the parser checks to see if the command is an executable file, and if so it runs that file. In the second example, the command is interpreted as "dir" + ".btm" + "parameter".

What's the difference? It's still the name of an executable file. Why does adding a parameter make a difference?

I'm well aware of the age-old kludge but I have always thought it applied ONLY to the parameter characters (e.g., DIR/P). "." isn't documented to be a parameter character. Is there a list of characters that will elicit the kludged behavior (";" will, "#" won't ... am I supposed to guess?).

 

[Charles Dye]

Remember how, in COMMAND.COM, to display an empty line you had to do echo. (with a trailing period)? And Microsoft documented this kludge, therefore Rex must duplicate it.

Unless he's gonna write a separate parser for each command, there must be a common arg parser shared by most commands, and it must support such compatibility bodges. I'm guessing his common parser has a flag argument governing miswarts like this; that one of those flags means "punctuation ends the command name, same as whitespace"; and that DIR sets that flag, because setting it draws fewer complaints than not setting it.

 

[rconn]

What Charles said.

There is < 0% chance I'm going to change this, as I cannot think of anything else I could do in the parser that would generate more problems with existing batch files & aliases.

 

[vefatica]

I still don't get it.

"DIR.BTM" is the name of an executable file.

"DIR.BTM foo" is the name of an internal command plus two parameters.

And the behavior is NOT the same as CMD.

v:\> cmd
Microsoft Windows [Version 10.0.18362.418]
(c) 2019 Microsoft Corporation. All rights reserved.

v:\> type dir.bat
@echo off
echo foo

v:\> dir.bat
foo

v:\> dir.bat parameter
foo

 

[vefatica]

There is < 0% chance I'm going to change this

Not even for CMD compatibility?

 

[rconn]

Not even for CMD compatibility?

Absolutely not.

This was for compatibility with COMMAND.COM, and retained for compatibility with a zillion existing batch files & aliases (with the minor kludge when MS changed CMD in Windows 2000 to check for an executable name if it's the only argument).

You can submit it to the Suggestions Forum, but I won't implement it. (I'd be willing to bet it would break some of your own batch files.)

 

[vefatica]

I'd be willing to bet it would break some of your own batch files.

That would depend on exactly what you did. I have never failed to put a space after the name of a command (internal or plugin). All I'm advocating is: if the first space-delimited token is the name of an executable file then leave it alone and look for parameters after it.

 

[rconn]

That would depend on exactly what you did. I have never failed to put a space after the name of a command (internal or plugin). All I'm advocating is: if the first space-delimited token is the name of an executable file then leave it alone and look for parameters after it.

No, no, a thousand times no.

If you absolutely must use dumb filenames, double quote it and it will work as you expect.

 

[rconn]

And before you become too enthralled with the CMD syntax (for the first time ever), you should be aware that CMD treats this completely differently depending on whether the first argument is in the current directory.

Put it in a directory in your PATH, switch to a different directory, and try to execute it in CMD. CMD will treat it like TCC (as DIR + two parameters).

 

[vefatica]

And before you become too enthralled with the CMD syntax (for the first time ever), you should be aware that CMD treats this completely differently depending on whether the first argument is in the current directory.

Put it in a directory in your PATH, switch to a different directory, and try to execute it in CMD. CMD will treat it like TCC (as DIR + two parameters).

You're right, I'm no fan of CMD compatibility. I only mentioned it because monkeying with a first argument on the command line when it's the name of an executable file just doesn't make any sense to me.

I was writing my own DESCRIBE.BTM (unfortunate choice of name) that uses a stream ":description.txt" and avoids all the Windows SummaryInformation business. Of course I renamed it (for now DESCRIB.BTM). It works pretty well, but now I have a new problem.

I'd like to use a user-defined function, say @DESCRIB[], in PDIR and I'd like it to return the first line of *:description.txt if *:description.txt exists and an empty string otherwise. That's proving difficult.