<small id='UciB2'></small><noframes id='UciB2'>

  1. <legend id='UciB2'><style id='UciB2'><dir id='UciB2'><q id='UciB2'></q></dir></style></legend>
      • <bdo id='UciB2'></bdo><ul id='UciB2'></ul>

    1. <i id='UciB2'><tr id='UciB2'><dt id='UciB2'><q id='UciB2'><span id='UciB2'><b id='UciB2'><form id='UciB2'><ins id='UciB2'></ins><ul id='UciB2'></ul><sub id='UciB2'></sub></form><legend id='UciB2'></legend><bdo id='UciB2'><pre id='UciB2'><center id='UciB2'></center></pre></bdo></b><th id='UciB2'></th></span></q></dt></tr></i><div id='UciB2'><tfoot id='UciB2'></tfoot><dl id='UciB2'><fieldset id='UciB2'></fieldset></dl></div>
    2. <tfoot id='UciB2'></tfoot>
    3. Windows 上 Java7 命令行的通配符扩展损坏(7?)

      时间:2024-08-25
        <bdo id='sfJJ3'></bdo><ul id='sfJJ3'></ul>

          <i id='sfJJ3'><tr id='sfJJ3'><dt id='sfJJ3'><q id='sfJJ3'><span id='sfJJ3'><b id='sfJJ3'><form id='sfJJ3'><ins id='sfJJ3'></ins><ul id='sfJJ3'></ul><sub id='sfJJ3'></sub></form><legend id='sfJJ3'></legend><bdo id='sfJJ3'><pre id='sfJJ3'><center id='sfJJ3'></center></pre></bdo></b><th id='sfJJ3'></th></span></q></dt></tr></i><div id='sfJJ3'><tfoot id='sfJJ3'></tfoot><dl id='sfJJ3'><fieldset id='sfJJ3'></fieldset></dl></div>

              <small id='sfJJ3'></small><noframes id='sfJJ3'>

                <tbody id='sfJJ3'></tbody>

            • <tfoot id='sfJJ3'></tfoot>
            • <legend id='sfJJ3'><style id='sfJJ3'><dir id='sfJJ3'><q id='sfJJ3'></q></dir></style></legend>
                本文介绍了Windows 上 Java7 命令行的通配符扩展损坏(7?)的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着跟版网的小编来一起学习吧!

                问题描述

                我观察到 Windows 上 Java7 通配符扩展行为的奇怪行为.

                几个世纪以来,*"与 * 之间有着明显的区别.
                对于 Java7(至少在 Windows7 上)来说,这似乎不再适用.

                我在使用 通配符类路径.
                尽管引用了通配符类路径,但它得到了扩展.
                因此,似乎不可能再将通配符传递给 java 应用程序.

                所以使用 java -cp "somewhere/*" 会失败(就像 "somewhere*" 一样).

                一种解决方法似乎是:java -cp "somewhere/*;" 抑制扩展.

                为了验证行为,我编写了一个小的 Echo.java 类.

                我发现使用 java 1.6.0 引用的*"和普通 * 可以正常工作,而在 Java7 上,我总是得到扩展的通配符.到目前为止,在 Windows7 上观察到了这种情况,不知道在 XP 上会发生什么.

                问题出现了,因为 Windows 上的通配符永远不会被黑暗时代的 CMD.EXE 扩展(就像 UNIX 上的任何 shell 一样).相反,每个可执行文件都必须使用 setargv.obj 显式执行此操作.p>

                我发现两个相关的问题似乎描述了一个类似的问题:

                • 多个命令行通配符扩展让 Windows 用户感到困惑
                • setargv.obj 通配符处理损坏

                这是其他人观察到的吗?
                或者是否有一些模糊的 Windows 或批处理文件设置来控制它?

                迪特.

                解决方案

                是的,我注意到了同样的问题.

                • Java7 的发行说明中将其解释为已知问题"更新 4.

                • 这是错误报告.该修复程序将在 Java7 更新 8 中提供(当前版本为更新 6).

                • 请注意,没有 shell-options 解决方法,因为在 Windows 中,shell 不处理通配符扩展.(而在 Unix 中,shell 执行扩展).

                I observe a strange behavior of wildcard expansion behavior for Java7 on Windows.

                For centuries there was a clean difference between "*" versus *.
                Seems this it not longer true for Java7 (at least on Windows7).

                I noticed the problem when using a wildcard classpath.
                In despite of quoting the wildcard-classpath it gets expanded.
                Thus it seems not possible any more to pass a wildcard to the java application.

                So using java -cp "somewhere/*" will fail (as does "somewhere*").

                A workaround seems to be: java -cp "somewhere/*;" which inhibits the expansion.

                To verify the behavior I wrote a small Echo.java class.

                I found that using java 1.6.0 quoted "*" and plain * works like expected, whereas on Java7 I always got the expanded wildcard. Until now this was observed on Windows7, don't know what happens on XP.

                The problem arises, since wildcards on Windows are never ever expanded by dark age CMD.EXE (like any shell does on UNIX). Instead each executable has to perform this explicitly using setargv.obj.

                I found two related issues which seem to describe a similar problem:

                • Multiple command line wildcard expansion confuses Windows users
                • setargv.obj wildcard handling broken

                Is this observed by someone else?
                Or are there some obscure Windows or batch-file settings to control this?

                Dieter.

                解决方案

                Yes, I noticed the same issue.

                • It's explained as a 'known issue' in the release notes for Java7 update 4.

                • Here is the bug report. The fix will be delivered in Java7 update 8 (current release is update 6).

                • Note that there isn't a shell-options workaround, because in Windows, the shell doesn't handle wildcard expansion. (Whereas in Unixes, the shell performs the expansion).

                这篇关于Windows 上 Java7 命令行的通配符扩展损坏(7?)的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持跟版网!

                上一篇:错误:CreateProcess 错误=216,此版本的 %1 下一篇:Eclipse-找不到JDK

                相关文章

                <i id='SsJxy'><tr id='SsJxy'><dt id='SsJxy'><q id='SsJxy'><span id='SsJxy'><b id='SsJxy'><form id='SsJxy'><ins id='SsJxy'></ins><ul id='SsJxy'></ul><sub id='SsJxy'></sub></form><legend id='SsJxy'></legend><bdo id='SsJxy'><pre id='SsJxy'><center id='SsJxy'></center></pre></bdo></b><th id='SsJxy'></th></span></q></dt></tr></i><div id='SsJxy'><tfoot id='SsJxy'></tfoot><dl id='SsJxy'><fieldset id='SsJxy'></fieldset></dl></div>

                1. <legend id='SsJxy'><style id='SsJxy'><dir id='SsJxy'><q id='SsJxy'></q></dir></style></legend>

                  <small id='SsJxy'></small><noframes id='SsJxy'>

                2. <tfoot id='SsJxy'></tfoot>

                  • <bdo id='SsJxy'></bdo><ul id='SsJxy'></ul>