This is the mail archive of the
mailing list for the Cygwin project.
remote.tar.gz & WIN95 , info re common problems
- To: gnu-win32 at cygnus dot com
- Subject: remote.tar.gz & WIN95 , info re common problems
- From: Matthew Moskewicz <moskewcz at Princeton dot EDU>
- Date: Wed, 03 Jun 1998 02:16:44 -0400
- Organization: Princeton Grammar School
Some info I gleaned installing remote.tar.gz on my win95 system. See my
last message for the details of my general system setup.
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 ...
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.
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:
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:
[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
I don't know why bash gets confused without the hard path, since ps
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).
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.
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 :)
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
"email@example.com" with one line of text: "help".