wildcards

[Roedy Green]

I posted the following link as evidence that it is not the command
interpreter but the application that expands wildcards:

<http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vccelng/htm/basic_22.asp>

It depends how you define application. It is definitely no the java
app you write that does it. The argument are expanded before they hit
MAIN. It seems likely the JRE is doing it.

--
Bush crime family lost/embezzled $3 trillion from Pentagon.
Complicit Bush-friendly media keeps mum. Rumsfeld confesses on video.
http://www.infowars.com/articles/us/mckinney_grills_rumsfeld.htm

Canadian Mind Products, Roedy Green.
See http://mindprod.com/iraq.html photos of Bush's war crimes

 

[Roland]

Portions of the essay are somewhat misleading. In Windows, it is not
the command interpreter or BAT language that expands the wildcards. It
is the application that is invoked that does the expanding. This
explains why wildcard expansion in Windows can be inconsistent from
program to program.

I am confused by one part of your essay:

- Oddly if you pass a wild card to any Java utility, the command
- processor expands the wildcards so that you program for *.* will see
- list of all the directories and all the files, one per arg slot.

Unless the directories have the a period character in the name, they
should not match the *.* wildcard expression. If this does happen
perhaps you have found a bug in the JVM.

try this out. I think you will be surprised.

/**
* Tests what sort of wildcard expansion happens automatically.
* It is very simple. Just look at the main method code to understand
* what it does and what you could use it for.
*
* try with:
* java WildcardExpansion *.*
* java WildcardExpansion "*.*"
* java WildcardExpansion s*.*
* java WildcardExpansion .
* java WildcardExpansion *.html
* java WildcardExpansion afile.txt anotherfile.txt
* java WildcardExpansion d?mmy.* (where you have dummy.* files and a
dummy dir)
* java WildcardExpansion t?mmy.* (where you don't have tummy.* files
or a tummy dir)
*
* My discoveries: For Win2K:
* Wildcards are automatically expanded before your program sees them.
* Who does it? Presumably the command processor or a Sun class.
* You get a list of matching files INCLUDING matching directory
names,
* but not the files in those subdirectories. Since directories
normally
* don't have extensions, you won't see the problem with *.html but
you will
* with s*.* or *.*.
* If the wildcard does not match anything, you get the raw wildcard.
* The wildcard in quotes gives you the raw wildcard.
* Author Roedy Green
* Version 1.0
*/

public class WildcardExpansion
{
/**
* Echo command line arguments, along with any automatic expansion
* Can be used to test wildcard expansion, quoting, or any other
basic features
* features of command line parsing.
*
* @param args whatever you want to test.
*/
public static void main ( String[] args )
{
System.out.println ( args.length + " arguments" );

for ( int i=0; i<args.length; i++ )
{
// [ ] help prove no lead/trail blanks tabs etc.
System.out.println( "[" + args + "]" );
}
}
}

Yep, Win2000's cmd.exe seems to expand wildcard commandline arguments,
not the JVM or the java.exe launcher. The expansion of 'd?mmy.*' to
include a directory without a dot in its name seems to be consistent
with the result of the command
dir d?mmy.*

The src.zip file in the JDK directory contains the C source of the Java
launcher (java.exe / javaw.exe). As far as I could see, the launcher
does not do any wildcard expansion. It does take care of handling the
launcher specific argument (like -classpath, -Xmx128m, -showversion,
etc.) and strips them from the arguments that eventually get passed to
the Java main method.

Looking at the C source also revealed that you can set the environment
variable _JAVA_LAUNCHER_DEBUG to enable logging of the launcher. Here's
an example of my trace:

C:\temp>dir d?mmy.*
Volume in drive C is NTFS
Volume Serial Number is E8DA-EAA9

Directory of C:\temp

26-06-2005 10:01 49 dammy.txt
26-06-2005 11:59 <DIR> dummy
31-12-2004 14:49 957 Dummy.java
26-06-2005 10:00 52 dummy.txt
3 File(s) 1.058 bytes
1 Dir(s) 1.285.324.800 bytes free

C:\temp>echo %CLASSPATH%
..;.;.;c:\PROGRA~1\Java\JMF21~1.1\lib\sound.jar;c:\PROGRA~1\Java\JMF21~1.1\lib\jmf.jar;c:\PROGRA~1\Java\JMF21~1.1\lib;%systemroot%\java\classes;.

C:\temp>set _JAVA_LAUNCHER_DEBUG=1

C:\temp>java -showversion -cp . WildcardExpansion d?mmy.*
----_JAVA_LAUNCHER_DEBUG----
Version major.minor.micro = 1.5.0
JRE path is C:\Program Files\Java\jre1.5.0
jvm.cfg[0] = ->-client<-
jvm.cfg[1] = ->-server<-
jvm.cfg[2] = ->-hotspot<-
name: -hotspot vmType: VM_ALIASED_TO alias: -client
jvm.cfg[3] = ->-classic<-
jvm.cfg[4] = ->-native<-
jvm.cfg[5] = ->-green<-
590 micro seconds to parse jvm.cfg
Default VM: client
JVM path is C:\Program Files\Java\jre1.5.0\bin\client\jvm.dll
4020 micro seconds to LoadJavaVM
JavaVM args:
version 0x00010002, ignoreUnrecognized is JNI_FALSE, nOptions is 3
option[ 0] =
'-Djava.class.path=.;.;.;c:\PROGRA~1\Java\JMF21~1.1\lib\sound.jar;c:\PROGRA~1\Java\JMF21~1.1\lib\jmf.jar;c:\PROGRA~1\Java\JMF21~1.1\lib;%systemroot%\java\classes;.'
option[ 1] = '-Djava.class.path=.'
option[ 2] = '-Dsun.java.command=WildcardExpansion dammy.txt dummy
dummy.java dummy.txt'
java version "1.5.0_04"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_04-b05)
Java HotSpot(TM) Client VM (build 1.5.0_04-b05, mixed mode)

88566 micro seconds to InitializeJVM
Main-Class is 'WildcardExpansion'
Apps' argc is 4
argv[ 0] = 'dammy.txt'
argv[ 1] = 'dummy'
argv[ 2] = 'Dummy.java'
argv[ 3] = 'dummy.txt'
34159 micro seconds to load main class
----_JAVA_LAUNCHER_DEBUG----
4 arguments
[dammy.txt]
[dummy]
[Dummy.java]
[dummy.txt]

C:\temp>
--
Regards,

Roland de Ruiter
` ___ ___
`/__/ w_/ /__/
/ \ /_/ / \

 

[Raymond DeCampo]

Portions of the essay are somewhat misleading. In Windows, it is not
the command interpreter or BAT language that expands the wildcards. It
is the application that is invoked that does the expanding. This
explains why wildcard expansion in Windows can be inconsistent from
program to program.

I am confused by one part of your essay:

- Oddly if you pass a wild card to any Java utility, the command
- processor expands the wildcards so that you program for *.* will see
- list of all the directories and all the files, one per arg slot.

Unless the directories have the a period character in the name, they
should not match the *.* wildcard expression. If this does happen
perhaps you have found a bug in the JVM.

try this out. I think you will be surprised.

As I said before, if directories without '.' in the name are matched by
*.*, that is a bug in the JVM.

BTW, if you would like to prove to yourself that the expansion is done
by the JVM and not the command processor, do not execute your programs
from the command processor. Use Runtime.exec() to invoke the java.exe
directly.

Ray

 

[Raymond DeCampo]

Portions of the essay are somewhat misleading. In Windows, it is not
the command interpreter or BAT language that expands the wildcards.
It is the application that is invoked that does the expanding. This
explains why wildcard expansion in Windows can be inconsistent from
program to program.

I am confused by one part of your essay:

- Oddly if you pass a wild card to any Java utility, the command
- processor expands the wildcards so that you program for *.* will see
- list of all the directories and all the files, one per arg slot.

Unless the directories have the a period character in the name, they
should not match the *.* wildcard expression. If this does happen
perhaps you have found a bug in the JVM.

try this out. I think you will be surprised.

/**
* Tests what sort of wildcard expansion happens automatically.
* It is very simple. Just look at the main method code to understand
* what it does and what you could use it for.
*
* try with:
* java WildcardExpansion *.*
* java WildcardExpansion "*.*"
* java WildcardExpansion s*.*
* java WildcardExpansion .
* java WildcardExpansion *.html
* java WildcardExpansion afile.txt anotherfile.txt
* java WildcardExpansion d?mmy.* (where you have dummy.* files and a
dummy dir)
* java WildcardExpansion t?mmy.* (where you don't have tummy.* files
or a tummy dir)
*
* My discoveries: For Win2K:
* Wildcards are automatically expanded before your program sees them.
* Who does it? Presumably the command processor or a Sun class.
* You get a list of matching files INCLUDING matching directory
names,
* but not the files in those subdirectories. Since directories
normally
* don't have extensions, you won't see the problem with *.html but
you will
* with s*.* or *.*.
* If the wildcard does not match anything, you get the raw wildcard.
* The wildcard in quotes gives you the raw wildcard.
* Author Roedy Green
* Version 1.0
*/

public class WildcardExpansion
{
/**
* Echo command line arguments, along with any automatic expansion
* Can be used to test wildcard expansion, quoting, or any other
basic features
* features of command line parsing.
*
* @param args whatever you want to test.
*/
public static void main ( String[] args )
{
System.out.println ( args.length + " arguments" );

for ( int i=0; i<args.length; i++ )
{
// [ ] help prove no lead/trail blanks tabs etc.
System.out.println( "[" + args + "]" );
}
}
}

Yep, Win2000's cmd.exe seems to expand wildcard commandline arguments,
not the JVM or the java.exe launcher. The expansion of 'd?mmy.*' to
include a directory without a dot in its name seems to be consistent
with the result of the command
dir d?mmy.*

The src.zip file in the JDK directory contains the C source of the Java
launcher (java.exe / javaw.exe). As far as I could see, the launcher
does not do any wildcard expansion. It does take care of handling the
launcher specific argument (like -classpath, -Xmx128m, -showversion,
etc.) and strips them from the arguments that eventually get passed to
the Java main method.

Looking at the C source also revealed that you can set the environment
variable _JAVA_LAUNCHER_DEBUG to enable logging of the launcher. Here's
an example of my trace:

C:\temp>dir d?mmy.*
Volume in drive C is NTFS
Volume Serial Number is E8DA-EAA9

Directory of C:\temp

26-06-2005 10:01 49 dammy.txt
26-06-2005 11:59 <DIR> dummy
31-12-2004 14:49 957 Dummy.java
26-06-2005 10:00 52 dummy.txt
3 File(s) 1.058 bytes
1 Dir(s) 1.285.324.800 bytes free

C:\temp>echo %CLASSPATH%
.;.;.;c:\PROGRA~1\Java\JMF21~1.1\lib\sound.jar;c:\PROGRA~1\Java\JMF21~1.1\lib\jmf.jar;c:\PROGRA~1\Java\JMF21~1.1\lib;%systemroot%\java\classes;.


C:\temp>set _JAVA_LAUNCHER_DEBUG=1

C:\temp>java -showversion -cp . WildcardExpansion d?mmy.*
----_JAVA_LAUNCHER_DEBUG----
Version major.minor.micro = 1.5.0
JRE path is C:\Program Files\Java\jre1.5.0
jvm.cfg[0] = ->-client<-
jvm.cfg[1] = ->-server<-
jvm.cfg[2] = ->-hotspot<-
name: -hotspot vmType: VM_ALIASED_TO alias: -client
jvm.cfg[3] = ->-classic<-
jvm.cfg[4] = ->-native<-
jvm.cfg[5] = ->-green<-
590 micro seconds to parse jvm.cfg
Default VM: client
JVM path is C:\Program Files\Java\jre1.5.0\bin\client\jvm.dll
4020 micro seconds to LoadJavaVM
JavaVM args:
version 0x00010002, ignoreUnrecognized is JNI_FALSE, nOptions is 3
option[ 0] =
'-Djava.class.path=.;.;.;c:\PROGRA~1\Java\JMF21~1.1\lib\sound.jar;c:\PROGRA~1\Java\JMF21~1.1\lib\jmf.jar;c:\PROGRA~1\Java\JMF21~1.1\lib;%systemroot%\java\classes;.'

option[ 1] = '-Djava.class.path=.'
option[ 2] = '-Dsun.java.command=WildcardExpansion dammy.txt dummy
dummy.java dummy.txt'
java version "1.5.0_04"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_04-b05)
Java HotSpot(TM) Client VM (build 1.5.0_04-b05, mixed mode)

88566 micro seconds to InitializeJVM
Main-Class is 'WildcardExpansion'
Apps' argc is 4
argv[ 0] = 'dammy.txt'
argv[ 1] = 'dummy'
argv[ 2] = 'Dummy.java'
argv[ 3] = 'dummy.txt'
34159 micro seconds to load main class
----_JAVA_LAUNCHER_DEBUG----
4 arguments
[dammy.txt]
[dummy]
[Dummy.java]
[dummy.txt]

C:\temp>

This analysis proves nothing. If you had bothered to look at the link
for MSDN on command line expansion you would have learned that MS
provides a library that does the command line wildcard expansion and
that all you have to do is link to it for the wildcards to be expanded
_before_ they are passed to your program. So, you cannot tell if
wildcards are expanded just by looking at the source code and you cannot
assume that the command processor is expanding wildcards by looking at
what is passed to main().

Ray

 

[Raymond DeCampo]

So this implies the JRE is calling setargv or equivalent for you. In
other words, the screw up is Sun's fault, not Microsofts that you
can't tell a wildcard expansion asking for ONLY *.* files, from a list
of directories and files to process keyed out longhand.

Huh? I expected you to be saying the opposite.

It is possible that to override setargv within your program by defining
it yourself. However, from the source code that Sun provides, it
appears they are not doing that. So the fault would lie in the default
implementation of setargv and my claim that it is a JVM bug was premature.

Ray

 

[Raymond DeCampo]

It depends how you define application. It is definitely no the java
app you write that does it. The argument are expanded before they hit
MAIN. It seems likely the JRE is doing it.

Well, application here means from the perspective of the command line
interpreter, which is the JRE. Yes, the arguments are expanded before
they hit main(), either the main() in Java or the C main() function for
the JRE. The wildcard expansion is done by setargv before the C main()
function is invoked. You control whether you want this for your (C/C++)
application by linking with a specific library that contains setargv.

Ray