Title: test_subprocess_jy fails when Argument has embedded quote
Type: Severity: normal
Components: Library Versions: Jython 2.7, Jython 2.5
Status: closed Resolution: out of date
Dependencies: Superseder:
Assigned To: Nosy List: jeff.allen, sowmyalakkappa, zyasoft
Priority: Keywords:

Created on 2013-06-19.05:58:35 by sowmyalakkappa, last changed 2014-06-28.04:16:17 by zyasoft.

File name Uploaded Description Edit Remove sowmyalakkappa, 2013-06-19.05:58:34
msg8050 (view) Author: Sowmya (sowmyalakkappa) Date: 2013-06-19.05:58:34 bundled with Jython 2.5.1. fails with the below error:
test test_subprocess_jy failed -- Traceback (most recent call last):
  File \'L:\\apps\\ascii\\jython\\70files\\current\\win\\Lib\\test\\\', line 13, in testDefaultEnvIsInherited
    p1 = Popen([sys.executable, \'-c\',
  File \'L:\\apps\\ascii\\jython\\70files\\current\\win\\Lib\\\', line 755, in __init__
    self._execute_child(args, executable, preexec_fn, close_fds,
  File \'L:\\apps\\ascii\\jython\\70files\\current\\win\\Lib\\\', line 1269, in _execute_child
    raise OSError(e.getMessage() or e)
OSError: Argument has embedded quote, use the explicit CMD.EXE call.

This test fails with both Oracle and IBM java from jdk7u21 b06.
Changes in Oracle 7u21 - Changes  affects applications using Runtime.exec and ProcessBuilder.(
Based on this, I see that the Jython code will need to be modified to use "Cmd.exe" while running commands that contains quotes in it as detailed in the above  error message
msg8250 (view) Author: Jeff Allen (jeff.allen) Date: 2014-03-09.09:05:36
I've been experimenting with this on 2.7b and with other Java versions. Java 6u45 fails in this way but 7u45 passes.

There are good release notes about this for 7u21, and in 7u25 Oracle introduced a property to suppress the fussy behaviour.

6u45 is roughly contemporary with 7u21 and has the same check.

The puzzle, then, is why these tests pass on 7u45. does an apparently correct job of looking for special characters and escaping them to conform to the Windows runtime API. The problem may be (may have been) that the new feature in ProcessBuilder for Windows did not take proper account of the escapes. Stepping through ProcessBuilderImpl in 6u45, that seems to be the case.

Oracle appear to have had second thoughts about this checking. Since 7u40 it is now in effect only when a security manager is set. The small print of the release notes for 6u40 leads to:

It is perhaps still an issue for applications that use a security manager, and cannot choose (at the application level) to use the CMD /C form. But I'm not sure we should force use of CMD /C in the library, since this is meant to be under client control through the shell argument to and Popen().
msg8490 (view) Author: Jim Baker (zyasoft) Date: 2014-05-21.22:29:27
Given that we have made Java 7 minimum for 2.7, is this still an issue?

(I don't see us fixing this for 2.5.)
msg8839 (view) Author: Jim Baker (zyasoft) Date: 2014-06-28.04:16:17
Use Java 7, this apparently fixes the problem
Date User Action Args
2014-06-28 04:16:17zyasoftsetstatus: open -> closed
resolution: out of date
messages: + msg8839
2014-05-21 22:29:27zyasoftsetnosy: + zyasoft
messages: + msg8490
2014-03-09 09:05:37jeff.allensetnosy: + jeff.allen
messages: + msg8250
components: + Library, - Any
versions: + Jython 2.7
2013-06-19 05:58:36sowmyalakkappacreate