Command$ parses wildcards in paths

[mdijkens]

When I start a compiled program and specify a command parameter with wildcards like 'd:\dev\.BAS' the parameter is immediately parsed and my _Commandcount is over a hundred containing all individual files instead of just the string 'd:\dev*.BAS'. This problem does not occur with . or no wildcards, only with .bas or *.docx etc.

If intended please update the documentation of COMMAND$ and provide other ways to get the exact parameter as typed by the user

[flukiluke]

The value returned by Command$ is the concatenation of the argv array received by the C main() function.

I was surprised to learn that the windows command interpreter does not do any wildcard expansion or argument splitting (in contrast to UNIX environments where that processing is done by the shell).

I would consider the following arrangement:

• On Windows, Command$ returns the original command line string without wildcard expansion.
• On Unix platforms, Command$ returns the concatenation of argv elements.
• On both platforms, Command$(n) continues to return the nth argument after expanding and splitting.

The biggest issue with this is whether anyone is relying on the implicit wildcard expansion in Command$ on Windows. A smaller question is whether the new unprocessed Command$ should include the executable name or not (i.e. argv[0]).

[mdijkens]

I was not aware of the behaviour on Unix platforms, but for Windows I've never seen wildcard expansion. Not in previous QB64 versions but certainly not in BC7/7.1 PDS and QB4.0/4.5. I would argue that the behaviour on Windows and Unix should always be as much the same as possible for code compatibility.

For compatibility-reasons I would argue not to have any wildcard expansion with command$ except with a new method e.g. _XCommand$ or something.

[flukiluke]

It doesn't make sense to not have wildcard expansion on Unix, the information simply doesn't exist.

[mdijkens]

Ok, so main questions are:

1. if the behaviour should stay as close as possible to the original Command$ of historic MS QB/BC or not?
2. If the behaviour on Windows and Linux should be as much the same as possible?
3. How the original unexpanded command string can be available on both?

[flukiluke]

1. It seems like the Least Surprising Behaviour for WIndows users is for Command$ to not be expanded, though I would like to have some broader community feedback on this before making a decision either way.

2 & 3. As I mentioned above, Unix systems do not make the unexpanded command line available to programs - the expansion is done before the program is launched. So assuming point 1, we can't make the behaviour across both platforms the same.

[FellippeHeitor]

Both v1.5 and the latest do wildcard expansion under Windows XP, so they probably do so in all other versions. Tested just now. The behaviour seems consistent across platforms, and seems to have been that way forever - only unnoticed/undocumented till now, in which case I'm in favor of documenting the feature as is.

[FellippeHeitor]

Another remark: wrapping a wildcard mask in quotation marks will disable expansion, and wrapping a path in quotation marks is pretty much standard, so it should suffice to "bypass" the expansion.

[FellippeHeitor]

I take back my remark regarding wrapping a wildcard file name in quotation marks, it doesn't really work (must have been a fluke) - but single quotes do work, as indicated.

Tested as far back as v1.3, and the behaviour in all Windows versions is the same. I'd call it a feature, one @mdijkens will need to workaround for now, especially considering it's always been that way, as said.

COMMAND$ used to exist in QB4.5, but not as an array, as we have it now, so the implementation of the function in QB64 has always been one of its own, departing from the original usage.

I keep my vote for it to remain unchanged, and to extend the documentation to add info about it. We don't know if other people wrote code relying on the way it currently works.

[GeorgeMcGinn]

I don't use wildcard masks, so as far as that goes, I'm more inclined to keep things working the way they are. The reason is for the next "smaller question" raised by Luke: "A smaller question is whether the new unprocessed Command$ should include the executable name or not (i.e. argv[0])."

If the executable name is removed, I will have a lot of code to change, as I use this for many programs of mine that create processing log files. I use the executable name so I know what program each message comes from.

Any change, whether it be with changing how the wildcard mask works or removing the executable name will create more problems for many.