Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.Sign up
JRuby + Cygwin + Jenkins causes message related to stty #3989
jruby 1.7.25 (1.9.3p551) 2016-04-13 867cb81 on Java HotSpot(TM) 64-Bit Server VM 1.8.0_31-b13 +jit [Windows 7-amd64]
When I run JRuby on Jenkins, but invoked from a Cygwin shell, I get the annoying warning message
This does not happen when I run JRuby from a (Cygwin-) command line (interactively), or on Jenkins from a Windows command line.
I remember that there was a very similar error in jruby 1.7.23, where a stty warning was always shown when executing jruby from a Cygwin shell script, even with an interactive one. This error had been fixed in 1.7.24.
Running the script as a Jenkins job means that there is no console associated to the job. Perhaps the bugfix mentioned, did not pay attention to this possibility.
Thomas Enebo commented to this in the JRuby mailing list in the following way: "The gist of things is when you run via cygwin on Jenkins it is from a daemon and it has no tty associated with it. When we run stty you get this error. When you run from a cygwin windows it does have a tty so stty completes without issue."
@rovf How much output are we talking about here? If this is a one-time warning it's not a big deal.
We could also silence stty by being a bit trickier with our spawning, so that if it has stderr warnings we don't see them.
And @enebo's question is valid too...ideally we wouldn't be hitting console for non-tty. That would indicate we're not properly detecting that there's no tty.
Can you track down where exactly this is happening? I suspect it's in io/console.rb.
From the viewpoint of functionality, if it is just a warning, it really is not a big deal. However, if you have - as in my case - a system consisting of plenty of (Zsh-)shell scripts, each calling lots of JRuby programs, seeing all the warnings looks confusing and is not something I would like to hand over to my customer as professional work from my side - my customer might argue that I'm using a programming language implementation which is not done in a good way. Since I not only want to get "my work done" somehow, but also demonstrate the pros of JRuby, I certainly want to avoid this warning to pop up.
A solution which I could do for myself, would be to write a wrapper script around JRuby, which catches STDERR and filters out exactly this warning, but since I'm likely not the only person seeing this warning, If it is difficult to fix the root cause, would it be possible to disable this warning by a command line switch? Kind of:
We haven't circled back to this in a while, so I think we need a refresh.
First off, I assume it still happens with 1.7.26?
Do we know that it's
This is obviously a much bigger issue, but does JRuby 126.96.36.199 have the same problem?
It basically occurs still, but much rarer: We have now only a single output of this message in our Jenkins job, while I could see the message several times in the past. I don't know where this message exactly comes from. It's a bit difficult to retest ist with JRuby 9.x, because this is a Java 1.6 application, and I can't rund JRuby 9 on it.
In our application, we do not explicit use io/console. Since it happens only when run on Jenkins, my guess is that it has to do how Jenkins is catching the output. I don't know about the internal working of Jenkins on Windows, but Jenkins catches "the console output", and maybe Jenkins simulates a console and makes JRuby think that it is writing to a console device when it is actually writing to STDOUT or STDERR.
I wonder how many places there are in the JRuby code, where a shell-out to stty happens. If they can be identified, a quick hack would be to add a command line switch to JRuby, --no-stty, which simply forbids the use of stty.
I'm not sure why it was ever intermittent for you, but I believe the problem was that cygwin does ship an stty, but Jenkins is not running your code under a proper terminal. So we had a weird perfect storm of Windows + stty + non-console that resulted in odd behavior.
If you are able to test it that would be great. Check out the branch and run