Feature #1482

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

Added by Evgeniy Dolzhenko about 6 years ago. Updated over 1 year ago.

[ruby-core:23491]
Status:Assigned
Priority:Normal
Assignee:Nobuyoshi Nakada

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 5 years ago

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

=begin

=end

#2 Updated by Usaku NAKAMURA over 5 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 5 years ago

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

=begin

=end

#4 Updated by Yusuke Endoh over 5 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 over 5 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 over 5 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 over 5 years ago

  • Target version set to 2.0.0
  • Category set to core

=begin

=end

#8 Updated by Evgeniy Dolzhenko about 5 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 over 3 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 2 years 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 2 years ago

Does this patch help?

#12 Updated by Usaku NAKAMURA over 2 years 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 2 years ago

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

#14 Updated by Yusuke Endoh over 2 years ago

Nobu, did you?

Yusuke Endoh mame@tsg.ne.jp

#15 Updated by Koichi Sasada over 2 years ago

  • Target version changed from 2.0.0 to 2.1.0

ping -> nobu.

#16 Updated by Nobuyoshi Nakada over 2 years 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 over 1 year ago

  • Target version changed from 2.1.0 to current: 2.2.0

Also available in: Atom PDF