I'm trying to write a python program to test a java program that takes input from stdin using Scanner.
All other posts point to using communicate with popen, but for me it absolutely does not work. When i run my python program, it just calls popen and then stops while the java program waits for input. I wrote a print statement after popen to check. It never prints.
Its very simple. I just want to give this program that waits for input some input.
here is the code:
import os.path, subprocess
from subprocess import PIPE
p = subprocess.Popen(['java', 'Main'], stdin=PIPE, stdout=PIPE)
print 'after subprocess' #this never get's printed
output = p.communicate(input='5 5 4 3 2 1'.encode())[0]
print output
Without more information (like some sample Java code) it's hard to be sure, but I'll bet the problem is that the Java code is waiting for a complete line, and you haven't sent one.
If so, the fix is simple:
output = p.communicate(input='5 5 4 3 2 1\n'.encode())[0]
As a side note, why exactly are you calling encode on that string? It's already encoded in whatever character set your source code uses. So, when you call encode, it has to first decode that to Unicode. And then, because you didn't pass an argument to encode, it's going to encode it to your default character set (sys.getdefaultencoding()), which doesn't seem any more likely to match what the Java code is expecting than what you already have. It's rarely worth calling encode with an argument, and you should almost* never call it on a str, only a unicode.
* In case you're wondering, the exception is when you're using a handful of special codecs like hex or gzip. In Python 3, they decided that the occasional usefulness of those special cases was nowhere near as much as the frequent bug-magnet of calling encode on already-encoded strings, so they took it out of the language.
Related
I'm utilizing this line codes
String string = "Some usefull information − don't know what happens with my output";
System.out.println(string);
String str2verify = driver.findElement(By.xpath("//someWellFormXpath")).getText();
Assert.assertEquals(str2verify , "Some usefull information − don't know what happens with my output");
And I'm getting this in my console, so if I want to use equals function doesn't work.
Output
Some usefull information ? don't know what happens with my output
expected [Some usefull information ? don't know what happens with my outputS] but found [Some usefull information − don't know what happens with my output]
java.lang.AssertionError: expected [Some usefull information ? don't know what happens with my outputS] but found [Some usefull information − don't know what happens with my output]
This is the process:
You write some text. In an editor. That is showing strings to you.
You save your file. files are bytes, not characters, so your editor is applying a charset encoding to do this. Which one? Your editor will know, you didn't mention which one you use so I can't tell you.
Javac reads your file. files are bytes, but javac needs characters, so javac is applying a charset encoding to do this. Which one? "The platform default", unless you use the -encoding parameter / the tool you are using that calls javac has a way to tell it which -encoding parameter to use.
Javac emits class files. These are byte based so this doesn't require encoding.
Your java JVM runs your class file. As part of running, a string is printed to standard out.
System.out refers to 'standard out'. These things are, on pretty much every OS, a stream of bytes. Meaning, when you send strings there, the JVM first encodes your string using some charset encoding, then it goes to standard out.
Something is connected to the other end of standard out and sees these bytes. These convert the bytes back to a string, also using some encoding.
The characters are sent to the font rendering engine on your OS. Even if the character 'survived' all those conversions back and forth, it is possible your font doesn't have a glyph for it. The intent is clearly for that character to be an emdash (a dash that is as long as the letter 'm' - the standard 'minus' character is an ndash, not the same thing; that one is a bit shorter).
Count em up - that's like 6 conversions. They all need to be using the same charset encoding. So, check that your editor and javac agree on what charset encoding your source file is in. Then, check that the console thing that is showing the string is in agreement with standard out (which should be 'platform default', whatever that might be), then, check if the font you use has emdash.
PrintStream ps = new PrintStream(System.out, true, "UTF-8");
Then write to ps, not System.out - that's how you can explicitly force some charset to be used when writing to output.
It turns that em dash doesn't have a representation in cp-1252 charset encoding, so at the end I have to change to UTF-8 all my files in the project to be able to save this character.
It was a pain in the brain this encoding issue.
Thanks for all the suggestions friends.
I have a straight forward (except the question) task to be implemented on JVM language.
This is a simple command line program which expects some input from user and outputs result to console.
The confusing part to me is the following sentence "STD input: input ends when an empty line is received or you reach the end of the input stream".
The part with empty line is received I understood as user started the program from console and the program expects the user to enter the data by hand and empty line at the end:
$ java Main.class
Enter your data:
data1
data2
Result:
result1
result2
The program closes the console reader after user submitted empty line, processes data and prints the result to the console.
Please correct me if I'm wrong.
Although, the you reach the end of the input stream part is more vague to me. This makes me think that the program takes a whole input stream as argument.
In java it might look like this:
java Main.class file.txt
Is this what it really means?
This would make more sense in terms of testing my submitted code. The person who validates the correctness will execute my class against bunch of text classes and read the output of my program.
And again, if so, how would people automate the reading validation of the console output from a program?
What does the phrase "input ends when an empty line is received or you reach the end of the input stream" might mean? Should I cover both cases when user inputs data by hand and the case with file input stream?
As #NomadMaker said in the comments, input can be piped. Check out this article for more details on this.
I have an interesting problem here.
First I have a UI in Java. The UI at one point connects to a rpi4 on the network via a socket. From there data is sent over the socket using .writeUTF(string).
On the rpi4 side, I'm running a simple Python 3 script. Its sole purpose is to spit out anything that comes over the socket and it does. But before it does I use recv.decode('utf-8') to decode the string.
From Java I send "fillOpen"
In python after decoding it prints "fillOpen"
The issue:
Performing a string compare in the python script on the decoded string always results in false. I have set it up as such:
Command = recv.decode('utf-8')
If Command == "fillOpen":
#Do work
I have also tried to not decode the string and compare to an encoded string. As such:
Command = recv
FillOpenCommand =
("fillOpen").encode('utf-8')
If fillOpenCommand == Command:
#Do work
None of these comparisons result in true.
I have read that the Java writeUTF is a UTF8 encoding but slightly "different"?
Can I adjust the .writeUTF to work with the Python 3 decoder? Is there an alternative for sending data that can be parsed then have a string comp applied via Python that would work?
Thank you guys.
Assuming you are using the writeUTF method as defined in the Java DataOutput interface:
The output from writeUTF starts with two bytes of length information. You can skip it or you can use it to make sure you have received a complete message.
The easiest thing to do is to skip it:
Command = recv[2:].decode('utf-8')
If your commands are simply ASCII and don't contain things like user input, emojis, musical notation, this is good enough. Otherwise, you still have a problem. The way writeUTF handles "surrogate pair" characters is not valid "utf-8", and decode('utf-8') will throw a UnicodeDecodeError. If I were you, in this case I would stop using writeUTF and start using methods that produce standard UTF-8 encoded data.
I was processing some data tweeter using java. I read them from the file, do some process and print to the stdout.
The text in file looks like this:
"RT #Bollogosta319a: #BuyBookSilentSinners \u262fGain Followers\n\u262fRT This\n\u262fMUST FOLLOW ME I FOLLOW BACK\n\u262fFollow everyone who rts\n\u262fGain\n #ANDROID \u2026"
I read it in, and print it out to stdout. The output is supposed to be:
"RT #Bollogosta319a: #BuyBookSilentSinners ☯Gain Followers\n☯RT This\n☯MUST FOLLOW ME I FOLLOW BACK\n☯Follow everyone who rts\n☯Gain\n #ANDROID …"
But my output is like this:
"RT #Bollogosta319a: #BuyBookSilentSinners ?Gain Followers
?RT This
?MUST FOLLOW ME I FOLLOW BACK
?Follow everyone who rts
?Gain
#ANDROID ?"
So, it seems that I have two problems to deal with:
1. print the exact Unicode character instead of Unicode string
2. keep "\n" as it is, instead of a newline in the output.
How can I do this? (I'm really crazy about dealing with different coding in Java)
I don't know how you are parsing the file, but the method you are using seems to be interpreting escape codes (like \n and \u262f). To leave instances of \n in the file literally, you could replace \n with \\n prior to using whatever means of interpreting the escape codes. The \\ will be converted to a single \, and the n will be left alone. Have you tried using a plain java.io.FileReader to read the file? That may be simpler.
The Unicode symbols may actually be read correctly; many terminals do not support the full range of Unicode characters and print some symbol in place of those it does not understand. Perhaps your program prints ☯ and the terminal simply doesn't know how to render it, so it prints a ? instead.
this is my first post. I am excited to a part of this community and I have been struggling with this problem for a while, so here goes:
In the following code:
if (j == 0)
{
if (!Arrays.equals(cipherData, c))
{
System.out.print("C: ");
for (int i = 0; i < encryptedData.length; i++)
System.out.print((char)cipherData[i]);
System.out.println();
}
}
The System.out.println()
method returns nothing at all. No line, or anything and I have no idea why. The goal is to print a blank line after printing the byte array is printed above when those if conditions are true.
Any help would be much appreciated and welcome.
System.out.print() does not print a newline character.
You're outputting a bunch of stuff, then printing a newline with System.out.println(). This causes the cursor to drop to the next line.
You need another one if you want a blank line after that.
Edit to add: I missed the fact that your for loop conditional is ... different than the array you're printing. Did you mean for that to be the case?
Also, since you're possibly printing non-printable characters, it is completely plausible that you're causing the terminal to be in a state where the newline will no longer work.
What it comes down to is, println() isn't broken. Either it's not getting called, or if you don't see a newline occur when it is called then the terminal is in a state where it no longer recognizes it.
Check
http://docs.oracle.com/javase/6/docs/api/java/io/PrintStream.html#println()
You may need System.out.print('\n');
Before iterating for loop you can check length of encryptedData
System.out.println("encryptedData.length:: "+ encryptedData.length);
if encryptedData.length return greater than 1 then it will go into for loop.
You should debug step by step .
I have concerns about this:
System.out.print((char)cipherData[i]);
Assuming that cipherData is an array of bytes, then casting a byte to a char and printing it via a character stream is not likely to give pretty results. For a start, bytes that are less that 32 decimal will map to ASCII "control characters".
And also you may be printing the wrong array ... or using the length of the wrong array.
(But the explanation for your problem is that you need to call println a second time to be a blank line. The first println is just terminating the line containing the ... umm ... "characters" from your cipher array.)
Sounds like the problem is that you have run a JVM without any standard output attached. Like on Windows, using javaw.exe to run a jar (which is the default, beware). Java.exe outputs to the console window, if you run it from a console, but javaw.exe does not. If you run the program from the file explorer window, even though you are using java.exe, you still won't get any standard out, because it's hidden by windows.
So, run the program in a command line window, and use java.exe, not javaw.exe.