I am trying to use JSch. I tried the example here
Although I can connect the output is weird.
I get the following:
Last login: Thu Jan 31 19:44:25 2013 from 10.2.251.77
[1mcli:~ # [m
And if I do e.g. an ls I get:
[0m[01;34m.InstallAnywhere[0m [00m.bash_history [00m.bash_profile[0m
[01;34mbin[0m [00msles11-patched[0m
[01;34m.kbd[0m [00mindex.html[0m [00mtest.sql[0m
[00m.viminfo[0m [00;31mipvsadm-1.26-1.src.rpm[0m
[m[1mcli:~ # [m
These are the directory contents but why are they displayed like that?
I am running in this from Eclipse and this is what I see in Eclipse output. If I run this from Windows CMD it stucks
Update:
I noticed that if I connect to a different linux the output is fine!
Only if I connect to a specific linux installation I see these weird characters! Any idea what is causing this?
Update2:
Following the link of #PeterMmm I did printf "äöü" | xxd. Both the "bad" and good one give:
0000000: e4f6 fc
I also did locale.
In the "bad" case:
# locale
LANG=POSIX
LC_CTYPE=en_US.UTF-8
LC_NUMERIC="POSIX"
LC_TIME="POSIX"
LC_COLLATE="POSIX"
LC_MONETARY="POSIX"
LC_MESSAGES="POSIX"
LC_PAPER="POSIX"
LC_NAME="POSIX"
LC_ADDRESS="POSIX"
LC_TELEPHONE="POSIX"
LC_MEASUREMENT="POSIX"
LC_IDENTIFICATION="POSIX"
LC_ALL=
In the good system:
LANG=POSIX
LC_CTYPE=en_US.UTF-8
LC_NUMERIC="POSIX"
LC_TIME="POSIX"
LC_COLLATE="POSIX"
LC_MONETARY="POSIX"
LC_MESSAGES="POSIX"
LC_PAPER="POSIX"
LC_NAME="POSIX"
LC_ADDRESS="POSIX"
LC_TELEPHONE="POSIX"
LC_MEASUREMENT="POSIX"
LC_IDENTIFICATION="POSIX"
LC_ALL=
Configuration seems to be the same. So what could be causing this?
Please check
Funny Shell Output: [01;32mtestfile.txt[00m instead of testfile.txt
((ChannelShell) channel).setPtyType("dumb");
Does the trick.
They are escape sequences for the terminal emulation. I guess that there is no relation to the character encoding.
Update:
If ChannelShell#setPty(false) is invoked, a pseudo-terminal will not be allocated and escape sequences will not be appeared.
Channel channel=session.openChannel("shell");
((ChannelShell)channel).setPty(false); // !!
...
channel.connect();
Related
I am testing to see if ANTLR-4.7.1 is working properly by using a sample, provided by my professor, to match these results for the same printed set of tokens:
% java -jar ./antlr-4.7.1-complete.jar HelloExample.g4
% javac -cp antlr-4.7.1-complete.jar HelloExample*.java
% java -cp .:antlr-4.7.1-complete.jar org.antlr.v4.gui.TestRig HelloExample greeting helloworld.greeting -tokens
[#0,0:4='Hello',<1>,1:0]
[#1,6:10='World',<3>,1:6]
[#2,12:12='!',<2>,1:12]
[#3,14:13='<EOF>',<-1>,2:0]
(greeting Hello World !)
However, after getting to the 3rd command, my output was instead:
[#0,0:4='Hello',<'Hello'>,1:0]
[#1,6:10='World',<Name>,1:6]
[#2,12:12='!',<'!'>,1:12]
[#3,13:12='<EOF>',<EOF>,1:13]
In my output, there are no numbers inside < >, which I believe should be defined from the HelloExample.tokens file that contain:
Hello=1
Bang=2
Name=3
WS=4
'Hello'=1
'!'=2
I get no error information and antlr seemed to have generated all the files I needed, so I don't know where I should be looking to resolve this, please help. And I'm not sure if it'll be of use, but my working directory started with helloworld.greeting and HelloExample.g4 and final directory now contains
helloworld.greeting
HelloExample.g4
HelloExample.interp
HelloExample.tokens
HelloExampleBaseListener.class
HelloExampleBaseListener.java
HelloExampleLexer.class
HelloExampleLexer.inerp
HelloExampleLexer.java
HelloExampleLexer.tokens
HelloExampleListener.class
HelloExampleListener.java
HelloExampleParser$GreetingContext.class
HelloExampleParser.class
HelloExampleParser.java
As rici already pointed out in the comments, getting the actual rule names instead of their numbers in the token output is a feature and shouldn't worry you.
In order to get the (greeting Hello World !) output at the end, you'll want to add the -tree flag after -tokens.
I have some issues with getting the java version out as a string.
In a batch script I have done it like this:
for /f tokens^=2-5^ delims^=.-_^" %%j in ('%EXTRACTPATH%\Java\jdk_extract\bin\java -fullversion 2^>^&1') do set "JAVAVER=%%j.%%k.%%l_%%m"
The output is: 1.8.0_121
Now I want to do this for PowerShell, but my output is: 1.8.0_12, I miss one "1" in the end Now I have tried it with trim and split but nothing gives me the right output can someone help me out?
This is what I've got so var with PowerShell
$javaVersion = (& $extractPath\Java\jdk_extract\bin\java.exe -fullversion 2>&1)
$javaVersion = "$javaVersion".Trim("java full version """).TrimEnd("-b13")
The full output is: java full version "1.8.0_121-b13"
TrimEnd() works a little different, than you might expect:
'1.8.0_191-b12'.TrimEnd('-b12')
results in: 1.8.0_19 and so does:
'1.8.0_191-b12'.TrimEnd('1-b2')
The reason is, that TrimEnd() removes a trailing set of characters, not a substring. So .TrimEnd('-b12') means: remove all occurrences of any character of the set '-b12' from the end of the string. And that includes the last '1' before the '-'.
A better solution in your case would be -replace:
'java full version "1.8.0_191-b12"' -replace 'java full version "(.+)-b\d+"','$1'
Use a regular expression for matching and extracting the version number:
$javaVersion = if (& java -fullversion 2>&1) -match '\d+\.\d+\.\d+_\d+') {
$matches[0]
}
or
$javaVersion = (& java -fullversion 2>&1 | Select-String '\d+\.\d+\.\d+_\d+').Matches[0].Groups[0].Value
So I have the following command that runs java application from the command line and produces a bunch of output.
java -jar client.jar --server test7.contoso.com --alternativeemailaddress fred1#contoso.com --organisation contoso --emailaddress fred#contoso.com --data1 1234 --Password1 123456 --data2 1234 --Password2 1234
I'm trying to run this from within PowerShell and capture the output to a variable for further processing.
So far I've found 100's of different ways to do this, but none have really worked particularly well.
Is there any best practice/convention as to how to get this done?
See: https://blogs.technet.microsoft.com/josebda/2012/03/03/using-windows-powershell-to-run-old-command-line-tools-and-their-weirdest-parameters/
For many ways to execute "legacy" commands with PowerShell
You need to include the .exe for one.
The new V3+ recommended way is to use --% to tell PowerShell to not parse the remaining arguments
PS> java.exe --% -jar client.jar --server test7.contoso.com --alternativeemailaddress fred1#contoso.com --organisation contoso --emailaddress fred#contoso.com --data1 1234 --Password1 123456 --data2 1234 --Password2 1234
OK so I worked it out. This is what I went with.
$params = #{ 'jar'='C:\client\client.jar';
'param1'='data1'
'param2'='data2'
'param3'='data3'
'param4'='data4'
'param5'='data5'
'param6'='data6'
'param7'='data7'
'param8'='data8'
'param9'='data9'
'param10'='data10'
'error_log'='C:\tmp\error_log.txt'
}
$data = & 'C:\Program Files\java\jdk1.8.0_121\bin\java.exe' -jar $params.'jar' `
--param1 $params.param1 `
--param2 $params.param2 `
--param3 $params.param3 `
--param4 $params.param4 `
--param5 $params.param5 `
--param6 $params.param6 `
--param7 $params.param7 `
--param8 $params.param8 `
--param9 $params.param9 `
--param10 $params.param10 `
2>$params.error_log
I would linke to call java app from PHP:
exec('LC_ALL=en_US.utf-8 java -jar /test.jar' . $filepath . ');
But always there are unsupported characters in the file path.
For example: # & ; ? * [SPACE]..., after change them to # \& ... it will be ok.
But a full list of these characters could not be find.
Any ideas to solve this problem?
Take a look at escapeshellarg() and escapeshellcmd().
They will take care of all necessary sanitation for you.
If $filepath comes from the outside (e.g. from user input), running escapeshellarg() is mandatory to prevent injections.
My problem resolved.
Useful url:
http://bugs.php.net/bug.php?id=44945
In documentation code I see some things like this:
/*
* #(#)File.java 1.142 09/04/01
what does characters like #(#) meaning?
#(#) is the character string used by the Unix what command to filter strings from binaries to list the components that were used to build that binary. For instance what java on AIX yields:
java:
23 1.4 src/bos/usr/ccs/lib/libpthreads/init.c, libpth, bos520 8/19/99 12:20:14
61 1.14 src/bos/usr/ccs/lib/libc/__threads_init.c, libcthrd, bos520 7/11/00 12:04:14
src/tools/sov/java.c, tool, asdev, 20081128 1.83.1.36
src/misc/sov/copyrght.c, core, asdev, 20081128 1.8
while `strings java | grep '#(#)' yields:
#(#)23 1.4 src/bos/usr/ccs/lib/libpthreads/init.c, libpth, bos520 8/19/99 12:20:14
#(#)61 1.14 src/bos/usr/ccs/lib/libc/__threads_init.c, libcthrd, bos520 7/11/00 12:04:14
#(#)src/tools/sov/java.c, tool, asdev, 20081128 1.83.1.36
#(#)src/misc/sov/copyrght.c, core, asdev, 20081128 1.8
#(#) was chosen as marker because it would not occur elsewhere, source code controls systems typically add a line containing this marker and the description of the file version on synchronisation, expanding keywords with values reflecting the file contents.
For instance, the comment you list would be the result of expanding the SCCS keywords %Z% %M% %R%.%L% %E% where the %Z% translates into #(#).
From (hazy) memory, that was the tag used by SCCS back in the "good old days". Given that (to my knowledge), BitKeeper uses SCCS underneath, it could be BitKeeper.
It is usually something that is added automatically by the version control system.
That construct has no special meaning in Java. It is just some text in a comment.
It looks like something that's inserted by a version control system.