Doubt in question 1 chapter 6 of K&B SCJP 5 Study Guide

Hi all,

I could not get the question 1 of chapter 6 in K&B scjp 5.0 study guide working. Can someone explain whats missing?

Here's is the question:

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

Answer is:
E. 01234456

But when i run this code there is nothing printed out. The matcher m does not return true on find().

But if use the regex pattern "\d?" for the same program then i do get an o/p as:
012334456

Though the logic explained in the book for the pattern "\d*" seems reasonable but i am not sure what is wrong about the code that m.find() returns false always.

Any explanation is much appreciated.

Thanks
Watsh

Originally posted by Watsh Rajneesh:
Hi all,

I could not get the question 1 of chapter 6 in K&B scjp 5.0 study guide working. Can someone explain whats missing?

Here's is the question:

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

Answer is:
E. 01234456

But when i run this code there is nothing printed out. The matcher m does not return true on find().

But if use the regex pattern "\d?" for the same program then i do get an o/p as:
012334456

Though the logic explained in the book for the pattern "\d*" seems reasonable but i am not sure what is wrong about the code that m.find() returns false always.

Any explanation is much appreciated.

Thanks
Watsh

I Could get this program return the answer in E with the use of possessive quantifier:
java Regex2 "\d*+" ab34ef

But possessive and reluctant quantifiers are not part of the exam so i think the question can be changed to use the pattern "\d?" instead and the correct answer will be 012334456 which forms none of the options mentioned.

I ran the program and got the output 01234456. Try to run it again. Perhaps you forgot to give inputs through command line parameters ?

Originally posted by John Meyers:
I ran the program and got the output 01234456. Try to run it again. Perhaps you forgot to give inputs through command line parameters ?

Thanks for trying out. I do get the output 01234456 when using "\d*+" as the regex pattern to match for the input source ab34ef but i dont get any o/p when using "\d*" as pattern. Its strange how "\d*" works at your end. I dont have an explanation for why "\d*" (greedy) does not work but "\d*+" (possessive) works.

The o/p for pattern "\d?" is 012334456.
and for "\d+" is 234.

Did you try "\d*" itself and not "\d*+" as pattern to match?

Thanks for your help.

I had some results with/without double quotes around regular-expression.

Cases without double quotes:

1) java Regex2 \d*+ ab34ef prints 01234456
2) java Regex2 \d* ab34ef prints nothing
3) java Regex2 \d? ab34ef prints 012334456
4) java Regex2 \d+ ab34ef prints 234

Cases with double quotes:

1) java Regex2 "\d*+" ab34ef prints 01234456
2) java Regex2 "\d*" ab34ef prints 01234456
3) java Regex2 "\d?" ab34ef prints 012334456
4) java Regex2 "\d+" ab34ef prints 234

Thanks everyone for responding.. the difference in our results was due to the fact that i have been using cygwin bash shell and when i tested the program from the WIN CMD shell then i got the result correct. But its an interesting find that the same command arguments are passed differently on these two shells to the same java program. Here's the result for comparison:

On win cmd shell:
Cases without double quotes:

1) java Regex2 \d*+ ab34ef prints 01234456
2) java Regex2 \d* ab34ef prints nothing
3) java Regex2 \d? ab34ef prints 012334456
4) java Regex2 \d+ ab34ef prints 234

Cases with double quotes:

1) java Regex2 "\d*+" ab34ef prints 01234456
2) java Regex2 "\d*" ab34ef prints 01234456
3) java Regex2 "\d?" ab34ef prints 012334456
4) java Regex2 "\d+" ab34ef prints 234

On cygwin bash shell:

Cases without double quotes:

1) java Regex2 \d*+ ab34ef prints 0123456
2) java Regex2 \d* ab34ef prints 0123456
3) java Regex2 \d? ab34ef prints 0123456
4) java Regex2 \d+ ab34ef prints nothing

Cases with double quotes:

1) java Regex2 "\d*+" ab34ef prints 01234456 (same as win)
2) java Regex2 "\d*" ab34ef prints nothing
3) java Regex2 "\d?" ab34ef prints 012334456 (same as win)
4) java Regex2 "\d+" ab34ef prints 234 (same as win)

Program behaving differently on two shells for following cases:
1) java Regex2 \d*+ ab34ef
2) java Regex2 \d* ab34ef
3) java Regex2 \d? ab34ef
4) java Regex2 \d+ ab34ef
5) java Regex2 "\d*" ab34ef

From now on i will know to check on both before shells before raising a red flag

.

Thanks everyone for your help.

Again it will be interesting to know how the bash shell on linux behaves for this program. I dont have a linux setup so someone who has can give it a shot and share the result with us atleast for the following:

java Regex2 "\d*" ab34ef

where, cygwin bash shell prints nothing while win cmd prints 01234456.

There is the very strange situation.
The program prints nothing instead of expected answer (or it depends on types of shell and operation system - it very strange for java language).

Can someone explain the reason?

And can someone explain \d*+ regexp. Why it works correct instead of \d* ?

Alexander Shrago wrote:There is the very strange situation.
The program prints nothing instead of expected answer (or it depends on types of shell and operation system - it very strange for java language).

Can someone explain the reason?

And can someone explain \d*+ regexp. Why it works correct instead of \d* ?

First, you do know that this is a six year old topic, and that most of the ranchers in this conversation has likely moved on, right? Second, since the ranchers with the issues are not here, we can only speculate -- although, I am surprised that no one mentioned this six years ago.

With the bash shell (actually, with most of the unix shells), double quote do not prevent file globbing. The shell will do a file pattern match, and replace the pattern with the list of files that match. So.... I would speculate that the reason "\d*" didn't work was because the OP had a file in the current directory that started with the letter "d", and the shell replaced the regex pattern with a list of the matching files. I also speculate that the reason the patterns "\d?" and "\d*+" did work. was because the filenames was not two letters long, nor did it end with the plus sign -- when the shell fails to match, it keeps the original pattern.

And..... this has nothing to do with Java. File globbing is done prior to executing the command on the command line. The program (in this case, the JVM) don't see the original pattern when it has been replaced with the matching list of files.

Henry

Watsh Rajneesh wrote:Again it will be interesting to know how the bash shell on linux behaves for this program. I dont have a linux setup so someone who has can give it a shot and share the result with us atleast for the following:

java Regex2 "\d*" ab34ef

where, cygwin bash shell prints nothing while win cmd prints 01234456.

The cygwin bash shell, like the standard unix bash shell, supports file globbing (as already mentioned). The windows cmd shell does not. And since cygwin is a windows program, I would not be surprised if there is also a weird interaction going on too.

Henry

Henry Wong wrote:

Alexander Shrago wrote:There is the very strange situation.
The program prints nothing instead of expected answer (or it depends on types of shell and operation system - it very strange for java language).

Can someone explain the reason?

And can someone explain \d*+ regexp. Why it works correct instead of \d* ?

First, you do know that this is a six year old topic, and that most of the ranchers in this conversation has likely moved on, right? Second, since the ranchers with the issues are not here, we can only speculate -- although, I am surprised that no one mentioned this six years ago.

With the bash shell (actually, with most of the unix shells), double quote do not prevent file globbing. The shell will do a file pattern match, and replace the pattern with the list of files that match. So.... I would speculate that the reason "\d*" didn't work was because the OP had a file in the current directory that started with the letter "d", and the shell replaced the regex pattern with a list of the matching files. I also speculate that the reason the patterns "\d?" and "\d*+" did work. was because the filenames was not two letters long, nor did it end with the plus sign -- when the shell fails to match, it keeps the original pattern.

And..... this has nothing to do with Java. File globbing is done prior to executing the command on the command line. The program (in this case, the JVM) don't see the original pattern when it has been replaced with the matching list of files.

Henry

i think the double quote characters( " " ) will escape any special character but not the $ sign on bash or any other linux shell.

gurpeet singh wrote:

i think the double quote characters( " " ) will escape any special character but not the $ sign on bash or any other linux shell.

Good point. I got the substitution of filenames mixed up with the substitution of variable values. Never mind. Sorry of the distraction.

Henry