Hello Atsuhiko,
Thanks! That solution makes sense.
I just have one suggestion that solves two issues IMHO:
(1) With your solution, the HashMap can now either hold a
String->String Mapping, or a Byte->Byte Mapping, right?
It means that just in case you'd ever want to switch
to Java 1.5 and Generics you couldn't port this because
it's polymorphic.
I'd thus suggest doing
> ((ChannelShell)channel).setEnv(env);
> ((ChannelShell)channel).setEnvAsBytes(envAsBytes);
Internally, you could maintain a single hashmap with
bytes and have the "String" version fallback to convert
to bytes earlier (when setting it).
(2) With your solution, signature of ChannelShell remains
exactly the same, so if I as a client don't know exactly
what JSch version I'm dynamically linked against, I don't
know if I'm allowed to set byte[] or not. There is also
no exception being thrown by older JSch.
That's another reason why I'd be proposing new
setEnvAsBytes() method.
Cheers,
--
Martin Oberhuber, Senior Member of Technical Staff, Wind River
Target Management Project Lead, DSDP PMC Member
http://www.eclipse.org/dsdp/tm
> -----Original Message-----
> From: Atsuhiko Yamanaka [mailto:[EMAIL PROTECTED]
> Sent: Donnerstag, 10. April 2008 04:11
> To: Oberhuber, Martin
> Cc: [email protected]
> Subject: Re: [JSch-users] ChannelShell.setEnv() cannot
> transport variables inremote encoding different than local
>
> Hi,
>
> +-From: "Oberhuber, Martin" <[EMAIL PROTECTED]> --
> |_Date: Thu, 10 Apr 2008 01:46:41 +0200 _______________________
> |
> |Assume that my remote Linux box uses UTF-8 encoding and
> my local Windows
> |box uses Cp1252 default encoding.
> |I'd like to open a ChannelShell session on the remote,
> end set some
> |default environment variables including Unicode Characters.
> ...
> |which uses the local Platform default encoding to encode
> the Strings, so
> |I cannot pass my UTF-8 Strings onto the Wire.
>
> |It's not a very big problem because most SSH daemons have disabled
> |environment setting support anyways,
> |but still it's not nice that this feature is missing.
>
> Accroding to RFC4254[1],
>
> 6.4. Environment Variable Passing
> Environment variables may be passed to the shell/command to be
> started later. Uncontrolled setting of environment
> variables in a
> privileged process can be a security hazard. It is
> recommended that
> implementations either maintain a list of allowable
> variable names or
> only set environment variables after the server process
> has dropped
> sufficient privileges.
>
> byte SSH_MSG_CHANNEL_REQUEST
> uint32 recipient channel
> string "env"
> boolean want reply
> string variable name
> string variable value
>
> it seems that we are allowed to send 'name' and 'value' in our
> favorite encoding.
>
> So, I have changed the internal and you can also set name and value
> in byte[] in the next release. I mean that,
>
> java.util.Hashtable env=new java.util.Hashtable();
> env.put(name.getBytes(yourEncoding),
> value.getBytes(yourEncoding));
> ((ChannelShell)channel).setEnv(env);
>
> channel.connect();
>
> Sincerely,
> --
> Atsuhiko Yamanaka
> JCraft,Inc.
> 1-14-20 HONCHO AOBA-KU,
> SENDAI, MIYAGI 980-0014 Japan.
> Tel +81-22-723-2150
> +1-415-578-3454
> Fax +81-22-224-8773
> Skype callto://jcraft/
>
-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
JSch-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/jsch-users
