Feature #1482

Kernel.exec doesn't respect COMSPEC environment variable on Windows

Added by Evgeniy Dolzhenko almost 5 years ago. Updated 3 months ago.

[ruby-core:23491]
Status:Assigned
Priority:Normal
Assignee:Nobuyoshi Nakada
Category:core
Target version:current: 2.2.0

Description

=begin
Here is pretty convoluted test case:

puts ENV["COMSPEC"] # => "C:\WINDOWS\system32\mycmd.exe"

File.open("1.bat", "w") { |f| f.write("time") } # create test batch file with command which waits for user input

Kernel.exec("1.bat") # now the process tree inspection shows that the "C:\WINDOWS\system32\cmd.exe" is still used to interpret 1.bat
=end

0001-win32.c-use-COMSPEC.patch Magnifier (2.03 KB) Nobuyoshi Nakada, 10/29/2012 05:39 PM

History

#1 Updated by ujihisa . over 4 years ago

  • Status changed from Open to Assigned
  • Assignee set to Usaku NAKAMURA

=begin

=end

#2 Updated by Usaku NAKAMURA over 4 years ago

  • Status changed from Assigned to Feedback

=begin
This is the spec of Windows itself.
Should we change the behavior with deviating from OS standard way?
=end

#3 Updated by Usaku NAKAMURA over 4 years ago

  • Priority changed from Normal to Low
  • Target version deleted (Ruby 1.8.7)

=begin

=end

#4 Updated by Yusuke Endoh about 4 years ago

=begin
Hi, usa

Should we keep this ticket open?

I'd like to close this ticket because there is no feedback from OP.
If you'll still wait, please change the target to 1.9.x.

--
Yusuke Endoh mame@tsg.ne.jp
=end

#5 Updated by Jon Forums about 4 years ago

=begin
While I didn't report the behavior, using the code from the OP but using the TCC LE shell from http://www.jpsoft.com/tccledes.htm which has a COMSPEC of

[C:\Users\Jon\Documents]echo %COMSPEC%
C:\Program Files\JPSoft\TCCLE11\TCC.EXE

and using Process Explorer from http://technet.microsoft.com/en-us/sysinternals/bb896653.aspx I get the same results as the OP, the TCC LE process starts a Ruby process that starts a C:\WINDOWS\system32\cmd.exe process to interpret the bat.

I'm curious, where is it described that this behavior is the spec of Windows itself? I'm not familiar with this from the DOS or WScript/CScript scripting perspective.

OTH, if Kernel.exec would be changed to honor COMSPEC, would it handle spaces in the path correctly when using shells such as TCC LE?

Jon
=end

#6 Updated by Nobuyoshi Nakada about 4 years ago

=begin
Hi,

At Wed, 31 Mar 2010 01:31:39 +0900,
Jon Forums wrote in :

I'm curious, where is it described that this behavior is the
spec of Windows itself? I'm not familiar with this from the
DOS or WScript/CScript scripting perspective.

It's depend on "the association of file extension to programs".

OTH, if Kernel.exec would be changed to honor COMSPEC, would
it handle spaces in the path correctly when using shells such
as TCC LE?

It's already done if you pass them properly.

--
Nobu Nakada

=end

#7 Updated by Kazuhiro NISHIYAMA about 4 years ago

  • Category set to core
  • Target version set to 2.0.0

=begin

=end

#8 Updated by Evgeniy Dolzhenko about 4 years ago

=begin
Documentation for exec method says:

  • The standard shell means always "/bin/sh" on Unix-like systems,
  • ENV["RUBYSHELL"] or ENV["COMSPEC"] on Windows NT series, and
  • similar.

    but I still can't get it to run my customized interpreter.

    When you say that it depends on "the association of file extension to programs" does
    that mean association of batch files? I tried to change this to my customized
    interpreter (Control Panel\Programs\Default Programs\Set Associations in Windows 7)
    and Ruby is still running cmd.exe (in the original test case).
    =end

#9 Updated by Yusuke Endoh about 2 years ago

Hello,

Usak-san or nobu, could you tell me the status?

Yusuke Endoh mame@tsg.ne.jp

#10 Updated by Usaku NAKAMURA over 1 year ago

  • Status changed from Feedback to Assigned

Now ruby recognize batch files as "programs", so they are simply passed to
CreateProcess() API.
So, current behavior is Windows' spec.

However, I suspect that this (= simply being passed to CreateProcess API) is not intended.
I'll discuss about it with nobu next week.

#11 Updated by Nobuyoshi Nakada over 1 year ago

Does this patch help?

#12 Updated by Usaku NAKAMURA over 1 year ago

Can you write a test for this patch, nobu?
If so, please commit them(=this patch and the test).

#13 Updated by Usaku NAKAMURA over 1 year ago

  • Assignee changed from Usaku NAKAMURA to Nobuyoshi Nakada
  • Priority changed from Low to Normal

#14 Updated by Yusuke Endoh over 1 year ago

Nobu, did you?

Yusuke Endoh mame@tsg.ne.jp

#15 Updated by Koichi Sasada about 1 year ago

  • Target version changed from 2.0.0 to 2.1.0

ping -> nobu.

#16 Updated by Nobuyoshi Nakada about 1 year ago

Unfortunately, I've lost my topic branch for this issue, so have to rewrite from the previous patch again.

#17 Updated by Hiroshi SHIBATA 3 months ago

  • Target version changed from 2.1.0 to current: 2.2.0

Also available in: Atom PDF