Michael Hall wrote:
>This obviously only is a concern because it's the shell and not chmod
>being exec'd.
Correct.
>What is still unclear to me is whether that is necessary for the Runtime
>exec with the Japanese characters to work correctly. I have OS X specific
>code where I Runtime chmod. If this represents a way to rather simply
>localize the code better I would be interested in knowing how I might use
>it.
What does "that" in "whether that is necessary" refer to?
Do you mean "Is proper quoting necessary?" If so, the answer is "Only for
a shell."
If you mean something else, please explain exactly what you're asking for.
>But, will UTF-8 encoding the filename passed to chmod be sufficient for it
>to work?
The question doesn't make sense. Where would this encoding occur?
If you exec() an array of Java Strings, then each String is already an
array of Java chars (the primitive Java type 'char', a UTF-16 code-point).
Somewhere deep in the native implementation of the exec() method, some code
will convert the Java Strings to UTF-8 (or whatever is appropriate for the
platform), but you would never have to do this conversion yourself. That's
why Runtime.exec() takes String args, not byte[] args.
So no, you don't have to perform any special encoding on any filenames
passed to chmod.
Besides, you can't do any special encoding, to UTF-8 or anything else,
because a Java String consists of 16-bit Java chars, and UTF-8 is an
encoding as 8-bit bytes. Since there is no version of Runtime.exec() that
takes byte[] args, it's impossible to pass it UTF-8 args.
>Or do you in fact have to UTF-8 encode the entire command and pass
>that to a Runtime exec of the shell?
Again, if you are passing String args to exec(), you would never have to
manually convert any String arg to UTF-8, since you can't pass a byte[] to
exec().
However... If, as originally posted, the exec() actually starts a shell
Process which is reading its standard input for the command-line, then yes,
you *DO* have to encode the command-line stream to the shell as UTF-8. How
you do that is up to you. You can use String.getBytes( "UTF-8" ) and write
the bytes from the byte[]. You can also make an OutpuStreamWriter on the
Process's OutputStream that encodes to UTF-8, and then write Strings to the
Writer.
One could also use the -c option to the shell, which tells it to interpret
the next arg as its command-line input. Then you don't convert to UTF-8,
for the same reason you don't convert any String to UTF-8 before exec().
I have used the -c option with some pretty big Strings as "scripts"
(including conditionals and loops), and it all works fine, as long as you
get the quoting, escaping, and command-endings right (; or \n).
-- GG
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Java-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/java-dev/email@hidden
This email sent to email@hidden
