remote.tar.gz & WIN95 , info re common problems

Matthew Moskewicz moskewcz@Princeton.EDU
Sun May 31 17:25:00 GMT 1998


***********
Abstract
***********

Some info I gleaned installing remote.tar.gz on my win95 system. See my
last message for the details of my general system setup.

************
Not-abstract
************

I'm not sure if this issue is still floating around, but I know that in
the past that various people have been having problems with Sergey's
remote.tar.gz, on W95 and otherwise, mainly reporting the error:

(pid) reaped, status 0x100

as fall as I can tell, this 'error' doesn't mean much by itself. In
fact, I still get this message (after I exit a session) even though
telnet works fine for me. However, I know that Win95 still has signal
problems, and I don't clain to have a 'perfect' install of B19.1, so
perhaps a 'good' NT setup of inetd doesn't ever see this error ...
verification, please?

Anyway, now that I have it working, I though people might be interested
in the following list of common things that will make in.telnetd
work/fail. Note that Sergey's login.w95 provides NO ACCESS CONTROL! In
general, this is geared toward getting the thing running at all, not
working out the details.

(1) 
Things that I'm doing that I don't think are quite right, but work:

  I have a 2 copies of bash.exe in /bin called bash.exe and sh.exe
  I altered sergey's login.w95 to read:

#!/bin/sh
exec /bin/bash -login

  Without the hard coded path to bash, bash gets seriously confused ...
I think it reverts to non-interactive behavior, ie. no prompt, no
aliases, etc... In any case, the hard coded path is 'safer' in that
inetd will run properly regardless of the lack of any enviornment
variables, including path. For example, it still works when invoked from
a dos box, with a minimal enviorment:

D>set
winbootdir=C:\WINDOWS
windir=C:\WINDOWS
PATH=
CMDLINE=inetd -d

D>inetd -d

[note, in reality, we don't ever do this, since bash can't find .bashrc,
etc ... but it limits the number of places where problems can arise for
testing]

I don't know why bash gets confused without the hard path, since ps
reports:

COMMAND
D:\CYGNUS\B19\H-I386-CYGWIN32\BIN\BASH.EXE                                                           
in either case, impling that the same copy of bash is being run in the
same way. I'm guessing bash is really getting invoked differently in the
two cases, and the difference in command line is what changes the
behavior (as bash is wont to do).

(2)
  Make sure to copy login.w95 (altered or otherwise) is copied to
/usr/local/bin/login , not login.exe or somesuch. Note that you should
check this from a DOS box, since if you did accidentally copy login.w95
to login.exe, bash won't let you copy login.exe to login, complaining
that they are the 'same file.' I'm assuming this is a low-level
cygwinb19.dll name-munging thing with the .exe suffix. It's all good.

(3)
 Things that didn't seem to matter (in terms of basic functionality, ie.
getting an interactive bash prompt via telnet)

(a) existance of /etc/*
(b) existance of enviornment variables  

(of course, to get .bashrc you need HOME, and you need /etc for terminal
stuff, etc ... but again, we want to limit the possibilities for error
until things work at a minimal level :)

Later,

Matt.

-- 
 Matthew Moskewicz	|	mailto:moskewcz@Princeton.edu
 24A Holder Hall - PU	|	http://www.Princeton.edu/~moskewcz	
 Princeton, NJ 08544    |	(609)258-9852
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".



More information about the Cygwin mailing list