# Coexistency Problem: cygwin + Ruby for Window (and suggestio **URL:** \ **Category:** Ruby\ **Created:** [May 15, 2007, 5:42pm UTC](https://www.ruby-forum.com/t/coexistency-problem-cygwin-ruby-for-window-and-suggestio/104227 "2007-05-15T17:42:56Z")\ **Posts on this page:** 7\ **Page:** 1
**Author:** ![ronaldfischer](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/r/67e7ee/32.png) [@ronaldfischer](https://www.ruby-forum.com/u/ronaldfischer)\ **Post date:** [May 15, 2007, 5:42pm UTC](https://www.ruby-forum.com/t/coexistency-problem-cygwin-ruby-for-window-and-suggestio/104227/1 "2007-05-15T17:42:56Z")
I just would like to point out a problem when installing Ruby for Windows and Cygwin on the same system: The installer of the Windows version of Ruby creates - at least on systems using a keyboard with European layout - a file named inputrc.euro in the bin directory of Ruby. As far I can tell, interactive Ruby tools (that is: irb) are using the file (via readline.dll) to access characters such as ‘[’ or ‘}’, which need to be accessed using the ‘AltGr’ modifier on European keyboards. In order that readline.dll can find this configuration file, the environment variable INPUTRC on the system is silently set to this path. This causes problems when the Cygwin package is also installed. Cygwin installs on the desktop an icon to launch a window running the bash shell, and bash also comes with its version of readline. The standard for all readline programs requires that, if the environment variable INPUTRC is set to some valid file name, that file is read for customizations; if this environment variable is NOT set, but the file $HOME/.inputrc exists, _that_ file is read customizations. In every other case, readline is not customized and uses just its default behaviour. A Cygwin user customizes therefore the readline behaviour by editing .inputrc in his/her home directory. But when Ruby for Windows is installed, bash (when started) sees that the environment variable INPUTRC exists, but does not point to a valid file (because the windows syntax for specifying a file path is not valid in Cygwin), and bypasses the definitions in ~/.inputrc. The only workaround I can think of, goes like this: Instead of using the standard Cygwin way to launch a Cygwin bash shell from the desktop (this goes via a batch file cygwin.bat), one can write his own Cygwin-bash-startup file, which unsets INPUTRC before calling bash. However, Cygwin users don’t expect that other systems “under the hood” change the Windows environment in such a way. I therefore suggest that either (1) the installer for Windows Ruby points out in the installation dialogue explicitly that it is changing the Windows environment by inserting a variable INPUTRC (and Cygwin users will then at least know what is going on), or (2) those Batch files in the Ruby distribution, which need INPUTRC, set the environment locally. Of course this would mean that the installation program has to “rewrite” those files (such as irb.bat) to contain the necessary “set INPUTRC=C:\MYRUBYDIR\bin\inputrc.euro”. Any opinions on that matter? Ronald ---
**Author:** ![ronaldfischer](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/r/67e7ee/32.png) [@ronaldfischer](https://www.ruby-forum.com/u/ronaldfischer)\ **Post date:** [May 15, 2007, 6:21pm UTC](https://www.ruby-forum.com/t/coexistency-problem-cygwin-ruby-for-window-and-suggestio/104227/2 "2007-05-15T18:21:03Z")
Hi, At Wed, 16 May 2007 00:41:43 +0900, Ronald F. wrote in [ruby-talk:251715]: > The installer of the Windows version of Ruby creates - at least on systems > using a keyboard with European layout - a file named inputrc.euro in the > bin directory of Ruby. As far I can tell, interactive Ruby tools (that is: > irb) are using the file (via readline.dll) to access characters such as > ‘[’ or ‘}’, which need to be accessed using the ‘AltGr’ modifier on European > keyboards. In order that readline.dll can find this configuration file, the > environment variable INPUTRC on the system is silently set to this path. Doesn’t that readline.dll have the default value of INPUTRC? ---
**Author:** ![ronaldfischer](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/r/67e7ee/32.png) [@ronaldfischer](https://www.ruby-forum.com/u/ronaldfischer)\ **Post date:** [May 16, 2007, 10:34am UTC](https://www.ruby-forum.com/t/coexistency-problem-cygwin-ruby-for-window-and-suggestio/104227/3 "2007-05-16T10:34:20Z")
> Doesn’t that readline.dll have the default value of INPUTRC? Yes, but this is not the point. I don’t claim that Ruby should not use readline.dll at all (it is very useful indeed and I have described an alternative solution, which would allow Ruby to use readline.dll without changing the system-wide settings). The problem is that the Windows installer for Ruby _silently_ changes the system-wide value of this environment variable (or creates it, if it does not exist). In both cases, this can interfer badly with other software installed. I mentioned the problem with Cygwin because I happened to have stumbled over it, and also because it is not unlikely that other people will face the problem too (if you, for example, develop Ruby programs intended to run on various platforms, it is not unlikely that you have the Cygwin version of Ruby and the Windows version installed at the same system). I could imagine, however, conflicts with other packages who happen to use readline.dll too. In general, I think that an application should never change an environment variable which it does not “own” exclusively, or at least give the user a chance to interfere. Readline.dll is a generally used library. Now suppose I have already installed several programs which use readline.dll, and I have set my INPUTRC environment variable to point to a file where I define my readline bindings. Then I install Ruby for Windows, and suddenly, my other programs don’t work anymore, because INPUTRC has been changed. This is certainly not what the user would like to have. These principles do apply to _all_ “commonly used” environment variables, not just INPUTRC. For example, a (well-behaved) Windows program would certainly not secretly replace the value of PATH, PATHEXT or CLASSPATH (though it may _add_ its own entries to them, leaving the others intact), nor would it set TEMP or TMP to different locations - at least not without asking the user for permission. Kind regards, Ronald ---
**Author:** ![ronaldfischer](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/r/67e7ee/32.png) [@ronaldfischer](https://www.ruby-forum.com/u/ronaldfischer)\ **Post date:** [May 16, 2007, 2:23pm UTC](https://www.ruby-forum.com/t/coexistency-problem-cygwin-ruby-for-window-and-suggestio/104227/4 "2007-05-16T14:23:18Z")
Hi, At Wed, 16 May 2007 17:33:32 +0900, Ronald F. wrote in [ruby-talk:251776]: > installed. > I imagined if it might read any fallback file like > /etc/inputrc, e.g., $INSTDIR/etc/inputrc or something (assume > there is readline.dll underneath $INSTDIR/bin), without > particular environment variables. > Or, setting HOME as $HOMEDRIVE/$HOMEPATH or $USERPROFILE at > initialization of ruby, like as 1.9 does. > I mentioned the problem with Cygwin because I happened to have stumbled > over it, and also because it is not unlikely that other people will face > the problem too (if you, for example, develop Ruby programs intended > to run on various platforms, it is not unlikely that you have the Cygwin > version of Ruby and the Windows version installed at the same system). > > I could imagine, however, conflicts with other packages who happen > to use readline.dll too. In general, I think that an application should > never change an environment variable which it does not “own” > exclusively, Agreed. ---
**Author:** ![ronaldfischer](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/r/67e7ee/32.png) [@ronaldfischer](https://www.ruby-forum.com/u/ronaldfischer)\ **Post date:** [May 16, 2007, 3:33pm UTC](https://www.ruby-forum.com/t/coexistency-problem-cygwin-ruby-for-window-and-suggestio/104227/5 "2007-05-16T15:33:26Z")
> I imagined if it might read any fallback file like > /etc/inputrc, e.g., $INSTDIR/etc/inputrc or something (assume > there is readline.dll underneath $INSTDIR/bin), without > particular environment variables. > Or, setting HOME as $HOMEDRIVE/$HOMEPATH or $USERPROFILE at > initialization of ruby, like as 1.9 does. Even this would not help. The conflict is basically this: Ruby uses (probably for irb, and for those Ruby functions which are “readline” aware) READLINE.DLL. This DLL _does_ have, to the best of my knowledge, a fallback mechanism about where to look for a definition file in case INPUTRC is not set, or simply use the defaults if none is set. But imagine for one moment that INPUTRC is not set (and the default inputrc file does not exist) and hence READLINE.DLL uses its default settings; further assume that we are running on a PC with European keyboard, and the user starts (in a Windows Command Shell) irb. The user would find now that he is unable to enter certain characters, such as brackets, curly braces or the ‘@’ character. This would render irb pretty useless for users in, say, Germany (and probably also for other European countries using a similar approach to generate these keys on their keyboard). Therefore, the Ruby installer (probably by looking at the Windows registry - but this is just my guess - finds out that the computer is using a (say:) German keyboard, creates a file named inputrc-euro somewhere below its $HOME which fixes the keyboard behaviour for European keyboards, and changes, respectively creates, a Windows environment variable named INPUTRC. This is all fine and dandy, unless we have on a computer a different application, such as Cygwin, which also depends on the INPUTRC variable, which would mean that both (Cygwin and Windows-Ruby) need to do their READLINE handling in different ways (Cygwin does not suffer from the keyboard problem, because they seem to have their own Readline; but instead, Cygwin users are used to put a lot of other useful stuff into their INPUTRC). As a consequence, no application should ever create (or modify) the Windows settings for INPUTRC. Instead, the conflict should be solved in that an application which _needs_ particular inputrc settings for Windows, should either always set INPUTRC locally, or hand over the responsibility to the user. As far I can tell, this should not be too difficult to do (and of course I will be happy contribute here by discussing possible solutions to this problem with the implementor of the setup program). Best regards, Ronald ---
**Author:** ![ronaldfischer](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/r/67e7ee/32.png) [@ronaldfischer](https://www.ruby-forum.com/u/ronaldfischer)\ **Post date:** [May 21, 2007, 10:33am UTC](https://www.ruby-forum.com/t/coexistency-problem-cygwin-ruby-for-window-and-suggestio/104227/6 "2007-05-21T10:33:31Z")
> I meant it would be nice if readline.dll for Windows were had > its own default rc path, or cygwin and mswin-ruby would have > different HOME pathes. Instead, it seems to get the fallback > path from the registry, “HKEY\_CURRENT\_USER\Software\Free > Software Foundation\libreadline\inputrc-file”. As far I can see, both apply, but also both are not helpful here. If readline.dll has/had its own default rc path, I think Ruby should not make use of it either, because the user might already have use _that_ file for placing definitions for his/her own use of readline.dll. ☹ Actually, what Ruby _really_ wants to do is to add its own Readline definition to those the user has already set up (if any), and as far I can tell, the basic principle of readline does not foresee this feature… Kind regards, Ronald ---
**Author:** ![ronaldfischer](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/r/67e7ee/32.png) [@ronaldfischer](https://www.ruby-forum.com/u/ronaldfischer)\ **Post date:** [May 16, 2007, 4:32pm UTC](https://www.ruby-forum.com/t/coexistency-problem-cygwin-ruby-for-window-and-suggestio/104227/7 "2007-05-16T16:32:37Z")
Hi, At Wed, 16 May 2007 22:32:32 +0900, Ronald F. wrote in [ruby-talk:251791]: > which are “readline” aware) READLINE.DLL. This DLL _does_ > have, to the best of my knowledge, a fallback mechanism > about where to look for a definition file in case INPUTRC > is not set, or simply use the defaults if none is set. I meant it would be nice if readline.dll for Windows were had its own default rc path, or cygwin and mswin-ruby would have different HOME pathes. Instead, it seems to get the fallback path from the registry, “HKEY\_CURRENT\_USER\Software\Free Software Foundation\libreadline\inputrc-file”. > But imagine for one moment that INPUTRC is not set (and > the default inputrc file does not exist) and hence READLINE.DLL > uses its default settings; further assume that we are running > on a PC with European keyboard, and the user starts (in a > Windows Command Shell) irb. The user would find now that he > is unable to enter certain characters, such as brackets, > curly braces or the ‘@’ character. This would render irb > pretty useless for users in, say, Germany (and probably > also for other European countries using a similar approach > to generate these keys on their keyboard). I think I understand the problem.