From: moskewcz AT Princeton DOT EDU (Matthew Moskewicz) Subject: remote.tar.gz & WIN95 , info re common problems 3 Jun 1998 13:24:38 -0700 Message-ID: <3574EA4C.60D8709D.cygnus.gnu-win32@Princeton.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: gnu-win32 AT cygnus DOT com *********** 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 AT Princeton DOT 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 AT cygnus DOT com" with one line of text: "help".