Coexistency Problem: cygwin + Ruby for Window (and suggestion for improving the Ruby installer)

[Ronald Fischer]

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=20
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,=20
that file is read for customizations; if this environment variable is
NOT set,=20
but the file $HOME/.inputrc exists, *that* file is read customizations.
In every=20
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.=20

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=3DC:\MYRUBYDIR\bin\inputrc.euro".

Any opinions on that matter?


Ronald
--=20
Ronald Fischer <[email protected]>
Phone: +49-89-452133-162
=20

 

[Nobuyoshi Nakada]

Hi,

At Wed, 16 May 2007 00:41:43 +0900,
Ronald Fischer 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?

 

[Ronald Fischer]

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.=20

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=20
*add* its own entries to them, leaving the others intact), nor would it=20
set TEMP or TMP to different locations - at least not without asking the
user for permission.

Kind regards,


Ronald

 

[Nobuyoshi Nakada]

Hi,

At Wed, 16 May 2007 17:33:32 +0900,
Ronald Fischer wrote in [ruby-talk:251776]:

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 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.

 

[Ronald Fischer]

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=20
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. =20

This is all fine and dandy, unless we have on a computer a
different application, such as Cygwin, which also depends on=20
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=20
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=20
solutions to this problem with the implementor of the setup program).

Best regards,

Ronald

 

[Nobuyoshi Nakada]

Hi,

At Wed, 16 May 2007 22:32:32 +0900,
Ronald Fischer wrote in [ruby-talk:251791]:

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.

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.

 

[Ronald Fischer]

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