Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT sources DOT redhat DOT com Delivered-To: mailing list cygwin AT sources DOT redhat DOT com Date: Thu, 31 Aug 2000 14:27:22 -0400 (EDT) From: Mark Schoenberg Message-Id: <200008311827.e7VIRMA21010@lpb.niams.nih.gov> To: cygwin AT sourceware DOT cygnus DOT com Subject: Re: Backing out of Cygwin-1.1.4 Mime-Version: 1.0 Content-Type: text/plain; charset=X-roman8 Content-Transfer-Encoding: 7bit Chris, Thank you for taking my "criticism" of 1.1.4 in the spirit of helpfullness it was meant, and not getting defensive or "negative". After reading your reply, I now think there are just two issues involved. Issue 1: Since I have faith in your assessment of what changed between 1.1.2 and 1.1.4, I suspect a lot of the problems I newly faced in 1.1.4 are related to the fact that I installed 1.1.2 in /, but (after the seeing setup's strongly worded warning) I installed 1.1.4 elsewhere. Issue 2: The second issue has to do with the fact that one of my previously working programs no longer worked in 1.1.4. Since I first wrote you, I have found a hack for that. The hack, along with your comments, possibly lead us where the problem lies. With regard to issue 1, I will take your advice and mount Cygwin-1.1.4 as I think it should be mounted and see if this works better for me, as I think it will, or causes problems. I will later share my experience with the Cygwin list. The reason I had to do so many mounts is because all the stuff I wanted access to was under C:\, and was referred to as /msmail, /cron, etc. Since I couldn't mount C:\ at / (since C:\Cygwin\ was mounted there), I had to individually mount each subdirectory. With regard to issue 2, the problem I had was a follows: cygwin-compiled msp.exe, is supposed to use system() run msm.exe. When launched from the bash prompt, it found msm.exe. When launched from the no-cygwin-compiled cron.exe running as a daemon, it couldn't find msm.exe. If you are correct that the msp.exe system() command always runs an sh.exe shell for msm.exe, then the problem must be that under my 1.1.4 installation, the launch from cron.exe does not supply the correct PATH. How does sh.exe know the PATH? Rather than use the Cygwin choice of PATH, I generally set my PATH variable in a .bashrc file. Could the difference between 1.1.2 and 1.1.4 be that in 1.1.2 I had a PATH-setting .bashrc file in a sensible place, but in 1.1.4 I do not? The sh.exe PATH seems to include the Windows PATH variable, since the hack that got things working under 1.1.4 was to put the directory in which msm.exe resides in the Windows PATH. Thanks, Mark Earlier communications follow: On Thu, Aug 31, 2000 at 10:51:13AM -0400, Mark Schoenberg wrote: >Date: Thu, 31 Aug 2000 10:51:13 -0400 (EDT) >From: Mark Schoenberg >To: cygwin AT sourceware DOT cygnus DOT com >Subject: Backing out of Cygwin-1.1.4 > >On Wed Aug 30 23:29:15 2000, Chris Faylor wrote, >>On Wed, Aug 30, 2000 at 11:12:11PM -0400, Mark Schoenberg wrote: >>> >>> Does anyone know of a way to back out of cygwin-1.1.4 and return to >>>cygwin-1.1.2? >> >>Can I ask why you'd want to do this? >> >>cgf >> > >Ok, here goes: >"Ten" reasons why I think 1.1.4 is going in the wrong direction. I've read everything below, and I'm not clear on what direction you think is evidenced from 1.1.2 to 1.1.4. It sounds like you may have hit upon a bug or two or an unexpected side-effect. This is no reason to assume that everything is going to hell, though. > As good as Cygwin is, it will not be anytime soon that it occupies the >majority of desktops. My own goal therefore, is to write programs that will >operate both in the Cygwin environment and without it. This is extremely >difficult when the two environments see different filesystems. It hardly makes >sense (at least to me), to have Cygwin, which is meant for Windows, to not see >the same portion of the disk as Windows does. To port 1.1.4, I had to issue >half a dozen mount commands. Why did you have to issue "half a dozen mount commands"? Cygwin should be able to properly deal with paths like c:\winnt\system32 if that's what you want to use. How is this different from 1.1.2? > Significant Unix-like windows programs that preceded Cygwin (emacs and >some operations within tcsh) think that dir/file is really C:dir/file. While >this doesn't make sense in a Unix environment, it is the way these >Windows-ported programs work at present. Actually, I would assume that any UNIX or Windows based software would assume that dir/file referred to dir/file in the current directory. That should be the case for cygwin unless dir is a mount point. This should not have changed between 1.1.2 and 1.1.4. > Two commands within Cygwin that have always difficult to run in both the >Cygwin and non-Cygwin Windows environment are mkdir() and system(). The former >is a pain, but at least I got used to programming in an ifdef to put in the >correct number of arguments when -mno-cygwin was used. Also, not a 1.1.2 vs. 1.1.4 problem but you do understand that we're emulating UNIX, right? >System was a greater pain, but in 1.1.0-1.2.2, all you had to remember >was that Cygwin-compiled programs required "/dir/com" and -mno-cygwin >compiled programs required "\\dir\\com". In 1.1.4, I have been unable >to figure out what the paradigm is that determines what shell the >system command runs in. I don't understand this. AFAIK, the system command has not changed. It should always run /bin/sh, just as before. If you can provide an example of something that behaves differently between 1.1.4 and 1.1.2 I'll be happy to investigate it. >I have gotten different behavior when a cygwin-compiled program which >uses system() is invoked from a bash prompt, and when it is invoked >using the system command in a no-cygwin compiled program. Maybe this is command line quoting? I tried to make 1.1.4 command-line quoting more Windows-like but apparently I wasn't successful since I've seen a couple of bug reports. >Not having thought about this too deeply, it seems that many of the >above problems (except the last one) could be solved by installing >Cygwin in /Cygwin or wherever, and then mounting C:\ on /, >C:\Cygwin\bin on /usr/bin, and C:\Cygwin\lib on /lib. We would then >just have to symbolically link /usr/bin to /bin until the Unix/Linux >community agrees on where to put executables. We might also have to >find a home for cygwin.bat, cygwin.ico, and maybe home/, but that >shouldn't be too difficult. Again, these are not 1.1.2 vs. 1.1.4 issues, AFAICT. However, if you want to do this on your system, you really should go ahead and do this. If it bothers you that running 'setup.exe' may cause problems with this layout, I'd suggest writing a fairly simple shell script to put things to your liking after you've run setup.exe. Or, you can even grab the setup sources and make whatever changes you think are appropriate. DJ is a reasonable person and he may just agree with you if you submit changes. cgf -- Want to unsubscribe from this list? Send a message to cygwin-unsubscribe AT sourceware DOT cygnus DOT com