RE: Another rvxt vs. minTTY 0.3.4
> From: Andy Koppe > > Paul McFerrin wrote: > > I have another difference between 0.3.4 and 0.3.3 of minTTY > and rxvt. > > > > If you have a long-running script running, any attemps to > stop it with > > either Control-C or Control-\ does nothing. > > It's working here. Just tried it with a 'configure' script. > Yeah, it worked all day for me today as well. Heavy duty makes, mix of Cygwin and native programs being invoked, plenty of CTRL-C's, never had one not get recognized. -- Gary R. Van Sickle -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: MinTTY 0.3.3
> From: Christopher Faylor > > On Sat, Jan 10, 2009 at 09:00:06PM -0600, Gary R. Van Sickle wrote: > >> From: Christopher Faylor > >> > >> On Sat, Jan 10, 2009 at 04:10:53PM -0700, Andrew DeFaria wrote: > >> >Out of here... > >> > >> If only that was really true. > > > >I thought there was a specific mailing list where such > >Cygwin-related-content-free urinating contests were more > appropriately > >held. I must have been misled. > > I think your confusion is pretty well documented by now. > > I can only speculate on your lack of embarrassment about the > frequent public displays of confusion however. > > cgf > Should you wish to continue the aforementioned contest and/or send more silly passive-aggressive insults my way, please do so on the cygwin-talk@ list. For your convenience, and for the benefit of the readers of the cygwin@ list, I have set followups accordingly. Thank you for your cooperation in keeping the cygwin@ list a place where Cygwin-related issues can be discussed with a minimum of topic-free distractions. -- Gary R. Van Sickle -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: MinTTY 0.3.3
> From: Christopher Faylor > > On Sat, Jan 10, 2009 at 04:10:53PM -0700, Andrew DeFaria wrote: > >Out of here... > > If only that was really true. > > cgf I thought there was a specific mailing list where such Cygwin-related-content-free urinating contests were more appropriately held. I must have been misled. -- Gary R. Van Sickle -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: xterm and cut & paste
> From: Andy Koppe > > Brian Salter-Duke wrote: > > On Fri, 02 Jan 2009 06:56:23 +, Fergus > >> Include -clipboard as an option for XWin. > >> e.g. > >>run XWin -clipboard -nolisten local -multiwindow 2>nul > & and then > >> selected text in xterm is automatically copied to the > clipboard for > >> onward pasting. > >> Fergus > > > > Thanks for that. I find X very confusing and mainly just > want a simple > > xterm to run mutt, slrn and unix like-codes. > > Fancy giving MinTTY a try? It is (or at least attempts to be) > compatible with xterm, but it's a native Win32 program, i.e. > X is not required. > > http://code.google.com/p/mintty > > Andy And best of all, it's MinTTY fresh, not MedicineTTY. ME = STILL GOT IT. ;-) PS: File drag and drop is total coolness. It pastes in a Win32 path though, which a few Cygwin apps probably won't be able to handle. Here's a two-for-one idea, free of charge: - Add a setting where the user can set whether he wants Win32 or POSIXy paths dropped. - Add a context menu when you right-drop which allows you to "Drop path as Win32" or "Drop path as POSIX". -- Gary R. Van Sickle -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: MinTTY
> From: Gary R. Van Sickle > > Hey Andy, > > After a thorough 2-minute evaluation, I can give you the > following feedback: > > 1. Good work. > 2. Super fast. > 3. Cut and paste in a Unixoid terminal for Cygwin finally > conforms to Windows norms (AKA "The One True Way"). That > alone is worth it. > 4. I wasn't getting color from ls, but that appears to be a > termcap/terminfo/wrong-bash-invocation issue, as your > screenshots clearly show color support. > 5. It needs a regular Windows installer. > 5a. I'm good with Windows installers. You want I should whip > one up for you? > > This will likely become my default terminal unless a more > thorough evaluation turns up some showstopper. Excellent work! Ok, more feedback after some more extensive use: - Yeah, the no color thing was solved by putting the standard "bash --login -i" on the shortcut's command line. That would be a nice one to have in the configuration dialogs, but I don't see how you avoid the registry in that case. Maybe just going with "bash --login -i" as the default if you don't tell it otherwise would be a 90% solution. I don't recall what Setup.exe's Shortcut capabilities are, but if it's capable enough, the setup package could tack that on the end when it generates a shortcut for it. - The ability to configure it via dialogs, especially such 21st century things as fg/bg/cursor colors and the font and point size to use, is most excellent and most welcome. - From the web page: "Mousewheel events can be sent as arrow keys. (This allows mousewheel scrolling e.g. in less.)" All I get is dings, and I don't see any documentation as to how to set this up. - OMG FULL-SCREEN MODE! Where we're going, we don't need roads! Dude, if you tell me that it uses DirectX and a multi-hundred-dollar video card to throw up a full-screen 80x24 text interface I will laugh for a week ;-)! - I don't know if this is good, bad, ugly, or indifferent, but: Urxvt: $ set | grep TERM COLORTERM=rxvt-xpm TERM=rxvt-unicode Native Windows console: $ set | grep TERM TERM=cygwin MinTTY: $ set | grep TERM TERM=xterm Suggestions: - It should default to "Show scrollbar" being on. For a while there I thought I didn't have a scrollback buffer. - The default Lucida 9-point seems rather too small to me. Now, my eyes are no spring chickens anymore, but even so, I think 12 point would be a better default. - When you open the Options dialog, it takes two clicks to select one of the option catagories in the tree pane on the left, as if the first is getting ignored for some reason. - It doesn't handle resizing correctly. I.e., with my urxvt-X.exe+Xwin setup, if I do "echo $PATH" (which goes way over 80 chars) and then I resize the window, the previously-printed path gets re-layed-out to fill the entire client area. With MinTTY, that doesn't happen. No relayout happens on either increasing or decreasing the window width (and hence the number of columns). Subsequently printed output does however take the new number of columns into account. To me, this is the most significant issue I've seen so far. - I don't see a config option to set the number of lines of scrollback buffer. Whatever it is defaulting to seems like plenty, but it would be nice to have that in the config dialogs. Verdict: I think everyone would win if this replaced the default Cygwin console-based terminal, even as-is. Just the reasonable copy/paste behavior and the ability to resize the window by sensical means close the deal in my book. Again Andy, good work. -- Gary R. Van Sickle -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: MinTTY
> From: Warren Young > > Christopher Faylor wrote: > > > > I think the only reason to use cygwin.bat is to set the cygwin > > environment variable before bash starts. There's no way to do that > > with a shortcut is there? > > In this case, it could be one of MinTTY's settings, because > it can set up the environment before calling bash. > Yes, but there's the complication of "CYGWIN=" settings that have to be set before the Cygwin DLL even loads. I don't know how many of these 1.7 will obsolete, but it's something that probably requires some cogitation before implementing. > For that matter, MinTTY could also provide GUI access to bash > command line flags, a way to change the login shell by > modifying /etc/passwd, etc. It could be glorious! Well, or overachieving ;-). For me it'd just be great to have a nice terminal that didn't require an X server and had Windows native-y configuration and copy/paste. We'll get to that 21st century yet! -- Gary R. Van Sickle -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: MinTTY
Hi Barry, > From: Buchbinder, Barry (NIH/NIAID) [E] > > Gary R. Van Sickle wrote on Tuesday, December 30, 2008 8:26 AM: > > 5. It needs a regular Windows installer. > > 5a. I'm good with Windows installers. You want I should > whip one up > > for you? > > Just curious: Why does this need "a regular Windows > installer"? On further attention-paying I guess it doesn't. I was thinking this wasn't a Cygwin-DLL-linked program, but it is. > Why not make this a cygwin package? (I suppose > this goes for PuTTYcyg et al.) > Looks like that's well underway. > - Barry -- Gary R. Van Sickle -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: MinTTY
Hey Andy, After a thorough 2-minute evaluation, I can give you the following feedback: 1. Good work. 2. Super fast. 3. Cut and paste in a Unixoid terminal for Cygwin finally conforms to Windows norms (AKA "The One True Way"). That alone is worth it. 4. I wasn't getting color from ls, but that appears to be a termcap/terminfo/wrong-bash-invocation issue, as your screenshots clearly show color support. 5. It needs a regular Windows installer. 5a. I'm good with Windows installers. You want I should whip one up for you? This will likely become my default terminal unless a more thorough evaluation turns up some showstopper. Excellent work! -- Gary R. Van Sickle > From: Gary R. Van Sickle > > Hmm, looks very interesting, I'll give it a try and report > back to the class. I've been looking for a replacement for > my preferred terminal emulator, MedicineTTY, for quite some time. ;-) > > -- > Gary R. Van Sickle > > > > From: Andy Koppe > > > > Hi, > > > > I'd like to introduce "MinTTY", a terminal emulator for > > Cygwin that I've been working on for a while. It is based on > > the terminal emulation and Windows frontend parts of PuTTY > > 0.60 by Simon Tatham and his team. > > > > Unlike PuTTYcyg, MinTTY discards PuTTY's networking > > functions, which are already convered by Cygwin's ssh and > > telnet packages. This results in simpler configuration, a > > leaner interface and small code size. MinTTY's most obvious > > difference to rxvt is its native Windows interface and > > configuration dialog. > > > > More info, as well as the latest sources and binary can be > > found on the project page: > > > >http://code.google.com/p/mintty > > > > The MinTTY discussion group can be found at: > > > >http://groups.google.com/group/mintty-discuss > > > > I hope you'll give MinTTY a try, and I'm looking forward to > > feedback and questions. Bug reports and feature requests can > > be sent via the issue tracker on the project page. > > > > Regards, > > Andy > > -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: MinTTY
Hmm, looks very interesting, I'll give it a try and report back to the class. I've been looking for a replacement for my preferred terminal emulator, MedicineTTY, for quite some time. ;-) -- Gary R. Van Sickle > From: Andy Koppe > > Hi, > > I'd like to introduce "MinTTY", a terminal emulator for > Cygwin that I've been working on for a while. It is based on > the terminal emulation and Windows frontend parts of PuTTY > 0.60 by Simon Tatham and his team. > > Unlike PuTTYcyg, MinTTY discards PuTTY's networking > functions, which are already convered by Cygwin's ssh and > telnet packages. This results in simpler configuration, a > leaner interface and small code size. MinTTY's most obvious > difference to rxvt is its native Windows interface and > configuration dialog. > > More info, as well as the latest sources and binary can be > found on the project page: > >http://code.google.com/p/mintty > > The MinTTY discussion group can be found at: > >http://groups.google.com/group/mintty-discuss > > I hope you'll give MinTTY a try, and I'm looking forward to > feedback and questions. Bug reports and feature requests can > be sent via the issue tracker on the project page. > > Regards, > Andy > -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: Rationale for line-ending recommendation?
> From: Spiro Trikaliotis > > Hello Gary, > Hey Spiro, > * On Fri, Dec 19, 2008 at 03:42:34AM -0600 Gary R. Van Sickle wrote: > > > From: Spiro Trikaliotis > [...] > > > Oh, and Subversion is problematic, too. Because the SVN > developers > > > decided to handle line endings on their own using libapr, opening > > > files in binary mode and reading and writing CR, LF or CR/LF on > > > their own, > > > > This is the right way to do things... > > I hope you are ironic here, right? > I wish I were. At the C runtime level, you have two options when writing code which deals with files, text and/or otherwise: 1. Ignore the problem and hope that all C runtimes with which your app may be linked are able to correctly guess the intent of your fopen() and correcty adjust the behavior of all the other f*() functions accordingly. 2. Open all files as "binary" at the C runtime level. If you're reading "plain text" files, treat '\n', '\r\n', and '\r' explicitly and equally. If you're writing "plain text" files, use the line ending convention of the platform you're running on. If you're not dealing with "plain text" files, limit your interactions with the opened FILE to fread(), fwrite(), and the seeks (fseek()/fgetpos()/fsetpos()/rewind()). #1 doesn't work real well, as evidenced by the fact that the calendar says "21st Century" and we're still expending a considerable amount of effort debating how many line ending characters can dance of the head of a pin. That leaves us with #2 as the correct solution. > > > on Cygwin, SVN is hard-coded to > > > *nix line endings. This is not nice. Note that this approach will > > > also fail badly if you mount parts of your system in > textmode, and > > > parts in binmode. > > > > > > Because of this, I am using an SVN version which I > compiled myself > > > with a patched libapr. > > > > > > > ...I'm not following this. Are you talking about the SVN > repository, > > or the clients, or...? What's the issue? > > You are right, I was not specific enough. I never tested an > SVN server on Cygwin, thus, I can only talk about the client side. > > If you check out some files which are set to CRLF=native, > Cygwin's SVN checks them out with LF line ending (as SVN > handles the endings on its own, and libapr tells it that > Cygwin == Unixoid == LF). > Hmm, yeah that sounds wrong. Can you force it to CRLF? BTW, the CVS issue was way worse IIRC, you had to have the repository on a "binary" mount, or it started on fire. Yeah, not cool. > Now, if you edit a file of this using some tool that 1. does > not have problems with the LF endings, but 2. generates CR/LF > endings on new lines (like, for example, MSVC does, but also > some other tools) > Right, many if not most native Windows text editors are going to do this (at least by default), which is of course the correct thing to do. > then SVN cannot check in that file. It complains that the > file has "mixed line endings". Yes, that's right, but why > does SVN care? > I'm... Hmmm, I use svn quite a bit and I've never actually run into that. That sounds more like a design defect of svn that anything else, because yeah, it shouldn't care. > Even commands like "svn diff" behave erratically. > > You have to use d2u in order to get this file checked in. > This is really annoying. > Welcome to the 21st Century. If you believe your calendar. Which of course you should not. ;-) > Note: In my opinion, this is clearly an SVN/libapr problem, > not a Cygwin problem. > Well, it's a basic field-wide problem that should have been solved long ago. Cygwin goes to herculean efforts to ameliorate the issue, and is amazingly successful at it, but there are fundamental limits as to what it can do to make broken programs not be broken. In the end, it's a rare problem indeed which can be fixed by not fixing the problem. > > I know CVS had some problems with the > > dreaded \n/\r\n issue back in the day, but I wasn't aware > of similar > > Subversion issues. > > The CVS issue was a mere cosmetical one, while the SVN one is > a real show-stopper, IMHO. > No, quite the reverse, see above (though we may be talking about two different problems resulting from this NP-Hard "line ending" problem). > > > Other than that, I never had any problems with the CR/LF > line endings. > > > > Bash has some known problems in this area, but there's a > > Cygwin-specific fix (that un
RE: printf goes to serial port?
> From: Alex Martin > Gary R. Van Sickle wrote: > >> From: Alex Martin > >> > >> Well, I was using a port monitor to debug some of the > traffic between > >> my serial device, and my software, when I noticed the output > >> accidentally. > >> > >> I am not sure when the behavior started. It used to work > fine, I was > >> using printf to debug things, then I turned off all of > those printf > >> statements, and continued development on the gui side (fox > toolkit) > >> of my application, and then had to go in and modify my low level > >> serial class and was trying to get my printf debug output > again, to > >> no avail. > >> > >> I have updated cygwin a few times, otherwise I cannot think of > >> anything specific. > >> > >> What other details can I provide? > >> > > > > Well, whatever details you have. I'm still in "pull mode" > here, which > > isn't conducive to problem-solving. So far I've been able > to gather: > > > > 1. You are developing some sort of app that communicates over a > > serial port to some other device. > > 2. You "have a cygwin environment". > > 3. The app has a GUI, using something called "fox toolkit" (with > > which I am not familiar). > > 4. You had debug printf()s that used to work, then a bunch > of stuff > > changed, and now they work differently. > > > > A few gaps that need filling before anything better than SWAGs can > > come your > > way: > > - Is this app a Cygwin app, > > No, it is a windows app. > > I am using cygwin primarily because I get the /dev/ttyS* > devices. ...ok, so it's a Cygwin app. You won't have /dev/anything otherwise. > I could not find info on how to talk to a serial > port in the windows world without using "MFC" which I refuse to touch. > I... Um, you can most certainly talk to serial ports under Windows without using MFC (is MFC even still around? I thought it was all ".NET" this and "ATL" that nowadays. I must not be getting as old as I thought I was). Search MSDN for... Well, here: http://msdn.microsoft.com/en-us/library/ms810467.aspx > or is Cygwin involved only perhiperally (e.g. > > you're using Cygwin make to run the MinGW toolchain), > > No mingw. Using all of cygwin's make, g++, etc. > Ok, again, that's a Cygwin app. You're linking with the Cygwin DLL. > or is Cygwin not > > directly involved at all and you're saying "My > non-Cygwin-related app > > was working fine, I changed a bunch of stuff in the app and also > > upgraded Cygwin, and now the app is broke and I'm thinking > Cygwin could be to blame"? > > I do not think the app is broken. I never do either, until I find out where I broke it. ;-) > Somehow stdout is going to > the serial port, my code relating to file descriptors (a > serialio class that provides functions like open, close, > read, write, flush), opening and closing the devices, etc has > never changed (that is, the code is the same code since back > when printf worked). Other code has changed, that is, the gui > layout, function flow, etc. > > > - Since your app is a GUI app, where did you expect your > printf()s to go? > > Well, someone taught me to use cygwin in this manner, and I > have been doing so for a long time, that is, I can use a > cygwin window to invoke my windows app, and the cygwin > console would catch printfs (stdout chatter), so you can use > it as a debug console. Hmm, well, maybe you have uncovered a Cygwin bug, or a deliberate change in Cygwin behavior. Next step: Which Cygwin DLL version behaved as above, and which version now is sending that info to the serial port? Make sure to use the same app (which you have assured me is not broken ;-)) when you test this; rule #1 is to change only one thing at a time so you can rule it out without the confounding factors of other things changing on you. -- Gary R. Van Sickle -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: printf goes to serial port?
> From: Alex Martin > > Well, I was using a port monitor to debug some of the traffic > between my serial device, and my software, when I noticed the > output accidentally. > > I am not sure when the behavior started. It used to work > fine, I was using printf to debug things, then I turned off > all of those printf statements, and continued development on > the gui side (fox toolkit) of my application, and then had to > go in and modify my low level serial class and was trying to > get my printf debug output again, to no avail. > > I have updated cygwin a few times, otherwise I cannot think > of anything specific. > > What other details can I provide? > Well, whatever details you have. I'm still in "pull mode" here, which isn't conducive to problem-solving. So far I've been able to gather: 1. You are developing some sort of app that communicates over a serial port to some other device. 2. You "have a cygwin environment". 3. The app has a GUI, using something called "fox toolkit" (with which I am not familiar). 4. You had debug printf()s that used to work, then a bunch of stuff changed, and now they work differently. A few gaps that need filling before anything better than SWAGs can come your way: - Is this app a Cygwin app, or is Cygwin involved only perhiperally (e.g. you're using Cygwin make to run the MinGW toolchain), or is Cygwin not directly involved at all and you're saying "My non-Cygwin-related app was working fine, I changed a bunch of stuff in the app and also upgraded Cygwin, and now the app is broke and I'm thinking Cygwin could be to blame"? - Since your app is a GUI app, where did you expect your printf()s to go? > Alex Martin > -- Gary R. Van Sickle > Gary R. Van Sickle wrote: > >> From: Alex Martin > >> > >> Hello, > >> > >> I have a cygwin environment, running some software I am writing to > >> talk to some serial devices. > >> > >> Somehow, trying to debug why I could not see printf output to > >> console, I ran a serial port sniffer and voila all of my printf > >> commands are writing on the serial port. > >> > > > > I can't say that it would cross my mind to look for my > missing printf > > output on a serial port, even if I was using a serial port in other > > parts of the program to talk to something. Whatever it was > that gave > > you the hunch to do that is probably at the core of your problem. > > > >> Any idea how to fix this? > >> > > > > Well, no, not really, since you've given very few details > to go on. > > I'd SWAG that you've somewhere, somehow, redirected stdout to the > > serial port you're trying to talk to those devices on. > > > >> Thanks, > >> Alex Martin > >> > > > > -- > Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple > Problem reports: http://cygwin.com/problems.html > Documentation: http://cygwin.com/docs.html > FAQ: http://cygwin.com/faq/ > -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: Rationale for line-ending recommendation?
[Followups set to -talk due to apropos but not-necessarily-Cygwin-specific devolution of the discussion] > From: Corinna Vinschen > > On Dec 19 10:29, Gary R. Van Sickle wrote: > > > From: Andrew DeFaria > > > > > > Mark J. Reed wrote: > > > > On Fri, Dec 19, 2008 at 4:42 AM, Gary R. Van Sickle wrote: > > > >> Me too, and like you and the OP report, it "just works" > > > 99.44% of the > > > >> time. Of course, since it's not the 21st century yet, many > > > >> Unixoid programs are still unable to handle text files > properly, > > > >> hence the remaining 0.66%. > > > > 100 - 99.44 = 0.66? You're right - it's clearly not the > > > 21st century > > > > yet, since you seem to be using one of the original > > > > floating-point-bugged Pentium chips. ;-) > > > Touche! Loved it! > > > > > > BTW, it's the 21st century over here. Please try to catch up... > > > > Another one who believes what their calendar tells them? > Then riddle > > me this Andrew: If this were in fact the 21st century (AKA "The > > Future"), why would we be be discussing software which is able to > > understand one text file format, but not a second > ever-so-slightly different text file format? > > Yeah, right, if this were in fact the 21st century, why would > we ever have to deal with a 30 year old, > idiotic-from-the-start text file format using two line ending chars? > > > Corinna > A-MEN sister! But how do you propose we get all these programs to understand UTF-32 when we can't even get them to handle an extra '\r' without starting on fire? ;-) -- Gary R. Van Sickle -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: printf goes to serial port?
> From: Alex Martin > > Hello, > > I have a cygwin environment, running some software I am > writing to talk to some serial devices. > > Somehow, trying to debug why I could not see printf output to > console, I ran a serial port sniffer and voila all of my > printf commands are writing on the serial port. > I can't say that it would cross my mind to look for my missing printf output on a serial port, even if I was using a serial port in other parts of the program to talk to something. Whatever it was that gave you the hunch to do that is probably at the core of your problem. > Any idea how to fix this? > Well, no, not really, since you've given very few details to go on. I'd SWAG that you've somewhere, somehow, redirected stdout to the serial port you're trying to talk to those devices on. > Thanks, > Alex Martin > -- Gary R. Van Sickle -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: Rationale for line-ending recommendation?
> From: Andrew DeFaria > > Mark J. Reed wrote: > > On Fri, Dec 19, 2008 at 4:42 AM, Gary R. Van Sickle wrote: > >> Me too, and like you and the OP report, it "just works" > 99.44% of the > >> time. Of course, since it's not the 21st century yet, many Unixoid > >> programs are still unable to handle text files properly, hence the > >> remaining 0.66%. > > 100 - 99.44 = 0.66? You're right - it's clearly not the > 21st century > > yet, since you seem to be using one of the original > > floating-point-bugged Pentium chips. ;-) > Touche! Loved it! > > BTW, it's the 21st century over here. Please try to catch up... Another one who believes what their calendar tells them? Then riddle me this Andrew: If this were in fact the 21st century (AKA "The Future"), why would we be be discussing software which is able to understand one text file format, but not a second ever-so-slightly different text file format? Now, if y'all shall excuse me, I have to go pick up my brand new nuclear turbine-powered flying car. -- Gary R. Van Sickle -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: Rationale for line-ending recommendation?
> From: Spiro Trikaliotis > > Hello David, > > * On Thu, Dec 18, 2008 at 05:42:20PM -0900 David Abrahams wrote: > > > > Can anyone explain why the installer began recommending using *nix > > line ending conventions? DOS-compatible endings have > always "just worked" > > for me and I've heard of lots of problems doing it the > now-recommended > > way. > > Personally, I also install it with CR/LF line endings. > Me too, and like you and the OP report, it "just works" 99.44% of the time. Of course, since it's not the 21st century yet, many Unixoid programs are still unable to handle text files properly, hence the remaining 0.66%. > However, I noticed one problem this way: xfonts. If you > install xfonts on cygwin with CR/LF line endings, the fonts > end up corrupt, and you cannot start X. I was bitten by this > problems many times, whenever I installed a fresh Cygwin. > > To fix this, You mean "work around this broken software". Presumably this will be "fixed" sometime in the 21st century, whenever that starts. > I use the following way: I mount /var/cache > (which also has > /var/cache/fonts/) in binmode, and reinstall xfonts. > > This is a long-running problem. > Indeed, but hardly surprising, since all indications are that handling text files is an NP-Hard problem. > Another problem I once had, but which might have been fixed > in the meantime, was the gcc compiler for the Lego > mindstorms: It did not accept sources files with DOS line > endings. Note, however, that this was 2000 or 2001, so it > might have changed in the meantime. > Gcc was broken for a while, but that did in fact get properly fixed quite a while ago. > Oh, and Subversion is problematic, too. Because the SVN > developers decided to handle line endings on their own using > libapr, opening files in binary mode and reading and writing > CR, LF or CR/LF on their own, This is the right way to do things... > on Cygwin, SVN is hard-coded to > *nix line endings. This is not nice. Note that this approach > will also fail badly if you mount parts of your system in > textmode, and parts in binmode. > > Because of this, I am using an SVN version which I compiled > myself with a patched libapr. > ...I'm not following this. Are you talking about the SVN repository, or the clients, or...? What's the issue? I know CVS had some problems with the dreaded \n/\r\n issue back in the day, but I wasn't aware of similar Subversion issues. > > Other than that, I never had any problems with the CR/LF line endings. Bash has some known problems in this area, but there's a Cygwin-specific fix (that unfortunately is off by default) which hopefully will get accepted upstream sometime in the next century. > However, the rationale might be that most problems are > testing better with LF line endings, as they come from the > *nix world. Remember, on *nix systems, the difference between > opening a file in text- or in binmode is practically > non-existant. Thus, many programmers do not care about the > "right" mode. > Well, better stated, they assume they can treat all files - text, executables, jpegs, whatever - as if they were Unix-formatted text files. Of course, they're not, hence problems ensue. > Best regards, >Spiro. -- Gary R. Van Sickle -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: cygwin and cygwin-xfree lists to merge
> From: Christopher Faylor > > The historical reasons for [un?]merging the cygwin and > cygwin-xfree lists no longer seems to exist so I am > contemplating merging the two lists. For us old-timers, what were the historical reasons again, and why/how did they go away? -- Gary R. Van Sickle -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: Public Cygwin 1.7 test starts today
> From: Corinna Vinschen [snip] > > Do you have a sense for what would make the next major release > > cygwin2.dll and not cygwin1.dll? Obviously an API or ABI breakage > > would require a new DLL name, but do you have something on the wish > > list that would require that, which was put off this time around? > > Windows will run under Cygwin 2.0 instead of vice versa. > Now THAT'S comedy! ;-))) Well, unless you were serious, in which case it's still good comedy. -- Gary R. Van Sickle -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: Setup wants to revert my upgrade of Emacs
> From: Jonathan Ferro > [snip having to check "binary"] > > Setup run 3: When rerunning Setup to look at something else, > fortunately I am in the habit of always looking at the > "Partial" view before hitting Next, and I see that it has > queued up all three packages to be reinstalled to version "21.2-13". > I have canceled out of that Setup session, but I'd like to > figure out how to get my choice to "stick". It sounds like you're having two possibly separate problems: 1. You shouldn't have to check binary, that sounds like a setup.ini problem. 2. Unfortunately there's no way to get any of your choices on the package chooser page to stick. -- Gary R. Van Sickle -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: [ANNOUNCEMENT] Updated: rxvt-20050409-9
> From: cygwin at cwilson etc etc > Sent: Saturday, November 15, 2008 11:49 PM > Subject: [ANNOUNCEMENT] Updated: rxvt-20050409-9 > > RXVT is a VT102 terminal emulator for both X and Windows. > > Brown paper bag release. Version -8 is withdrawn; it > erroneously required the X11 libXpm. Reported by WxH. > > -- > Chuck > Been using it for ~12hrs straight now with no (new) problems. Thanks as always Chuck. As to the non-(new) problems: Screwy copy and paste. I've been having this thing where copy/paste works fine for a while, then for no observable reason starts to act up. Multiple installations. Generally it starts with having to try to do a paste multiple times before it does anything, and eventually programs start throwing errors saying they're unable to talk to the clipboard (*any* program, not just Cygwin ones). I figured it was my ...ecks... server, which until now had not been the Cygwin/ecks one, but with the recently renewed activity I've switched to that one and I appear to be having the same problems, so now I'm starting to suspect rxvt. A little Googling didn't turn up any similar reports. Known issue? Suspected issue? I don't know how clipboard responsibilities are divided between rxvt and/or the server, so I'm not sure who to blame or where to look here. -- Gary R. Van Sickle -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: cygwin g++ strictness
> From: Eric Blake
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> According to John Emmas on 10/31/2008 9:35 AM:
> > question - when programming like this:-
> >
> > int32_t i = 32;
> > printf("%d", i);
> >
> > is it reasonable for a programmer to assume that a type declared as
> > int32_t will be compatible with "%d" when building for a
> 32-bit platform?
>
> It is not portable to platforms with 16-bit int (although
> these days, such platforms are museumware).
That, or:
- Running your car's engineware.
- Exploding an airbag into your face on detecting a collisionware.
- Recording your vital signsware.
- Pumping insulin into youware.
- Doing your laundyware
- Computerized exercise machinewear
- Microwaveware
- A billion other products with 8- and 16-bit microcontrollers in themware.
CSci doesn't begin and end with the CPU currently on our desks!
> You can probably
> ignore the warning on 32-bit platforms, but the better fix is
> to make your code portable by using .
>
Well, yeah. There's always the option to not Do The Right Thing(tm), but my
personal experience is that correct way is usually also the easiest way.
--
Gary R. Van Sickle
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
RE: cygwin g++ strictness
> From: John Emmas
>
> - Original Message -
> From: "Peter Rosin"
> Sent: 31 October 2008 15:19
> Subject: Re: cygwin g++ strictness
> >
> > I some projects I'm involved with there's quite a bit of
> the following:
> >
> > [...]
> >
> > int.c:6: warning: int format, int32_t arg (arg 2)
> >
> I must confess, this has been a source of irritation for me
> too but at least it doesn't stop the build. It does however
> bring us back to the fundamental question - when programming
> like this:-
>
> int32_t i = 32;
> printf("%d", i);
>
> is it reasonable for a programmer to assume that a type
> declared as int32_t will be compatible with "%d" when
> building for a 32-bit platform?
No. The only reasonable assumption to make in a case like this is that if
you don't do it right, you'll end up doing it over. "%d" means "int". You
use that to print an int. If you have something that is not an int, and you
want to print it, then you have exactly two reasonable choices:
1. Cast whatever you have to an int, then use "%d" to print it.
2. Use the proper format specifier, and pass whatever you have to directly
printf() (i.e. un-casted).
In this particular instance, #1 is the wrong choice, since you have no
guarantee that an int can contain an int32_t. You are left with #2, which
is not only the correct answer, but the path of least resistance as well.
Everybody wins!
> I'd be surprised if there's
> a programmer amongst us who can honestly say he wouldn't have
> made that assumption.
>
Be surprised ;-).
> John
>
--
Gary R. Van Sickle
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
RE: cygwin shell scripting - how to pass values from command line to ssh remote command
Thorsten Kampe wrote: > * Dave Korn (Tue, 14 Oct 2008 23:41:05 +0100) > > Thorsten Kampe wrote on 14 October 2008 21:11: > > > * Z W (Tue, 14 Oct 2008 11:59:07 -0700) > > >> I'm have a shell script, test.sh below to run with cygwin in a > > >> Windows box. > > >> > > >> #!/usr/bin/sh > > >> > > >> ssh [EMAIL PROTECTED] 'export MAX_MS=100; export OFFSET_MS=89900; export > > >> THREADS=4; export RAMP=1; export LOOPS=2; echo load01 ; cd > > >> /cygdrive/c/apps/bin ; pwd ; nohup ./start.sh \& ; ps > -efW | grep > > >> java ; exit ' > > > > > > That's not a shell script - it's just a single command. > > > > Uh, it's a shell script *containing* a single ssh command. Note the > > shebang. Also note the mention of the filename "test.sh", > which is not > > to be confused with the script "start.sh" on the remote machine. > > Putting a single command in a shell script is useless - > because it's a single command. You can call it a shell script > because it has the shebang but I call it as it is: it's just > a single command. ...whahuh? It's only useless until you have to type "ssh [EMAIL PROTECTED] 'export MAX_MS=100; export OFFSET_MS=89900; export THREADS=4; export RAMP=1; export LOOPS=2; echo load01 ; cd /cygdrive/c/apps/bin ; pwd ; nohup ./start.sh \& ; ps -efW | grep java ; exit '" more than once. Regardless, as I believe others have already pointed out, the cygwin content of this thread is tending towards zero. I humbly suggest all parties involved take a break, get their morning coffee/dewski/homebrew, and continue this discussion in a forum more suited for answering this sort of generic unixoid question. -- Gary R. Van Sickle -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: inetutils 1.5-4, ftp + inline password immediately quits
> From: Robinson, Paul T (NonStop)
>
> I have a pile of bash scripts with variations on this theme:
>
> ftp -n ${HOST} < user ${USER}
> ${PASSWORD}
> cd ${MYDIR}
> get ${MYFILE}
> bye
> FTP_EOF
>
Helpful hint: to reduce your overall hassle level, use ncftp of wget for
doing this sort of thing, and don't look back. That will allow you to put
all of those params on the command line. Both programs work great on
Cygwin.
--
Gary R. Van Sickle
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
RE: Bizarre Cygwin/Explorer/paths problem half-solved
Hi Luke,
> I discovered today that if I try to run Windows Explorer from
> the Cygwin command line, and give it a pathname with spaces,
> it fails, but if I give the same command line to a cmd.exe
> command line, Explorer works!
>
> I.e. from Bash, explorer fails with an error message like
> "The path '/e,c:\temp\space dir' does not exist or is not a
> directory."
>
> I've tried every quote combo I can. If I leave off the /e
> option then it does open the directory, but without the side
> pane (which is what you'd expect with the /e option omitted).
>
I've had this little gem in my .bash_profile for ages, and it's never failed
me regardless of the craziness of the path:
# Easy "Explorer here" command
x()
{
if [ "${1}" = "" ];
then
XPATH=".";
else
XPATH="$(cygpath -w "${1}")";
fi
explorer $XPATH & disown %-
}
No tree view though. Lessee what happens if I add a "/e,":
# Easy "Explorer here" command with tree control on the left
x()
{
if [ "${1}" = "" ];
then
# No parameter given, open Explorer in the current bash
directory.
XPATH=".";
else
# Open the given path.
XPATH="$(cygpath -w "${1}")";
fi
explorer /e,$XPATH & disown %-
}
...yep, that works like a charm too.
--
Gary R. Van Sickle
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
perl-5.10.0-4 -> perl-5.10.0-5 update appears to break DateTime
Hi Reini,
It looks like something changed between perl 5.10.0-4 and -5 which breaks
the DateTime module from CPAN (version 0.4302, latest). The attached Simple
Test Case(tm) results in only the following errors:
Use of uninitialized value $id in pattern match (m//) at
/usr/lib/perl5/site_perl/5.10/DateTime/Locale.pm line 65.
Use of uninitialized value $id in exists at
/usr/lib/perl5/site_perl/5.10/DateTime/Locale.pm line 68.
Use of uninitialized value $native_pieces[0] in join or string at
/usr/lib/perl5/site_perl/5.10/DateTime/Locale.pm line 83.
Use of uninitialized value $id in hash element at
/usr/lib/perl5/site_perl/5.10/DateTime/Locale.pm line 85.
Use of uninitialized value $id in hash element at
/usr/lib/perl5/site_perl/5.10/DateTime/Locale.pm line 90.
Use of uninitialized value $id in pattern match (m//) at
/usr/lib/perl5/site_perl/5.10/DateTime/Locale.pm line 65.
Use of uninitialized value $id in exists at
/usr/lib/perl5/site_perl/5.10/DateTime/Locale.pm line 68.
Use of uninitialized value $id in concatenation (.) or string at
/usr/lib/perl5/site_perl/5.10/DateTime/Locale.pm line 68.
You cannot replace an existing locale ('') unless you also specify the
'replace' parameter as true
BEGIN failed--compilation aborted at
/usr/lib/perl5/site_perl/5.10/DateTime/Locale.pm line 151.
Compilation failed in require at
/usr/lib/perl5/site_perl/5.10/i686-cygwin/DateTime.pm line 46.
BEGIN failed--compilation aborted at
/usr/lib/perl5/site_perl/5.10/i686-cygwin/DateTime.pm line 46.
Compilation failed in require at ./simple_test_case_datetime.pl line 3.
BEGIN failed--compilation aborted at ./simple_test_case_datetime.pl line 3.
Doing the "perl -MExtUtils::Installed [...]"/"cpan `cat module.list`" thing
(and also a "force install DateTime") results in the same errors, and
needless to say doesn't end up generating a working DateTime module. This
same version of DateTime did work without error in 5.10.0-4 and does work
with 5.8.8-4.
--
Gary R. Van Sickle
simple_test_case_datetime.pl
Description: Binary data
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
RE: chmod permission denied on windows 2008
> From: Christopher Faylor > > On Thu, Jul 03, 2008 at 11:22:03PM +0100, Steven Hartland wrote: > > Hope this gets through the lists broken spam detection, and > helps id > > the issue. > > How to Win Friends and Influence People... > > cgf > Please take such Cygwin-content-free snarking to the appropriate list please. -- Gary R. Van Sickle -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: path separator
> From: samitj > Subject: Re: path separator > > > hmm... i thought cygwin emulates a unix shell in windows. > $ echo $PATH > /usr/local/bin:/usr/bin:/bin:/usr/X11R6/bin:/cygdrive/c/WINDOW > S/system32:/cygdri. > > anyway, if i use a windows separator (;), it doesnt work and > it considers it the end of the command as per unix shell behavior. > > dont know if u r trying to say something different, do u have > a solution to make that work ? > PATH under Cygwin uses ':' as the separator. Cygwin reads Windows' PATH env var and replaces the ';'s with ':'s for its own use and any child Cygwin processes. There's more magic happening but that's most of what you care about here. No such special treatment is given CLASSPATH, since as others have already pointed out, this is not anything that's any sort of standard. It's an environment variable that the native Windows executable java.exe uses for its own purposes. As such Cygwin leaves it untouched. If you're trying to set CLASSPATH in a (Cygwin) shell script, you'll have to quote it so the ';'s don't get misinterpreted like you've discovered. Hit the Googles for "shell quoting" and settle in for a long night of reading. -- Gary R. Van Sickle -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: how can I stop Windows setting HOME?
> From: Adam Thompson > Subject: Re: how can I stop Windows setting HOME? > > 2008/6/6 anadem <>: > > > > Each time I boot my pc Windows sets the HOME environment > variable to > > my "Documents and Settings" directory, which screws up > cygwin. Before > > I can use cygwin I have to do the My > Computer/Properties/Advanced ... > > etc stuff and delete HOME from my User variables. Otherwise cygwin > > sets my $HOME to Window's idea of HOME, which is a pain in the neck. > > > > Is there any way to permanently unset the HOME env-var in > Windows? I > > could run a batch file at startup but afaik that would not be a > > systemwide removal of HOME. > > > > I don't think XP sets a var called HOME by default. It sets > HOMEPATH and HOMEDRIVE - and in some cases HOMESHARE. [snip] > > I do not think this is a Windows issue. > > -- > AdamT You're right, it's not a Windows issue per se. I've seen the same issue as the OP at two large companies, and I suspect he's seeing the same thing. What's happening is that for reasons known only to the IT department, the XP login "scripts" (COUGHbatchfilesdontdeservethemonikerCOUGH) that IT has deployed set it. If that's the case, then your only recourse is to get IT to change it, and of course good luck with that. That said, it probably isn't as real an issue as the OP may think. If it points to somewhere halfway sane (which it looks like it does for the OP, i.e. XP's idea of a user's home directory), it shouldn't "screw up cygwin". OP: What exactly is getting "screwed up"? -- Gary R. Van Sickle -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: [ANNOUNCEMENT] Updated: bash-3.2.39-19
> From: Eric Blake [] > 4. This version of bash has a cygwin-specific shell option, > named "igncr" > to force bash to ignore \r, independently of cygwin's mount > style. As of bash-3.2.3-5, it controls regular scripts, > command substitution, and sourced files. I hope to convince > the upstream bash maintainer to accept this patch into the > future bash 4.0 even on Linux, rather than keeping it a > cygwin-specific patch, but only time will tell. First the *government* sends *me* a check, now the first glimmer of hope appears in solving the heretofore-assumed-NP-complete text file line ending problem which has plauged computer science since prehistoric times. Man I love living in the future. Thank you Eric for your doggedness in getting this implemented and (hopefully) accepted. Here's hoping this can default to "on" upstream. -- Gary R. Van Sickle -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: postinstall hang
[sorry for the post-through, I don't have the original post] > > David Johnstone wrote on 01 April 2008 20:55: > > > For the moment I only really need the cygwin X-Server - do > you think > > that will that run ok with the Logitech Process Manager? > > Or is that asking for trouble again? > Dave, if literally all you need is an X server for Windows, use Xming instead: http://www.straightrunning.com/XmingNotes/ I use this with an otherwise full-on Cygwin install and it works great. -- Gary R. Van Sickle -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: FAQ suggestion
> From: Dan Kegel > > Christopher Faylor wrote: > > I assume that they are either trying to 1) cheat, 2) bend > the rules, > > 3) not spend any time whatsoever worrying about the problem, or 4) > > become annoyed because they have thought about it for > thirty seconds > > and it seems like we're purposely trying to punish them. > > I have to think the question comes up frequently, else it > wouldn't elicit such a strong reaction. > > > But, yes, sure, a FAQ entry would not be a bad idea. > > OK, I'm game: [snip] Allow me to be the first to thank you, Dan, for contributing to the Cygwin documentation (or attempting to at any rate). While I of course cannot speak for anyone else, I am sure that all other professionals here appreciate your efforts. -- Gary R. Van Sickle -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: Cygwin setup: DL rate should show as kB/s not kb/s ?
> From: Bill Meier > > Gary R. Van Sickle writes: > > > > > > From: Bill Meier > > > or maybe KB/s for kilobytes/sec ? > > > > > > > It should be an option, but that begs an "Options..." dialog, which > > doesn't exist. > > > > > Unfortunately I didn't express myself clearly in my original message. > > The numeric DLL rate shown by the Cygwin setup program is > actually in units of K Bytes/sec and thus either kB/s or KB/s > should be used as the text following the numeric rate. > Ohhh, oh oh oh, ok. Yeah, then I suppose kB/s is the correct way to go, if my SI serves me right (and please, no "kibbis", lordy). My point stands though: it would be a useful addition to have this user-selectable, as in some other file transfer programs. But my counterpoint also stands: no options dialog. > Looking at the code I also note that maybe the 2nd sprintf > should be changed to use %03.1f to be consistent with the 1st > sprintf ... > Ooof, still using C string manipulation I see. That brings back some memories -- Gary R. Van Sickle -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: Cygwin setup: DL rate should show as kB/s not kb/s ?
> From: Bill Meier > or maybe KB/s for kilobytes/sec ? > It should be an option, but that begs an "Options..." dialog, which doesn't exist. > > Bill Meier > -- Gary R. Van Sickle -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: [1.7.0 HEAD]: Cygwin no longer encoding/decoding names on managed
> From: Jeff > Sent: Tuesday, January 15, 2008 4:00 AM > Subject: Re: [1.7.0 HEAD]: Cygwin no longer encoding/decoding > names on managed [snip] > >Managed mounts? They're intended to handle names with > things like ":" > >in them, which will choke Windows no matter what year is in its name. > > Aren't they also intended to support apps that expect and > require file names to be POSIXly case-sensitive? Apps that > include core files that have the same names except for case? > ...which will cause file collisions in Windows, no matter > what year is in its name. > Yep, that kind of stuff as well. > It seems to me that Cygwin /still/ has just as much need to > map POSIX file names onto Windows, as Windows still has the > need (at least through XP-- I do not know if this is > supported in Vista) to map long file names onto DOS 8.3 file > names. Like Corinna said, file handling in the tip is a work in progress. While I don't want to speak for anybody, I am unaware of any plans to remove this functionality, as appears to be your concern. > Oh yeah, which reminds me-- cygpath no longer escapes > the spaces in Windows long file names when converting them to > POSIX paths, making the following kludgy shell script > necessary: > > #! /bin/bash > ppath=$(cygpath "$2" | sed 's/ /\\ /g') > if [ -n $3 ] ; then > eval $1 "$ppath" $3 > else > eval $1 "$ppath" > fi > > > Jeff > $ cygpath -u 'c:\Program Files' /cygdrive/c/Program Files $ cygpath -v cygpath (cygwin) 1.42.4.1 Path Conversion Utility Copyright 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005 Red Hat, Inc. Compiled on Dec 14 2007 Yep, I can replicate your report. I'm doubt that it's incorrect behavior though: $ find /cygdrive/c/Program\ Files/ /cygdrive/c/Program Files/ [...etc...] -- Gary R. Van Sickle -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: [1.7.0 HEAD]: Cygwin no longer encoding/decoding names on managed mounts
> From: Dave Korn > Sent: Monday, January 14, 2008 8:25 PM > Subject: RE: [1.7.0 HEAD]: Cygwin no longer encoding/decoding > names on managed mounts > > On 14 January 2008 21:41, Nicholas Wourms wrote: > > > I'm not sure when this cropped up, but it happened sometime > after the > > great "win 9x" code purge. The problem is that the Cygwin dll no > > longer decodes or encodes file/directory names on managed mounts. > > Isn't that the whole idea? > Managed mounts? They're intended to handle names with things like ":" in them, which will choke Windows no matter what year is in its name. > cheers, > DaveK > -- > Can't think of a witty .sigline today > -- Gary R. Van Sickle -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: copying a million tiny files?
> From: Brian Dessent > > sam reckoner wrote: > > > I'm not exaggerating. I have over one million small files > that like to > > move between disks. The problem is that even getting a directory > > listing takes forever. > > > > Is there a best practice for this? > > I know it's heresy but if you just want to copy files why not > use the native XCOPY? It will not suffer the performance > degredation of having to emulate the POSIX stat semantics on > every file, just like the native DIR command in a large > directory does not take ages because it simply uses > FindFirstFile/FindNextFile which are fairly efficient (but do > not provide sufficient information to emulate POSIX.) > > Brian > I have a similar situation to the OP (copying many thousands of small files over a fairly slow link), and actually timed using XCOPY vs. Cygwin methods (cp in my case). It didn't make a significant difference. Ultimately what I think you run into in these sorts of situations is that you bump up against the slowness of the link (or physical disk) because, POSIX emulation or not, all your caches do is thrash. -- Gary R. Van Sickle -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: sftp removing writable bit
[snip] Cygwin Content-O-Meter(tm), as of a few dozen posts in this thread ago: +---+ | 0% 100% | | \ | | \| | \ | |O | +---+ Too bad nobody polices such things. -- Gary R. Van Sickle -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: Don't like "setup" for ocassional updates
Hi Paul, The Cygwin list is the appropriate place for followups: > From: Paul McFerrin > > Gary R. Van Sickle wrote: > >> From: Paul McFerrin > >> > >> I thought is was that straight forward. Consider the .bz2 > file under > >> bzip2: > >> bzip2-1.0.3-2.tar.bz2 > >> I did a "bunzip2 -d file..." and ended up with a file > "bunzip2.exe" > >> which is corrupt. Can't do > >> tar -t file... > >> > > > > Perhaps it's time to upgrade your Cygwin installation. :-0 > > > Well I did, without the knowledge that setup would do that. > I'm now running version 1.5.24. I'll stay with that. The > last person (Larry > Hall) mentioned using wget or curl but gave no URL's on where > I might even find the files. Maybe I'm blind, but that seems > to be a secret. It's no secret to those of us using setup.exe ;-). There's an old saying in Tennessee - I know it's in Texas, probably in Tennessee - that says, "If you lived here, you'd be home by now." Use setup.exe and you can't get fooled again. -- Gary R. Van Sickle -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: Don't like "setup" for ocassional updates
> From: Paul McFerrin > > I thought is was that straight forward. Consider the .bz2 > file under bzip2: > bzip2-1.0.3-2.tar.bz2 > I did a "bunzip2 -d file..." and ended up with a file "bunzip2.exe" > which is corrupt. Can't do > tar -t file... Perhaps it's time to upgrade your Cygwin installation. :-0 > without getting the corrupt file error. Maybe I just got a > corrupt file but I thought I would check things out before > continuing to really mess things up. > How can I re-get that one file without setup messing up my > current system? You're using a Cygwin that was built when the Dead Sea was only sick. In addition to all the problems that people have been adding to the distro, I suspect some defects may have been fixed since. Why, heck, it's possible you're running into one in your efforts to not update. Bite the bullet and update. Everything. With setup. The chances that you'll be able to piecemeal update a few apps to present-day versions while retaining a Cretaceous-era cygwin1.dll and have it be a pleasant experience are zero. -- Gary R. Van Sickle -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: hacked package on server
> From: Brian Mathis [snip] > > Yes, everyone now has been quite hilarious on this part of > the matter, but I think it's time to get past the arrogance > and, god forbid, consider that a user's reported problem, oh > my god, might actually be a problem! > Heheheh! He thinks he's on the [insert name of any other project here] mailing list! -- Gary R. Van Sickle -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: scripting and cygwin
> From: Phil Betts [] > > You're comparing chalk & cheese and complaining that your > mouth's full of grit. Oh man, that's goin' in the act! ;-) -- Gary R. Van Sickle -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: CygWin and email clients
Try mutt. -- Gary R. Van Sickle > -Original Message- > From: Jeremy T. Harrison > > I have tried with varied success to use "ssmtp" and "email" > as my email send applications under CygWin. For what ssmtp > was designed to do, it works fine, but, doesn't meet my > requirements; "email" seems to be a stepchild of sorts, and > does not meet my needs (it doesn't support TLS), though I do > very much like its flexibility otherwise. > > Are any CygWin users out there using a command line e-mail > application? > My requirements are basically, that I can send e-mail from > the command line (i.e. from within scripts and from crontab); > include attachments; and, use different ports as well as TLS. > > I have read variously of scripts to run ssmtp with > attachments; but I have not come across any of those scripts. > If anyone might be able to direct me to such a script I > would be grateful! Notwithstanding, if anyone has a > different email solution - that meets requirements comparable > to mine - I would appreciate learning how you meet your needs. > > Thank you! > > Jeremy Harrison > > [EMAIL PROTECTED];[EMAIL PROTECTED] > > > > -- > Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple > Problem reports: http://cygwin.com/problems.html > Documentation: http://cygwin.com/docs.html > FAQ: http://cygwin.com/faq/ > -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: script problem
> From: Lev Bishop > Sent: Saturday, March 03, 2007 2:42 PM > Subject: Re: script problem > > On 3/2/07, Gary R. Van Sickle wrote: > > The only downside to the switch that I've experienced is that my > > interactive shells take quite a bit longer to come up, but I think > > that may have something to do with my setup rather than something > > intrinsic to the rxvt-unicode+Xserver setup. My usage > pattern is such > > (start one or two interactive shells and leave them up all > day) that > > it's not an issue for me. > > Does running fc-cache speed up your startup? > > Lev It hasn't bothered me enough to even look in to it frankly. My Cygwin interactive shell startup times have been a bit slower than normal for years because I have a bit of Perl/Cygpath magic in my bash_profile to despacify PATH, which for whatever reason has always seemed to take quite a bit longer than it should. I may look into it when I get enough of them round tuits, but like I said it's still in the tolerable range for me. -- Gary R. Van Sickle -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: Difference Between CYGIPC And CYGServer
> From: Corinna Vinschen > Sent: Friday, March 02, 2007 2:01 PM > Subject: Re: Difference Between CYGIPC And CYGServer > > On Mar 2 12:54, Charles Wilson wrote: > > (In cygwin-1.7.0+, cygserver will also implement POSIX-compliant > > shared memory objects and message queues). > > Even better. POSIX shared memory objects and message queues > are both implemented using file backed sharead memory which > works without help of cygserver. > Swt. -- Gary R. Van Sickle -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: script problem
> From: Marco Atzeri > Sent: Friday, March 02, 2007 9:05 AM > Subject: Re: script problem > > > --- Asher Vilensky > > > Thanks for the kind advice. I indeed installed rxvt. I've noticed > > that rxvt does not save me much memory over XWin. > > Approx 10MB (rxvt) > > over 20MB (XWin). No biggie. Are there any other > advantages of using > > rxvt over XWin? If so, what are they? > > > > 20Mb less. > Because Xterm+Xwin (Xterm need Xwin) 30MB > RXVT alone less than 10MB > > rxvt-unicode (one instance) + Xming comes out to ~20MB total, ~6MB for urxvt and ~14MB for Xming. -- Gary R. Van Sickle -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: script problem
> From: Asher Vilensky > Sent: Friday, March 02, 2007 7:32 AM > Subject: Re: script problem > > Thanks for the kind advice. I indeed installed rxvt. I've > noticed that rxvt does not save me much memory over XWin. > Approx 10MB (rxvt) over 20MB (XWin). No biggie. Are there > any other advantages of using rxvt over XWin? If so, what are they? > Actually the advantages tend to go the other way at this point. The Cygwin non-X rxvt is no longer being actively maintained upstream. rxvt-unicode is being actively maintained both upstream and here in Cygwinton. It looks nicer (fonts appear to get antialising), there's bugfixes (though I've only ever run into one minor bug on the non-X rxvt), and has some Unicode/UTF-8 support if that's important to you. I recently switched over to rxvt-unicode completely, after being a longtime non-X rxvt user. The only downside to the switch that I've experienced is that my interactive shells take quite a bit longer to come up, but I think that may have something to do with my setup rather than something intrinsic to the rxvt-unicode+Xserver setup. My usage pattern is such (start one or two interactive shells and leave them up all day) that it's not an issue for me. > BTW, nobody has yet to suggest a solution to my original > problems - XWin won't die during Windows shutdown. Try Xming as your X server instead, I've never seen this problem with it. -- Gary R. Van Sickle -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Old Flex
Is there a technical reason why flex is stuck at 2.5.4a? If so, what is it? That version dates to summer of 1997 (i.e. early Devonian epoch), and there have been two subsequent releases in 2003 and 2006. I've verified that the latest flex source builds OOB, but of course has the usual line ending troubles. -- Gary R. Van Sickle -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: bash scripting problem
> From: Rob Walker > Sent: Friday, December 01, 2006 5:29 PM > Subject: Re: bash scripting problem > > Eric Blake wrote: > > -BEGIN PGP SIGNED MESSAGE- > > Hash: SHA1 > > > > According to Andrew Louie on 12/1/2006 3:17 PM: > > > >>> You have DOS line endings in these files. Use 'd2u' to > remove them. > >>> > >>> > >> Thanks! I would have never known that, > >> > >> now, can i run d2u on every file in my installation? > >> > > > > No, only run it on text files (it corrupts binary files, > such as *.exe). > > > d2u may also corrupt "text" files that need to have CR in > them. This includes bash scripts that need to parse or output CR. > > -Rob Do you have a link to such a script? I don't mean a proof-of-principle; I'm sure a suitable example can be contrived. What I'm looking for is a shell script "in the wild" that purposely has a carriage return embedded in it for reasons other than ending a line of the script. -- Gary R. Van Sickle -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: .exe.stackdump and core dump files questions
> From: Eli Zaretskii > Sent: Friday, November 24, 2006 12:36 PM > Subject: Re: .exe.stackdump and core dump files questions > > > Date: Fri, 24 Nov 2006 13:22:42 -0500 > > From: Christopher Faylor <[EMAIL PROTECTED]> > > > > If you look at a output of a stackdump file, it is obviously human > > readable. It is an ascii file which has English words in > it. It was > > NOT clear to me that the OP had actually looked at it. > > Others obviously did understand that; [snip] Eli, you need to take this discussion to cygwin-talk or Faylor will ban you. -- Gary R. Van Sickle -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: device drivers - general info
> From: George Locke > Sent: Wednesday, October 25, 2006 1:48 PM > Subject: device drivers - general info > > Hi group, > > I am running windows 2k with the most recent Cygwin version > 1.5.21-1, just installed it last week. > > I wish to create a C++ program that communicates with a > windows device driver (for a PCI card that interfaces with > external electronics). > The maker of the driver has provided a C++ library that > allows me to write C++ programs that communicate with the PCI > card, and i know that this works in regular windows, but i am > feeling unsure about whether it will work in Cygwin. > > Would you say "in general yes, that kind of thing should > work"? If the C++ library is not provided in source-code form, you're pretty much out of luck, due to name-mangling differences and other issues. If they're giving you a C++ source library that ultimately communicates with the kernel-level driver via normal Win32 filehandles and/or IOCTLs, I would say, "if you've followed me so far, in general this kind of thing can be made to work, but be prepared to roll up your sleeves, because odds are that the code was written for Visual Studio." > Is there a general rule for how Cygwin interacts with > windows hardware drivers? The Cygwin DLL is Win32 application-level code, so Cygwin apps don't interact any differently with drivers than "normal" Win32 apps. > is there a web-page that will > explain driver issues within Cygwin (googling the cygwin site > has been unfruitful so far)? > I'm sure there is no such animal, since again there's nothing special with Cygwin when it comes to drivers. > If you need more specifics i'll provide them. I can't simply > test this because I don't have the driver, and i won't buy it > ($900) unless i feel assured that i will be able to make it > work, hence this email. > > Regards, > > George Locke > -- Gary R. Van Sickle -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: igncr vs text mode mounts, performance vs compatibility
> From: Eric Blake > Sent: Tuesday, October 24, 2006 7:03 PM > Subject: Re: igncr vs text mode mounts, performance vs compatibility > > According to Lewis Hyatt on 10/24/2006 12:57 PM: > > Just a thought, it would probably solve 99% of people's problems if > > you just specified that if the first line of the script > ends in \r\n, > > then \r will be ignored for the rest of the file. Then you > would just > > need to read the first line a byte at a time, and every subsequent > > line could be read efficiently whenever possible, right? > And it seems > > unlikely that this could possibly break anything. > > Propose a patch, and I will consider it. In my opinion, it > was much easier to do igncr as an all or none option than it > was to parse the first line and discard \r on a per-file > basis, not to mention that all-or-none is easily configurable > so that those of us who WANT literal \r I'm just curious here: *Why* do you (or anybody else) want bash to not ignore \r's (or better stated, to only understand The One True Text File Format (Whatever That Is)(tm))? I keep trying to figure out what is going to break when bash suddenly is able to understand \r\n as well as \n, and keep coming up empty. Furthermore, I don't recall a single instance of anybody coming to the list with a problem that was due to bash ignoring \r's (when it used to do so). > as required by POSIX > can do so. Is this the reason? If so, do you know why POSIX requires this? At some point POSIX compliance ceased to be a goal of the Cygwin project, so I don't see that as an argument either way. -- Gary R. Van Sickle -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: cygwin unix commands in windows
> From: Eric Blake [snip] > You asked, so I'll answer. Yes, it is an accident that other > tools understand c:/. It's no accident that make used to, and now again will, be supporting Windows paths. People put considerable time and effort into making it work originally, and then again just recently in finally solving the problem and pushing the fix upstream. [snip] > Another example of a program that parses its arguments is > make; you need only read last months archives for the debate > about make 3.80 vs. make > 3.81 for proof that using DOS paths in cygwin programs is > ASKING for problems. I think you're misreading the make issue. Using Windows paths in make was apparently never "asking for problems" until the last release, at which time a problem was introduced, a solution was found, pushed upstream, and the problem is now solved (or will be when the next Cygwin build is released). -- Gary R. Van Sickle -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: Bash and CR/LF line-endings
> From: Eric Blake > Sent: Tuesday, October 03, 2006 9:07 PM > Subject: Re: Bash and CR/LF line-endings > [snip] > > Perhaps so, but that was a risk I was willing to take, since > cygwin's stated goal is to provide a Linux emulation on > Windows, and Linux users don't go creeping in cr/lfs. > At the risk of being over-obvious, Linux users... use Linux. In such an insular environment, perhaps they have the luxury of only using the One True Text File Format (whatever that is). Actually, Windows users also have that luxury, as long as they wish to remain in their own world as well. Where the twain meet of course is where we run into issues, and the twain meet at Cygwin. Used to, anyway. > > > > So why was the solution of using the 1st line of the script > (which, it > > was claimed, is read anyway for other purposes) and base > the seeking > > behavior on the detection of cr/lf there, rejected? > > It is not rejected, merely unimplemented. My patches have > focused on the minimal amount of code to get a decent > workaround, and hacking the initial 80-character read of a > file proved harder than hacking the input engine. > If someone else (how about you?) were to submit a patch doing > just that, then I would certainly review it and likely apply > a derivative of it, in part because reviewing a patch is a > much smaller time commitment on my part than me writing yet > another workaround from scratch. > > Actually, if anyone is interested in pursuing this further, > it may be worth auto-setting the igncr shopt according to the > first line of the script, rather than the current behavior of > defaulting that option to unset for every new bash > invocation. Also, you must consider how things should work > when stdin is a pipe containing \r\n data, since with pipes, > you can't prescan the first line of input to see what it > contains because you can't rewind afterwards. > What's going to break if igncr is simply always on? -- Gary R. Van Sickle -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: Problems with archiver "ar"
> From: Eric Blake > Sent: Wednesday, September 27, 2006 8:42 PM > Subject: Re: Problems with archiver "ar" > [snip] > > > > But due to the newest bash update, I rather need "textmode" > to re-use > > my existing scripts without conversion, as the come from a revision > > control system which always generates the EOLs according to > the underlying system. > > See the other thread on this today. First, why can't you > teach your revision control system that on a cygwin binary > mount, the underlying system uses \n line endings, not \r\n? I hate to sound like a broken record, but not-quite-correct statements such as the above give aid and comfort to our common enemy, The "/r/n vs /n vs /r" Debacle Which None Of Us Shall Live Long Enough To See Resolved, and I therefore must wax pedantic: The "underlying system" (i.e. Windows, Linux, Cygwin binary mounts, whatever) has no notion of what a "line ending" even is, much less what values might represent it. Bytes is bytes; have been since CP/M died. Programs which manipulate text in some way, and the libraries they link with, are who and what define the notion of a text file, and hence text file formats, and hence "line endings". Most of these programs and/or libraries are broken in either implementation or design, in that they are only capable of reading one text file format. When faced with the simple task of reading a plain text file with a format other than the One True Format which they can handle, they fail, with varying degrees of spectacularity. Researchers have been unable to determine why, in the 21st century, this problem is still as bad as its ever been, but such is the sorry state of affairs of the Computer Science world we live in. At any rate, in an effort to mitigate the inevitable problems caused by these broken programs, workarounds such as Cygwin's "text mode mount" were invented. Of course, Life never closes a door without also closing a window, and these workarounds are not without their own problems. There can be speed issues, especially if the broken program wants random access to the file (lseek()/fseek()). Programs that are broken in the opposite direction, i.e. programs which treat all files - executables, binaries, graphics, whatever - as if they were text files in their One True Format, can be broken (and yes, as impossible as it is to believe, such programs are not at all uncommon!). The good news, Gentle Reader, is that there is a teeny-tiny glimmer of hope on the horizon: Unicode. The Unicode standard actually had the courage to define not one, but no less than *seven* valid line terminator sequences (q.v.: http://en.wikipedia.org/wiki/Newline). So, as Unixoid, Windowsoid, and Macoid tools slowly become Unicode-capable, and assuming they make even a token attempt at meeting the standard, perhaps, some day, our great, great, great, greatgreatgreat grandchildren will be able to creat a plain text file on one computer and have it be understood on another. But I wouldn't put money on it. -- Gary R. Van Sickle -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: Bash 3.1.17(8) CR/LF problem
> From: Eric Blake > Sent: Wednesday, September 27, 2006 8:14 PM > Subject: Re: Bash 3.1.17(8) CR/LF problem > [snip] > > I guess I'm 50/50 here. On one hand is most certainly not a > > standard line terminator character on Unix systems, but at the same > > time Cygwin advertises a "collection of tools which provide > Linux look > > and feel" for Windows. > > Here's my take on it. If you want POSIX behavior and Linux > compatibility, use binary mounts and LF line endings, and > don't edit files with notepad. Actually, it would be: "don't use notepad at all, don't create any text files you want bash to understand with any native Windows text editor, and if you are going to use a native Windows text editor to edit files you want bash to understand, make sure it maintains the original line endings. Also, make sure any other tools you might wish to use to process text, cygwin or non-cygwin, do the same." The "/r/n vs /n vs /r" Crisis Which Shall Plague Computer Science Forever is most assuredly not merely a matter of "don't use notepad". -- Gary R. Van Sickle -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: [ANNOUNCEMENT] Updated [experimental]: bash-3.1-7
> From: Eric Blake > Sent: Friday, September 08, 2006 10:18 PM > Subject: [ANNOUNCEMENT] Updated [experimental]: bash-3.1-7 > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > A new release of bash, 3.1-7, is available for experimental use. > > NOTICE: > === > This version removes several outdated #defines that were once > necessary in older versions of cygwin, but which made bash on > cygwin different and slower than bash on Linux. [snip, the > line-ending fiasco that shall forever plague computer science] How much slower? While I'm all for saving a cycle here and there (q.v. the 1% make improvement ;-)), I have a hard time believing that ignoring the occaisional "\r" is even a blip on bash's radar compared with fork()ing et al. -- Gary R. Van Sickle -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: Need Volunteers to test patch for gnu make
Hi Bill, > From: William A. Hoffman > Sent: Friday, September 08, 2006 2:35 PM > Subject: Re: Need Volunteers to test patch for gnu make > > At 12:38 PM 9/8/2006, William A. Hoffman wrote: > > >Thanks Bob. OK, so that is three people that have tested > this patch. > >Please try the patch if you use make. DOS paths will be on > by DEFAULT > >and there will be no way to turn it off. We want to make > sure this does > >not break any POSIX based makefiles. > > Since folks seem to be adverse to building from source, I > have made the patched make.exe available here: > > http://www.cmake.org/files/cygwin/make.exe You might want to strip this; it's ~4xxkB unstripped, 147kB stripped. > Please try it, and report any problems on this list. > > Thanks. > > -Bill > I just finished trying it on my standard test, building a cvs pull of wxWindows tip. Worked like a charm. It even shaved almost 18 seconds (!) (;-)) off my build time: Old make: $ time make [...] real23m30.751s user3m57.150s sys 3m2.379s New make (i.e. the one from your link, but stripped): $ time make [...] real23m13.115s ^^ 18 seconds saved (approx. 1%) user3m56.285s sys 3m2.261s So, I shall take that 18 seconds to also thank you for your great work. ;-) -- Gary R. Van Sickle -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: cygwin fork()
> From: Christopher Faylor > Sent: Friday, September 01, 2006 1:01 PM > Subject: Re: cygwin fork() > > On Fri, Sep 01, 2006 at 06:57:10PM +0100, Dave Korn wrote: > >On 01 September 2006 18:47, clayne wrote: > >>I found the real culprit, which I had also ifdef'd out because it > >>looked bogus and crufty: > >> > >>/* Return 1 if a seek on FD will succeed. */ #ifndef __CYGWIN__ # > >>define fd_is_seekable(fd) (lseek ((fd), 0L, SEEK_CUR) >= 0) > #else # > >>define fd_is_seekable(fd) 0 #endif /* __CYGWIN__ */ > > > >Yeeesh. This is a terrible way of dealing with the fact > that you can't > >seek a stream accurately if you open it in text mode, because of the > >ambiguity about whether you've advanced one or two chars through the > >underlying file when you see an LF that could perhaps have actually > >been a CR/LF. What we really want is > > AFAIK, Cygwin's lseek should handle seeking on text streams. > DJ implemented that years ago. > Last I looked, which was admittedly also years ago, it was "#if 0"'ed out, with a comment to the effect of "Nobody has any business seeking around in text files." -- Gary R. Van Sickle -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: copying and pasting in the terminal window?
> From: G.W. Haywood > Sent: Friday, August 25, 2006 4:53 AM > Subject: RE: copying and pasting in the terminal window? > > Hi there, > > > On Fri, 25 Aug 2006, Gary R. Van Sickle wrote: > > > ... The main trick is (or at least used to be) getting > your delete, > > home, end, etc keys working right, and I can send you my magical > > .initrc to take care of that post-haste. > > Please cc me on that one, huh? Or better, post it to the > list, my mailserver might block your ISP. > Ask and ye shall receive my good man! I'm currently using the attached. Be sure though to check what gets installed by default - ISTR that at some point at least some of this got into the distribution. -- Gary R. Van Sickle .inputrc Description: Binary data -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: copying and pasting in the terminal window?
> From: mwoehlke > Sent: Thursday, August 24, 2006 10:44 AM > Subject: Re: copying and pasting in the terminal window? > > Gary R. Van Sickle wrote: > >> From: mwoehlke > >> Cygwin also has an rxvt terminal emulator that may be more to your > >> liking, but I haven't used it and so can't tell you what it's like. > > > > It's awesome, if you're still using the DOS box change over > immediately. > > Believe me now and thank me later. > > Awesome? Awesome. > It appears to be xterm (which I never liked to begin > with), which needs an X server As others have stated, it's not xterm and there's no X server required. > and is a PITA to configure, Mm, no, in the Unixoid scheme of things it's probably one of the easier programs to configure. The main trick is (or at least used to be) getting your delete, home, end, etc keys working right, and I can send you my magical .initrc to take care of that post-haste. > has an ugly font, ??? You can pick whatever font you want, even the cmd one if you want. > and probably has issues running certain CUI > applications (at least I know I've heard such rumors). I can confirm that particular rumor. Essentially you get no I/O with certain non-Cygwin command-line apps, generally ones that are interactive. It's never been enough of an issue for me to switch back to the horrific cmd, and I've been using rxvt forever. > And I > see exactly zero ways in which it is an improvement over Console. > Copy/paste, scrollback buffer, and "Unix-like, X or no X" are three that immediately come to mind. > Console is awesome, if you're still using rxvt change over > immediately. Nope, if you look back you'll turn into a pillar of salt! > Believe me now and thank me later. :-) > I shall do neither! ;-) > If you *must* have an X-based terminal emulator for some > reason (or even just something that isn't using the CUI > subsystem under the covers), I would strongly recommend > Konsole as VASTLY superior to xterm/rxvt. You can get an old > version... um, somewhere, or wait and see if KDE4 makes good > on native Windows support (which I guess would no longer be > X-based, but would also not need an X server). Well you can rest assured I shall give it a try should they come out with a native port. Now in the meantime, get rxvt installed before it's too late!!! To get you started, here's the command line of the shortcut I've used for countless years of cmd-free Cygwinning: C:\unix\bin\rxvt.exe -tn rxvt-cygwin-native -sr -sl 1000 -fn "Lucida Console-bold-14" -e bash --login -i You're welcome. ;-) -- Gary R. Van Sickle -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: copying and pasting in the terminal window?
> From: mwoehlke [snip] > Cygwin also has an rxvt terminal emulator that may be more to > your liking, but I haven't used it and so can't tell you what > it's like. It's awesome, if you're still using the DOS box change over immediately. Believe me now and thank me later. -- Gary R. Van Sickle -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: A build problem of C++ code on Cygwin
> From: Brian Dessent > Sent: Tuesday, August 22, 2006 6:30 PM > Subject: Re: A build problem of C++ code on Cygwin > > Brian Dessent wrote: > > > I've seen this a million times. It's a makefile that doesn't know > > about $EXEEXT and assumes that executables have no > extension. Because > > of this one of the stock built-in make rules gets invoked > instead of > > the proper link command. Look in the Makefile for the rule that > > generates the final binary and I'm willing to bet that it has no > > $EXEEXT. This works fine on linux because there is no > extension for executables there. > > Indeed. The attached patch (and then re-running automake at the > top-level) causes the build to work correctly -- or at least > get past the problem you reported, I don't feel like waiting > for the full build. > > You should report this upstream. The change should be safe > for any platform. > > Brian Another very similar one to watch out for are makefiles that actually do support $EXEEXT, but for whatever reason $EXEEXT gets set to nothing. I think it's mainly hand-rolled makefiles these days, but IIRC if somebody's using crusty enough autotools they'll get configures that do this to you. -- Gary R. Van Sickle -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: NTFS fragmentation
[cc'ing you per your request] > From: Vladimir Dergachev > Sent: Wednesday, August 02, 2006 5:33 PM > Subject: NTFS fragmentation > > > Hi all, > >I have encountered a rather puzzling fragmentation > that occurs when writing files using Cygwin. > >What happens is that if one creates a new file and > writes data to it (whether via a command line redirect or > with a Tcl script - have not tried C > yet) the file ends up heavily fragmented. > >In contrast, native Windows utilities do not exhibit > this issue. > >Someone suggested to me that Windows requires an > expected file length to be passed at the time of open, thus I > searched on Google and found "fsutil" program that allows to > reserve space on the filesystem. > >I attached a small Tcl script that, when run, creates > two 30 MB files - one using regular open/write pair (and > which is fragmented into about 300 pieces on my system) and > one using fsutil/open in append mode/seek 0 method. > > To see the problem defragment your system, run the test > script and then run analyze and ask to view report. You will > see a.dat at top of the list, while b.dat never appears in > the report. > >Despite the workaround, it is still kinda hard for me > to believe that anyone has designed a filesystem that needs > to know what is the file size going to be - especially for a > single program writing on an almost empty disk. Perhaps there > is some sort of environment variable that I need to set ? > > Any suggestions and comments would be greatly > appreciated. > Please CC me - I am not on the list. > >thank you very much > > Vladimir Dergachev I'll try your test case when I get a chance, but my WAG is that you're seeing the effects of Cygwin's creation of sparse files by default for any file beyond a certain size. I unfortunately do not recall what that size is. What happens as you change FILE_SIZE and/or BUFFER_SIZE in your script, to maybe a small multiple of your cluster size? -- Gary R. Van Sickle -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: cygwin copy problems usb 2.0
> From: aldana > Sent: Thursday, July 27, 2006 7:15 AM > Subject: cygwin copy problems usb 2.0 > > > hi, > > i've got usb 2.0, when i copy through TotalCommander the copy > speed is quite high. I have no idea what a TotalCommander is, but from the context here I assume it's a native Windows app that has copying abilities which are highly optimized for speed. > when i copy through cygwin shell it > seems that it is transmitting data only with usb 1.x speed. > very spooky, because i thought that cygwin is calling windows > drivers/api so it should be indirectly supporting usb2.0 ? > I can assure you with 99.44% confidence that Cygwin is not somehow downgrading your USB connections from 2.0 to 1.x. Such decisions get made at a much much lower level than user-mode apps operate at. In fact, I doubt it's even possible for this to happen in kernel-mode code - I think this all happens at the hub/device hardware/SIE level. Cygwin's cp is slower than a native copy, from anywhere to anywhere else, for a number of reasons. The main one, last I looked (admittedly years ago), was a fallout of portability. Cp opens file and copies them an (f)read/(f)write buffer at a time, while your Windows native program almost certainly simply calls CopyFile() (a Win32 API), bypassing a ton of library code. -- Gary R. Van Sickle -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Detecting intrusive programs in cygcheck (was: RE: SOLVED: sshd+ssh localhost connects, but don't reach the shell)
> From: Vilar Camara > > >I'd really like to thank you for all your support tracing my > problem. > >I've uninstalled ZoneAlarm and everything works fine now. > > Just an additional information: I've installed ZoneAlarm Free > Edition and sshd is working. My previouos complaints were > about ZoneAlarm Pro. So, it's something related to the Pro version. > > -- > Best regards, > Vilar Camara Neto Two things: 1. Does ZoneAlarm cause the same volume of havok with other software as it does with Cygwin? The equation appears to be "Cygwin + ZoneAlarm = Disaster", but I have a hard time believing that it isn't really a system of equations more along the lines of "AnythingThisSideOfNotepad + ZoneAlarm = Disaster". 2. Would it make any sense to have cygcheck look for ZoneAlarm, any and all AV programs, Google Desktop, etc etc etc, and at least prominently flag their existence, if not make some clear statement to the effect of "This program is almost certainly causing your problem, plus dozens of others you don't even know about. Uninstall it."? IIRC, Setup actually gives the user the option of temporarily disabling AV software. -- Gary R. Van Sickle -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: 200 GB drive has room but gzip indicates "No space left on device"
> From: David Christensen > > Replies to mailing list mail should go to the mailing list, > not the poster... > > -Original Message- > From: David Christensen [mailto:[EMAIL PROTECTED] > Sent: Monday, May 29, 2006 2:05 PM > To: 'Dave Korn' > Subject: RE: 200 GB drive has room but gzip indicates "No > space left on device" > > Dave Korn wrote: > > Or could it be a dodgy AV program interfering with normal > operations? > > I use McAfee Virus Scan Enterprise 8.0i. It seems to work > just fine with all my drives (up to 250 GB). > Shut it off and give it another try. Also make sure Google Desktop isn't running, or anything else that sits in the background hitting files "behind your back". -- Gary R. Van Sickle -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: slow share = slow scripts?
> From: mwoehlke [snip] > Also, why *is* > fstat() so inefficient? Short answer: because it gets a bunch of information about the file that isn't necessarily available without hitting (open()ing) the file itself. > Can anything be done about it? Short answer: No. Longer answer: Much has, but the real problem is the very definition of the function. -- Gary R. Van Sickle -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: slow share = slow scripts?
> From: mwoehlke > > I'm trying to run some scripts off of a slow network share, > and it takes > *forever* in Cygwin (it's OK in Interix). > > Looking at an strace (attached) via 'sort -n' shows a LOT of > time being spent in read(), apparently just after (caused > by?) an fstat(), which means this feels like an inefficiency > somewhere in Cygwin's POSIX emulation. Cygwin's fstat() is slow. That's a known situation brought on by the POSIX definition of the function. Fstating stuff across a slow link is simply going to exacerbate the problem. > Other than "RTFSC", > does anyone have any ideas what I could do (workarounds, etc) > so that I can run scripts in a reasonable amount of time? > (Might this have anything to do with my share being non-writable?) > The obvious is to copy everything to a fast (preferably local) drive/share and do your business there, if that's possible. It might be a win for you even if you did a copy-to-local/modify/copy-back sort of deal, depends on the situation. -- Gary R. Van Sickle -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: Test: zip-2.31 and unzip-5.52
> From: Charles Wilson > Charles D. Russell wrote: > > > I use zip and gzip for backup files, where a bug is unlikely to be > > detected before the problem is catastrophic. Thus I like > to stick to > > old, well-tested versions, and am interested in understanding where > > problems might arise. I would have thought that the cygwin > executable > > would be the same as that obtained by taking the standard source and > > running make. > > > > Do you really think that every cygwin package compiles > out-of-box with no changes? Not even close to true! I think you meant to say something to the effect of, "...every 'standard' source tarball compiles...". All Cygwin packages should of course compile OOB, or there'd be little reason to produce them. To the OP: "Old" != "Well Tested". You should be testing whatever program you're using to do backups, GNU, Cygwin, or otherwise. -- Gary R. Van Sickle -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: Windows 95 support ?
> From: Brian Dessent > > "Gary R. Van Sickle" wrote: > > > Sorry folks, this is going to probably have to wait until > the weekend. > > But I am still about 99.44% confident that this is solvable in a > > reasonably painless manner. > > Don't you think it's sufficient just to leave it at "thou must install > IE3+"? > > Brian It probably is, and that was probably my argument at the time*. But I also believe that if a shortcoming such as this can be solved in a simple and non-intrusive manner, it should be solved. I think I now have that solution, so I'm gonna give it a go. -- Gary R. Van Sickle * Assuming I actually argued for this; I frankly can't recall if I was pushing for it or not. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: Windows 95 support ?
> From: Gary R. Van Sickle > > > From: Samuel Thibault > > > > Gary R. Van Sickle, le Mon 24 Apr 2006 23:20:55 -0500, a écrit : > > > > > > http://home.att.net/~g.r.vansickle/cygwin/SetupInstaller/SetupInstalle > > > r.exe > > > > Same result as when I manually copied MSVCRT.DLL to my system for > > getting the usual setup.exe running: when I type setup.exe from > > c:\cygwin\setup, the mouse cursor turns into a sandglass, > then back to > > a normal arrow shape, and I get the command.com prompt > again without a > > single message. I tried setup.exe /h, /?, same result. > > > > Regards, > > Samuel > > Hmmm. That's good info though, it means that > SetupInstaller.exe is able to do its thing at least. Reading > the rest of the thread (and dusting off the ol' grey matter > archives) it's clear this is in fact (at a minimum) a > comctl32 version dependency issue. I think I can still fix > this without too much trauma... tomorrow. > > Thanks for all the testing Samuel. > > -- > Gary R. Van Sickle Sorry folks, this is going to probably have to wait until the weekend. But I am still about 99.44% confident that this is solvable in a reasonably painless manner. -- Gary R. Van Sickle -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: Windows 95 support ?
> From: Samuel Thibault > > Gary R. Van Sickle, le Mon 24 Apr 2006 23:20:55 -0500, a écrit : > > > http://home.att.net/~g.r.vansickle/cygwin/SetupInstaller/SetupInstalle > > r.exe > > Same result as when I manually copied MSVCRT.DLL to my system > for getting the usual setup.exe running: when I type > setup.exe from c:\cygwin\setup, the mouse cursor turns into a > sandglass, then back to a normal arrow shape, and I get the > command.com prompt again without a single message. I tried > setup.exe /h, /?, same result. > > Regards, > Samuel Hmmm. That's good info though, it means that SetupInstaller.exe is able to do its thing at least. Reading the rest of the thread (and dusting off the ol' grey matter archives) it's clear this is in fact (at a minimum) a comctl32 version dependency issue. I think I can still fix this without too much trauma... tomorrow. Thanks for all the testing Samuel. -- Gary R. Van Sickle -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: Windows 95 support ?
> From: Brian Dessent > > "Gary R. Van Sickle" wrote: > > > Looking through the source tarball brings up another issue though: > > there's no copy of the GPL included with the source, nor > could I find > > one pending in cvs for an upcoming release. I took the liberty to > > include a copy in SetupInstaller.exe; it gets installed in the > > installation directory as "LICENSE_FOR_SETUP_EXE". Doesn't help > > anybody downloading the sources though > > I added a copy of the GPL as COPYING to CVS just now. Excellent, thanks Brian. > I hope > that's kosher -- the project was always licensed that way > anyway per the headers on each file. > > Brian Right, no, I didn't mean to imply that it wasn't covered properly, just perhaps a bit incompletely. The source anyway - it still seems to me that the EXE needs at least a notice of some sort. -- Gary R. Van Sickle -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: Windows 95 support ?
> From: Brian Dessent
> "Gary R. Van Sickle" wrote:
>
> > locate said source. However, it is not where this page <
> > http://sources.redhat.com/cygwin-apps/setup.html> indicates it is
> > ("Source code for setup.exe is available from
> > http://cygwin.com/setup/."; - no, it isn't, at least not for
> > 2.510.2.2). Nor is there any identifiable tag in
>
> I thought I took care of this a long time ago but apparently
> I neglected it. The source is now in that location.
>
> Brian
Great, thanks Brian. It is now on my FTP site as well, along with the
awesomeness that is SetupInstaller:
http://home.att.net/~g.r.vansickle/cygwin/SetupInstaller/SetupInstaller.exe
http://home.att.net/~g.r.vansickle/cygwin/SetupInstaller/setup-2.510.2.2.tar
.bz2
Looking through the source tarball brings up another issue though: there's
no copy of the GPL included with the source, nor could I find one pending in
cvs for an upcoming release. I took the liberty to include a copy in
SetupInstaller.exe; it gets installed in the installation directory as
"LICENSE_FOR_SETUP_EXE". Doesn't help anybody downloading the sources
though
--
Gary R. Van Sickle
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
RE: Windows 95 support ?
> From: Eric Blake
>
> Gary - you should know better.
No I shouldn't.
> Top-posting reformatted, to
> avoid http://cygwin.com/acronyms/#TOFU,
OMG I did top-post! How the ^*& did that happen? My sincerest apologies.
> and raw email munged;
> you really should http://cygwin.com/acronyms/#PCYMTNQREAIYR.
>
I still have yet to hear an offical judgement on whether this applies to
addresses of the actual lists. I see no reason for it to. And I think we
can both agree that in any case, the top-posting is the far more heinous
crime.
> >
> > > -Original Message-
> > > From: cygwin-owner AT cygwin DOT com
> ^
> > > >
> > > > I have a w95 qemu image which I can use for testing, yes.
> > > >
> > >
> > > Excellent, I'll try and get something together tonight.
> > >
> > Ok Sam, give it a try:
> >
> >
> http://home.att.net/~g.r.vansickle/cygwin/SetupInstaller/SetupInstalle
> > r.exe
> >
> > This installer contains the latest released Cygwin setup.exe
> > (2.510.2.2) and msvcrt.dll version 6.0.9782.0, which AFAIK is the
> > latest redistributable available. It won't overwrite a
> newer version of either the exe or the DLL.
> > Works great for me on XP here.
> >
> > There'd be source for setup.exe 2.510.2.2 here as well if
> it was here:
> > http://www.cygwin.com/setup/ or somewhere else that I could find it.
>
> setup.exe is under the GPL.
Yep. I GPLed a bunch of it myself. You're welcome.
> In order for you to distribute a
> version of setup.exe on your website, you must also offer to
> distribute the sources you used to build it. I also hope you
> didn't violate the GPL by including msvcrt.dll in your
> binary;
As do I, since that would truly cause a rift in the spacetime continuum.
> but I will leave that to an actual lawyer to
> determine if you are in violation.
>
Meh, don't waste your money. Three words: Mere aggregation clause.
Since we're getting all licencey today, allow me to point out something any
one of us should have caught long ago: setup.exe as distributed on the
Cygwin web site does not include a copy of the GPL, which, while IANAL, I
believe is a violation of the GPL.
> By my understanding of the GPL, a link on your site pointing
> to
> http://sources.redhat.com/cgi-bin/cvsweb.cgi/setup/?cvsroot=cy
> gwin-apps
> is inadequate -
Which is why I put no such link on my site.
> by publishing the binary yourself, you are
> now obligated to also publish the snapshot of the source you
> used to build your binary.
>
Which, as I indicated in my original email, would already be done if I could
locate said source. However, it is not where this page <
http://sources.redhat.com/cygwin-apps/setup.html> indicates it is ("Source
code for setup.exe is available from http://cygwin.com/setup/."; - no, it
isn't, at least not for 2.510.2.2). Nor is there any identifiable tag in
cvs for it. I would be most grateful if you could point me in the direction
of the source distribution on the Cygwin site for this particular setup.exe
build, or even the appropriate cvs tag, so that both my site and the Cygwin
Setup webpage can be corrected immediately.
In the interim, I shall once again, but perhaps more clearly this time,
exercise my responsibilities under Paragraph 3 Subsection c) of the GPL
Version 2 by making the following statement: "I received the software in
question in binary format, with the offer of obtaining the sources from
http://cygwin.com/setup/. Unfortunately, as the sources are not in fact
located there, nor anywhere else that I have been able to locate, you as the
receiver of this unmodified binary have as much access to its source code as
I do."
Meanwhile Eric, feel free to give my awesome SetupInstaller a try.
> --
> Eric Blake
--
Gary R. Van Sickle
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
RE: Windows 95 support ?
> From: Max Bowsher > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Gary R. Van Sickle wrote: > >> From: Corinna Vinschen > >> Sent: Friday, April 21, 2006 6:38 AM > >> To: cygwin@cygwin.com > >> Subject: Re: Windows 95 support ? > >> > >> On Apr 21 12:59, Samuel Thibault wrote: > > [snip] > >>> Ok, but the question remains: does cygwin still target windows 95? > >> Just the setup tool has some problem, apparently. > >> Cygwin still runs on 95, which will probably change at one point, > >> since it's getting incredibly awkward to support it. > >> > >> > >> Corinna > >> > > > > Perhaps, but as long as the Cygwin DLL etc do support 95, it seems > > that Setup should be self contained and not require W95 users (all > > dozen of them > > ;-)) to hunt down DLLs all over the internet. Perhaps I'll > whip up a > > regular Setup installer which includes the necessary > redistributables. > > Why bother? > Meh, keeps me off the streets. ;-) > To put this in perspective, this affects only users who are > using Windows 95 original edition (*not* any OSR version), > *AND* have not installed a non-ancient Internet Explorer version. > > For this tiny minority, is it *really* worth the confusion of > a separate Cygwin setup bundle, Only if it's confusing, separate, and adds no other value. Check it out and see what you think: http://home.att.net/~g.r.vansickle/cygwin/SetupInstaller/SetupInstaller.exe Erase "Where do I put this darn setup.exe thing?!!?" off the FAQ! ;-) > as compared with the > alternative of just writing a FAQ entry explaining how to get > the necessary prerequisites? > > Max. Well, I could just as easily turn the agument around and ask, "Why bother writing a FAQ entry that only a tiny minority of the tiny minority it applies to is going to read?" But mainly, as I said above, it seems rather silly to me to have Cygwin operate on systems on which it can't be installed. This solves the problem.* -- Gary R. Van Sickle * Assuming Sam or someone else confirms that it works of course. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: Windows 95 support ?
Ok Sam, give it a try: http://home.att.net/~g.r.vansickle/cygwin/SetupInstaller/SetupInstaller.exe This installer contains the latest released Cygwin setup.exe (2.510.2.2) and msvcrt.dll version 6.0.9782.0, which AFAIK is the latest redistributable available. It won't overwrite a newer version of either the exe or the DLL. Works great for me on XP here. There'd be source for setup.exe 2.510.2.2 here as well if it was here: http://www.cygwin.com/setup/ or somewhere else that I could find it. -- Gary R. Van Sickle > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Gary R. Van Sickle > Sent: Monday, April 24, 2006 8:20 AM > To: cygwin@cygwin.com > Subject: RE: Windows 95 support ? > > > From: Samuel Thibault > > Sent: Monday, April 24, 2006 3:51 AM > > To: cygwin@cygwin.com > > Subject: Re: Windows 95 support ? > > > > Hi, > > > > Gary R. Van Sickle, le Mon 24 Apr 2006 02:54:59 -0500, a écrit : > > > Mr. Thibault, do you have any interest in helping test out > > whatever I > > > come up with? > > > > I have a w95 qemu image which I can use for testing, yes. > > > > Regards, > > Samuel > > > > Excellent, I'll try and get something together tonight. > > > -- > Gary R. Van Sickle > > > -- > Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple > Problem reports: http://cygwin.com/problems.html > Documentation: http://cygwin.com/docs.html > FAQ: http://cygwin.com/faq/ > -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: Windows 95 support ?
> From: Samuel Thibault > Sent: Monday, April 24, 2006 3:51 AM > To: cygwin@cygwin.com > Subject: Re: Windows 95 support ? > > Hi, > > Gary R. Van Sickle, le Mon 24 Apr 2006 02:54:59 -0500, a écrit : > > Mr. Thibault, do you have any interest in helping test out > whatever I > > come up with? > > I have a w95 qemu image which I can use for testing, yes. > > Regards, > Samuel > Excellent, I'll try and get something together tonight. -- Gary R. Van Sickle -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: Windows 95 support ?
> From: Corinna Vinschen > Sent: Friday, April 21, 2006 6:38 AM > To: cygwin@cygwin.com > Subject: Re: Windows 95 support ? > > On Apr 21 12:59, Samuel Thibault wrote: [snip] > > Ok, but the question remains: does cygwin still target windows 95? > > Just the setup tool has some problem, apparently. > Cygwin still runs on 95, which will probably change at one > point, since it's getting incredibly awkward to support it. > > > Corinna > Perhaps, but as long as the Cygwin DLL etc do support 95, it seems that Setup should be self contained and not require W95 users (all dozen of them ;-)) to hunt down DLLs all over the internet. Perhaps I'll whip up a regular Setup installer which includes the necessary redistributables. Mr. Thibault, do you have any interest in helping test out whatever I come up with? I haven't had access to a Win95 machine since... well, pretty much forever in PC-years, so the only testing I could do myself would be that it doesn't wreck anything with XP Pro and Home, and maybe ME if I can ressurect that machine. -- Gary R. Van Sickle -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Arbitraily Banning Maintainers From Mailing Lists Which They Need To Perform Their Duties
[Follow-ups set to cygwin@, since the arbitrary banning of maintainers, or anyone else for that matter, from Cygwin mailing lists is most certainly of grave concern to the Cygwin community at large.] > From: Christopher Faylor > Sent: Thursday, April 20, 2006 1:12 AM > To: [EMAIL PROTECTED] > Subject: A banner day > > Tonight, it occurred to me that I have banned three people in > the course of my tenure as admin for the cygwin mailing list. > All of them repeatedly ignored my request to stop sending > off-topic messages in one form or another. Usually, these > people just couldn't stop sending personal details of their > lives but there was, IIRC, one person who was somewhat abusive. > > I gave each of these people 3 or 4 warnings before blocking > them and, when I did block them, it was with a sick feeling > in my heart even though I felt it was necessary. Two of > those people are back today and sending email to cygwin lists > with no problem. > > Usually when I block someone, I block them from all of the > cygwin lists. > But, tonight, I have chosen to only block Gary R. Van Sickle > from the cygwin-apps list. Maybe when I wake up tomorrow, I > will conclude that this was a big mistake because, after all, > Gary does sometimes provide useful technical feedback. > > Tonight, however, it just seems to make sense that, in > fairness to other people who have been banned, there was no > reason to have to suffer with someone who repeatedly and > determinedly breaks the mailing list rules. > > I have refrained from this action for a long time because I > knew that it would seem like a non-objective personal > response and, again, maybe when I wake up tomorrow it will > seem like that to me again. But, we'll see... > > Anyway, if anyone has a problem with my decision, feel free > to send me private email (me+cygwin-apps at cgf dot cx) to > discuss it. I promise to listen calmly and respond > rationally as long as you don't use the words "no personal > offense intended". I'll even listen if you think I need to > block myself from all cygwin lists since I know I'm no saint. > That's another thing that has kept my finger away from the > "ban" button for so long... > > cgf Let me see if I have the order of events straight here: 1. You reply to one of my posts on cygwin-apps@ suggesting that the thread be moved to a more appropriate list [http://cygwin.com/ml/cygwin-apps/2006-04/msg00109.html]. You however neglect to change the followups accordingly [ibid., "Reply-to: cygwin-apps at cygwin dot com"]. 2. I reply to your reply [http://cygwin.com/ml/cygwin-apps/2006-04/msg00112.html], but take care to in fact set the followups properly, so that the thread will indeed get moved to the more-appropriate list, i.e. cygwin-talk@ [ibid., "Reply-to: "]. 3. You then reply to that reply - but not in the cygwin-talk@ list which I had redirected the thread to. Rather, you bring the thread /back/ into cygwin-apps@, only to inform me that you are /banning/ me from that mailing list [http://cygwin.com/ml/cygwin-apps/2006-04/msg00113.html] for doing the very thing YOU should have done in the previous message! Furthermore, you have also changed the followups of the thread /back/ to cygwin-apps@ [ibid., "Reply-to: cygwin-apps at cygwin dot com"]! 4. You then post an announcement to cygwin-apps@ that, due to your decision to ban me from cygwin-apps@, I have been, by definition, relieved of my voluntary duties as mutt maintainer [http://cygwin.com/ml/cygwin-apps/2006-04/msg00115.html] and a new one is required. A minor point: one would think such a call would also go out to [EMAIL PROTECTED] 5. Finally, you post the above to, of all places, /cygwin-talk@/. Do I have the sequence of events correct? I took considerable pains to get the facts laid out as accurately and precisely as possible, but if I have somehow made an error in the above I emplore you Mr. Faylor or anyone else to correct this chronology. Wow. I have to admit, I'm having an especially hard time getting my mind around #3 there. What sort of thought process sees me redirecting a thread to a more appropriate venue, decides to ban me from the orginal list for doing so, and /then/ proceeds to redirect the conversation /right back to where, by the agreement of both parties, it didn't belong/? Beyond that, how is that /not/ the very transgression you baselessly accuse /me/ of, only worse seeing as you had to manually do all that "misthreading"? And yet, you are not content to merely accuse, but immediately pass summary judgement upon?! I shall make no comment regarding your statement about "block[ing] myself from all cygwin lists since I know I'm no saint". It
RE: [NON-WHINE] RE: mkstemp vs. text mode
More non-negative news: The Cygwin/X Server creates its own subdirectory and a bunch of files in /tmp and still appears to work fine. -- Gary R. Van Sickle > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Gary R. > Van Sickle > Sent: Wednesday, April 19, 2006 8:56 PM > To: cygwin-patches@cygwin.com > Cc: cygwin@cygwin.com > Subject: [NON-WHINE] RE: mkstemp vs. text mode > > > From: Gary R. Van Sickle > > > > > From: Gary R. Van Sickle > > > > > > > From: Christopher Faylor > > > [snip] > > > > Yes, I think it makes sense to open temp files in binary > > > but I'll bet > > > > that someone is relying on textmode behavior. > > > > > > I'll see that bet and raise you; I'll bet this results in massive > > > problems. > > > > > Welp, looks like I (probably) lose that hand (happily). Using: > > CYGWIN_NT-5.1 DFW5RB41 1.5.20s(0.155/4/2) 20060418 12:31:05 > i686 Cygwin > > with a /tmp mounted as text mode works fine for a configure, > build, and install of wxWindows. The configure does most of > the temp file machinations, with about 2000 add, modify, and > remove events in the /tmp directory, as reported by a program > I have for monitoring such things. > > -- > Gary R. Van Sickle > -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
[NON-WHINE] RE: mkstemp vs. text mode
> From: Gary R. Van Sickle > > > From: Gary R. Van Sickle > > > > > From: Christopher Faylor > > [snip] > > > Yes, I think it makes sense to open temp files in binary > > but I'll bet > > > that someone is relying on textmode behavior. > > > > I'll see that bet and raise you; I'll bet this results in massive > > problems. > > Welp, looks like I (probably) lose that hand (happily). Using: CYGWIN_NT-5.1 DFW5RB41 1.5.20s(0.155/4/2) 20060418 12:31:05 i686 Cygwin with a /tmp mounted as text mode works fine for a configure, build, and install of wxWindows. The configure does most of the temp file machinations, with about 2000 add, modify, and remove events in the /tmp directory, as reported by a program I have for monitoring such things. -- Gary R. Van Sickle -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: The 20060324/20060326 snapshots hang on testcase
> From: Dave Korn > Sent: Monday, March 27, 2006 5:00 AM > To: cygwin@cygwin.com > Subject: RE: The 20060324/20060326 snapshots hang on testcase > > On 27 March 2006 04:04, Volker Quetschke wrote: > > > The newest 20060324/20060326 snapshots started to hang on the > > following testcase. Note, I only tried the following versions: > > > > release 1.5.19 no hang > > snapshot 20060306 no hang > > snapshot 20060324 hangs > > snapshot 20060326 hangs > > CVS 20060317: no hang. > > [ Just to help refine the search a bit. ] > Ahem, without resolution to the minute that's going to help how again? -- Gary R. Van Sickle -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: Multiple cygwin installs
> From: Larry Hall (Cygwin) > Sent: Sunday, March 26, 2006 10:42 PM > To: cygwin@cygwin.com > Subject: Re: Multiple cygwin installs > > Brian Hawkins wrote: > > Just FYI. I found a pretty good way to manage multiple > cygwin installs. > > > > I use the windows subst command. > > > > It works like this. Create a directory c:\cyginstalls. > Then beneath > > it create a directory for each cygwin install you want like cygwin1, > > cygwin2 whatever. Then use the subst command like so: > > subst x: c:\cyginstalls\cygwin1 > > > > Now install cygwin to x:\. Change the subst to > c:\cyginstalls\cygwin2 > > and install again to x:\. > > > > To choose what cygwin you use just subst x to the > appropriate folder. > > Kind of a poor mans symbolic link. > > Why are you commandeering one thread to inject another? If > you have something you want to say and it has nothing to do > with any previous thread, just start a new one by sending > email to the list. > > The flaw that I see with your approach is that you're not > taking into account any existing mounts in the mount table. > Without resetting the mount table in between each > installation, you will very likely end up with subsequent > installations overwriting the first one. I've probably said this a dozen times before, but there is in fact a proper way to do this (There Can Be Only One-style library installs, not "swapping versions" which is inherently wrong). The GTK folks even use it. It's called "C:\Program Files\Common Files", or CSIDL_PROGRAM_FILES_COMMON in CSIDL-speak. You make your own subdirectory, ala "C:\Program Files\Common Files\Cygwin", and put the DLLs or what have you in there. You make sure that it gets reference counted, that your Cygwin apps can find it (eg put it in the Windows PATH), and you're done. To keep versions dealt with correctly, you probably want to use InnoSetup or Windows Installer to deal with that. -- Gary R. Van Sickle -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: The 20060324/20060326 snapshots hang on testcase
> From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Christopher Faylor > Sent: Sunday, March 26, 2006 9:54 PM > To: cygwin@cygwin.com > Subject: Re: The 20060324/20060326 snapshots hang on testcase > > On Sun, Mar 26, 2006 at 10:34:42PM -0500, Christopher Faylor wrote: > >On Sun, Mar 26, 2006 at 10:03:57PM -0500, Volker Quetschke wrote: > >>The newest 20060324/20060326 snapshots started to hang on the > >>following testcase. Note, I only tried the following versions: > >> > >>release 1.5.19 no hang > >>snapshot 20060306 no hang > >>snapshot 20060324 hangs > >>snapshot 20060326 hangs > > > >How about narrowing it down a little? I have been keeping more > >snapshots around so that it's easier to do that sort of thing. > > Nevermind. It dawned on me what the problem probably was. > > However, if you had narrowed this down to a specific failing > snapshot or mentioned where it was hanging or what it was > trying to do, I would have been able to figure this out much faster. > > cgf > Faster than 19 minutes? Wow! -- Gary R. Van Sickle -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: bash, find | xargs grep
> Hi: > > (tried posting this to the comp.windows.cygwin usenet group > and got no response, so) > There's a comp.windows.cygwin USENET group? When did that happen? -- Gary R. Van Sickle -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: _kbhit
> From: Shankar Unni > Sent: Friday, February 17, 2006 2:28 PM > To: cygwin@cygwin.com > Subject: Re: _kbhit > > Gary R. Van Sickle wrote: > > > Arend-Jan Westhoff writes: > >> I cannot confirm your assertion that msvcrt.dll and cygwin1.dll > >> cannot be used together. > > > The Gary Exclusion Principle: Two C runtimes cannot occupy > the same > > point in space at the same moment in time. > > The problem here is that unfortunately they *can* occupy the > same point in space at the same time, with the same bad > effects as in science fiction movies when one object > materializes in the middle of another :-). > Exactly: Attempting to violate the Gary Exclusion Principle can only result in tragedy. In this case, the computer turns into a particle so dense not even light can escape. > The problem is that, for instance, some of your malloc calls > will link to the cygwin libc, while others (from within the > Windows DLLs) will link to MSVCRT, and if you free the > pointer with the "other" library, terrible things will happen. Ah yes, the Gump Uncertainty Principle: You never know which malloc you're going to get. -- Gary R. Van Sickle -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: _kbhit
> > I cannot confirm your assertion that msvcrt.dll and > cygwin1.dll cannot be used together. If I compile the > attached (almost C) file that dynamically links to msvcrt.dll > using Cygwin: > gcc -o kbhit.exe kbhit.cpp > it compiles, links and works (on CMD and bash on CMD but not > on rxvt; as stated elsewhere in this thread the Microsoft > _kbhit is not very good). > > HTH, > > Arend-Jan Westhoff. The Gary Exclusion Principle: Two C runtimes cannot occupy the same point in space at the same moment in time. A corollary to that: "Worked" and "Works" are not the same thing. -- Gary R. Van Sickle -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: BUG: ualarm(0,0) not clearing ualarms
> From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Robb, Sam > Sent: Tuesday, February 14, 2006 10:09 AM > To: cygwin@cygwin.com > Subject: RE: BUG: ualarm(0,0) not clearing ualarms > > Gary R. Van Sickle wrote: > > I get the same can't-duplicate as Chris does, on 'uname -a'= > > > > CYGWIN_NT-5.1 DFW5RB41 1.5.20s(0.153/4/2) 20060209 14:37:47 > > i686 Cygwin > > > > I don't have any of this stuff in $CYGWIN, might be worth a try to > > ditch it: > > > > " > > CYGWIN = 'server ntsec forkchunk:32768' > > " > > Chris, Gary, et al, > > I'm able to reproduce this on my machine, but only when I'm > running it under rxvt. If I run it from cmd.exe or within a > standard cygwin bash shell, then it completes without the > '-- BOGUS ALARM --' warnings. > > $ uname -a > CYGWIN_NT-5.0 claus 1.5.19(0.150/4/2) 2006-01-20 13:28 i686 Cygwin > > $ gcc -o ua-test ua-test.c > > $ ./ua-test.exe > First ualarm - one shot > Second ualarm - one shot > Last ualarm - repeats 3 times > Clearing ualarm > Sleeping > --- BOGUS ALARM --- > --- BOGUS ALARM --- > Done > > -Samrobb Rxvt here too, but no problems. WinXPSP2+EveryPossibleUpdate btw. -- Gary R. Van Sickle -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: How Can I Use the FtpCommand Function with Cygwin?
> From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Tischler, Ron > Sent: Tuesday, February 14, 2006 12:44 PM > To: cygwin@cygwin.com > Subject: RE: How Can I Use the FtpCommand Function with Cygwin? > > These makefiles are large, and they came to us from another > company, and there are good business reasons to avoid > changing them. Saying that the makefiles are going about > everything the wrong way is not an option. > Sometimes failure is not an option; it comes standard. -- Gary R. Van Sickle -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: BUG: ualarm(0,0) not clearing ualarms
[snip] > >I get the same can't-duplicate as Chris does, on 'uname -a'= > > > >CYGWIN_NT-5.1 DFW5RB41 1.5.20s(0.153/4/2) 20060209 14:37:47 > i686 Cygwin > > > >I don't have any of this stuff in $CYGWIN, might be worth a > try to ditch it: > > > >" > >CYGWIN = 'server ntsec forkchunk:32768' > >" > > Btw, I have a hyperthreaded machine running at 3.06G with 1G > of RAM. I wouldn't expect that to make a difference in this > case, though. I can't see how this could be a N-processor > race-related bug. > > cgf Hyperthreding P4 3.4GHz "X-Treme Edition" (more cache?), 1Gig RAM. Maybe this is the one bug that HT actually masks instead of reveals. ;-) -- Gary R. Van Sickle -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: BUG: ualarm(0,0) not clearing ualarms
> From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Jerry D. Hedden > Sent: Monday, February 13, 2006 1:58 PM > To: cygwin@cygwin.com > Subject: RE: BUG: ualarm(0,0) not clearing ualarms > > > Original Message > > From: Christopher Faylor <[EMAIL PROTECTED]> > > > > Thanks for the test case but I don't see any difference in > operation > > between cygwin and linux when I run it: > > I know that Perl version of the bug occurred on both my work computer > (Win2K) and home computer (WinXP) both using the lastest Cygwin DLL. > The C code I sent, produced the bug on my work computer. > I'll try my home computer this evening. I get the same can't-duplicate as Chris does, on 'uname -a'= CYGWIN_NT-5.1 DFW5RB41 1.5.20s(0.153/4/2) 20060209 14:37:47 i686 Cygwin I don't have any of this stuff in $CYGWIN, might be worth a try to ditch it: " CYGWIN = 'server ntsec forkchunk:32768' " -- Gary R. Van Sickle -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Gmsh Using Cygwin "Badly"
I just ran across a program, Gmsh (http://www.geuz.org/gmsh/, "an automatic 3D finite element grid generator (primarily Delaunay) with a build-in CAD engine and post-processor"), that does the "multiple cygwin1.dll's" thing. While the README acknowledges the issue, it offers the following incorrect advice on dealing with the situation: "2) About cygwin1.dll: If you plan to use other programs than Gmsh that depend on the cygwin1.dll library, you should keep only one version of this library on your system (i.e., move cygwin1.dll to the Windows system directory--usually C:\Windows\System\--and suppress all other versions of cygwin1.dll). Failing to do so may result in an incorrect behavior of applications sharing the library and running simultaneously." Gmsh folks: Putting cygwin1.dll in "C:\Windows\System\" is bad, don't do it, and don't recommend it to people. Just having cygwin1.dll in your path is sufficient. -- Gary R. Van Sickle -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: gnu make causes reboot
Dude: The problem is a driver. You can reinstall Windows as many times on as many different partitions as you want, or you can update all your drivers, yes, each and evry one of them, and solve your problem. The second option takes far less time, plus you solve your problem. It's win-win. Bonus hint: Norton Antivirus counts as both a driver and the cause of almost every problem anybody has ever had with a computer, except for those caused by all other anti-anything software. -- Gary R. Van Sickle > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of cc979.uk > Sent: Saturday, February 11, 2006 5:47 AM > To: cygwin@cygwin.com > Subject: Re: gnu make causes reboot > > > sorry about not attaching cygwin results > > i've just installed windows on a new-partion > > no outpost firewall or nod32 antivirus and cygwin works > perfectly, so i'm going install them one at a time and try > again do see what causes the bsod > > > -- > View this message in context: > http://www.nabble.com/gnu-make-causes-reboot-t1102615.html#a2884464 > Sent from the Cygwin Users forum at Nabble.com. > > > -- > Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple > Problem reports: http://cygwin.com/problems.html > Documentation: http://cygwin.com/docs.html > FAQ: http://cygwin.com/faq/ > -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: _kbhit
> From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Michiel De Hoon > Sent: Friday, February 10, 2006 5:58 PM > To: cygwin@cygwin.com > Subject: Re: _kbhit > > > On Sun, Feb 05, 2006 at 01:17:33PM -0500, Michiel De Hoon wrote: > > >For one of my software projects, I need the _kbhit > function to check > > >the console for keyboard input. While this function is present in > > >msvcrt.dll, > it > > >is missing from cygwin1.dll, so I started writing this function > > >myself > (I'm > > >hoping to contribute it to Cygwin if it works well). > > > > I really appreciate the sentiment of submitting code but > _kbhit is not > > a linux function (or POSIX, POSIX, POSIX... off>) so it > > really isn't a candidate for inclusion in the Cygwin DLL. > > > > cgf > > > Even though _kbhit is not a POSIX function, I think a valid > argument can be made to include it in Cygwin anyway. > > First, some Cygwin programs will need this function to be > able to interact with the Windows OS. That's simply not true. They may *want* it so that they can interact with cmd.exe, in which case they're not a "Cygwin program". > Second, as the Cygwin > DLL is a replacement for msvcrt It isn't intended to be that. It's intended to be a POSIX-compliant C runtime. Sorry, I meant "Linux compliant". > (and msvcrt.dll and > cygwin1.dll cannot be used together), developers may expect > to find the same functionality in cygwin1.dll as in msvcrt.dll. They shouldn't expect that. Even Microsoft agrees; that's why they put the "_" on there. > Whereas it is possible for each developer to add needed > functions missing in cygwin1.dll to their own source code, it > will lead to ugly #ifdef __CYGWIN__ statements and complicate > porting Windows programs to Cygwin (which is what I am > effectively doing). Finally, coding the _kbhit function is > not entirely > straightforward: simply doing a select() on file descriptor 0 > is inconsistent with _kbhit in msvcrt if stdin is redirected. > If you're using _kbhit, I have to assume what you're trying to port is some sort of DOS or Windows app with one of those glorious text-mode "GUI"s to Cygwin. If so, you're in luck: The Unix world has obsessively perfected the Frankensteinian paradox of the Text-Mode GUI. You want to look into ncurses. Using it, your app's TMGUI(tm) will run on everything from an ancient VT05 terminal to the very latest multi-bajigahertz quad-banger double-headed workstation running a VT05 terminal emulator! WE CALL THIS "PROGRESS"! (Note: I am not making fun of your app, but rather 21st-century text-mode GUIs in general) > So, if I was able to convince you, I'd be happy to > submit a patch. If not, ... well for my own project a kbhit() > function based on select() is sufficient, so that'll work for > me at least. > You may also want to look at MinGW. They actually link with the real msvcrt.dll. > --Michiel. > > Michiel de Hoon > Center for Computational Biology and Bioinformatics Columbia > University 1150 St Nicholas Avenue New York, NY 10032 -- Gary R. Van Sickle -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: make: rm: command not found
> From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Christopher Faylor > Sent: Friday, February 10, 2006 1:38 PM > To: cygwin@cygwin.com > Subject: Re: make: rm: command not found > > On Fri, Feb 10, 2006 at 07:36:39PM +, Chris Taylor wrote: > > > >Ah, but it would have added bonus of stopping them from bitching at > >everyone on this list - they wouldn't be able to ;) > > > >Maybe it could force the OS wrapping to *BSD or Linux? :P > > That would be a nice goal but, in practice, it usually seems > to stop wrapping once it hits MS-DOS 4.0. I don't know why. > I think it was because they couldn't get the Installable File System thing working properly. Which is truly shocking really, considering Microsoft's otherwise-blemishless reputation when it comes to getting all things file system spot-on. "What, Me Read-Only?" -- Gary R. Van Sickle -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: cygwin bsod using make after configure on gcc
> From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of c c > Sent: Thursday, February 09, 2006 5:50 PM > To: cygwin@cygwin.com > Subject: cygwin bsod using make after configure on gcc > > i've recently installed cygwin - i'm new to this so excuse me > if i'm in error > > after using configure on gcc-4.0.2, run make and my pc bsod's > > i'm using windows xp sp2 Windows XP BSODs for a number of reasons, none of them Cygwin-specific. I list them here in decreasing order of liklihood: 1. An uninstalled "Windows Update". 2. A faulty driver. 3. A defect in XP for which Microsoft offers no patch at the present time. 4. Faulty hardware. 99% of the time its 1 or 2, 1% of the time 3 or 4. The only other help anybody can offer is to look at the BSOD info. It used to tell you what kernel mode component was BSODing on you, but to tell you the truth it's been so long since I've seen one I don't know if it does anymore. If it does, it will probably be a driver, and then you're 99% of the way towards a solution. Hey, this would make a reasonably good Not-Entirely-Infrequently-Asked-Question. -- Gary R. Van Sickle -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: stat(2) triggers on-demand virus scan
> From: Brett Serkez > Sent: Saturday, January 14, 2006 3:19 PM > To: cygwin@cygwin.com; cygwin@cygwin.com > Subject: Re: stat(2) triggers on-demand virus scan > > > On Sat, Jan 14, 2006 at 03:35:17PM -0500, Brett Serkez wrote: > > >I'm still researching, I was going to respond this is posting at a > > >later time with more insight, but before things get out-of-hand, I > > >wanted to jump in. I suppose I'm still hopeful that we > can zero in > > >on what precisely is causing the on-demand scanners to consume so > > >much CPU. Since Windows programs don't trigger the same level of > > >response (or atleast they don't appear to) their must be > some change > > >that can be made. > > > > I just wanted to make it clear that we aren't going to be > making any > > special concessions to a product like a virus scanner which cause > > perfectly acceptable code to misbehave. If that is the > case then it > > is a situation for the virus scanner to work out. It's not a > > requirement that cygwin work around things like this. > > Well, that is a pretty strong statement, I'd expect from a > for-profit company run by corporate management. ZoneLabs > offical stance is that they don't support emulated > environments. I have to assume whoever said or wrote that was either thinking "Wine", or not thinking at all, since Cygwin is ultimately no different than any other Windows application from their software's perspective. > Humm... So if neither are willing to change, > then what? I don't know Symantec's or McAfee's offical stance. > Last I checked it was "cause more problems than the viruses we purportedly protect you from would". Look guys, the bottom line here is that on-access virus scanners cause trouble. Not just for Cygwin, and not just particular ones. Scan your incoming email, scan your downloads, do your backups, cross your fingers, and hope for a horrible death for the virus-writing idiots of the world. -- Gary R. Van Sickle -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: stat(2) triggers on-demand virus scan
> From: Paul McFerrin > Sent: Saturday, January 14, 2006 5:19 PM > To: Cygwin@Cygwin.com > Subject: Re: stat(2) triggers on-demand virus scan > > Boy did I open a can of worms! > No, it's like this on a regular, periodic basis. > When I looked at the source of Cygwin1.dll a few years ago at > the time, the stat(2) basically called a MS API function to > retreive the information and then did a simpe return. > I think it the faulty design of MS not to privide a > function to get status information without triggering all > sorts of other OS's overhead (e.g. on-demand scanning). > > If the stat(2) is following the MS SDK guidelines for POSTIX ...um, POSIX. It's POSIX. > compatability, then I don't see much other attractive > recourse but live with MS supid design. What Chris F. said. Plus, while I refuse to defend the ability of MS's Operating Systems to properly work with Disks (admittedly it's a new thing for them), stat's definition and/or the way many programs use stat is the real culprit here. > After it *is* MS. > Unless there is some obsolete non-POSTIX MS API that > retrieves this information that does not have this side > effect, then I'll live with it. It does seem silly to me > that you can't perform a > stat(2) without triggering side effects. Maybe I'm too much > of a Unix Geru. > > Here is something a little OT > > When making comparisons between multiple runs to run timing > tests before and after a change, it there a way I can > guarantee more consistent results? e.g. Condider the following: > > time find . -print | wc -l > > I can run the above sequence 3 times in a row and get huge > differences due to OS caching and probably application > caching (281 secs, 11 secs, 0.8 secs respectively). Is there > any known way within MS XP Pro to flush all caching other > than a reboot?? The short non-rant answer to that is no, there isn't. The long non-rant answer would require a logical explanation from Microsoft as to why their filesystem infrastructure is completely incapable of properly handling removable media, and that is highly unlikely to be forthcoming. -- Gary R. Van Sickle -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
