jruby's system("ls") seems to behave different than MRI

Details

Type: Bug
Status: Closed
Priority: Major
Resolution: Duplicate
Affects Version/s: None
Fix Version/s: None
Component/s: None
Labels:
None
Environment:
jruby 1.6.0.RC2 (ruby 1.8.7 patchlevel 330) (2011-02-10 6fdca25) (Java HotSpot(TM) Client VM 1.6.0_18) [Windows 7-x86-java]

Testcase included:
yes
Number of attachments :
0

Description

http://groups.google.com/group/jruby-users/browse_thread/thread/047a79c9de6c3c1d?fwc=1

ed that when I run system("ls.exe")
in jruby
C:\jruby-1.5.5\bin>jruby -e 'system("ls.exe")'
ast
ast.bat
autospec
autospec.bat
gem
and in mri:
C:\jruby-1.5.5\bin>ruby -e 'system("ls.exe")'
ast autospec.bat generate_yaml_index.rb jgem.bat jirb_swing
ast.bat gem generate_yaml_index.rb.bat jirb
(it gives the long output in jruby, but not in mri).

This is the ls.exe from mingw, or also from system('c:\program files\git\bin\ls') (msysgit)

Issue Links

depends upon

JRUBY-1608 STDIN/STDOUT "not a tty" under Kernel.system

duplicates

JRUBY-1608 STDIN/STDOUT "not a tty" under Kernel.system

Activity

Ascending order - Click to sort in descending order

Hide

Permalink

Charles Oliver Nutter added a comment - 17/Feb/11 4:52 PM

The reason for this is that when the JVM launches a subprocess, that process does not inherit the parent's stdio streams. As a result, "ls" will not see that it's outputting to a terminal/tty, and so you get the non-tty output.

It's similar to the following output:

~/projects/jruby &#10132; ls *.xml
blah.xml		build.xml		findbugs.xml		netbeans-ant.xml	pom.xml			testrun-times.xml

~/projects/jruby &#10132; ls *.xml | cat
blah.xml
build.xml
findbugs.xml
netbeans-ant.xml
pom.xml
testrun-times.xml

We can work around this by not using JVM mechanisms for spawning processes (or by using Java 7 features that allow inheriting streams), but those are the only ways.

I'm going to see if we have a general "subprocesses don't inherit TTY" bug.

Show

Charles Oliver Nutter added a comment - 17/Feb/11 4:52 PM The reason for this is that when the JVM launches a subprocess, that process does not inherit the parent's stdio streams. As a result, "ls" will not see that it's outputting to a terminal/tty, and so you get the non-tty output. It's similar to the following output: ~/projects/jruby ➔ ls *.xml blah.xml build.xml findbugs.xml netbeans-ant.xml pom.xml testrun-times.xml ~/projects/jruby ➔ ls *.xml | cat blah.xml build.xml findbugs.xml netbeans-ant.xml pom.xml testrun-times.xml We can work around this by not using JVM mechanisms for spawning processes (or by using Java 7 features that allow inheriting streams), but those are the only ways. I'm going to see if we have a general "subprocesses don't inherit TTY" bug.

Hide

Permalink

Charles Oliver Nutter added a comment - 17/Feb/11 4:54 PM

I'm calling this a duplicate of the earliest-known subprocess TTY bug I could find: JRUBY-1608 "STDIN/STDOUT "not a tty" under Kernel.system"

Show

Charles Oliver Nutter added a comment - 17/Feb/11 4:54 PM I'm calling this a duplicate of the earliest-known subprocess TTY bug I could find: JRUBY-1608 "STDIN/STDOUT "not a tty" under Kernel.system"

Charles Oliver Nutter made changes - 17/Feb/11 4:54 PM