WAD DIR.BTM?

May 20, 2008
9,856
69
Syracuse, NY, USA
What's up with this?

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

Code:
v:\> type dir.btm
echo foo

v:\> dir.btm
foo
I cannot execute it with parameters.

Code:
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

Administrator
Staff member
May 14, 2008
11,421
108
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".
 
May 20, 2008
9,856
69
Syracuse, NY, USA
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

Super Moderator
Staff member
May 20, 2008
3,957
53
Albuquerque, NM
prospero.unm.edu
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.
 
May 20, 2008
9,856
69
Syracuse, NY, USA
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.

Code:
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
 

rconn

Administrator
Staff member
May 14, 2008
11,421
108
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.)
 
May 20, 2008
9,856
69
Syracuse, NY, USA
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

Administrator
Staff member
May 14, 2008
11,421
108
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

Administrator
Staff member
May 14, 2008
11,421
108
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).
 
May 20, 2008
9,856
69
Syracuse, NY, USA
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.