Posted on 24 March 2015
Windows Shell parses any wildcard path arguments that you supply over the command
line, before passing the arguments to the actual program that has been invoked.
Now let’s see why this is a problem. A simple tool when invoked from the
command line behaved very differently from when the same arguments were provided either via
Java debugger or an
OS X environment. The command line being:
$ java -jar clitools.jar findfile -r \Users\sangupta\*.jpg
When this command was invoked via Windows Shell, I could see only 1 result coming. When invoked
OS X shell, I could see multiple results - infact more than 1000 results.
I added a debug point and on going over could see that the logic was fine. It was recursively
fetching all files from the directory and matching against the wildcard of
*.jpg. Then I added
some log statements to debug the incoming parameters. This was when I realized the major difference
Windows Shell and others.
Windows Shell was interpreting the path on its own, and passing
the following arguments to Java:
[ "-r", "\Users\sangupta\sangupta.jpg", "\Users\sangupta\sangupta2.jpg" ]
This made it clear. My code when trying to retrieve a list of files could match only 1 file because the argument supplied was an exact match.
Now if we take a look, the meaning/result of the command line tool was completely changed due to
the behavior of pre-parsing the command line arguments by
Windows Shell. Had there been a way
to instruct Windows not to do the same, would have been great. But there is none. The only
workaround to this is to enclose the params in double-quotes,
$ java -jar clitools.jar findfile -r "\Users\sangupta\*.jpg"
This makes it difficult to achieve a parity with other Windows built-in command-line tools, that actually take similar parameters and yet can work on the wildcard arguments.
On a relatively different note,
clitools is my own collection of common useful command line tools.