Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Getting "io/console not supported; tty will not be manipulated" on Windows #1614

Closed
davidhooey opened this issue Apr 8, 2014 · 27 comments
Closed
Milestone

Comments

@davidhooey
Copy link

W:\rubyzip>java -version
java version "1.7.0_51"
Java(TM) SE Runtime Environment (build 1.7.0_51-b13)
Java HotSpot(TM) Client VM (build 24.51-b03, mixed mode, sharing)

W:\rubyzip>jruby -v
jruby 1.7.10 (1.9.3p392) 2014-01-09 c4ecd6b on Java HotSpot(TM) Client VM 1.7.0_51-b13 [Windows 7-x86]

W:\rubyzip>jruby -S rake -T
io/console not supported; tty will not be manipulated
rake build    # Build rubyzip-1.1.2.gem into the pkg directory
rake install  # Build and install rubyzip-1.1.2.gem into system gems
rake release  # Create tag v1.1.2 and build and push rubyzip-1.1.2.gem to R...
rake test     # Run tests
@denserv
Copy link

denserv commented May 14, 2014

This issue prevents a command line app from hiding a user's password when entered via STDIN.

require 'io/console'
password = STDIN.noecho(&:gets)

Text is still echoed back to the console in Windows.

@djberg96
Copy link
Contributor

Please fix.

@mikebridge
Copy link

Same error here using rake on windows, e.g. rake -T

    C:\> jruby -v
    jruby 1.7.19 (1.9.3p551) 2015-01-29 20786bd on Java HotSpot(TM) 64-Bit Server VM 1.8.0_31-b13 +jit [Windows 8.1-amd64]
    C:\>java -version
    java version "1.8.0_31" Java(TM) SE Runtime Environment (build 1.8.0_31-b13) Java HotSpot(TM) 64-Bit Server VM (build 25.31-b07, mixed mode)

@PragTob
Copy link

PragTob commented Feb 11, 2015

I'm getting the same thing on the appveyor (CI for Windows). Quite curiosly I have a build where the error pops up after gem install bundler and it continues to run and one where the error pops up and console output halts. Unfortunately there are more of the latter ones... :-/

That the output stops could also be on appveyors side...

edit: for me that's using jruby-1.7.19
edit2: And of course I'm an idiot and deleted that appveyor project together with all history... I have a new one though that will soon exhibit similar issues: https://ci.appveyor.com/project/PragTob/shoes4/build/1.0.2

@hathawad
Copy link

Getting as well on:
jruby 1.7.19 (1.9.3p551) 2015-01-29 20786bd on Java HotSpot(TM) 64-Bit Server VM 1.8.0_31-b13 +jit [Windows Server 2008 R2-amd64]

@mjstrasser
Copy link

I am getting the same message on Windows and Solaris with JRuby 1.7.19. It does not occur on JRuby 1.7.18.

Windows

D:\>jruby -v
jruby 1.7.19 (1.9.3p551) 2015-01-29 20786bd on Java HotSpot(TM) Client VM 1.7.0_67-b01 +jit [Windows 7-x86]

D:\>gem list
io/console not supported; tty will not be manipulated

Solaris

-bash-3.2$ jruby -v
jruby 1.7.19 (1.9.3p551) 2015-01-29 20786bd on Java HotSpot(TM) Server VM 1.7.0_67-b01 +jit [SunOS-sparc]
-bash-3.2$ gem list
io/console not supported; tty will not be manipulated

@headius
Copy link
Member

headius commented Feb 25, 2015

This is usually caused when some native support can't load. Windows should be falling back on a dummy implementation.

Of course I just got back up and running in my OS X env, so I'm not going to be looking at this in the short term, but if someone wants to poke around the code is in lib/ruby/1.9/io/console.rb. At the very least it should be possible to sort out what supressed errors are causing it to fall into the noisy path.

@djberg96
Copy link
Contributor

For solaris, it looks to me like you're just missing a sunos/solaris string in the regex check.

@enebo
Copy link
Member

enebo commented Feb 27, 2015

For Solaris I would not expect to see the error since it will try and stty and I would have thought that would work on Solaris but @djberg96 is right in that we should probably be following the first if in io/console.rb:

if RbConfig::CONFIG['host_os'].downcase =~ /darwin|openbsd|freebsd|netbsd|linux/

@mjstrasser can you print out RbConfig::CONFIG['host_os'] on Solaris. I believe it will be 'sunos' but I
would like to make sure. You could also edit lib/ruby/1.9/io/console.rb to see if adding solaris host_os to that regexp fixes it. What is weird about the Solaris observation is that we have not change io/console.rb on 1.7 in almost exactly 2 years. So we either made some seemingly unrelated changes in IO which is causing the stty path to break or perhaps something maybe changed in your env recently? In any case, we should go for real native support and not rely on stty on Solaris so let's fix the regexp...

For Windows, we clearly never do anything but try to stty which we know will fail in the next if statement where we unconditionally warn and setup dummy IO. So I guess we can at least eliminate the bogus stty check (unless perhaps we try it in cygwin or mingw? ), but that does not solve the warning and warning is meaningful. Short of trying to port windows side of ext/io/console.c I am not sure the best way to solve this.

@mjstrasser
Copy link

It returns solaris. I also noticed that JRuby 1.7.19 outputs a different message on JDK 6:

-bash-3.2$ export JAVA_HOME=/usr/jdk/instances/jdk1.6.0
-bash-3.2$ jruby -v
jruby 1.7.19 (1.9.3p551) 2015-01-29 20786bd on Java HotSpot(TM) Server VM 1.6.0_37-b06 +jit [SunOS-sparc]
-bash-3.2$ jruby -e 'puts RbConfig::CONFIG["host_os"]'
io/console on JRuby shells out to stty for most operations
solaris

On JDK 7:

-bash-3.2$ export JAVA_HOME=/usr/jdk/instances/jdk1.7.0_67
-bash-3.2$ jruby -v
jruby 1.7.19 (1.9.3p551) 2015-01-29 20786bd on Java HotSpot(TM) Server VM 1.7.0_67-b01 +jit [SunOS-sparc]
-bash-3.2$ jruby -e 'puts RbConfig::CONFIG["host_os"]'
io/console not supported; tty will not be manipulated
solaris

@enebo enebo added this to the JRuby 1.7.20 milestone Mar 3, 2015
@enebo
Copy link
Member

enebo commented Mar 3, 2015

@mjstrasser If you could modify the regexp in io/console.rb and try it out it would help in resolving this since I have no immediate access to Solaris instance. Your observation re Java 6/7 is interesting...perhaps we are not properly invoking processes correctly? on Java 6 it appears the stty path must have worked but not on Java 7 :|

@mjstrasser
Copy link

I tried the following edit:

-bash-3.2$ diff console.rb.orig console.rb
24c24
< if RbConfig::CONFIG['host_os'].downcase =~ /darwin|openbsd|freebsd|netbsd|linux/
---
> if RbConfig::CONFIG['host_os'].downcase =~ /darwin|openbsd|freebsd|netbsd|linux|solaris/
28c28
<     if RbConfig::CONFIG['host_os'].downcase =~ /darwin|openbsd|freebsd|netbsd/
---
>     if RbConfig::CONFIG['host_os'].downcase =~ /darwin|openbsd|freebsd|netbsd|solaris/

Then, with $VERBOSE=true:

-bash-3.2$ export JAVA_HOME=/usr/jdk/instances/jdk1.7.0_67
-bash-3.2$ jruby -ve 'puts RbConfig::CONFIG["host_os"]'
jruby 1.7.19 (1.9.3p551) 2015-01-29 20786bd on Java HotSpot(TM) Server VM 1.7.0_67-b01 +jit [SunOS-sparc]
failed to load native console support: Could not load FFI Provider: (NotImplementedError) FFI not available: null
 See http://jira.codehaus.org/browse/JRUBY-4583
io/console not supported; tty will not be manipulated
solaris

On JDK 6:

-bash-3.2$ export JAVA_HOME=/usr/jdk/instances/jdk1.6.0
-bash-3.2$ jruby -ve 'puts RbConfig::CONFIG["host_os"]'
jruby 1.7.19 (1.9.3p551) 2015-01-29 20786bd on Java HotSpot(TM) Server VM 1.6.0_37-b06 +jit [SunOS-sparc]
failed to load native console support: Could not load FFI Provider: (NotImplementedError) FFI not available: null
 See http://jira.codehaus.org/browse/JRUBY-4583
io/console on JRuby shells out to stty for most operations
solaris

Does this shed any light?

@enebo
Copy link
Member

enebo commented Mar 4, 2015

@mjstrasser Ok that was somewhat unexpected. The error indicates that our native support (which allows us to bind to native shared libraries is not loading on your machine. I wonder it host_os changed somewhat recently from sunos to solaris?

Can you now type in:

jruby -Xnative.verbose=true -e 1

It should say:

Successfully loaded native POSIX impl.

If not then we should figure out this second issue...

@mjstrasser
Copy link

No luck. With the changes I made yesterday to the regexps in console.rb, on JDK 7 I get this:

-bash-3.2$ export JAVA_HOME=/usr/jdk/instances/jdk1.7.0_67
-bash-3.2$ jruby -v -Xnative.verbose=true -e 1
jruby 1.7.19 (1.9.3p551) 2015-01-29 20786bd on Java HotSpot(TM) Server VM 1.7.0_67-b01 +jit [SunOS-sparc]
failed to load native console support: Could not load FFI Provider: (NotImplementedError) FFI not available: null
 See http://jira.codehaus.org/browse/JRUBY-4583
io/console not supported; tty will not be manipulated
-e:1 warning: Useless use of a literal in void context.

On JDK 6 I get this:

-bash-3.2$ export JAVA_HOME=/usr/jdk/instances/jdk1.6.0
-bash-3.2$ jruby -v -Xnative.verbose=true -e 1
jruby 1.7.19 (1.9.3p551) 2015-01-29 20786bd on Java HotSpot(TM) Server VM 1.6.0_37-b06 +jit [SunOS-sparc]
failed to load native console support: Could not load FFI Provider: (NotImplementedError) FFI not available: null
 See http://jira.codehaus.org/browse/JRUBY-4583
Failed to load native POSIX impl; falling back on Java impl. Stacktrace follows.
java.lang.UnsatisfiedLinkError: could not load FFI provider jnr.ffi.provider.jffi.Provider
        at jnr.ffi.provider.InvalidProvider$1.loadLibrary(InvalidProvider.java:30)
        at jnr.ffi.LibraryLoader.load(LibraryLoader.java:265)
        at jnr.ffi.Library.loadLibrary(Library.java:123)
        at jnr.posix.POSIXFactory$DefaultLibCProvider$SingletonHolder.<clinit>(POSIXFactory.java:223)
        at jnr.posix.POSIXFactory$DefaultLibCProvider.getLibC(POSIXFactory.java:227)
        at jnr.posix.BaseNativePOSIX.<init>(BaseNativePOSIX.java:36)
        at jnr.posix.SolarisPOSIX.<init>(SolarisPOSIX.java:15)
        at jnr.posix.POSIXFactory.loadSolarisPOSIX(POSIXFactory.java:103)
        at jnr.posix.POSIXFactory.loadNativePOSIX(POSIXFactory.java:78)
        at jnr.posix.POSIXFactory.loadPOSIX(POSIXFactory.java:38)
        at jnr.posix.LazyPOSIX.loadPOSIX(LazyPOSIX.java:35)
        at jnr.posix.LazyPOSIX.posix(LazyPOSIX.java:31)
        at jnr.posix.LazyPOSIX.newProcessMaker(LazyPOSIX.java:41)
        at org.jruby.util.ShellLauncher.buildProcess(ShellLauncher.java:495)
        at org.jruby.util.ShellLauncher.run(ShellLauncher.java:1365)
        at org.jruby.util.ShellLauncher.run(ShellLauncher.java:1313)
        at org.jruby.util.ShellLauncher.runAndWaitPid(ShellLauncher.java:546)
        at org.jruby.RubyKernel.backquote(RubyKernel.java:1639)
        at org.jruby.RubyKernel$INVOKER$s$1$0$backquote.call(RubyKernel$INVOKER$s$1$0$backquote.gen)
        at org.jruby.RubyClass.finvoke(RubyClass.java:742)
        at org.jruby.runtime.Helpers.invoke(Helpers.java:503)
        at org.jruby.RubyBasicObject.callMethod(RubyBasicObject.java:363)
        at org.jruby.ast.XStrNode.interpret(XStrNode.java:84)
        at org.jruby.ast.NewlineNode.interpret(NewlineNode.java:105)

... many lines omitted

        at org.jruby.Main.main(Main.java:197)
Caused by: java.lang.ExceptionInInitializerError
        at jnr.ffi.provider.jffi.NativeRuntime.getInstance(NativeRuntime.java:49)
        at jnr.ffi.provider.jffi.Provider.<init>(Provider.java:29)
        at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
        at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
        at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
        at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
        at java.lang.Class.newInstance0(Class.java:355)
        at java.lang.Class.newInstance(Class.java:308)
        at jnr.ffi.provider.FFIProvider$SystemProviderSingletonHolder.getInstance(FFIProvider.java:60)
        at jnr.ffi.provider.FFIProvider$SystemProviderSingletonHolder.<clinit>(FFIProvider.java:49)
        at jnr.ffi.provider.FFIProvider.getSystemProvider(FFIProvider.java:35)
        at jnr.ffi.Library.loadLibrary(Library.java:110)
        ... 183 more
Caused by: java.lang.IllegalStateException: Can't overwrite cause
        at java.lang.Throwable.initCause(Throwable.java:320)
        at com.kenai.jffi.Type$Builtin.lookupTypeInfo(Type.java:252)
        at com.kenai.jffi.Type$Builtin.getTypeInfo(Type.java:237)
        at com.kenai.jffi.Type.resolveSize(Type.java:155)
        at com.kenai.jffi.Type.size(Type.java:138)
        at jnr.ffi.provider.jffi.NativeRuntime$TypeDelegate.size(NativeRuntime.java:178)
        at jnr.ffi.provider.AbstractRuntime.<init>(AbstractRuntime.java:48)
        at jnr.ffi.provider.jffi.NativeRuntime.<init>(NativeRuntime.java:57)
        at jnr.ffi.provider.jffi.NativeRuntime.<init>(NativeRuntime.java:41)
        at jnr.ffi.provider.jffi.NativeRuntime$SingletonHolder.<clinit>(NativeRuntime.java:53)
        ... 195 more
io/console on JRuby shells out to stty for most operations
-e:1 warning: Useless use of a literal in void context.

@headius
Copy link
Member

headius commented Apr 21, 2015

The original issue was about io/console not loading properly on Windows, and since then I'm sure we've had several JRuby releases tested and working on Windows.

For all of you seeing this problem on other platforms, please file new issues with your platform information so we can sort out who is having what problems. This bug has grown to cover too much.

@headius headius closed this as completed Apr 21, 2015
@enebo
Copy link
Member

enebo commented Apr 21, 2015

This is confirmed fixed on Windows (just double-checked).

@mikebridge
Copy link

This is still a problem in 1.7.20 on Windows.

C:\>jruby -v -e ""
jruby 1.7.20 (1.9.3p551) 2015-05-04 3086e6a on Java HotSpot(TM) 64-Bit Server VM 1.8.0_45-b14 +jit [Windows 8.1-amd64]
io/console not supported; tty will not be manipulated

@slackfan
Copy link

The issue is also reproducible on Windows 7 64bit

C:\Tools\jruby-1.7.20>jruby -v -e ""
jruby 1.7.20 (1.9.3p551) 2015-05-04 3086e6a on Java HotSpot(TM) 64-Bit Server VM 1.7.0_76-b13 +jit [Windows 7-amd64]
io/console not supported; tty will not be manipulated

and on Windows 2012 R2 64bit

c:\Tools\jruby-1.7.20>jruby -v -e ""
jruby 1.7.20 (1.9.3p551) 2015-05-04 3086e6a on Java HotSpot(TM) 64-Bit Server VM
 1.7.0_76-b13 +jit [Windows Server 2012-amd64]
io/console not supported; tty will not be manipulated

On the mentioned operating systems for me this was no issue using JRuby-1.7.17.

I guess it's worth reopening the ticket.

@mikebridge
Copy link

This is still in 9.0.1.0, Windows Server 2008 R2

D:\> jruby -version
jruby 9.0.1.0 (2.2.2) 2015-09-02 583f336 Java HotSpot(TM) 64-Bit Server VM 24.51-b03 on 1.7.0_51-b13 +jit [Windows Server 2008 R2-amd64]

@aparajitahait
Copy link

I still see this issue with Windows platform for JRuby 9.0.4, 1.7.16, 1.7.23.

I have tried giving

jruby -Xnative.verbose=true -e 1

It said:
Successfully loaded native POSIX impl.

Still the error
io/console not supported; tty will not be manipulated

Is there any workaround for this.

@perlun
Copy link
Contributor

perlun commented Apr 7, 2016

@aparajitahait - I'm also seeing it. Windows 10, Java 8, JRuby 1.7.

@ilhee
Copy link

ilhee commented May 30, 2016

@aparajitahait - I'm also seeing it. Windows 10, Java 1.8.0_77, JRuby 1.7.

@perlun
Copy link
Contributor

perlun commented May 30, 2016

What specific JRuby 1.7 version is this? It is apparently fixed in 1.7.24 (see #3550 that was referred to above).

@AdrianPhil
Copy link

AdrianPhil commented Mar 14, 2017

Same here. When will this be addressed?
java version "1.8.0_92"
Java(TM) SE Runtime Environment (build 1.8.0_92-b14)
Windows 10

@enebo
Copy link
Member

enebo commented Mar 14, 2017

@adriannotimportant can you also specify which version of JRuby you are using? I do not see this occurring in either 1.7.27 nor 9.1.8.0 (although I am on win7). If you are seeing it with the latest versions of JRuby then perhaps explain a little more about run you run and something about the env.

@cmichon
Copy link

cmichon commented Mar 14, 2017 via email

@enebo
Copy link
Member

enebo commented Mar 15, 2017

@cmichon yeah I did mean 1.7.26 and we do mean to release a 1.7.27; so if people are still seeing this we want to make sure we address it. I am hoping it was just an older release though.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests