Regexp question K&b

[Krishnamoorthy Sethuraman]

The first question in K&b book from chapter.6

import java.util.regex.*;
class Regex2 {
public static void main(String[] args) {
Pattern p = Pattern.compile(args[0]);
Matcher m = p.matcher(args[1]);
boolean b = false;
while(b = m.find()) {
System.out.print(m.start() + m.group());
}
}
}    

And the command line:
java Regex2 "\d*" ab34ef
What is the result?
A. 234
B. 334
C. 2334
D. 0123456
E. 01234456
F. 12334567
G. Compilation fails.

Answer given in book is E. Conceptually the answer is correct. But, when
I execute this in my machine, I don't get anyof the above answers. I have
this file in my D:\ drive under the folder :\work\java\scjp.

The first argument that is getting passed is not "\d*" in my case. But it
is "\downloads". downloads is one of my folder in D:\ drive. However
I'm in the d:\work\java\scjp directory. there is no folder by name "downloads" in this directory(d:\work\java\scjp).

The OS is windows XP. So, the above command line argument is "\d*" only
and not "\\d*"(i even tried the second parameter, which is interpreted by
java as "\\d*" and not "\d*", so no output in this case also).

My question is how to pass the parameter "\d*" in case of windows command
prompt. And the second question is why \d* expanded by the OS looks for
a directory under the root directory(D:\) and not the current directory(d:\work\java\scjp) from which the java was invoked.

Thanks,
Krishna.

[mambe nanje]

have u tried to pass the \d argument with no quotes and see, just consider that even the elements in the array passed in the main method are sent in with no quotes and it will give u a guide

[Krishnamoorthy Sethuraman]

quote is used to pass a argument containing spaces(from or by the shell to java) (as otherwise it will be split into two parts and be treated two different arguments). So, using or not using quote for a argument not containing space is not going to make any difference(tested this infact).

[mambe nanje]

in the K and b book the solution to that problem is specified somewhere that at times that will occur so go in to it and read

[mambe nanje]

the extract below is from the k and b book


A similar problem can occur when you hand metacharacters to a Java program
via command-line arguments. If we want to pass the \d metacharacter into our Java
program, our JVM does the right thing if we say
% java DoRegex "\d"
But your JVM might not. If you have problems running the following examples, you
might try adding a backslash (i.e. \\d) to your command-line metacharacters. Don't
worry, you won't see any command-line metacharacters on the exam!

[Krishnamoorthy Sethuraman]

Please don't reproduce the content from book. My question is different from
what you have understood. I'll better stop this thread.

[Bert Bates]

Hi Guys,

I think the general policy on this forum is that it's okay to display a question from a book or from a simulator, and that it's okay to display a paragraph or two from a similar source. The strong suggestion is that when you do that you should always credit the author of whatever content is being discussed. I think a thread like this one is totally acceptable. In fact, while can't speak for other authors, Kathy and I really like it when examples from our books are discussed here - even if sometimes you guys find an errata

So keep up the good discussions

Bert

[ak pillai]

just a work around:

c:\> java Regex2 \"\d*\" ab34ef

The slightly modified code as follows

import java.util.regex.*;
 
class Regex2 {
    public static void main(String[] args) {
       String strTemp =  args[0];
       String str1 = strTemp.replaceAll("\"", "");
       String str2  = args[1];
        
       System.out.println(str1);
       System.out.println(str2);
       
        Pattern p = Pattern.compile(str1);
        Matcher m = p.matcher(str2);
        boolean b = false;
        while (b = m.find()) {
            System.out.print(m.start() + m.group());
        }
    }
}

[Chris Allen]

I am a little confused on why the m.find() function always interrogates one position beyond the length of the string passed in. Is it because of the 0 to many identifier (the asterisk)? When I try it with \d+ instead, it does what I expect (produces 234 ). I would have expected the method to only go for as many positions that are available (i.e. only produce 0123445).

[Krishnamoorthy Sethuraman]

yes, it was because of the 0 to many modifer. A match on the empty string("") for the pattern \d* will give the first execution of match.find() as 0.