Re: cygwin on a 386?
On Wed, Oct 18, 2000 at 09:23:37PM -0500, Chris Abbey wrote: I have two very fuzzy recollections that may help... The first is that when I first got hooked on cygwin (beta 1x, 3=x=5 ??) my main machine would have been a 386Dx w/387 co-proc so unless I learned to love cygwin somewhere else (not likely because while I used a LOT of other machines back then, it was rare to use the same one more than once, and even rarer for me to be able to install software on anything.) The second is that a friend in uni was screaming about not being able to get it to work in the "pc emulator" software he used on his mac. I still have the 386dx mobo and memory, and ide card if you need a testbed to actually try this on yours for the price of shipping handling ;) Interesting. I am sure that I have a 386 motherboard (and maybe a whole computer) sitting around somewhere but I'm sure it has never run Windows 95. I don't look forward to trying to install Windows 95 on anything like this, so I'm hoping that someone else might be happily (a relative term) using cygwin on their ancient system and will chime in here. Cygwin not working in a PC emulator could be due to unimplemented Win32 functions. That's why cygwin doesn't work in Wine currently. Thanks for the info. cgf -- Want to unsubscribe from this list? Send a message to [EMAIL PROTECTED]
Re: A standard bug-reporting program for cygwin
I already answered this question with regard to bugzilla. I anticipate that 99% of the "bugs" reported will be cockpit errors and I don't want to set up a database to handle user errors. cgf On Thu, Oct 19, 2000 at 12:17:34AM -0230, Neil Zanella wrote: If you really want to set up a bug reporting program then why not use something such as the http://samba.anu.edu.au/jitterbug/ program? Then we can just add an entry in the FAQ for this and a line in /etc/profile saying "echo Read the FAQ loacted in directory..." and "echo Report bugs at http://...". Bye, Neil On Mon, 16 Oct 2000, Heribert Dahms wrote: Hi David, and what about the human reason, that those not finding or even searching about cygcheck in FAQ/README probably won't find this bugreport program, too? In the worst case the traffic on the list isn't cut down, but merely pointing to this new program instead of cygcheck! Bye, Heribert ([EMAIL PROTECTED]) -Original Message- From: David A. Cobb [SMTP:[EMAIL PROTECTED]] Sent: Monday, October 16, 2000 23:38 To:[EMAIL PROTECTED] Subject: Re: A standard bug-reporting program for cygwin Is there a good technical reason why an existing open-source system, such as Bugzilla, is inappropriate? Chris Faylor wrote: I'd like to set up a shell script or program which could be run to generate text to be sent to the cygwin mailing list. It would ask a limited number of questions and generate a text file appropriate for mailing here. My idea would be for the script to run 'cygcheck -r -s -v' and then ask What program is causing problems (e.g., gcc, bash, awk, etc)? Describe the problem in detail (a simple test case would be appreciated): Enter the name of any associated files needed to generate the problem. . . . Created file xxx. Please send this file to [EMAIL PROTECTED] with the subject "bug report". Does this make sense? My goal is to cut down on the back and forth of the "I can provide details if necessary". "Yes. Provide details." cgf -- Want to unsubscribe from this list? Send a message to [EMAIL PROTECTED] -- David A. Cobb, Software Engineer, Public Access Advocate. Public Key at: http://pgpkeys.mit.edu:11371/pks/lookup?op=getsearch=superbiskit "Don't buy or use crappy software" "By the grace of God I am a Christian man, by my actions a great sinner" -- The Way of a Pilgrim [R. M. French, tr.] -- Want to unsubscribe from this list? Send a message to [EMAIL PROTECTED] -- Want to unsubscribe from this list? Send a message to [EMAIL PROTECTED] -- Want to unsubscribe from this list? Send a message to [EMAIL PROTECTED] -- [EMAIL PROTECTED]Red Hat, Inc. http://sources.redhat.com/http://www.redhat.com/ -- Want to unsubscribe from this list? Send a message to [EMAIL PROTECTED]
Re: ps output format
On Wed, Oct 18, 2000 at 10:38:43PM +0100, David Starks-Browning wrote: On Wednesday 11 Oct 00, Chris Faylor writes: On Wed, Oct 11, 2000 at 09:39:46PM +0100, David Starks-Browning wrote: Is there anything that can be done with ps output format before 1.1.5 is released? Thanks for reminding me. I'll look into fixing this. It's actually using Windows 98 native pids now which are, of course, negative (?). I just installed the 2000-10-17 snapshot, and this looks a *lot* better now. Thanks! Purists might not be happy with the alignment of column headers, though: starksb@STARKSB-P$ ps PIDPPIDPGID WINPID TTY UIDSTIME COMMAND 353411 1 353411 4294613885 0 500 21:56:14 /usr/local/BIN/RXVT 661739 353411 661739 4294301261 1 500 21:56:16 /usr/bin/BASH 662723 661739 662723 4294196185 1 500 21:56:22 /usr/local/BIN/RXVT 783339 662723 783339 4294212997 2 500 21:56:23 /usr/bin/SSH 589383 661739 589383 4294407093 1 500 22:31:32 /usr/bin/PS 589383 661739 589383 4294407093 1 500 22:31:32 /usr/bin/PS But purists ought not to use Win98, eh? Ok, ok. I added a space or two to the output. Now Windows 9echs looks ok but Windows NT looks rather sparse. I suppose I could add a switch that shrinks the space for Windows NT. I'll probably wait until some purist complains about the excessive whitespace on NT, though. cgf -- Want to unsubscribe from this list? Send a message to [EMAIL PROTECTED]
Re: cygwin on a 386?
On Wed, Oct 18, 2000 at 09:52:54PM -0500, Chris Abbey wrote: At 22:45 10/18/00 -0400, Christopher Faylor wrote: Now that I've had a minute to think about this though, let me ask you a better question WHY? What could you possibly want to put into cygwin that you feel it HAS to be done in asm? And that you can write better asm for this than gcc? There are all sorts of places where you can get a speed advantage by going straight to asm. Or, there are simply some things you cannot do in C when you are attempting to emulate an OS. In this particular case, I'd like to avoid the overhead of a function call when doing a relatively frequent operation (InterlockedIncrement and InterlockedExchange). These are basically one instruction but the function call overhead makes this much higher -- especially on Windows 95. Windows 95 uses an unbelievable number of instructions to do these relatively simple operations, thanks to the fact that it runs on more than just Pentiums. InterlockedExchange uses an opcode that is available on 80486 and above (I believe) but is unavailable on 80386 and below. There are also place in Cygwin where it's necessary to read the frame when adjusting things after a fork. You can't do that with C. We use asm for signal handling, auto loading of DLLs, for setting up exception handlers, and for experimental vfork emulation. cgf -- Want to unsubscribe from this list? Send a message to [EMAIL PROTECTED]
Re: Adding Cygwin FAQ to distro
On Wed, Oct 18, 2000 at 11:14:06PM -0400, DJ Delorie wrote: You realize that a FAQ included in a distribution is guaranteed to be out-of-date almost immediately, right? However, if we add a cygwin/cygwin-faq-MMDD.tar.gz to latest, it can be updated as it changes, and setup will keep everyone up-to-date with the latest FAQ. It doesn't have to go in with the cygwin DLL. It doesn't matter. It will still be out of date on the user's machine unless they remember to update. I'm not against the idea, but I wonder if we're just making more work for ourselves by including it. cgf -- Want to unsubscribe from this list? Send a message to [EMAIL PROTECTED]
Re: ps output format
On Wed, Oct 18, 2000 at 10:13:14PM -0500, Chris Abbey wrote: the only new switch ps really needs at this point is the one to say "screw human readable, make it easier for my scripts to grok". I don't see much difficulty in parsing the output now, actually. cgf -- Want to unsubscribe from this list? Send a message to [EMAIL PROTECTED]
Re: ps output format
On Wed, Oct 18, 2000 at 10:45:58PM -0500, Chris Abbey wrote: At 23:23 10/18/00 -0400, Christopher Faylor wrote: I don't see much difficulty in parsing the output now, actually. true, once you know what you're doing... I've seen a lot of people write scripts that would have choked on that output you had above, simply because they saw formatted output and started making assumptions, where as if they'd seen colon separated values.. well cut -d ':' would become a much more heavily used script construct. Often picking up those scripts and moving them between *nix platforms has been a royal pain in the past, not only do you have to deal with the myriad of conflicting command line options, and the different ordering, but also that sometimes a field is 4 chars, and others it could be 10. This could *all* be solved if there was ONE switch across all ps implementations that output a simple csv style out put that could be accessed with a simple hlookup style of argument. ok, so I'm off in left field smoking crack and picking daises... It's not a bad idea, but I doubt that anyone would adopt Cygwin's convention if we adopted one. :-) Our insight debugger product goes to great lengths to attempt to parse ps output on various platforms and of course it breaks every time there is a new OS upgrade. Cygwin's PS output is really easily parsable using awk, I think -- except for the date. The date/time field is where there are always problems. If you are aware of an existing ps implementation that does this, though, I wouldn't mind a patch to have ps emulate it. The ps code is really pretty simple so it should not be hard to modify. cgf -- Want to unsubscribe from this list? Send a message to [EMAIL PROTECTED]
Re: Adding Cygwin FAQ to distro
On Thu, Oct 19, 2000 at 02:56:12PM +0100, David Starks-Browning wrote: On Wednesday 18 Oct 00, Christopher Faylor writes: Ok. Actually, maybe this could be part of a cygwin-docs distro. We could include all of the cygwin documentation there. OK (although I am in principle opposed to anything that creates more work for me). This should probably be something like latest/docs with two tar files, one containing the User's Guide and API Reference, and the other containing the FAQ. I say that because the former hardly ever changes, while the latter would change every week or so. But this is not a high priority for me. I would rather work on getting the FAQ into better shape *before* hundreds (thousands?) of copies get mirrored and installed all over the place. Good point. I wasn't thinking that you'd have to do this. I could probably drop this into the directory that I use for net releases and just generate tar balls from there. I could even do it on a weekly basis, if there was a need for this. cgf -- Want to unsubscribe from this list? Send a message to [EMAIL PROTECTED]
Re: FAQ about make
On Thu, Oct 19, 2000 at 06:07:23AM -0700, Earnie Boyd wrote: --- Chris Faylor [EMAIL PROTECTED] wrote: On Wed, Oct 18, 2000 at 10:14:57PM +0100, David Starks-Browning wrote: Wait, I'm confused now. Red Hat will ship with the environment variable MAKE_MODE=win32 set? Or will ship a version of make where --win32 behavior is the default? The latter. Would it help if we voiced complaint somewhere within Redhat? What reasoning is behind this? The reasoning is that we have customers who are used to MAKE_MODE=win32 and rely on it. One of our biggest customers uses make, gcc, etc. only as a native windows solution. They don't care about mount tables or cygwin at all. They want to be able to say: d:\foo\bar.exe : gcc -o d:\foo\bar.exe c:\bob\sproing.c and not have to worry about specifying MAKE_MODE=win32. Complaining to Red Hat wouldn't help with this. There is too much entrenched use of the win32 stuff with the old Cygnus customers. I believe that eCos might even use it in their makefiles, in fact. cgf -- Want to unsubscribe from this list? Send a message to [EMAIL PROTECTED]
Re: documentation
On Thu, Oct 19, 2000 at 12:11:13PM -0500, Gongtao Wang wrote: Can someone tell me where to find some good documents about c++ library of unix process/thread programming? Thank you. You're in the wrong mailing list. I'd suggest searching www.google.com or dejanews.com. cgf -- Want to unsubscribe from this list? Send a message to [EMAIL PROTECTED]
Re: Why does ls report some directory dates as future?
On Fri, Oct 20, 2000 at 09:31:02AM +0100, Don Sharp wrote: Following up on Larry Hall's suggestion to try a new snapshot I downloaded cygwin-inst-20001018.tar.bz2 but the resulting dll makes bash exit immediately with a handle complaint. Can anyone recommend a relatively stable recent snapshot? Yep. 20001018 was broken. 20001019 should be better. cgf -- Want to unsubscribe from this list? Send a message to [EMAIL PROTECTED]
Re: Cygwin SEGVs
On Fri, Oct 20, 2000 at 01:35:04AM -0400, Jonathan Kamens wrote: A few days ago, I wrote: If you're really motivated, you can build cygwin yourself Alas, much easier said than done. My attempt to build was failing in all kinds of strange ways, apparently related to configure getting the wrong answers about the questions it was asking. The first wrong answer I noticed in my build log was: checking whether gcc -L/scratch/jik/cygwin/build/i686-pc-cygwin/winsup -L/scratch/jik/cygwin/build/i686-pc-cygwin/winsup/cygwin -L/scratch/jik/cygwin/build/i686-pc-cygwin/winsup/w32api/lib -isystem /scratch/jik/cygwin/src/winsup/include -isystem /scratch/jik/cygwin/src/winsup/cygwin/include -isystem /scratch/jik/cygwin/src/winsup/w32api/include -isystem /scratch/jik/cygwin/src/newlib/libc/sys/cygwin -isystem /scratch/jik/cygwin/src/newlib/libc/sys/cygwin32 -B/scratch/jik/cygwin/build/i686-pc-cygwin/newlib/ -isystem /scratch/jik/cygwin/build/i686-pc-cygwin/newlib/targ-include -isystem /scratch/jik/cygwin/src/newlib/libc/include accepts -g... no After several hours of trying various things to debug this, I finally relized that the problem is that many of the tests in the configure scripts rely on empty output from gcc to indicate that there were no errors, but gcc was generating the warning "file patch prefix `/scratch/jik/cygwin/build/i686-pc-cygwin/newlib/' never used" to stderr, thus causing all of those tests to fail. I worked around this problem and managed to get the build to finish by moving gcc.exe to gcc.real and installing this as gcc: #!/bin/sh gcc.real "$@" 2/tmp/err.$$ STATUS=$? grep -v "file path prefix \`.*' never used" /tmp/err.$$ 12 rm -f /tmp/err.$$ exit $STATUS Is this something y'all expect to fail? If so, is it documented anywhere? If not, can it be fixed? If anyone answered this part of my message, I didn't see it; did some send an answer to the mailing list without CC'ing it to me? In any case, this is still broken in the 10/18 snapshot. Can someone from the Cygwin team either acknowledge that there is a problem here or explain why it isn't one? :-) There is a problem. Someone changed the top level configure a while ago and broke things. Newer versions of gcc won't output the warning that you're seeing so configure succeeds. There hasn't been much activity lately in coming up with a fix that is acceptable for older compilers so, if you have a generic fix, it would be appreciated. Otherwise your work around probably makes sense. cgf -- Want to unsubscribe from this list? Send a message to [EMAIL PROTECTED]
Re: Make --win32 shell bug?
I've applied your make patches to the sources. If you could send along appropriate ChangeLog entries it would be appreciated. I've chosen to correct Cygwin's behavior by using the program argument that was passed to spawn_guts rather than looking for command.com in the path. It was actually a bug that this wasn't done already. Thanks for investigating this. If you could send me the ChangeLog, I'll look into releasing a new version of make over the weekend. FYI, please follow *exactly* the format used in the current ChangeLog with regard to spacing, formatting, and filename/function usage. cgf On Thu, Oct 19, 2000 at 02:27:09PM -0400, Town, Brad wrote: Attached is a patch to winsup/cygwin/spawn.cc -- it's the final piece of the puzzle. It and the patches I sent yesterday fix the make --win32/cmd.exe problem. -- Want to unsubscribe from this list? Send a message to [EMAIL PROTECTED]
Re: Cygwin SEGVs
On Fri, Oct 20, 2000 at 02:03:55PM -0400, DJ Delorie wrote: There is a problem. Someone changed the top level configure a while ago and broke things. That would be me, so I guess I better explain ;-) Actually, I don't think it was you, DJ. I remember the discussion to use any output at all from a compilation as indication of an error. I think that is what changed, wasn't it? I thought that Alexandre Oliva made this change. I know that you were trying valiantly to *fix* it, though. cgf -- Want to unsubscribe from this list? Send a message to [EMAIL PROTECTED]
Re: CygWin 1.1.4: problem in default /etc/profile when HOME has s paces
Cygwin uses the PATH variable internally. The windows API has no problems with filenames or directories with spaces in them. When you start attempting to use filenames with spaces on a command line, then you have problems. You have problems with PATH in this context, too, and, in fact, people have reported the same overwhelming perplexing problems with using PATH in this context as they have with HOME. cgf On Sat, Oct 21, 2000 at 02:57:10PM +1100, Robert Collins wrote: Well the path variable is an example of this that seems to work w/o problems. Rob - Original Message - From: "Larry Hall (RFK Partners, Inc)" [EMAIL PROTECTED] To: "Robert Collins" [EMAIL PROTECTED]; "Earnie Boyd" [EMAIL PROTECTED]; "Town, Brad" [EMAIL PROTECTED]; "'Ignasi Palou-Rivera'" [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Saturday, October 21, 2000 10:17 AM Subject: Re: CygWin 1.1.4: problem in default /etc/profile when HOME has s paces If you can figure a way to make sure that spaces in HOME are always treated as escaped no matter how its used, that's a possibility. After doing some shell programming, its not clear to me how one could guarantee that spaces in any environment variable is always escaped but just because the notion eludes me doesn't mean it couldn't be done!;-) Larry Hall [EMAIL PROTECTED] RFK Partners, Inc. http://www.rfk.com 118 Washington Street (508) 893-9779 - RFK Office Holliston, MA 01746 (508) 893-9889 - FAX At 07:13 PM 10/20/2000, Robert Collins wrote: What about having cygwin "\ " escape the spaces? Worth a thought? Rob - Original Message - From: "Earnie Boyd" [EMAIL PROTECTED] To: "Town, Brad" [EMAIL PROTECTED]; "'Ignasi Palou-Rivera'" [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Saturday, October 21, 2000 12:55 AM Subject: RE: CygWin 1.1.4: problem in default /etc/profile when HOME has s paces Brad's comment is certainly valid but your solution, Ignasi, is already implemented in the current setup.exe. IMO the better solution is to use a mount point like so (using Brad's example): mkdir -p /home/palau ;# if it doesn't already exist mount -b "C:/Documents and Settings/palau/My Documents" /home/palau I suppose that we should add a W2K entry in the TODO list for this issue. Cheers, Earnie. --- "Town, Brad" [EMAIL PROTECTED] wrote: The best solution would be to not have spaces in HOME at all, since it breaks many a good program. For example, if you wanted your home directory to be "C:\Documents and Settings\palau\My Documents", you could use "C:\Docume~1\palau\MyDocu~1" or a mount point. Brad Town -Original Message- From: Ignasi Palou-Rivera [mailto:[EMAIL PROTECTED]] Sent: Friday, October 20, 2000 9:33 AM To: [EMAIL PROTECTED] Subject: CygWin 1.1.4: problem in default /etc/profile when HOME has spaces The default /etc/profile for the 1.1.4 version of CygWin chokes when HOME is defined including blanks. The solution is to quote the reference to $HOME in line 14: IPALOU$ diff profile profile.orig 14c14 if [ ! -d "$HOME" ]; then --- if [ ! -d $HOME ]; then I'm running under Win2000, but I'm sure that's irrelevant. Ignasi. -- Want to unsubscribe from this list? Send a message to [EMAIL PROTECTED] __ Do You Yahoo!? Yahoo! Messenger - Talk while you surf! It's FREE. http://im.yahoo.com/ -- Want to unsubscribe from this list? Send a message to [EMAIL PROTECTED] -- Want to unsubscribe from this list? Send a message to [EMAIL PROTECTED] -- Want to unsubscribe from this list? Send a message to [EMAIL PROTECTED] -- [EMAIL PROTECTED]Red Hat, Inc. http://sources.redhat.com/http://www.redhat.com/ -- Want to unsubscribe from this list? Send a message to [EMAIL PROTECTED]
bash exiting problem fixed?
My fingers will never be the same, but I managed to reproduce the bash exiting problem on my system with some degree of reliability. It only took typing 'sleep 2' and then CTRL-P, CTRL-M about 100 times every time I wanted to duplicate it. The problem seems to be caused by bash's inability to handle two commands in a row returning the same pid. Windows NT can do this occasionally. Windows 95 can do it repeatably. I guess some people's versions of Windows NT can do it more than occasionally. In the scenario where two successive commands return the same pid, bash does not reset the tty's process group to itself and the next attempt to read from the tty results in an error, which causes an exit. Guess what? I'd already fixed this for Windows 95. So, please try tonight's snapshot. I've just started a rebuild going for it now (2000-10-21 1:03AM), so it won't be available for a while. To verify, before you download the snapshot, check the ChangeLog. The ChangeLog has to have this entry in it: * fork.cc (fork_parent): Avoid returning same pid twice in a row regardless of OS. or my proposed fix won't be in the DLL. Please send email to the cygwin mailing list if this does or doesn't solve the problem, along with a cygcheck -r -s -v, of course. I think I'm going to go soak my hands in some hot water now... cgf -- Want to unsubscribe from this list? Send a message to [EMAIL PROTECTED]
Re: cygwin on a 386?
On Sat, Oct 21, 2000 at 12:27:53AM -0500, Tom Hutto wrote: | The instruction in question is CMPXCHG. It's only available on a 486 | and above: | | http://developer.intel.com/design/intarch/techinfo/Pentium/instsum.htm | | I'm still waiting for someone to inform me that Cygwin works fine on a | 386... What happens if you NEVER get it? I guess eventually my head will explode. cgf -- Want to unsubscribe from this list? Send a message to [EMAIL PROTECTED]
Re: Sharing a name !
On Mon, Oct 23, 2000 at 09:08:47PM -0400, Chris A Faylor wrote: Hello, This is addressed to Christopher Faylor, from Christopher A. Faylor. I'm not sure if I have written you before, but the sight of my name on something I have no connection to, well gets my attention. I would hope to hear from you and find out if there is any family connection, seeing that Faylor is NOT a common last name. I appreciate any info you may have to share, thanks for your time. The other Chris Hopefully no one will disagree with me that this is just a tad off-topic for the cygwin mailing list. I've sent Christopher Faylor some private email. cgf -- Want to unsubscribe from this list? Send a message to [EMAIL PROTECTED]
Re: Can't kill processes with 10-22 snapshot
On Mon, Oct 23, 2000 at 03:09:09PM -0700, Rick Rankin wrote: I have several command-line based processes that I start in the background from bash. I have a shell script that starts and stops them for me as I need them. The commands themselves are .exe files that are built with VC++. With 1.1.4 and earlier, I could start and stop these processes with no problem. With the current snapshot, I can still start the processes; however, I get a 'not owner' message when I try to kill them. Should be fixed in tonight's snapshot. Thanks for the report. cgf -- Want to unsubscribe from this list? Send a message to [EMAIL PROTECTED]
Re: non latin file names?
On Tue, Oct 24, 2000 at 10:22:38AM +0400, Andrej Borsenkow wrote: Problem 1 - SAMBA and 8-bit characters. You must tell SAMBA what OEM code page is used by your client. This is probably either 850 or 437. You better ask on SAMBA list about this problem. most likely this is the problem, I've done some more hacking (trying to answer your previous questions with a step by step demo you could run yourself to do a bare minimum recreation) and I see that whatever error is happening on the xfr from windows to linux via samba it's orthogonal... gigo... such that even though the filename becomes garbage on linux, it's at least consistently able to spit it back to me correctly on NT. I'll follow up with a samba guru I know at work. The root problem in this case was that, while the two files appeared to have the same file name, with the same glyphs, at a binary level they didn't match... cygwin on nt wanted to use 0xF3, but the file that came over from linux had 0xA2. Cygwin is obviously using ANSI code page, while file comes to Linux in OEM code page (additionally, SAMBA may, if configured, convert OEM code page to whatever local character set is used on server). Unless all parties agree to use single charset - and that should be some version of Unicode for general case - problem remains. Our good fellas in ASCII world are _very_ lucky to not have this problem. Well, we wouldn't have the problem if someone contributed code to correct it. It's a free software project, right? cgf -- Want to unsubscribe from this list? Send a message to [EMAIL PROTECTED]
Re: source for setup.exe?
On Tue, Oct 24, 2000 at 11:14:45AM -0400, John Pollock wrote: is the source available for setup.exe? I looked for it on the ftp site but couldn't find it. I was going to look into adding a silent option to the setup program and see how difficult it would be (maybe accept a parameter for whether it's installation from a local directory vs. from the internet). Right now i'm getting around the problem by using scriptit to invoke setup, but that's extremely fragile (if the window titles for any of the cygwin dialog boxes change, it'll break scriptit). It's available via CVS or in one of the snapshots. It's a component of the winsup directory. cgf -- Want to unsubscribe from this list? Send a message to [EMAIL PROTECTED]
Re: CYGWIN1.DLL was not found
On Tue, Oct 24, 2000 at 12:24:19PM -0400, Larry Hall (RFK Partners, Inc) wrote: At 11:49 AM 10/24/2000, you wrote: On Tue, Oct 24, 2000 at 11:31:15AM -0400, Larry Hall (RFK Partners, Inc) wrote: At 11:07 AM 10/24/2000, you wrote: Hi, I get "A required .DLL file, CYGWIN1.DLL was not found" when execute a program in windows? I searched for it but it's not on my system disk. Better get it. Install from www.cygwin.dll. www.cygwin.com :-) Thanks Chris. Obviously my developer's mind-set is very ingrained!;-) And, you seem to have a reflexive need to answer questions and be helpful. You have to learn to curb these tendencies or you're never going to get any development work done. :-) cgf -- Want to unsubscribe from this list? Send a message to [EMAIL PROTECTED]
Re: non latin file names?
On Tue, Oct 24, 2000 at 09:26:05PM -0500, Chris Abbey wrote: I'm not going to do it because I have no experience in doing it and little interest in learning how to do it. interest in i18n/l17n aren't really needed... that code, at least the conversion tables that are iconv/gconv are there... what's needed is to make them available to programs in cygwin (jikes could make use of it today, hence my interest) then as the general i18n/l17n work takes place in the GNU World (groan, bad pun) it can be readily absorbed by cygwin (ie. to tie this back to the start of the thread, ls will someday learn how to display ó in the general gnu-fileutils; when it does, cygwin will be ready. That second part btw is a massive effort, and one that a handfull of big companies (IBM) are looking at very hard.) If no changes to cygwin1.dll are required then this is a possibility. Otherwise, due to licensing considerations we can't just take GPL'ed code that is owned by another entity into Cygwin or newlib. So, it is not necessarily this simple, unfortunately. cgf -- Want to unsubscribe from this list? Send a message to [EMAIL PROTECTED]
Re: gdb5.0 on cygwin B20.1, compiler problems
On Wed, Oct 25, 2000 at 02:15:38PM +0200, Johan Niklasson wrote: I have been trying for a few days now to compile gdb-5.0 I have a NT sp4 machine Cygwin B20.1 gcc 2.7.2 (comes with the cygwin-release) I have been forced to change some lines in the makefiles because obviously configure have some problems. I'm currently stuck on win32-nat.c. And I was wondering if you have an example of a makefile for gdb that works. It'd be great to compare with. I've been looking at the different mailinglist but have not found any answer. If you haven't got any I'd like to know if you have any experience to share. 1) Don't use B20.1. It is old. Check out http://www.cygwin.com/ . 2) Use either a snapshot version of gdb, a CVS version, or the version that comes with the 1.1.x version of gdb. GDB 5.0 probably won't work well on W2K. cgf -- Want to unsubscribe from this list? Send a message to [EMAIL PROTECTED]
Re: Porting my console app...
On Wed, Oct 25, 2000 at 02:29:25PM -0400, John Ehrlinger wrote: I am porting a program from a Unix platform to windows using the cygwin and mingw. I've managed to get the code to compile across both platforms and am currently testing and debugging on the windows platform. The program is a console app that I want to run in native windows (-mno-cygwin) since I'll be distributing it to outside users. My program uses getenv to locate a temporary directory for file storage. I'm defining the directory environment variable in Windows but my program does not resolve the variable. I figured in cygwin I can import the windows environment through the .bash files. Is there another method I should use to get the windows environment variables when I'm running my app stand alone? I could conditionally compile around the getenv to a windows method, but I'd need a pointer to the correct api. Sorry if the question is repetitive or simplistic. I'm just a Unix programmer porting to a windows world. Then don't use -mno-cygwin. It's not a cygwin app at that point. If you need help with your -mno-cygwin program then you should probably check out www.mingw.org . They have pointers to mailing lists that are populated by people who might be used to handling this type of question. cgf -- Want to unsubscribe from this list? Send a message to [EMAIL PROTECTED]
Re: -include is not silent in 3.79.1
On Wed, Oct 25, 2000 at 04:39:50PM -0400, Paul D. Smith wrote: %% Robert Mecklenburg [EMAIL PROTECTED] writes: rm I don't know if this is a cygwin bug or a make bug, so I've sent rm to both lists. When the following makefile is run on W2K with the rm latest cygwin make (3.79.1) it produces a warning message and rm should not. It works correctly for me (doesn't print a message) with GNU make 3.79.1 on Linux, so I think it must be a cygwin problem... ? Well, I don't see any problems with the cygwin version that I just released, so it's not a simple problem. Remember that the source to make is available for your viewing pleasure. cgf -- Want to unsubscribe from this list? Send a message to [EMAIL PROTECTED]
Re: ash and executable files (Was: sometimes ash does not like a.out)
I've mentioned in other email that you can use mount's '-x' option to either mount individual files or directories. That will force the executable bit on for the file or directory. I appreciate that you seem to have given this a lot of thought but, if this is important to you, then a patch is what is required. This mailing list is great because DJ, Corinna, and I all are responsive and fix problems. That does not mean that we are available to make suggestions into reality. Ideas are wonderful. Everybody is filled with good ideas. Actual work is scarce. Especially in this mailing list. So, you have the sources. Go nuts. cgf On Thu, Oct 26, 2000 at 05:11:04PM +0200, Hubert Garavel wrote: It was reported recently that using "sh" to build RCS does not work because "sh" refuses to execute a file named "a.out". This is again the same problem I reported on September, 29 ( see http://sources.redhat.com/ml/cygwin/2000-09/msg01019.html ) /bin/sh.exe fails to execute a binary program that has no ".exe" extension, if the pathname used to invoke his executable program contains at least one slash. Chris Faylor answered wisely that "sh" does not execute files if they do not have the executable bit set. On FAT partitions, this bit is always 0ff if the file has no ".exe" extension. On NTFS, this bit can also be set if CYGWIN=ntsec and a "chmod +x" is done. ( see http://sources.redhat.com/ml/cygwin/2000-09/msg01022.html ) This solution is not satisfactory, although I understand that it is difficult to emulate the executable bit on FAT partitions that do not support it. Using "CYGWIN=ntsec" could do the job. But there are still many FAT partitions and everyone would prefer a Cygwin solution that works identically on both FAT and NTFS. Drawbacks of the current approach - 1/ It causes a lot of confusion, as proven by the recent discussion on RCS build. Traditional Unix users do not understand why a binary program named "a.out" cannot be launched by "sh" 2/ Relying on the ".exe" suffix to set the executable bit gives strange (non-POSIX?) behaviours. For instance, when executing: mv program.exe new_program.out the program.exe loose its executable bit, although "mv" is not supposed to modify the stat attributes. Solution 1 : modify the implementation of stat() A solution would be to refine the implementation of stat() to check the contents of the file, in addition to its ".exe" extension. The executable bit would be set to 1: - if the file has an ".exe" extension - but also if the first bytes of the file look like a Win32 executable - if the file starts with "!#" (which probably indicates a Unix shell) This would be similar to the file(1) command, which tries to guess the type of a file by a quick analyzis of its contents. This approach might slow down all calls to stat(), fstat(), etc. Solution 2 : keep stat() as is, but improve /bin/sh.exe --- If stat() remain unchanged, then "sh.exe" should be improved, because this is the main place where the approximation on the executable bit creates troubles. Notice first that "sh.exe" has problems, but "bash.exe" doesn't. Example: if you type the following commands cp /bin/echo.exe /tmp/echo.out /tmp/echo.out foo in a bash window, bash will display "foo". If you give the same commands to "sh", you will get an error message "/tmp/echo.out: not found" Therefore, it seems reasonable to modify "sh.exe" in order to make it compatible with "bash" and to avoid the confusion created by the annoying "not found" messages. The change should probably took place in the find_command() of the "exec.c" module of "sh". Currently, if the name of the file contains a slash, "sh" checks that the file exists, is regular, and is executable. The "executable" condition should be relaxed, by being aligned with the strategy used in bash.exe. -- Want to unsubscribe from this list? Send a message to [EMAIL PROTECTED]
Re: problems with mount, ftpd and telnetd
On Thu, Oct 26, 2000 at 11:15:34AM -0500, Ayers, Mike wrote: From: Christopher Faylor [mailto:[EMAIL PROTECTED]] On Wed, Oct 25, 2000 at 06:36:43PM -0500, Ayers, Mike wrote: Both telnet and ftp are known to be currently broken. See /usr/doc/Cygwin/inetutils-*.README for details. I use telnet all of the time. I'd be lost without it. It is also listed as "What is working?" in the document that you reference. That it is, I notice. However, my telnetd isn't working either. I'll upgrade and see what happens. Maybe that's what the OP needs to do, too. My apologies for the bad info, but I distinctly remember crossing some reference to ftpd and telnetd not working correctly - I now forget where. AFAIK, telnetd has been working since 1997. cgf -- Want to unsubscribe from this list? Send a message to [EMAIL PROTECTED]
New GCC test release available
On Thu, Oct 26, 2000 at 01:39:48PM -0400, Ed Bradford/Raleigh/IBM wrote: If I knew which list to send email to I would try to prevail on the gcc/cpp owner to fix the problem. Apparently, it sees LF CRLF ok, and \LF ok, but \CRLF gets broken. It seems like an easy fix. That way people wouldn't have to worry about the exact format of header files in /usr/include. Gee. You'd "prevail", would you? You're willing to take time to "prevail" but not to investigate the problem and provide an "easy" fix? How helpful. Well, coincidentally, I have recently asked DJ to look into a fix for gcc. He's provided one and I've generated a new, test release with his patch. It is now available on mirrors. This is a test version of gcc, so you have to choose it appropriately when running setup.exe. The only fix in this release is the CRLF problem in cpp. There are no other changes from the previous version. Ironically, the version of gcc that we ship to customers has had this problem fixed already. So, I actually scheduled DJ's time to work on this net release issue. But, I'm sure that is exactly what everyone expects. After all, doesn't Red Hat have a staff of engineers devoted to nothing else but scanning the cygwin mailing list and listening to user gripes? Anyway, please send success or failure reports to the mailing list. If this solves everyone's problems, I'll remove the "test" distinction. You're welcome, by the way. cgf -- Want to unsubscribe from this list? Send a message to [EMAIL PROTECTED]
Re: Problems build perl modules on Win2K using cygwin
On Thu, Oct 26, 2000 at 04:54:13PM -0400, Larry Hall (RFK Partners Inc) wrote: If you don't have the most up-to-date DLL and make, get them. The is most likely a CR/LF issue... 'make' should deal with CRLF transparently, i.e., it shouldn't matter if their are \r's before \n's in the file. cgf -- Want to unsubscribe from this list? Send a message to [EMAIL PROTECTED]
Re: [patch] ambiguous else
On Fri, Oct 27, 2000 at 02:21:12PM +0200, Bernard Dautrevaux wrote:
-Original Message-
From: Jimen Ching [mailto:[EMAIL PROTECTED]]
Sent: Friday, October 27, 2000 6:53 AM
To: [EMAIL PROTECTED]
Subject: [patch] ambiguous else
Hi all,
Can someone verify that the following patch is needed.
Also, in exceptions.cc, there is a comment in interrupt_setup
which says
it is not multi-thread aware. I am running into a strange
problem where I
see an error about "couldn't send signal 14" and "wait for
sig_complete
event failed, ..." Are these related? Can someone give me
some hints as
to where to start looking if I want to know why these
messages are showing
up? Thanks.
--jc
diff -u -r1.51 sigproc.cc
--- sigproc.cc 2000/10/23 20:50:36 1.51
+++ sigproc.cc 2000/10/26 03:47:13
@@ -1121,10 +1121,12 @@
* this thread should terminate.
*/
if (rc == WAIT_TIMEOUT)
+{
if (!sig_loop_wait)
break; // Exiting
else
continue;
+}
if (rc == WAIT_FAILED)
{
These are not *needed*, but having them avoids anybody to wonder if the code
is doing this or that...
The indentation should be a clue here.
cgf
--
Want to unsubscribe from this list?
Send a message to [EMAIL PROTECTED]
Re: sh-utils: need interface to realpath()
On Fri, Oct 27, 2000 at 05:22:48PM -0400, Stephen Gildea wrote: I find I need a simple utility in a shell script: something to read through symlinks and give me the true name of a file. I don't see anything in Bash (2.04), sh-utils (2.0), or Cygwin (1.0) that provides this functionality. There is a common Unix function realpath() that does what I want, but it needs to be wrapped in a small utility program. I'm not sure where to suggest this utility be added. We needed it in Cygwin to clean Cygwin pathnames of symlinks before passing them to native NT programs, so I'm offering this here. It is also possible the base GNU shell utilities would be a good place to add such a program. If such a program is not already in the GNU shell utilities, then you should contact the maintainer and lobby to have your program included. We don't add special things to the GNU utilities if we can help it. Doing so just complicates making new releases. cgf -- Want to unsubscribe from this list? Send a message to [EMAIL PROTECTED]
So, has anyone *tried* the new gcc test release?
There was a lot of discussion about the problems with gcc where something like: #define foo bar \^M baz caused problems. So, I asked DJ to fix this and made a new release. Where are all of the "Yay! It fixes everything!" or "This doesn't work for me!" comments? Has anyone tried this? In case it isn't clear, you just have to choose the test version of gcc when running setup.exe. The only change in this release is DJ's change to eat ^M's in every case in cpp. cgf -- Want to unsubscribe from this list? Send a message to [EMAIL PROTECTED]
Re: [ANNOUNCEMENT] Updated: less 358-2
On Sun, Oct 29, 2000 at 11:25:27PM -0800, Vladimir G Ivanovic wrote: Let me do some more experimenting because I installed the new cygwin and couldn't run (version mismatch problem), ...which would indicate that you have two versions of cygwin1.dll on your system. That doesn't work. cgf -- Want to unsubscribe from this list? Send a message to [EMAIL PROTECTED]
Re: [ANNOUNCEMENT] Updated: less 358-2
On Mon, Oct 30, 2000 at 10:49:03AM +0300, Andrej Borsenkow wrote: Let me do some more experimenting because I installed the new cygwin and couldn't run (version mismatch problem), so I reverted to the current, still official version. Now, less-358-2 + xterm works the same way that the previous version of less (i.e. displays on all 40 liens, but puts the mode line on line 24.) I also have a W2K system I can try things on. Unfortunately, I won't be able to experiment until Wednesday. This does work with current versions in Cygwin shell window (bash or zsh). If I resize window and then start less, less correctly puts prompt on last line. What does not work, is resizing window while less is running. In this case display is messed up, and status line sometimes appear in the middle of screen. It does not work with vim either, so, it looks like cygwin does not support SIGWINCH. % cd /cygnus/src/winsup/cygwin % grep SIGWINCH *.cc *.h exceptions.cc: if (sig == SIGCHLD || sig == SIGIO || sig == SIGCONT || sig == SIGWINCH) fhandler_console.cc: kill_pgrp (tc-getpgid (), SIGWINCH); fhandler_tty.cc:_kill (-get_ttyp ()-getpgid (), SIGWINCH); select.cc:kill_pgrp (fh-tc-getpgid (), SIGWINCH); cgf -- Want to unsubscribe from this list? Send a message to [EMAIL PROTECTED]
Re: So, has anyone *tried* the new gcc test release?
On Mon, Oct 30, 2000 at 04:38:09PM +0800, Peter Sadrozinski (NRJ) wrote: I still notice the multi-line macro / CR-LF problem compiling C programs. Using version 2.95.2-3 Please send the output of gcc --version so that I can be convinced that you are, in fact, running 2.95.2-3. I obviously tried this and found that it solved the problem. Or, even better, the output from this command would show exactly what was being run: % touch t.c % gcc -v t.c cgf -- Want to unsubscribe from this list? Send a message to [EMAIL PROTECTED]
Re: question about cygwin terminal type
On Mon, Oct 30, 2000 at 05:10:36AM -0330, Neil Zanella wrote: SIGWINCH isn't related to the $TERM value (it's whether or not your host supports the negotiations about window size) Does Win2K support SIGWINCH? It's not "Win2K" that is the issue. It's Cygwin. Cygwin tries to emulate all UNIX signals, including SIGWINCH. cgf -- Want to unsubscribe from this list? Send a message to [EMAIL PROTECTED]
Re: Cygwin 1.1: setup of info files is incomplete.
On Mon, Oct 30, 2000 at 09:00:39AM -0500, Jason Tishler wrote: On Fri, Oct 27, 2000 at 02:00:10PM -0700, Masterson, Dave wrote: The 'info' command (from Texinfo) looks for "dir" (directory) files to determine what the menu is that should be displayed when invoked. This file is not created by the installation of Cygwin 1.1. However, the nature of this "dir file is such that it needs to be updated (pretty much) after every package installation -- it really can't be included in any particular package. Could "setup" be adjusted to run "install-info" after every package installation? I agree with the above, but I think that it should be generalized. There are postinstall tasks that should be one-shot (i.e., as currently implemented in setup) and ones that should be executed every time (e.g., regenerating the info dir files). The question is how to best integrate the support of both one-shot and every time postinstall scripts into DJ's setup? That's one question. The more important question is "Who's going to do the work?" cgf -- Want to unsubscribe from this list? Send a message to [EMAIL PROTECTED]
Re: Installation of OpenSSH on NT
On Mon, Oct 30, 2000 at 04:11:16PM +0100, Corinna Vinschen wrote: Bladt Norbert wrote: P.S. Corinna are you still on this list ? No. I'm just posting to this mailing list to distract people. Huh? What? Who is this? Why are you sending me email? What are all those other messages in my mailbox about a Cyg Win? Is this related to SIGWINCH? I'd like to shore up my signals with a WINCH but I never knew how to do this. Does your Cyg Winch program provide all of the chains, ropes, and other stuff needed for heavy lifting? Sorry to bother you. I haven't had time to read the Syg Winch FAQ. I'd rather just pester you all with email since you insist on sending email to me. I have a lot of signals and engines and stuff that need to be lifted. I hope to hear from you soon. cgf -- Want to unsubscribe from this list? Send a message to [EMAIL PROTECTED]
Re: locatedb: No such file
On Mon, Oct 30, 2000 at 10:34:57AM -0600, Dennis W. Bulgrien wrote: Though I left cygwin prompt open all night, locate fails. Is it supposed to work? $ locate dsp.bat locate: /usr/var/locatedb: No such file or directory Hmm. I wonder what in the world that error message could possibly mean. cgf -- Want to unsubscribe from this list? Send a message to [EMAIL PROTECTED]
Re: vivian hunt
On Mon, Oct 30, 2000 at 06:31:15PM +, Vivian Hunt wrote: Dear sir/madam I recently downloaded cygwin from your site. I have several files = with the extension .tar and these are opened in winzip, which won't open them for me. Can you tell me which = software does please. e-mail:[EMAIL PROTECTED] Go to the cygwin web site at: http://www.cygwin.com/ and click on the "Install Cygwin Now" link. That will download a program that is used to install Cygwin. You are aware that Cygwin emulates the UNIX environment, right? .tar and .tar.gz files are common in this environment (they are files created with the 'tar' utility) so I'm just double checking. cgf -- Want to unsubscribe from this list? Send a message to [EMAIL PROTECTED]
Re: I've ported MIT kerberos v1.2.1 to cygwin
On Mon, Oct 30, 2000 at 05:15:51PM -0800, Mark Seigle wrote: I'm new to this list, but I figured that some people might like the most up-to-date version of MIT kerberos. I'm not sure what the protocol is for posting patches etc. Please clue me in. If you would like to produce a tarball with this stuff, we can include it in the standard distribution, assuming that you're willing to be responsive to problems that crop up here. For kerberos, I think that this just means that things are installed by default in /usr/kerberos/... Are you interested in being the cygwin kerberos maintainer? cgf -- Want to unsubscribe from this list? Send a message to [EMAIL PROTECTED]
Re: Can't start background processes from script
On Mon, Oct 30, 2000 at 10:42:26AM -0800, Rick Rankin wrote: For the last few snapshots, including the 1.1.5-1 test release, some shell scripts I have that start some background processes haven't been working. By 'not working', I mean that the background processes never get started. These same scripts do work, however, if I backup to cygwin-1.1.4. This should be fixed in tonight's snapshot and in the newly released cygwin-1.1.5-2. Thanks for the report. cgf -- Want to unsubscribe from this list? Send a message to [EMAIL PROTECTED]
Re: cygwin 1.1.6?
On Mon, Oct 30, 2000 at 01:51:02PM +0800, Topas wrote: After I install the cygwin-1.1.5-2, uname reports the system is cugwin 1.1.6 Sorry about that. I guess I need a cygwin-1.1.5-3. It will be available shortly. cgf -- Want to unsubscribe from this list? Send a message to [EMAIL PROTECTED]
Re: ps and psql from PostgreSQL not working with cygwin-1.1.5-2
On Tue, Oct 31, 2000 at 04:26:41PM +0100, Dr. Volker Zell wrote: "Chris" == Chris Faylor [EMAIL PROTECTED] writes: Chris I've uploaded a new, testing version of Cygwin to sources.redhat.com. Chris A partial list of what has changed is below. If anyone who has Chris submitted changes that are not mentioned below wants to chime in, please Chris feel free. Chris I'm making this available as a testing version first because there were Chris major changes in this version of cygwin and I thought it would be easier Chris to test if it was installable via setup.exe. Chris If there are no serious complaints with this version of cygwin, I'll make Chris it the next official version on Thursday. I'm using cygwin-1.1.5-2 and have problems running ps from cygwin and psql from PostgreSQL: ps gives no output expect the headerline: vzell:/tmp ps PIDPPIDPGID WINPID TTY UIDSTIME COMMAND psql gives the following error: vzell:/tmp psql.exe -h localhost template1 psql.exe: connectDBStart() -- connect() failed: No more processes Is the postmaster running (with -i) at 'localhost' and accepting connections on TCP/IP port '5432'? Switching to cygwin-1.1.4 everything is fine. I can't duplicate the ps problem and I don't use psql.exe so, unless someone can debug this, or provide more details, this will be a problem that is in 1.1.5. strace output would probably help. Offhand it sounds like you're missing either psapi.dll if you're on Windows NT or CreateToolhelp32Snapshot stuff in your kernel32.dll on Windows 9x. cgf -- Want to unsubscribe from this list? Send a message to [EMAIL PROTECTED]
Re: latest cygwin does not track pwd?
On Tue, Oct 31, 2000 at 02:10:42PM -0500, Larry Hall (RFK Partners, Inc) wrote: At 01:57 PM 10/31/2000, Richard Y. Kim wrote: I updated to all latest files as of 10:30AM on October 31, 2000 from ftp.freesoftware.com as well as ftp.yggdrasil.com. I give two examples of how bash and/or cygwin1.dll gets confused about pwd. First "ls -l ./foo" reports that ./foo does not exist. However, "cat ./foo" prints out its old content! bash-2.04$ cd d:/projects/apwin/tools/ bash-2.04$ ls -l ./foo ls: ./foo: No such file or directory bash-2.04$ cat ./foo #!/usr/local/bin/perl use Cwd; my $dir = cwd; print "cwd = $dir\n"; bash-2.04$ Is the behavior different if you mount d: and access cd to the directory that way (or use the /cygdrive/d convention)? Can anyone else duplicate this? It works as expected for me. cgf -- Want to unsubscribe from this list? Send a message to [EMAIL PROTECTED]
Re: latest cygwin does not track pwd?
On Tue, Oct 31, 2000 at 03:55:28PM -0500, Larry Hall (RFK Partners, Inc) wrote: At 02:39 PM 10/31/2000, Richard Y. Kim wrote: "LH" == Larry Hall (RFK Partners, Inc) [EMAIL PROTECTED] writes: LH Try cding into /mnt/d/projects/apwin/tools/ and LH doing the ls -l ./foo. I assume that foo is LH listable if you provide the full DOS or mounted LH path, right? # cd'ing via /mnt/d does not show ./foo bash-2.04$ cd /mnt/d/projects/apwin/tools/ bash-2.04$ ls -l ./foo ls: ./foo: No such file or directory bash-2.04$ cat ./foo cat: ./foo: No such file or directory # cd'ing via d:/ *does* show ./foo bash-2.04$ cd d:/projects/apwin/tools/ bash-2.04$ ls -l ./foo ls: ./foo: No such file or directory bash-2.04$ cat ./foo #!/usr/local/bin/perl use Cwd; my $dir = cwd; print "cwd = $dir\n"; # using fullpath does not show ./foo at all bash-2.04$ ls -l d:/projects/apwin/tools/foo ls: d:/projects/apwin/tools/foo: No such file or directory bash-2.04$ ls -l /mnt/d/projects/apwin/tools/foo ls: /mnt/d/projects/apwin/tools/foo: No such file or directory bash-2.04$ cat d:/projects/apwin/tools/foo cat: d:/projects/apwin/tools/foo: No such file or directory bash-2.04$ cat /mnt/d/projects/apwin/tools/foo cat: /mnt/d/projects/apwin/tools/foo: No such file or directory bash-2.04$ I recall reading about a new feature in w2k's file system where it tries to keep a single copy of a file if the content is the same. I am going to see if I can dig up the reference to that. Perhaps that "feature" is getting in the way of cygwin? I'll keep you posted. If this reference is what I think it is, then I don't think you'll find it addresses your issue. Actually, I just tried the latest DLL (1.1.5.x) and similar actions worked OK for me. I did this on W2K so I don't think there's an issue there. Here's the output of uname -a from this DLL: CYGWIN_NT-5.0 ENTERPRISE-E 1.1.6(0.29/3/2) 2000-10-30 20:28 i686 unknown Given that you note in another (private) email message that adding a "/" to the end of the directory you cd to resolves the issue, it almost seems to have the flavor of a CR/LF issue, though obviously that's not really it. Can you ls any files in the directory with foo? Can you ls that directory itself? Is you ls aliased to anything? As you can tell, I'm grasping at straws!;-) What does /bin/pwd report after you've cd'ed? And, what does 'ls -l .' show? cgf -- Want to unsubscribe from this list? Send a message to [EMAIL PROTECTED]
Re: sh-utils: need interface to realpath()
On Tue, Oct 31, 2000 at 04:26:01PM -0500, Stephen Gildea wrote:
cygpath -w {cygwin-path-to-symlink}
Thank you for your reply.
The cygpath program does do the cygwin_conv_to_full_win32_path() part,
but it does not do the more interesting realpath() expansion. That is,
it doesn't expand symlinks.
Have you looked at the source code for 'realpath()' and
'cygwin_conv_to_full_win32_path()'. They are almost identical, i.e.,
both should translate symbolic links.
And, guess what? I actually tried cygpath just to verify what it does.
It does translate symolic links.
cgf
--
Want to unsubscribe from this list?
Send a message to [EMAIL PROTECTED]
Re: 1.1.4: Inconsistent i-node numbers
This is a long-standing problem in cygwin. Using real inode numbers in readdir would be expensive but using hashes for everything would be imprecise. I've never heard of a great solution for this, unfortunately. cgf On Tue, Oct 31, 2000 at 04:01:03PM -0500, Boris Gjenero wrote: NOTE: I am not on the mailing list. If you want to reach me, e-mail me. Stat returns Windows inode numbers on certain devices (fixed disks, CD-ROMs, etc.). It only uses hashing if the device is not one of those or if it can't open the file. readdir always uses the filename hashing mechanism to generate the inode number. This means that inode numbers won't agree on certain devices like hard disks and CD-ROMs. Of course, not a lot of software cares about i-node numbers. I discovered the bug when I compiled an NFS server and all NFS file handles were stale. The readdir function is in: winsup/cygwin/dir.cc The stat inode handling is in the function fhandler_disk_file::fstat in winsup/cygwin/fhandler.cc But then if stat can't open a file it will use code in the stat_worker function in winsup/cygwin/syscalls.cc My temporary fix is to change fhandler_disk_file::fstat so it always uses hashing. (Look around line 935 in fhandler.cc) However, this may not be the right thing to do; perhaps inodes should be used by all functions if possible. BTW. Yeah, nfs-server-2.2beta47.tar compiles with a few modifications and it works. I've hacked device support into CygWin using a .DEV NT extended attribute to store the device number. I'm also going to add another attribute to store the UID and GID of a file. When that's done the NFS server should be more-or-less Unix-comatible. -- Want to unsubscribe from this list? Send a message to [EMAIL PROTECTED] -- [EMAIL PROTECTED]Red Hat, Inc. http://sources.redhat.com/http://www.redhat.com/ -- Want to unsubscribe from this list? Send a message to [EMAIL PROTECTED]
Re: Problem in readlink() function?
On Tue, Oct 31, 2000 at 05:25:38PM -0500, Jeff Hu wrote: According to the documentation I have, the readlink() function is supposed to return ENOENT, EINVAL, or ERANGE in the errno global variable if the file doesn't exist, is not a symlink, or is too long. But I'm seeing that errno is being set to 0 for files that don't exist. This is with the latest CVS source of path.cc Yep. There's a problem. I've just checked in a fix. Thanks for the bug report. cgf -- Want to unsubscribe from this list? Send a message to [EMAIL PROTECTED]
Re: latest cygwin does not track pwd?
On Tue, Oct 31, 2000 at 11:31:08PM -0500, Charles Wilson wrote: Christopher Faylor wrote: cwd = just as Richard Kim says. The code for Cwd::cwd on cygwin is implemented by perl-src/cygwin.c -- but I don't know why it's failing. Patches gratefully accepted (and archived -- I'm not planning to release a new perl build myself until 5.6.1 comes out; and probably not even then if a third party takes the initiative... The problem is that it looks like perl is calling getcwd like this: getcwd (NULL, 0); and cygwin is returning a NULL, as is mandated by both the Single Unix Specification and the linux man page. 1.1.4 allowed zero length length arguments but that was a bug that I fixed in 1.1.5. I had no idea that people were relying on the bug. I'm not sure what to do about this. I am loathe to accomodate a bug like this but I don't want to force a new perl release or endure to the next two years of "I cygwined my perl 1.1.[5-9] and it am broke" messages either. cgf -- Want to unsubscribe from this list? Send a message to [EMAIL PROTECTED]
Re: ps and psql from PostgreSQL not working with cygwin-1.1.5-2
On Wed, Nov 01, 2000 at 09:54:25AM +0100, Dr. Volker Zell wrote: Your're right, I'm missing psapi.dll. Where should it be ? Obviously it's not in the cygwin-1.1.5-2.tar.gz file. It's a Microsoft DLL. Even my 3.5 NT system has it. cgf -- Want to unsubscribe from this list? Send a message to [EMAIL PROTECTED]
Re: Installation of OpenSSH on NT
On Wed, Nov 01, 2000 at 12:51:29PM +0100, Bladt Norbert wrote: And the result was some trash on this list, too. Sorry for that. Just for your and everyone else's information, I do not consider occasional lapses into humor to be "trash" or even off-topic. If this bothers anyone then please find another UNIX for Windows project and another mailing list. cgf -- Want to unsubscribe from this list? Send a message to [EMAIL PROTECTED]
Re: BUG: cygwin-1.1.5-3 cannot call fl32 anymore...
On Wed, Nov 01, 2000 at 05:15:29PM +, Fons Rademakers wrote: Hi Chris, here is the cygcheck info first for cygwin-1-1-4 (sorry not 1.4.0), next for 20001031. The "pcsalow [129]" is my bash prompt. fl32 is not a cygwin program but a native win32 program (Digital Fortran). Invoking it without arguments prints the logo. To avoid anything strange coming from my .bash_profile and .bashrc I ran without them. See below: $ fl32 fl32: error: Unmatched quote character in command line now I tried strace to see if I could see something about what is going on and, low and behold, this is what I got: $ strace fl32 DIGITAL Visual Fortran Optimizing Compiler Version: V5.0 Copyright (c) 1997 Digital Equipment Corp. All rights reserved. notice that the MS VC++ 6.0 compiler works fine: That's not surprising. strace is invoking the program in this case, not bash. You'll have to run 'strace -f -osomefile bash' and type in fl32 to see what cygwin is doing. cgf -- Want to unsubscribe from this list? Send a message to [EMAIL PROTECTED]
Re: OpenSSH-2.2.0p1 for Cygwin 1.1.4
On Wed, Nov 01, 2000 at 07:18:06PM +0100, Ralf Fassel wrote: * Corinna Vinschen | I want to announce the latest OpenSSH version 2.2.0p1 ported for | Cygwin-1.1.4. --snip-snip-- | SSH protocol versions 1.3 and 1.5 are still part of that version, so | you shouldn't have problems in communicating with other SSH-1.2.X | versions. Just for the record: after installing this version, I get on my IRIX box: % ssh -V SSH Version 1.2.26 [mips-sgi-irix6.3], protocol version 1.5. Standard version. Does not use RSAREF. % ssh -x -t neptun Local: Bad packet length 1349676916. ssh from the NT box to itself works ok, and OpenSSH 2.1.1 from the UNIX box too, so I guess it's a problem of the protocol version. I used to see this problem with older versions of the ssh.com version of ssh on UNIX. I believe that the problem my lie in 1.2.26. You could try building a newer version for your IRIX system to see if that helps. cgf -- Want to unsubscribe from this list? Send a message to [EMAIL PROTECTED]
Re: latest cygwin does not track pwd?
On Wed, Nov 01, 2000 at 02:34:43PM -0500, Robinow, David wrote: On Wed, Nov 01, 2000 at 02:18:23PM -0500, Robinow, David wrote: It's definitely 'getcwd(NULL, 0)' in Chuck's sources. Also in 5.7.0 development sources. I think I'll just revert the behavior. It appears that a number of packages are expecting it. Is there a reason these packages can't be fixed? Is 'getcwd(NULL, -1)' broken in some version? Not that I know of, but Corinna has pointed out that some versions of linux suggest that getcwd(NULL, 0) is ok and, possibly, BSD allows this construction. So, I think we'll be constantly responding to this on the mailing list. I'd rather just "fix" cygwin. OK, it's your call. For what it's worth Solaris and IRIX both require EINVAL. I can't think of why failure to return EINVAL would break something though. It seems to work fine on Linux, the man page not withstanding. So, I've reverted my error test. cgf -- Want to unsubscribe from this list? Send a message to [EMAIL PROTECTED]
Re: make
On Thu, Nov 02, 2000 at 10:36:52AM +1300, [EMAIL PROTECTED] wrote: Hi all, I'm trying to include a file from a makefile, but it says that the file is not there. I'm using the UNIX_MODE and sh. In the current directory I have a makefile with the following line. The global file is in the same directory. What's wrong?? include "global" Don't quote the filename argument. cgf -- Want to unsubscribe from this list? Send a message to [EMAIL PROTECTED]
Re: 1.1.4, select, and SIGCHLD
On Wed, Nov 01, 2000 at 12:18:18PM -0800, Robert Fidler wrote: Below is a test program that exhibits the behavior I described. By defining WORKS, you will add a 1 second sleep between the kills and the program will work as expected. Thanks for the text case. It was an interesting problem. I have checked in a fix. cgf -- Want to unsubscribe from this list? Send a message to [EMAIL PROTECTED]
Re: ps and psql from PostgreSQL not working with cygwin-1.1.5-2
On Wed, Nov 01, 2000 at 10:40:40AM -0500, Christopher Faylor wrote: On Wed, Nov 01, 2000 at 09:54:25AM +0100, Dr. Volker Zell wrote: Your're right, I'm missing psapi.dll. Where should it be ? Obviously it's not in the cygwin-1.1.5-2.tar.gz file. It's a Microsoft DLL. Even my 3.5 NT system has it. I've eliminated the need for psapi.dll but I don't know if my net connection will accomodate a new version of 1.1.5 tonight. cgf -- Want to unsubscribe from this list? Send a message to [EMAIL PROTECTED]
Re: FAQ about make
On Thu, Nov 02, 2000 at 11:03:36AM +, David Starks-Browning wrote: On Thursday 2 Nov 00, Schaible, Joerg writes: Chris will have to clarify this for me. Is the distinction between the net release and Redhat's commercial release made only in the setting of MAKE_MODE in /etc/profile or cygwin.bat? I assumed it was in the version of make that shipped. AFAIK the cygwin.bat is in both versions the same (uups, it has no MAKE_MODE entry, i.e. win32 *is* the default for make). Just DJ's setup changes the environment setting for MAKE_MODE to unix in /etc/profile. I thought make had been changed for the net release to run in UNIX mode by default. The MAKE_MODE=UNIX in /etc/profile is superfluous. It has been changed. Your description is correct. I don't think that you should be discussing where environment variables are set in the FAQ entry. IMO, your entry is perfect as is. cgf -- Want to unsubscribe from this list? Send a message to [EMAIL PROTECTED]
Re: patch text mode problem with latest CVS source
On Thu, Nov 02, 2000 at 03:44:56PM -0500, Jason Tishler wrote: On Thu, Nov 02, 2000 at 03:20:46PM -0500, Christopher Faylor wrote: On Thu, Nov 02, 2000 at 03:17:09PM -0500, Jason Tishler wrote: Using the cygwin1.dll that I built from the latest CVS source (as of about 11 AM EST today) causes patch to convert all files actually patched to text mode. Note that I checked and my cygdrive mount is binary so this is not the problem. Has anyone else observed this with CVS or 1.1.5-3? A better question is if this behavior differs from cygwin 1.1.4. Yes, in my experience the behavior differs. In 1.1.4, patched files do not get converted into text mode, in 1.1.5 they do. If I toggle between the DLLs and apply the same patch to the same file (or a copy of the original), the file remains binary in 1.1.4 and converts to text in "1.1.5". In my experience, patch does exactly the same thing under 1.1.4 and 1.1.5. It seems to be controlled by the value of your "TMP" (or possibly "TEMP") environment variable. If that is set to a directory that is mounted as text, then the resulting file has \r\n line endings. If you can give me a simple test case which illustrates the problem I will investigate it. Please include the cygcheck -r -s -v output for both the failing and succeeding cases. cgf -- Want to unsubscribe from this list? Send a message to [EMAIL PROTECTED]
Re: Cygnus question
On Thu, Nov 02, 2000 at 04:50:02PM -0700, Scott Carter wrote: I'm not a unix expert, nor a Windows expert, but I don't think David's statements are all correct. In unix, as I understand it (and as David stated), it is the shell (bash, csh, ksh, ...) that does the filename expansion on the b* argument in ls b* The shell passes that expansion to ls on the command line (unless the expansion is empty, in which case the shell just passes the b*). If you have cygwin installed on a WinNT machine (with the cygwin bin directory in the PATH), you can run the cygwin ls command from the WinNT command prompt, and it works, the same as it does from a cygwin bash prompt. But I'm pretty sure that the WinNT shell (cmd.exe) does NOT expand b*. If that is true, ls must read the b* from the command line and (likely) pass it to a function which does the expansion. And I suspect that the function is located in the cygwin1.dll, and that it, in turn, calls a windows function, which is case insensitive. If that is true, the cygwin function would have to do extra work to force case sensitivity. [semi-educated speculation] So it seems to me that it would be possible to make ls case insensitive in cygwin. Whether or not it's a good idea, and how easily it could be done, is a different issue. Cygwin does wildcard translation on the command line when a program is run directly from a Windows command shell. It does this prior to starting the program just like bash. There are no facilities in cygwin for case insensitive globbing currently and I have no plans or desires to add this. If someone is interested (hah) in providing a patch, I'll gladly consider it. cgf -- Want to unsubscribe from this list? Send a message to [EMAIL PROTECTED]
Re: BUG: cygwin-1.1.5-3 cannot call fl32 anymore...
On Thu, Nov 02, 2000 at 10:55:23AM +, Fons Rademakers wrote: In the atachment find the part of the trace where fl32 is invoked. It looks like the problem might be in spawn_guts(). If you need more trace let me know. The strace indicates that the first argument is being properly quoted. It's quoted because it is being run from a directory with a space in it. It sounds like there is a bug in fl32. I assume that you'd get the same error if you tried to run it from the Start-Run menu. The trace for cl looks the same except that spawn_guts returns with res 0. spawn_guts returning 0 would indicate an error. cgf -- Want to unsubscribe from this list? Send a message to [EMAIL PROTECTED]
Re: BUG: cygwin-1.1.5-3 cannot call fl32 anymore...
On Fri, Nov 03, 2000 at 03:29:17PM +0100, Schaible, Joerg wrote: It might be a bug in fl32, but the bug was not triggered in cygwin1.dll version 1.1.4, so something in cygwin has changed that triggers this problem. Any idea what has changed in this area? Your TEMP directs into a directory with text mount. Try to change this and report what happens. Huh? Why would this have any bearing on the quoting of arguments? cgf -- Want to unsubscribe from this list? Send a message to [EMAIL PROTECTED]
Re: bison having ^M problems?
On Fri, Nov 03, 2000 at 11:37:45AM -0800, Earnie Boyd wrote: Please, PLEASE, make this as option. Make it default to the value of "Default Text File Type" but let users to change it. We don't need more options in setup for this. If UNIX is chosen then Jason's patch will apply "binary mode" to the /cygdrive prefix. If DOS is chosen then Jason's patch will apply "text mode" to the /cygdrive prefix. Users who are in the know can use `mount --change-cygdrive-prefix ...' to change it to something different. Sounds like a good plan to me. cgf -- Want to unsubscribe from this list? Send a message to [EMAIL PROTECTED]
Re: BUG: cygwin-1.1.5-3 cannot call fl32 anymore...
On Fri, Nov 03, 2000 at 02:12:53PM +, Fons Rademakers wrote: It might be a bug in fl32, but the bug was not triggered in cygwin1.dll version 1.1.4, so something in cygwin has changed that triggers this problem. Any idea what has changed in this area? Cygwin was incorrectly not quoting the first argument when it included spaces. Now it is. Did you try running fl32.exe via the run command, as I suggested? cgf -- Want to unsubscribe from this list? Send a message to [EMAIL PROTECTED]
Re: patch text mode problem with latest CVS source
On Fri, Nov 03, 2000 at 09:08:57AM -0500, Jason Tishler wrote: On Thu, Nov 02, 2000 at 05:14:51PM -0500, Christopher Faylor wrote: It seems to be controlled by the value of your "TMP" (or possibly "TEMP") environment variable. If that is set to a directory that is mounted as text, then the resulting file has \r\n line endings. Diff-ing cygcheck outputs between 1.1.4 and 1.1.5-3, I determined exactly what is the root cause. I had my TMP variable set as follows: export TMP=$SYSTEMDRIVE\\tmp just in case some Windows programs were using this variable. In 1.1.4, the TMP (and TEMP) environment variable was automagically converted into a POSIX style path, while in 1.1.5-3 it remained unchanged. Hence, I was bitten by the unmounted drives defaulting to text mode feature. Cygwin now passes on exactly what was set in the environment and in the argv list. Translation to UNIX format only happens in the first cygwin process that is run. Children of this process receive whatever the user sets. So, after the first translation, Cygwin emulates UNIX exactly. However, if you do something like: export TMP=/cygdrive/c/tmp A non-cygwin Windows app will see TMP as "c:\tmp", so there should be no reason to use Windows path specs when setting TMP environment variables. cgf -- Want to unsubscribe from this list? Send a message to [EMAIL PROTECTED]
Re: test report on ver 1.1.5-4
On Sat, Nov 04, 2000 at 08:14:05PM +0100, stefan wrote: I forgot: All this contribution/assign thingies are far to complicated for me as a programmer. It makes it unnecessarily delay. As I concluded from what i read RedHat is the owner of the cygwin1.dll ? So why is there a "net community" helping so much ??? I don't understand the question. Are you using Cygwin? Are you benefitting from it? Why wouldn't you want to help out on a free software project regardless of who owns the code? Just about all of the code distributed under the GPL is owned by someone. I don't enjoy having to jump through legal hoops getting people to sign over their changes to the DLL but it is a necessary evil. This does mean that you can't just take code owned by someone else (the FSF owns glibc) and plonk it into cygwin. You couldn't go in the other direction either. If that were possible, we certainly would have grabbed a lot of code from glibc by now. Just so it is clear -- Red Hat actually does sell Cygwin occasionally. We provide "buy out" licenses to customers that allow the customer to provide software that they've written to use the Cygwin DLL without "infecting" their code with the GPL. So, if you would like to be offended by the fact that Red Hat owns Cygwin, your next step is to be outraged that your efforts could actually be sold to customers. Your only cold consolation would be that if you make a positive change to Cygwin, your changes will be appreciated by many thousands of people who never paid a dime for it and any improvements that are made to Cygwin that result in an actual sale is another reason for Red Hat to continue funding the development. Because, of course, you are all benefitting from Red Hat's funding of development. Despite the fact that much of what DJ, Corinna, and I do in this mailing list and for the net community (do you think that Red Hat needs a setup.exe which downloads from the internet?) is on a volunteer basis, I doubt that you would see continued steady development if all of us were whisked to other projects. Oops. It's already happened to DJ. I expect that his new gcc duties will leave him much less time to work on setup.exe. So, there, we certainly could use net volunteers. cgf -- Want to unsubscribe from this list? Send a message to [EMAIL PROTECTED]
Re: test report on ver 1.1.5-4
On Sat, Nov 04, 2000 at 06:47:15PM -0800, Tim Prince wrote: I do work on commercial projects which use MKS, yet I have cygwin running on as many of the same boxes as it will run on, and prefer it for ad hoc tasks like grepping, finding, editing and the freedom from worry about violating the license. The changes I would like to make to cygwin generally turn out to affect too many other things for them to go anywhere; I have an FSF assignment on file just in case something does go through, although I haven't dealt with the issues which may be raised by changing my employment. I notified my new employer throught the internal process that I have FSF assignments on file, covering prior work, but they are too busy for sure to pay any attention to it. Unfortunately, FSF != Red Hat. Red Hat owns Cygwin. So any changes that you make to Cygwin require an Red Hat assignment. cgf -- Want to unsubscribe from this list? Send a message to [EMAIL PROTECTED]
Re: RedHat != FSF
On Sun, Nov 05, 2000 at 02:44:09PM +0100, stefan wrote: We provide "buy out" licenses to customers that allow the customer to provide software that they've written to use the Cygwin DLL without "infecting" their code with the GPL. That might be quite complicated too, if these people who do not want to get "infected" start using the libraries Cygwin additionally puts to their distribution because most of them are GPL'd. What libraries would those be? AFAIK, only readline is GPLed and not LGPLed? cgf -- Want to unsubscribe from this list? Send a message to [EMAIL PROTECTED]
Re: mail problems
On Sun, Nov 05, 2000 at 07:36:36AM -0800, Tim Prince wrote: Myrealbox and earthlink/mindspring have done a fairly good job for me. I generally wait until one service kicks the message back before trying another. That does present annoying delays at times, and I too have had messages disappear with no warning. Cygwin has been one of the worst about blocking legitimate posts while allowing spam to come through. I am not sure what other mailing lists you are subscribed to but cygwin uses exactly the same spam blocking procedures as any other mailing list on sources.redhat.com. This includes the gcc.gnu.org lists. We filter email through a number of open-relay services before it makes it to any of the sources.redhat.com mailing lists. Additionally, when I see spam, I immediately block the sender from future posts here and report the offender to their ISP, if possible. I'm often tempted to additionally block the accounts of people who *respond to the spam* here since I find the "Hey! This is SPAM! Somebody should do something!" messages more annoying than the SPAM itself. So far, I've resisted the urge. I can't completely explain why the cygwin mailing list gets more spam than, say, the gdb or gcc mailing lists. Possibly it is because the cygwin mailing list is mentioned on more sites which are harvested by spammers. This is the *first* that I've heard of disappearing messages. I have, personally, never had a message disappear. I assume that the assumption by the original poster when he "thought the first message didn't get through" would have been solved by exercising slightly more patience. sources.redhat.com does an absolutely amazing job at maintaining good response time with its mailing lists, owing to its use of qmail/ezmlm, but sometimes it can take a half an hour or more for email to show up. If you would like to track down the problem with email disappearing, send mail to [EMAIL PROTECTED], the next time that it happens with as much information about the message (time, date, subject, email address, etc.) as you can provide. I guess it is not obvious that we will track down problems with our mailing lists if people provide details that enable us to look into the problems. cgf -- Want to unsubscribe from this list? Send a message to [EMAIL PROTECTED]
Re: showstopper bugs (boring technical details -- run away! run away!)
On Mon, Nov 06, 2000 at 09:55:30AM -0500, Town, Brad wrote: Chris Faylor wrote: I've had a couple of show stopper bugs reported to me which, of course, I can't duplicate, so I've held off on the release until I can either duplicate and fix them or someone else can fix them (hah). Arrgh! There's that "hah" again! :) Would it be possible for you to briefly recap the show-stopper bugs? I'll help if I can. Wow. I've really stumbled onto something with the (hah). The showstopper bugs were (I'm using the past tense because I am such an incurable optimist) random errors from wait_subproc when logging in via ssh. Corinna reported them and since they were indicative of a serious problem in cygwin, I've been trying to track them down "in my spare time" (I'm supposed to be doing more managing and less programming). I duplicated the problems last night at around 9PM and checked in a fix at around 1AM. As I was triumphantly drifting off to sleep, I realized that some of my fix was questionable, so I have to redo it today. The problem was due to the way cygwin handles the 'exec' call. Since Windows has nothing that says "start a new process and give it the same pid", we have to kludge around this. So, when a program exec's, a stub sticks around waiting for an event from the newly "execed" process. When it gets the event, the stub opens the parent process with OpenProcess, duplicates a handle to the newly execed process into its parent, and then exits. The parent notices the exit, discovers that there is a new handle, for its child, does some bookkeeping and goes back to waiting for children to exit. The problem was that the process of contacting the parent was not 100% reliable. I don't know why this is now the case, but I worked around the problem by always passing a handle to the parent process to all of the children. This is something that I've wanted to do for a while anyway. In the process of fixing this bug, I stumbled across several other *#$! signal races which I worked around. Today, after a fresh night's sleep, I believe that I know how to fix them. Anyway, thanks for the offer. If you want to look at the code in question, it's in sigproc.cc (wait_subproc) and spawn.cc (spawn_guts). This is not for the faint of heart. I keep meaning to add more comments and document the whole sorry mess but I've never gotten around to it. By the way, I now need to do some laundry unless someone else gets around to it (hah). cgf -- Want to unsubscribe from this list? Send a message to [EMAIL PROTECTED]
Re: Error: couldn't make stderr distinct from stdout
On Tue, Nov 07, 2000 at 01:26:02PM -0500, Larry Hall (RFK Partners Inc) wrote: At 01:30 AM 11/7/2000, Georges, Chris wrote: I just upgraded my cygwin installation from 1.0 to the latest cygwin DLLs (cygwin-1.1.5-4) and now almost every utililty (ls,cat,etc) prints out "couldn't make stderr distinct from stdout" when it starts. tcsh prints the error and exits. I backed out to cygwin-1.1.4 and got the same problem. I am running all of these apps remotely in a telnet window connected a windows 2000 telnet server (the default one that comes with win2k) on a remote machine, this worked fine until I upgraded cygwin. The apps appear to run OK when run in a normal window on the local machine. A cygcheck -s -r -v may be helpful. My guess is you have a mixture of 1.0 and 1.1.x stuff that's causing you troubles, but that's purely a guess. The results of cygcheck should help you determine this. I don't know why 1.0 stuff and 1.1.x stuff would cause problems unless there are two cygwin DLLs on the system. If you can't run 1.0 binaries under 1.1.x then that's a very serious bug. cgf -- Want to unsubscribe from this list? Send a message to [EMAIL PROTECTED]
Re: Error: couldn't make stderr distinct from stdout
On Tue, Nov 07, 2000 at 12:23:10PM -0800, Georges, Chris wrote: From: Larry Hall (RFK Partners Inc) [mailto:[EMAIL PROTECTED]] Sent: Tuesday, November 07, 2000 10:26 AM To: Georges, Chris; '[EMAIL PROTECTED]' Subject: Re: Error: couldn't make stderr distinct from stdout At 01:30 AM 11/7/2000, Georges, Chris wrote: I just upgraded my cygwin installation from 1.0 to the latest cygwin DLLs (cygwin-1.1.5-4) and now almost every utililty (ls,cat,etc) prints out "couldn't make stderr distinct from stdout" when it starts. tcsh prints the error and exits. I backed out to cygwin-1.1.4 and got the same problem. I am running all of these apps remotely in a telnet window connected a windows 2000 telnet server (the default one that comes with win2k) on a remote machine, this worked fine until I upgraded cygwin. The apps appear to run OK when run in a normal window on the local machine. A cygcheck -s -r -v may be helpful. My guess is you have a mixture of 1.0 and 1.1.x stuff that's causing you troubles, but that's purely a guess. The results of cygcheck should help you determine this. I think the problem is in cygwin1.dll, which is printing out that message in stdio_init() in source file "winsup\cygwin\dtable.cc". It's calling DuplicateHandle() which apparently fails, and somehow the error causes everything to exit. I couldnt find a corresponding function in the source for cygwin 1.0. I backed out to the cygwin 1.0 version of cygwin1.dll and the message went away. The *fact* that an error is being printed is not indicative of an error in cygwin1.dll. The same code is in 1.0 and 1.1.x. Larry's suggestion of running 'cygcheck -s -r -v' was the best way to debug your problem. cgf -- Want to unsubscribe from this list? Send a message to [EMAIL PROTECTED]
Re: make and $(shell uname -a)
On Tue, Nov 07, 2000 at 11:48:57PM -0500, John A. Turner wrote: environment: o Win2kSP1 o cygwin 1.1.5(0.29/3/2) 2000-11-02 o MAKE_MODE unix the following makefile: SHELL = /usr/bin/bash foo = `/usr/bin/uname -a` bar = $(shell /usr/bin/uname -a) test: @echo "backticks work:" @echo $(foo) @echo "shell doesn't:" @echo $(bar) generates: backticks work: CYGWIN_NT-5.0 MIZU 1.1.5(0.29/3/2) 2000-11-02 02:01 i686 unknown shell doesn't: /usr/bin/bash: -c: line 1: syntax error near unexpected token `1.1.5(0' /usr/bin/bash: -c: line 1: `echo CYGWIN_NT-5.0 MIZU 1.1.5(0.29/3/2) 2000-11-02 02:01 i686 unknown' gmake: *** [test] Error 2 my question is, should $(shell) work? Do this: @echo "$(bar)" and it works fine. You're getting an error from bash indicating that it doesn't like the parentheses on the line with the echo. cgf -- Want to unsubscribe from this list? Send a message to [EMAIL PROTECTED]
Re: Stop Fries !
I've unsubscribing him now. cgf On Wed, Nov 08, 2000 at 01:56:27PM +0100, Schaible, Joerg wrote: From: "Schaible, Joerg" [EMAIL PROTECTED] To: cygwin-list [EMAIL PROTECTED] Subject: Stop Fries ! Date: Wed, 8 Nov 2000 13:56:27 +0100 Hi -Original Message- From: Fries [mailto:[EMAIL PROTECTED]] Sent: Wednesday, November 08, 2000 12:49 PM To: [EMAIL PROTECTED] Subject: Re: strange permissions: -- Hi! Please don´t send me such e-mails! Jürgen Fries, BDV GmbH can someone block this guy permanently from the list ? I receive the whole morning this annoying brain-dead messages. All mails I sent him to change his stupid little rule, were answered with the same stereotype answer. Mail rule configuration seems to be a too complicated task for him. Greetings, Jörg -- Want to unsubscribe from this list? Send a message to [EMAIL PROTECTED] -- Want to unsubscribe from this list? Send a message to [EMAIL PROTECTED]
Re: Bug report: gcc + cygwin
On Wed, Nov 08, 2000 at 05:33:28PM +0200, Medve Emilian-EMMEDVE1 wrote:
This is my program (it's also attached to this e-mail):
#includeio.h
#includestdio.h
#includestdlib.h
int main(void)
{
int n=0;
while(dup(1)!=-1)n++;
printf("Size of FILE0 table is: %d.\n",n+3);
exit(EXIT_SUCCESS);
}
Compilation command line: gcc -Wall -o dup dup.c
And this is the output:
d:\Profiles\emmedve1\LOCALS~1\Temp\dup.exe: *** couldn't commit memory for
cygwi
n heap, Win32 error 487
In other words, you tried to grow the fd table without bounds and
eventually cygwin ran out of memory. You can't find the size of the
file table this way. It's a terrible method for doing this. Cygwin's
file table doesn't have an upper limit.
Well, I guess 2^32 is probably an upper limit.
If I use -mno-cygwin everythig works as expected (fine).
Well then, problem solved.
cgf
--
Want to unsubscribe from this list?
Send a message to [EMAIL PROTECTED]
Re: Possible bug with select and master side of pty
It may be a real problem and I appreciate your attempts to track it down but since this seems to be working fine for the vast majority of things which use the pty, I don't think I'll be fixing it any time soon. If someone else would like to take a stab at this (hah?) that would be swell. cgf On Wed, Nov 08, 2000 at 05:46:06PM +0300, Andrej Borsenkow wrote: From: "Andrej Borsenkow" [EMAIL PROTECTED] To: "Cygwin Mailing List" [EMAIL PROTECTED] Subject: Possible bug with select and master side of pty Date: Wed, 8 Nov 2000 17:46:06 +0300 When polling master side of pseudo tty for reading, select is just using common function fhandler_pipe::select_read. This does not work when we do onlcr conversion (actually, always), read buffer of size 1 and are reading NL. In this case, first select returns readable descriptor (because there is real data in master-slave pipe) and first read returns CR. Second select does not think fd is readable because there is no more data in pipe; still, read from master side would return NL here. It _looks_ like adding fhandler_tty_master::select_read that is combination of fhandler_tty_common::select_read (when need_nl == 0) and fhandler_null::select_read (when need_nl != 0) should do the job. But I never programmed in C++ and do not trust myself to fully understand all these method interaction :( -- Want to unsubscribe from this list? Send a message to [EMAIL PROTECTED]
Re: Possible bug with select and master side of pty
On Wed, Nov 08, 2000 at 07:53:00PM +0300, Andrej Borsenkow wrote: It may be a real problem and I appreciate your attempts to track it down but since this seems to be working fine for the vast majority of things which use the pty, I don't think I'll be fixing it any time soon. If someone else would like to take a stab at this (hah?) that would be swell. I'm doing it just now. After spending an hour compiling distro I've found that I have to modify one header file that implies make clean because dependencies are not )re-)generated (I know they are supposed to). If you could do a favour to community and fix this tiny build problem ... :-) Perhaps if I had the slightest clue what you were talking about, I might. On the other hand, since this doesn't affect me, perhaps you might consider doing this, too, since it is such a tiny problem. Personally, I feel that I have already done the community a few favors and don't feel compelled to track this one done. cgf -- Want to unsubscribe from this list? Send a message to [EMAIL PROTECTED]
Re: Problem Executing Scripts
On Wed, Nov 08, 2000 at 04:50:18PM -0800, Jeffrey Gruen wrote: Recently, I downloaded Cygwin-b20 (cygwin-1.1.4.tar) for WindowsNT. Where did you get the impression that this was "Cygwin-b20"? This is Cygwin 1.1.4. It has nothing to do with B20. It has been working just fine until today when we tried to write some very simple scripts to run. Below is one such script that runs beautifully on a dec alpha UNIX machine, but will not run in Cygwin for NT: #this little script makes back-up of files in a directory for file in * do cp $file $file.bak done So far, we have discovered: 1. How to make the file executable in Cygwin (by adding .exe to the end, since "chmod" does not seem to work very well) 2. That the "*.exe" file must to be in the bin folder in order to run 3. That bash crashes if we make the first line of the script "#!/bin/sh" (We even tried running: "echo '#!/bin/sh' script.exe; ./script", but this did not work either). Please help. How can a make a script file that runs flawlessly in UNIX run in Cygwin, as well. The ability to write and execute small scripts like this would save me much time! As you have discovered, Windows does not have an 'execute bit', so you cannot just put some commands in a file, do a 'chmod -x file' and then './file'. Well, actually you can. If you are using an NTFS filesystem, then setting the CYGWIN environment variable to 'ntsec' (do this prior to running any cygwin program) will allow you to set the executable bit. The "NT security" model allows you to use full UNIX permissions on your files. It only works on NT, though. The usual way to make your scripts executable is by adding a '#!/bin/sh' to the beginning of them. Don't give the scripts a '.exe' extension. That will cause Windows to try to execute them as Windows executables rather than scripts. To execute the file, it has to be located in a directory referenced by your PATH environment variable. The current directory "." is not located in your PATH by default. You'll have to add it if you want to execute files in your current directory without typing "./file". One esoteric way to give a script or a directory executable permission is to use the mount command: mount -x -b c:\cygwin\bin /bin # cygwin gives everything in /bin # the 'executable' bit mount -x -b c:\cygwin\bin\foo /bin/foo # cygwin gives /bin/foo the # executable bit Most of the above should be located in the Cygwin FAQ. I would suggest that you read this and the other documentation available at www.cygwin.com so that you don't have to "figure out" stuff in the future. cgf -- Want to unsubscribe from this list? Send a message to [EMAIL PROTECTED]
Re: PATCH: (sort of) RE: Possible bug with select and master side of pty
On Wed, Nov 08, 2000 at 09:59:32PM +0300, Andrej Borsenkow wrote: It may be a real problem and I appreciate your attempts to track it down but since this seems to be working fine for the vast majority of things which use the pty, I don't think I'll be fixing it any time soon. If someone else would like to take a stab at this (hah?) that would be swell. Attached is the half-hearted patch against 1.1.5-4 (relative to winsup/cygwin). The problem happens when someone reads from master side of pty using 1 byte buffer and onlcr is enabled. In this case read gets CR and appears to hang after that before it gets NL. It looks, like it "hangs" at the end of line. The same problem seems to be with select after CR was read - it thinks, no input is available. Forgive me my horrible c++; I still do not quite understand all these inheritance isuues. But the patch appears to work. This patch looks pretty good and helped me enormously in understanding what was going on. After studying your patch and looking at the code a little, I decided to go another way. I just broke out the test in peek_pipe which was already checking for a pty master and added the need_nl test there. Your patch is more strictly correct since it properly uses C++ inheritance to handle this rather than use an if test but since the if test was already there, I decided to just go with that (actually, I rewrote it to be a switch statement). At some point, I'd like to use cygwin's typeahead handling for dealing with this and get rid of the need_nl stuff. At that point we would be back to using the same peek_pipe function, so I'd rather not disturb stuff too much right now. Could you test out the patch below and let me know if it works for you? This will be in tonight's snapshot and in the new cygwin 1.1.5-6 test release. Thanks again for taking the time to track this down and develop a patch. I really appreciate it. cgf -- Want to unsubscribe from this list? Send a message to [EMAIL PROTECTED]
Re: Bug report: gcc + cygwin
On Wed, Nov 08, 2000 at 09:05:40PM +0200, Medve Emilian-EMMEDVE1 wrote: Thanx for the prompt response. I have some questions regarding your answer. How CygWin manages the size of fd table since the same program compiled with -mno-cygwin says that my Windows allows a process to have only 256 files opened at a time? winsup/cygwin/dtable.cc contains the fd table handling code. As far as I know, Windows does not impose a handle limit on a process other than system resource limits. You said that I used a terible method to find out the size of fd table. Do you know a better method? Can you tell it to me? Well, cygwin really has no upper bounds so you'd have to choose something arbitrary. The normal way of doing this is to use sysconf (_SC_OPEN_MAX). This just returns the current size of the table in cygwin, though. The comments in this code (winsup/cygwin/sysconf.cc) suggest that the NOFILE or OPEN_MAX constants might be better. You could probably just use an arbitrary number like 512, or something, though. cgf -- Want to unsubscribe from this list? Send a message to [EMAIL PROTECTED]
Re: [ANNOUNCEMENT] cygwin-1.1.5-6, mingw-20001103-1, w32api-20001103-1, gcc-2.95-4
On Wed, Nov 08, 2000 at 10:13:33PM -0500, Charles Wilson wrote: Chris - you need make the latest/w32api and latest/mingw directories world readable --Chuck Yeah, someone sent me private email about this. I'll probably get another half dozen messages as I type this. cgf -- Want to unsubscribe from this list? Send a message to [EMAIL PROTECTED]
Re: Case-insensitive globbing (was RE: Cygnus question)
On Fri, Nov 03, 2000 at 05:24:50PM -0500, Town, Brad wrote: Thanks for the patch but this really needs to be under the control of a CYGWIN setting. We already have CYGWIN=glob. Maybe something like CYGWIN=glob:ignorecase would be appropriate. Here are patches to dcrt0.cc, environ.cc, and glob.c to do just that. Note that ignore_case_with_glob is an int, not a BOOL like it should be. I did that because I'm late getting home. For future reference, is the way I did it The Right Way? Sorry I didn't respond before this. A lot of this was right. The environ.cc and dcrt0.cc parts looked ok. The changes to glob.c were obvious but I'm not sure that they are correct. The problem is that the glob() function is exported from the DLL. I don't know if its operation should be under the control of the CYGWIN environment variable when it is called by the program directly. I don't think it should be actually. Maybe all that you need is clear the "ignore_case_with_glob" after dcrt0.cc has called glob. Then glob() would revert to its normal operation. I'd appreciate it if you would test that glob's operation when called from a program is unchanged, too. So, this was very close. If I had thought of and enunciated these issues before I'm sure it would have been perfect. Thanks, cgf -- Want to unsubscribe from this list? Send a message to [EMAIL PROTECTED]
Re: [ANNOUNCEMENT] Updated: OpenSSH-2.3.0p1
On Thu, Nov 09, 2000 at 02:46:24PM +0100, Corinna Vinschen wrote: Corinna Vinschen wrote: If you can't connect it would be very helpful if you could take a look into that. I will try to debug the `pwd' and `ls' problems. Good news so far. I could find the problem with `ps'. I can't solve it but I would be able to create a simple workaround in sftp-server. Do you mean 'pwd'? I haven't seen any problems with 'ps' in this thread. cgf -- Want to unsubscribe from this list? Send a message to [EMAIL PROTECTED]
Re: [ANNOUNCEMENT] cygwin-1.1.5-6, mingw-20001103-1, w32api-20001103-1, gcc-2.95-4
On Thu, Nov 09, 2000 at 12:10:04PM -0500, Charles S. Wilson wrote: I seem to remember this being report earlier, but I couldn't find it -- besides, it was related to an older 1.1.5-x. I had hoped this error had been fixed, but apparently not since I just saw it again with cygwin-1.1.5-6: Sometimes when starting a cygwin app from within bash, the bash prompt will return immediately but ps shows that the app (say, vim) is still running in the 'S' state. However, it's not in the background -- there does not seem to be anyway to 'foreground' that application. All I can do is kill it, and try again. This happens *very* infrequently, so it's extremely hard to track down -- in fact, it had been so long since I had seen the error, and mindful that I think it had already been reported, I assumed it had been fixed. But it hasn't. I can't duplicate this. It will be in the release version. Have fun. cgf -- Want to unsubscribe from this list? Send a message to [EMAIL PROTECTED]
Re: cygwin proplem with *.exe
On Thu, Nov 09, 2000 at 03:42:06PM +0100, Anatol Studler wrote: I am still playing with the *.exe endings of the files, and I don't have a clue whats going on. For example I have two executables in the same directory. (/cygdrive/c/WINNT/system32) The one which is called "notepad.exe" works with calling "notepad" or "notepad.exe" the other one "ipconfig.exe" only works with calling "ipconfig" but not with "ipconfig.exe". [CYGSERV] ~ ipconfig.exe ipconfig.exe: Command not found. Does anybody have an idea what's going on? God no. cgf -- Want to unsubscribe from this list? Send a message to [EMAIL PROTECTED]
Re: potential cygwish80 problem
On Thu, Nov 09, 2000 at 08:52:44AM -0600, Karl North wrote: So the problem appears to be that cygwish80 cannot seem to interpret a full (absolute) pathname when it is passed as the first parameter. This is the way that the pathname is passed by the "exec" line in my script(s). tcl/tk does not have full understanding of Cygwin paths. cgf -- Want to unsubscribe from this list? Send a message to [EMAIL PROTECTED]
Re: Can not found crt1.o when using -mno-cygwin option
On Thu, Nov 09, 2000 at 03:15:11PM +0800, Topas wrote: After install cygwin-1.1.5-6, mingw-20001103-1, w32api-20001103-1, = gcc-2.95.2-4 When compiling a program with -mno-cygwin option,=20 gcc t1.c -mno-cygwin /usr/bin/ld: cannot open crt1.o: No such file or directory collect2: ld returned 1 exit status Is there's any thing I forget to setup? I screwed up the mingw case. Can't believe that I forgot to test this. Adding a -B/usr/lib/mingw to your command line will probably help. You may need a -I/usr/include/w32api, too. And, Can I suggest to do something in setup.ini that cygwin-1.1.5-6, mingw-20001103-1, w32api-20001103-1, gcc-2.95.2-4 will be installed, when the test version is selected. And, cygwin-1.1.4, gcc-2.95-3 will be installed for the current version. No one can stop you from suggesting. There is no reason to do any of the above but you can certainly suggest that "someone" should do this. cgf -- Want to unsubscribe from this list? Send a message to [EMAIL PROTECTED]
Re: Case-insensitive globbing (was RE: Cygnus question)
On Thu, Nov 09, 2000 at 11:09:16AM -0500, Town, Brad wrote: The problem is that the glob() function is exported from the DLL. I don't know if its operation should be under the control of the CYGWIN environment variable when it is called by the program directly. I don't think it should be actually. I agree. I've made the change and attached new patches. I'd appreciate it if you would test that glob's operation when called from a program is unchanged, too. Source to the program I used to test is attached. So, for those of you just joining us, adding "glob" to the CYGWIN environment variable enables case-sensitive globbing for arguments passed on the command line when the program is called from a Windows shell. With the patches, "glob:ignorecase" would make the globbing case-insensitive. Looks good with a couple of minor issues (sorry). The changes to reset the globbing case sensitivity should go right before the call to main in dcrt0.cc. In 1.1.5 the code which breaks apart argv is not called for cygwin subprocesses so resetting ignore_case_glob in build_argv is not a good idea. So, if you could make that change and supply a ChangeLog entry for your masterpiece, I'll incorporate it. Also please include a statement telling me that this is your work and that your employer has no claim to it. Also, my preferences is to see diffs in '-u -p' format. The '-p', in particular, helps me understand what's going on a little more quickly. I appreciate your efforts in doing this. I think that this option will make a lot of people happy. cgf -- Want to unsubscribe from this list? Send a message to [EMAIL PROTECTED]
Re: Process limit
On Fri, Nov 10, 2000 at 06:33:24PM -, Allan Clearwaters wrote: Is there any way to increase the process limit under Cygwin? What is it set to curretly? 1.1.5 has no process limit. It will be available soon. I believe that 1.1.4 has a 128 process limit and there is no way to increase this without recompiling cygwin. cgf -- Want to unsubscribe from this list? Send a message to [EMAIL PROTECTED]
Re: Case-insensitive globbing (was RE: Cygnus question)
Bingo. Thanks, Brad. Much appreciated. cgf On Fri, Nov 10, 2000 at 02:13:58PM -0500, Town, Brad wrote: Okay, let's try this again. :) Attached are patches making yet another attempt to provide case-insensitive yada yada yada. Legal stuff: --- cut here --- All of the work I perform for the Cygwin project is mine. My employer has no claim to it. I hereby assign copyright for the work to Red Hat. --- cut here --- Is that enough? Brad Town -- Want to unsubscribe from this list? Send a message to [EMAIL PROTECTED]
Re: openSSH primer for Cygwin
On Fri, Nov 10, 2000 at 11:55:09AM -0800, Mike Ayers wrote: I've read the README for ssh and got it to work with NT password authentication, but not with the RSA authentication. Before I pester the list, is there perchance an existing FAQ for this? Have you looked at http://www.openssh.com/ ? I honestly don't know if there is anything there that would help you but I suspect that this would be a logical first place to look. cgf -- Want to unsubscribe from this list? Send a message to [EMAIL PROTECTED]
Re: Process limit
On Sat, Nov 11, 2000 at 03:38:43PM -, Allan Clearwaters wrote: I know you don't want to commit but how soon is "...soon" - days, weeks? The reason for my question relates to some work I'm doing where I suspect the process limit under the current version of 1.1 is getting in my way. In any case, if there were no process limit then it would allow me a bit more freedom. You're right that I steadfastly refuse to give release dates, especially when prodded. It sets a dangerous precedent. Look back over the cygwin mailing list in the last few weeks and draw your own conclusions. While we're on the subject, are there any good reference sites about the Windows process/task api either in general or under Cygwin? The process/task api in cygwin is the same as UNIX. What would you expect? Windows APIs are documented on the Microsoft site. cgf -- Want to unsubscribe from this list? Send a message to [EMAIL PROTECTED]
[ANNOUNCEMENT] Re: Updated: Cygwin 1.1.5-7, mingw-20001103-, w32api-20001111-1
On Sat, Nov 11, 2000 at 09:20:12PM -0500, Christopher Faylor wrote: I've updated the version of the cygwin DLL in cygwin/latest to 1.1.4. Apologies for the extra email but, in case it wasn't obvious, the above sentence should have read: "I've updated the version of the cygwin DLL in cygwin/latest to 1.1.4." I'm sorry if this typo generated any confusion. cgf -- Want to unsubscribe from this list? Send a message to [EMAIL PROTECTED]
[ANNOUNCEMENT] Re: Updated: Cygwin 1.1.5-7... grrrrrrrrrrrrr...
On Sat, Nov 11, 2000 at 10:13:55PM -0500, Christopher Faylor wrote: On Sat, Nov 11, 2000 at 09:20:12PM -0500, Christopher Faylor wrote: I've updated the version of the cygwin DLL in cygwin/latest to 1.1.4. Apologies for the extra email but, in case it wasn't obvious, the above sentence should have read: "I've updated the version of the cygwin DLL in cygwin/latest to 1.1.4." I'm sorry if this typo generated any confusion. I really really am brain dead today: "I've updated the version of the cygwin DLL in cygwin/latest to 1.1.5." I'm not sure how I managed to toggle a 4 to a 5 and back again. Sigh. cgf -- Want to unsubscribe from this list? Send a message to [EMAIL PROTECTED]
Re: long double support in cygwin
On Sun, Nov 12, 2000 at 09:28:14AM -0500, Stephen L Moshier wrote: Why aren't you using any of these six or seven codes that various people have indeed implemented? What is the policy? We can't use glibc based code. There are licensing considerations which prevent us from taking code from LGPLed sources Fascinating. Well, the code I could supply that is not glibc was formally placed in the public domain so that the FSF could adopt it and install it into gcc. The gcc changes are owned by FSF but I would guess what was in the public domain is still in the public domain. Does that sound like something that would satisfy the legal requirement? If the code has been assigned to the FSF and is now owned by the FSF, we can't use it. IANAL. That is undoubtedly why no one suggested folding his changes back into newlib. I wonder if Bowman, the author of inline-math, knew that the LGPL would *prevent* people from using his code! It should be up to him to decide whether you have permission. Red Hat has special licensing considerations which I mentioned in the URL that I provided. The LGPL still requires that source code be distributed if you are *providing the library* does it not? If I try to sell you a copy of glibc, I will have to provide you with the sources. If I sell you a copy of a program linked with glibc, I don't have to give you the sources for glibc. It's a subtle distinction, but this is why we can't use it. We occasionally sell copies of the cygwin license for proprietary use. You can scream or be offended by this fact but it is a fact of life. That means that we have to own what goes into newlib/cygwin or the licenses of the source has to allow distribution of binaries without source code so that cygwin1.dll is encumbered. IMO, the LGPL does not allow this. IANAL. At any rate, cygwin is about six years old now. This issue has been endlessly hashed and rehashed, as you may imagine. As to whether the author of the code can reassign the code for use in cygwin, that is another issue. I don't know if John's statement (quoted from another message) is adequate or not: In any case, I hereby give my permission to Christopher Faylor [EMAIL PROTECTED] to make unrestricted use of the source code found at ftp://sunsite.unc.edu/pub/Linux/libs/inline-math-2.7.tar.gz, provided that he respects my right to distribute this code freely to the programming community. IANAL. And, more importantly, I don't control what goes into newlib. So, assigning the rights to me will not be useful. I again suggest that you take this discussion to the newlib mailing list. cgf -- Want to unsubscribe from this list? Send a message to [EMAIL PROTECTED]
Re: serial programming HOWTO
On Sun, Nov 12, 2000 at 11:37:19PM +0100, Frank Wagner wrote: Hello and thanks for the reply, From the linux man page: "The sa_restorer element is obsolete and should not be used." It's also not mentioned in the Single UNIX Specification. Means this that I can comment out that line with the sa_restorer statement? I assume so, yes. After that I tried to compile that example under Linux and got the follwing error message program.c: 39 incompatible types in assignment --dir=. that refers to the folloing line of the source: saio.sa_mask = 0; Why do I get a error message form an example that is written for linux? Because cygwin is not linux? The above use of saio.sa_mask is incorrect. You should be using sigemptyset() to clear the mask. This will also work on linux. But the serial programming HOWTO is witten for linux. Did the author make a mistake in this case? The author apparently used a nonportable construct. cgf -- Want to unsubscribe from this list? Send a message to [EMAIL PROTECTED]
Re: XEmacs on cygwin wierdness
On Mon, Nov 13, 2000 at 12:07:21AM -0500, Charles S. Wilson wrote: I've tried to build XEmacs-21.2.36 multiple times tonight. Each time, it works perfectly as long as I launch it from with a cygwin-bash window. However, if I launch it from the DOS cmd prompt, it stackdumps. Why aren't you running it under gdb to pinpoint where the error is occurring? cgf -- Want to unsubscribe from this list? Send a message to [EMAIL PROTECTED]
Re: XEmacs on cygwin wierdness
On Mon, Nov 13, 2000 at 12:56:12AM -0500, Charles S. Wilson wrote: Christopher Faylor wrote: On Mon, Nov 13, 2000 at 12:07:21AM -0500, Charles S. Wilson wrote: I've tried to build XEmacs-21.2.36 multiple times tonight. Each time, it works perfectly as long as I launch it from with a cygwin-bash window. However, if I launch it from the DOS cmd prompt, it stackdumps. Why aren't you running it under gdb to pinpoint where the error is occurring? I got a popup saying "Program received signal SIGSEGV, Segmentation fault" Stack window shows "_size_of_stack_reserve__" That is the symbol that gdb seems to use when it can't find anything else to use. What address is associated with this? Is this the only thing in the stack window? There aren't any other addresses being displayed? How about the .stackdump file? unfortunately, I can't get further than that -- I think it's because of the odd structure of an xemacs executable -- in-built lisp data + interpreter, this wierd "dumping" process it does to itself when building, etc... Now, maybe I'm blowing bull patties, but I can't even get the source window to show anything but assembler -- because "xemacs.exe" is a dumped executable generated by "temacs.exe" which loads a bunch of lisp code and data and then "dumps" an image of itself to disk during the build. So, gdb shows *me* nothing -- which is why I asked if anyone could make a *guess* as to why a program will run fine under a bash shell, but stackdump when run from a DOS box (or within gdb). Try using gdb -nw. cgf -- Want to unsubscribe from this list? Send a message to [EMAIL PROTECTED]
