Re: two instances of a.exe on dual processor - still only 50% performance
At 01:24 PM 7/7/2004, Rolf Campbell wrote: Brian Dessent wrote: mathiasdotwagneratphilipsdotcom wrote: Many thanks for this tip. I tried it out and indeed there is a Set Affinity option in the Taskmanager. Apparently, this option lets you assign one or more of the 4 virtual processors to a particular task. (W2K seems to have this concept of virtual processors, I am no expert at all here). But it doesn't change a thing. still 50% are spent on Idle mode... You see 4 CPUs because of HyperThreading. A HT CPU registers with the OS as two CPUs, but it's not. Only in certain circumstances can it run two threads concurrently (such as performing an integer and floating operation at the same time.) Thus 50% CPU usage means that your system is fully loaded. On a HT system you've got to double all the CPU usage percentages for it to make sense. Occasionally you might see it surpass 50%, which would mean that the hyperthreading is particularly suited to whatever combination of instructions is being executed and it's using the CPU more efficiently. Brian Sorry Brian, that is bogus. I'm running one HT processor right now. The combined CPU utilization is not an actual display of usage, but theoretical usage, based on scheduling. It's really how much of the CPU was NOT being used by the idle task, and given that there is only one CPU, if some process is taking up 99% of it, and some other process takse up the other 1% on the other 'hyper thread' then the idle task will not be able to run at all on either virtual cpu. Thus Task Manager will (and does) show 100% dual CPU utilization. Now, Mathias's problem: Sounds like your program is bound by something other than CPU. If you have two programs that try to access the hard-disk, they are not going to be twice as fast with 2 CPUs (virtual or not). -Rolf Sorry Rolf, but at least on my HT processor running Windows XP pro, the reporting of utilization by task manager is exactly as described by Brian. -- 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: Cygwin Package List search does not work
Make sure your browser has cookies enabled for the site and it should work -Original Message- Of Dennis G. Wicks Sent: Thursday, April 08, 2004 11:28 AM Subject: Cygwin Package List search does not work The Search Package List: function on the Cygwin Package List (http://www.cygwin.com/packages/) does not work. It returns HTTP 404 - File not found when it attempts to access http://cygwin.com/cgi-bin2/package-grep.cgi?grep=cygp; -- 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: Bogus assumption prevents d2u/u2d/conv/etal working on mixed files.
I don't think the behavior should be changed. d2u stands for dos to unix which means \r\n to \n. Why would one expect a dos to unix utility to convert mixed line terminator files. If you need such a utility, then add one but don't take a utility that does dos to unix and try to turn it in to anything to unix or if you do then change the name. Just my 2 cents worth -Original Message- From: Charles Wilson Sent: Monday, April 05, 2004 12:33 AM Subject: Re: Bogus assumption prevents d2u/u2d/conv/etal working on mixed files. David Fritz wrote: You guys are missing the point. Charles Wilson mentioned a side effect of the code at issue in the original post and suggested that it was valuable. I think there is some misunderstanding about the cygutils package. I did not write any of it.(*) I do not defend any of the design decisions that were made by the original coders; it's no skin off my nose -- so comments like It should according to the thinking in this thread. fail to move me -- except as a data point that GVanSickle really REALLY dislikes the current behavior.g (*) Well, maybe the hexdump program or the silly ascii chart, but it's been so long I don't remember anymore. The d2u/u2d progs were some code I thought, back in the dawn of time, would be useful on the cygwin platform -- at least *I* had need of a dos2unix converter all the time. So I found the code, adapted it, and put it in my kit, which was called the misc package back then. Now, I remember, when first porting the code for cygwin, wondering WHY it did certain things certain ways -- especially the check the first line and bail out stuff. All I could figure, at the time, were the two reasons I posted in this thread. I never said I agree with those reasons -- personally, I hate 'rm -i' and the like. But *I am not willing* to unilaterally change behavior of tools that may adversely affect users, without a damn good reason. Unfortunately, it offends a single user's sensibilities -- even mine -- doesn't quite rise to that level. And THAT's why I asked for more discussion. I'm getting the feeling that a preponderance of users -- at least, the ones actually responding to this thread -- dislike the current behavior, or at least wouldn't mind a change away from the current Microsoft-Bob-like behavior. I'd like to see what some other users, who haven't yet stated their opinions, have to say... -- Chuck -- 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: bash incorrectly determines HOME and HOMEDRIVE
I don't think this is really a bash issue. I think HOMEDRIVE is actually set by XP and bash is just importing it. Cygwin has a default for NOME if it is not set but it is unlikely to be what you desire. Just set the environment variable HOMEDRIVE to 'H:' and it will do exactly what you wish. The correct procedure on Cygwin is to manually set the environment variables to whatever you wish them to be Ken -Original Message- Ralf G. R. Bergs Sent: Thursday, March 25, 2004 3:42 PM Subject: bash incorrectly determines HOME and HOMEDRIVE [Please CC: me in your replies, since I'm not subscribed to this list. I will post a summary if I receive enough response.] Hi there, I've a quite unusual setup on my XP box since my profile directory is NOT on the XP system drive. I moved it from there onto a separate partition. ALL Windoze apps are happy and succeed to determine the correct profile path when storing application data, but Cygwin fails. :-( My system drive is E:, and Cygwin incorrectly sets HOMEDRIVE to E: and HOME to E:\Documents and Settings\rabe. The correct location of HOME is H:\Documents and Settings\rabe, so HOMEDRIVE should be set to H:. I've manually set the correct values in XP's System Properties - Environment Variables. That makes HOME appear correctly in a bash, but HOMEDRIVE is still incorrect (E:). I suspect it's a bug in bash. Can anyone check whether my assumption is correct? Thanks, Ralf -- 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: bash incorrectly determines HOME and HOMEDRIVE
-Original Message- Larry Hall Sent: Thursday, March 25, 2004 5:04 PM Subject: Re: bash incorrectly determines HOME and HOMEDRIVE Larry Hall WroteK HOMEDRIVE is set by Windows. You don't have to set it. And bash wouldn't know HOMEDRIVE from a hole in the wall. ;-) That is what I thought but I can definitely reproduce this behaviour on XP. I set HOMEDRIVE in H: in windows and then run bash and its reset to C:. Definitely strange. Not that I really care since I don't use it for anything. BTW, It is possible to change it in the .bashrc file -- 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: SDL on Cygwin
- -Original Message- Of Yaakov Selkowitz Sent: Monday, March 22, 2004 4:37 PM Subject: Re: SDL on Cygwin -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Frédéric L. W. Meunier wrote: | By it builds OOTB on Cygwin I assumed it was without | -mno-cygwin. If you want to use it, you should rebuild all | other libraries with -mno-cygwin. it builds OOTB on Cygwin = the vanilla sources compile and link in the current Cygwin environment | -mno-cygwin is probably more appropriate for a MinGW | mailing-list. I think you may have missed my point, I DON'T want to use -mno-cygwin because it limits my options for building things dependent on SDL. | I see no references to SDLmain on Linux. Actually, it's a dummy | file: | | 840 Mar 15 16:57 libSDLmain.a | | Maybe you get the same compiling with Cygwin | (without -mno-cygwin). Well, it doesn't give a choice as I said, it uses the -mno-cygwin flag by default when building in Cygwin. I believe the libSDLmain.a is their way of avoiding the [EMAIL PROTECTED] issue, but it shouldn't be necessary with the current autotool-devel packages (and I did autoreconf before building this). So again, how can SDL be build WITHOUT -mno-cygwin, and what does one do with this libSDLmain.a? The fact that it builds out of the box with -mno-cygwin would appear to indicate that whoever distributes the SDL application has gotten it running as a native WIN32 application build using MINGW32 (aka -mno-cygwin). To get it to run as a cygwin application with the cygwin dll instead, someone will have to port it to cygwin. What this involves can probably only be determined by diving into the source code. Basically it requires someone with enough interest plus enough knowledge of cygwin + SDL to dive in and figure it out. I believe there is a SDL mailing list. You might try it to see if anyone is already working on a cygwin port or has any suggestions Ken Yaakov -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFAX1yBpiWmPGlmQSMRAvFUAKC9ekBhMNMoN+PWCfzk9L8mFdQaRgCgtJML Y1rC2cZ8Tx3QjBY8v0wDf8A= =edEX -END PGP SIGNATURE- -- 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: Cywin Setup application not able to maximise
-Original Message- Michael John Sent: Friday, March 05, 2004 4:51 PM Subject: Cywin Setup application not able to maximise Hi, i'm using Cygwin for more than half a yeah now. Admittedly, i find it very impractical not being allowed to resize, respectively maximize, the setup application, because the tree of packages to install is much to large for the window. Is this intended? Differently asked, is there a projected time to change this behaviour? A search of the archives will prove instructive Ken TIA, mic -- 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: Problem with dd to raw disks
What really bugs me is people who complain instead of doing something. Quit complaining and do something about it. This is open source after all. Ken -Original Message- From: Yitzchak Scott-Thoennes Subject: Re: Problem with dd to raw disks On Mon, Mar 01, 2004 at 11:44:38AM -0500, Christopher Faylor wrote: On Mon, Mar 01, 2004 at 11:35:40AM -0500, Larry Hall wrote: Pah! The User's Guide. That's just a document full of useful information. Why would anyone want to read that? ;-) Maybe we need a howto on reading the user's guide. It should certainly be in the FAQ that people should read the documentation. How would people know that they should read the documentation unless it was spelled out somewhere in black and white? You know, the thing that really bugs me about cygwin is the half-baked attempts at documentation. A FAQ entry suggesting reading the User's Guide is completely useless unless the User's Guide tells people to read the 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/ -- 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: problem running bash inside NTemacs
I can verify this behaviour for Cygwin 1.5.7 and NT emacs 21.3. Judging by the lack of response on the list, I suspect this is something you will have to chase down yourself if this is a big problem for you. -Original Message- David S. Sent: Monday, February 23, 2004 4:18 PM Subject: Re: problem running bash inside NTemacs Larry Hall suggested I check the email archives. I found nothing there related to this problem. He also pointed me to the problems.html page, so here is the suggested information. The problem can be recreated by running NTemacs (as noted in my original msg, I'm using GNU Emacs 20.7.1 (i386-*-nt5.1.2600)) running bash as the emacs shell (as noted in my original msg, I'm using BASH_VERSION='2.05b.0(1)-release') running 'ed' and performing any command that should print output (like .). The erroneous behavior is that the output is not produced until the program is terminated. Additional information since original msg: a) the same behavior is produced with other shells; tcsh, sh b) 'less' behaves like 'cat'; it doesn't prompt at all `cygcheck -s -v -r` returns: Cygwin Win95/NT Configuration Diagnostics Current System Time: Mon Feb 23 10:23:46 2004 Windows XP Professional Ver 5.1 Build 2600 Service Pack 1 Path: f:\xxx\bin C:\Progra~1\Cygwin\bin c:\WINDOWS\system32 c:\WINDOWS c:\WINDOWS\System32\Wbem c:\PROGRA~1\THINKPAD\UTILITIES c:\Progra~1\doxygen\bin c:\SFU\common\ . C:\Progra~1\Cygwin\usr\sbin c:\progra~1\gsview\gsview e:\xxx\Pkg\gnuplot\bin c:\progra~1\ghostscript\gs7.04\bin c:\progra~1\ghostscript\gs7.04\lib Output from C:\Progra~1\Cygwin\bin\id.exe (nontsec) UID: 1005(xxx) GID: 513(None) 513(None) Output from C:\Progra~1\Cygwin\bin\id.exe (ntsec) UID: 1005(xxx) GID: 513(None) 513(None)544(Administrators) 545(Users) SysDir: C:\WINDOWS\System32 WinDir: C:\WINDOWS HOME = `f:\xxx' LD_LIBRARY_PATH = `C:\Progra~1\Cygwin\usr\local\src\hdf5-1.4.1\lib' PWD = `/f/xxx/ChomboCurrent/Chombo/lib/test/PIC' ALLUSERSPROFILE = `C:\Documents and Settings\All Users' APPDATA = `C:\Documents and Settings\xxx\Application Data' CLIENTNAME = `Console' COMMONPROGRAMFILES = `C:\Program Files\Common Files' COMPUTERNAME = `GABLE' COMSPEC = `C:\WINDOWS\system32\cmd.exe' EMACS = `t' EMACSDATA = `C:/Program Files/Emacs/emacs-20.7/etc' EMACSDOC = `C:/Program Files/Emacs/emacs-20.7/etc' EMACSLOADPATH = `C:/Program Files/Emacs/emacs-20.7/site-lisp;C:/Program Files/Emacs/emacs-20.7/lisp;C:/Program Files/Emacs/emacs-20.7/leim' EMACSLOCKDIR = `C:/Program Files/Emacs/emacs-20.7/lock' EMACSPATH = `C:/Program Files/Emacs/emacs-20.7/bin' EMACS_DIR = `C:/Program Files/Emacs/emacs-20.7' EM_PARENT_PROCESS_ID = `1724' HOMEDRIVE = `C:' HOMEPATH = `\Documents and Settings\xxx' LOGNAME = `xxx' LOGONSERVER = `\\X MORE = `-s' NUMBER_OF_PROCESSORS = `1' OS = `Windows_NT' PAGER = `more' PATHEXT = `.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.tcl' PROCESSOR_ARCHITECTURE = `x86' PROCESSOR_IDENTIFIER = `x86 Family 6 Model 11 Stepping 1, GenuineIntel' PROCESSOR_LEVEL = `6' PROCESSOR_REVISION = `0b01' PROGRAMFILES = `C:\Program Files' PS1 = `\h:\w \# ' RSYNC_RSH = `ssh' SESSIONNAME = `Console' SFUDIR = `C:\SFU\' SHELL = `/bin/bash' SHLVL = `1' SYSTEMDRIVE = `C:' SYSTEMROOT = `C:\WINDOWS' TEMP = `c:\DOCUME~1\xxx\LOCALS~1\Temp' TERM = `emacs' TERMCAP = `emacs:co#105:tc=unknown:' TMP = `c:\DOCUME~1\xxx\LOCALS~1\Temp' TMPDIR = `c:\DOCUME~1\xxx\LOCALS~1\Temp' USERDOMAIN = `GABLE' USERNAME = `xxx' USERPROFILE = `C:\Documents and Settings\xxx' WINDIR = `C:\WINDOWS' _ = `/usr/bin/cygcheck' setpath = `1' HKEY_CURRENT_USER\Software\Cygnus Solutions HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\mounts v2 (default) = `/' cygdrive flags = 0x0022 HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\Program Options HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2 (default) = `/' cygdrive flags = 0x002a HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/ (default) = `C:\Progra~1\Cygwin' flags = 0x000a HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/usr/bin (default) = `C:\Progra~1\Cygwin/bin' flags = 0x000a HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/usr/lib (default) = `C:\Progra~1\Cygwin/lib' flags = 0x000a HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/usr/X11R6/lib/X11/fonts (default) = `C:\Progra~1\Cygwin\usr\X11R6\lib\X11\fonts' flags = 0x000a HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\Program Options a: fd N/AN/A c: hd NTFS7006Mb 96% CP CS UN PA FC IBM_PRELOAD d: cd N/AN/A e: hd
RE: 20040214 no fix for unzip, cygwin debugging howto?
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Thomas L Roche Sent: Monday, February 16, 2004 12:01 AM To: [EMAIL PROTECTED] Subject: Re: 20040214 no fix for unzip, cygwin debugging howto? Christopher Faylor Sun, 15 Feb 2004 21:12:02 -0500 it occurred to me that I could add some increased debugging which might show why cmalloc was returning NULL. How thoughtful of you. So, the next snapshot will have more strace output for the failing condition, meaning that if you do this: strace -o strace.out unzip whatever it should produce a large strace file. The only interesting output for now would come from the _csbrk function which will have words like couldn't commit memory for cygwin heap... in it. If you are interested in tracking this down, please send the information from that line here. Unfortunately 20040215 came out while I was debugging 20042014. Since you claim to have done anything that might have actually fixed the problem, the results obtained at http://cygwin.com/ml/cygwin/2004-02/msg00705.html are still relevant. Christopher Faylor Sun, 15 Feb 2004 12:36:44 -0500 To be perfectly frank, your inability to figure anything out here seems to illustrate that you will not be able to provide any useful debugging details. Maybe you should do yourself a favor, standardize on 1.5.5 and just give up. If building and debugging is beyond your current skills then it's not likely that you'll be providing any useful feedback anytime soon. To be perfectly frank, your insolence is egregious; it will be addressed separately. If you do not like his attitude, feel free to quit asking him to fix problems for you. This is an OPEN SOURCE project. No one is required to fix problems except as there interests lead them to. This includes CGF. He has pointed out that he is not particular interested in fixing the unzip problem that you are experiencing. That is his privelidge. I have been following this list and using cygwin for a long time. We continually get new subscribers who somehow have the expectation that somehow CGF is responsible for fixing all problems. He's not so get over it. -- 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: Why choice between unix and dos line endings?
At 09:10 PM 2/14/2004, you wrote: Something I've never been able to figure out is why Cygwin offers to install with the choice of either dos or unix line endings. The way I see it is that using dos line endings allows for good integration with native windows apps. I can see no advantage of using unix line endings, though I guess there must be one otherwise the option wouldn't be offered. Can any one shed some light on this. Thanks Chuck The purpose of the cygwin project is to provide a posix emulation on top of win32 to allow easy porting of unix applications. Unix applications DO NOT use DOS line endings. Integration with native windows applications is at best a secondary goal of the project. I would never select DOS line endings because it would break most of the applications I use cygwin for. -- 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: Problem rolling back cygwin from 1.5.7.1 to 1.5.5.1
This would seem to indicate that you have two copies of the cygwin1 dll in your path. -Original Message- On Behalf Of Charles Plager Sent: Tuesday, February 10, 2004 9:08 AM To: Cygwin Mailing list Subject: Problem rolling back cygwin from 1.5.7.1 to 1.5.5.1 Hello, Since I've been having so much trouble with many different versions of emacs, I decided to try to go back to cygwin 1.5.5.1 using setup.exe. It installs without any complaints and tells me to reboot before using. So after rebooting, I keep getting an error message popping up when I try to use bash or calling commands from perl: (title) Sh.exe: Entry Point Not Found (body) The procedure entry point _fcntl64 could not be located in the dynamically linked library cygwin1.dll. Upgrading back to 1.5.7.1 solves this problem. Has this been seen before? Is it possible to successfully downgrade cygwin back to 1.5.5.1? (Has anyone been having problems with emacs and 1.5.5.1?) Thanks, Charles -- 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: cannot make a directory called aux
Hint, Did you ever consider reading the FAQs before posting -Original Message- From: cygwin-owneratcygwin.com On Behalf Of Troy Hicks Sent: Monday, February 09, 2004 1:09 AM To: cygwinatcygwin.com Subject: cannot make a directory called aux This is a strange problem. Here are the basics: = in your home directory (or any directory from cygwin) try to mkdir aux. For me this fails with the following complaint: $ mkdir aux mkdir: `aux' exists but is not a directory Anyone seen/know of a problem like this? I'm running WinXP with cygwin: $ uname -a CYGWIN_NT-5.1 gw600 1.5.5(0.94/3/2) 2003-09-20 16:31 i686 unknown unknown Cygwin More info === in the same directory in which mkdir aux was attempted ls -al give the following (note no aux file, directory or otherwise): $ ls -al total 12 drwxrwxrwx+ 4 Troy A. None0 Feb 8 19:04 . drwxrwxrwx+ 3 Troy A. None0 Jan 31 12:29 .. -rw---1 Troy A. None 6459 Feb 7 13:19 .bash_history -rwxr-xr-x1 Troy A. None 533 Jan 31 11:10 .bash_profile -rwxr-xr-x1 Troy A. None 625 Jan 31 11:10 .bashrc -rw---1 Troy A. None 188 Feb 6 12:52 .cvspass -rw---1 Troy A. None 286 Feb 7 11:16 .history -rwxr-xr-x1 Troy A. None 267 Jan 31 11:10 .inputrc drwxr-xr-x+ 2 Troy A. None0 Feb 8 22:02 .ncftp drwx--+ 2 Troy A. None0 Feb 9 00:28 .ssh I ran into the problem when trying to cvs co a source tree that had aux as a subdirectory down several levels from the top. -- 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: Plausibility of sendmail?
As far as whether it gets in the cygwin distribution, it is primarily a function of whether someone is willing to port it to cygwin and maintain it. Otherwise, it won't. Someone asks about sendmail for cygwin periodically but I have never seen anyone express an interest in actually doing the port and seving as maintainer. From what Brian Dessant says about the state of the code base, it is pretty obvious why. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Brian Dessent Sent: Monday, February 02, 2004 10:45 AM To: [EMAIL PROTECTED] Subject: Re: Plausibility of sendmail? [EMAIL PROTECTED] wrote: If someone is crazy enough to want a production mailserver with Cygwin, let them run Exim. Point well taken. Having limited experience with mail servers in general, I will certainly keep your advice filed away in the ole noodle for future reference. Of course a lot of reasons that *crap* persists is because there's a lot of folks who are familiar with and experienced with such *crap*. For someone under the gun to come up with a quick fix, inevitably they will attempt to implement the familiar. If sendmail REALLY deserves to die, then keeping it out of the Cygwin distribution is something I would understand, and probably support (as long as there are advertised alternatives of course!) Well, I don't see sendmail dying anytime soon. It's still running on something like half of all mail servers, and I'm pretty sure it's still the #1 MTA. But, it's decades old and has reams and reams of security bulletins, both past and present (and future!) Security was just not such a concern back before The Internet existed, when ARPAnet and this new TCP/IP thing were all the rage. It's configured with a sendmail.cf file that closely resembles line noise and is so byzantine that it takes a 1232 page O'Reilly book to explain it. It's rumoured that some sendmail developers don't even understand parts of the file. The recommended advise is to never touch it, but instead edit the more friendly .mc file which is passed through a number of m4 macros to generate the .cf file. It sticks around due to legacy, as far as I can tell. It just works at a number of places and nobody wants to be the person to rip it all out and install something else. It also has support for some really anachronistic features (e.g. UUCP) that you likely won't find elsewhere. It's probably got the worst performance of the big four, but it can be made to do most of the things that you would ever want out of an MTA, and since it's so old everything's at least documented pretty well. So, if you use Webmin to configure it, and you stay up to date with your patches, and you aren't trying to run a whole enterprise's mail on a Pentium then it will probably work fine. I suppose it would be unfair to call it crap, and you will always be able to find those who defend it with the same level of fanaticism as a heated vi-vs-emacs argument. And to swing this back on-topic, I personally don't think it should be propagated to new places where it has yet to exist, such as Cygwin, especially when viable alternatives already exist there. Brian -- 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: snapshot cygwin1-20031212.dll.bz2
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Christopher Faylor Sent: Wednesday, December 17, 2003 10:49 AM To: [EMAIL PROTECTED] Subject: Re: snapshot cygwin1-20031212.dll.bz2 On Wed, Dec 17, 2003 at 08:28:53AM +, Marcus Van Der Beek wrote: But, then it's been theorized that I am rather incompetent about testing these things, preferring to test in a magical It always works type of environment that is loaded with super special software. That's why I need something like the stack dump from normal folks who don't have access to all of my whiz bang cygwin spy gadgets and such. its good to see you acknowledge and agree with what others have been saying even though its got a sarcastic tone about it. Do you wear ear muffs to muffle the sound of things whooshing by over your head? It must be quite distracting otherwise. cgf CGF provides a tremendous service to the open source community whatever some list members think of his attitude. Some of you people who are trashing him at the same time you are expecting him to reproduce and fix bugs, which often seem to affect only a very few installations, really should read Dale Carnegies book How To Win Friends And Influence People. You would really get a lot more accomplished that way. -- 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: Mozilla vis-a-vis Cygwin
Welcome to user maintained open source software. Someone has to care enough about something for it to get done. I am sure that interested volunteers would be greatly appreciated. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Michael F. March Sent: Tuesday, June 17, 2003 1:37 PM To: Randall R Schulz Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: Mozilla vis-a-vis Cygwin I posted the same thing last month and no one seems to care. http://www.cygwin.com/ml/cygwin/2003-05/msg00599.html Hi, A while back there was some talk about the feasibility of a Cygwin-based Mozilla. In perusing the release notes for Mozilla 1.4 (http://www.mozilla.org/releases/mozilla1.4rc1/) I noticed this: - As of Mozilla 1.4b, it is possible to build Mozilla for Win32 using GCC. See the win32 build instructions (http://www.mozilla.org/build/win32.html) for details. Perhaps this represents a meaningful portion of a the porting work necessary to create a GCC- / Cygwin- / X-based Mozilla variant. -- march Michael F. March - [EMAIL PROTECTED] Ph: (415)462-1910 Fax: (602)296-0400 P.O. Box 2254 Phoenix, AZ 85002-2254 Seriously - HSR
