RE: Re: Problem when using variable assignment, backticks in shell script
> Whether you typed it yourself or not, those type of disclaimers are actually not allowed in mail to mailing lists at this site: > http://sourceware.org/lists.html OK. I can't post. My mistake was attempting to make a suggestion to a person asking for help - which is more than you did. What a waste of time. > Please find some other way of sending email which does not try to enforce some kind of faux-legal obligations on the reader. Can't. And why bother. And do you really feel that I "try to enforce some kind of faux-legal obligations" on you? You must be very afraid. Unsubscribing. Moron. Alan Carter This message and any files transmitted with it are legally privileged and intended for the sole use of the individual(s) or entity to whom they are addressed. If you are not the intended recipient, please notify the sender by reply and delete the message and any attachments from your system. Any unauthorised use or disclosure of the content of this message is strictly prohibited and may be unlawful. Nothing in this e-mail message amounts to a contractual or legal commitment on the part of EUROCONTROL, unless it is confirmed by appropriately signed hard copy. Any views expressed in this message are those of the sender. -- 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/
Problem running cron service
Hi,
I am running Cygwin in my Windows 2k3 machine. I am
not able to run the cron service. When i checked with
the following command.
$cygrunsrv -Q cron
I get the following result.
Output of "cygrunsrv -Q cron" command :
Service : cron
Current State : Stopped
Command : /usr/sbin/cron -D
I have also checked with cron_diagnose.sh script. I
get the following message.
Output of "cron_diagnose.sh" script :
cron_diagnose.sh 1.10
This script did not find any errors in your cron
setup.
If you are still unable to get cron to work, then try
shutting down the cron service, uninstalling it,
reinstalling it, and restarting it.
The following commands will do that:
$ cygrunsrv --stop cron
$ cygrunsrv --remove cron
$ cygrunsrv --install cron -p /usr/sbin/cron -a -D
(You can also add a -u switch)
$ cygrunsrv --start cron
Also, examine the log file for cron,
/var/log/cron.log, for
information that it might give you about the problem
cron is
having.
If none of this fixes the problem, then report your
problem
to [EMAIL PROTECTED] Please include a copy of your
crontab,
('crontab -l') and the output of 'cygcheck -srv >
cygcheck.txt'.
Please include the generated file 'cygcheck.txt' *as
an attachment*,
and NOT in the body of the mail message.
I have also tried Removing and installing cron
service. But, no use. I have attached the file
"cygcheck.txt" which has the output of "cygcheck -srv"
and "cron.txt" which is the job assigned for crontab.
Please help me how to start the cron service in my
Cygwin.
Thanks & Regards,
Hemaraj
__
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.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/
Re: Color Schemes
On Thu, Aug 31, 2006 at 12:59:09PM -0500, mwoehlke wrote: >> George wrote: >> On Thu, Aug 31, 2006 at 09:44:51AM -0500, mwoehlke wrote: >>> Dave Korn wrote: >>> [...] and I am not aware of any way to examine the terminal's >>> "palette", nor should you need to. If a user wants to fiddle with >>> these, it is his responsibility to keep things legible. >> >> $ grep color ~/.Xdefaults >> [...] >> Or am I missing something? > > Sure. Now do it for Konsole (hint: DCOP *might* let you), CUI, Console, > rxvt, PuTTY, and every other terminal emulator in existence. I guess I don't understand why one would expect that to be possible, or desirable. > What you found is the *default* colors for *one* emulator (what happens > if you override them with command-line switches?). No, those are my colors (the default colors are very different) and are used by any emulator that makes uses of .Xdefaults, which includes rxvt and standard xterms. Command-line switches for both are mostly in a one-to-one correspondence with the directives in .Xdefaults. > Dave and I were talking about being able to query the terminal > emulator in a standardized way, and I am pretty sure there is no such > way. Sorry for the noise. -- George -- 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: [Mingw-msys] POSIX names for drive letters
> >> By the way, any idea why //localhost/C$ doesn't work? > > do you have > > 127.0.0.1 localhost > > in your hosts file ? Yes, localhost is in %SystemRoot%\System32\etc\drivers\hosts. > No, I don't think that's it. This is netbios name > resolution and DNS doesn't come into it; it's resolved by > broadcasting a udp datagram with the desired netbios name and > seeing if anyone in the local network jumps up and claims it. > It would be bad if every machine on the network all claimed > to be 'localhost' at the same time! I think you're right: $ ls //localhost/C$ ls: //localhost/C$: Given log. name not unique $ nslookup localhost Server: mail2.siemens.de Address: 139.25.208.11 Non-authoritative answer: Name:localhost.ww002.siemens.net Address: 127.0.0.1 $ which is weird, I shouldn't have thought that nslookup return a positive answer at all, and especially not a fully-qualified name. Regards, Konrad Schwarz -- 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/
mp3 player from cygwin
Hello all , is there any thing like that ? mp3 player from cygwin? not graphic or graphic command line that working ? thanks -- View this message in context: http://www.nabble.com/mp3-player-from-cygwin-tf2201356.html#a6094977 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/
RE: [Mingw-msys] POSIX names for drive letters
On 01 September 2006 08:37, Schwarz, Konrad wrote: > $ nslookup localhost > Server: mail2.siemens.de > Address: 139.25.208.11 > > Non-authoritative answer: > Name:localhost.ww002.siemens.net > Address: 127.0.0.1 > > $ > > which is weird, I shouldn't have thought that nslookup return a positive > answer at all, and especially not a fully-qualified name. nslookup by default appends the local domain. Use a period to prevent it. Try "nslookup localhost." instead. cheers, DaveK -- Can't think of a witty .sigline today -- 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/
cygwin fork()
Is it just me or is cygwin fork(), or a support syscall underneath, terribly slow for some reason? While building projects using libtool (which using heavy sh, hence fork() calls) I regularly have to fire off 'make -j16's just to get around waiting ages when using a single make job. -cl -- 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()
On 01 September 2006 11:02, [EMAIL PROTECTED] wrote: > Is it just me or is cygwin fork(), or a support syscall underneath, > terribly slow for some reason? Some reason == "lack of O/S support". cheers, DaveK -- Can't think of a witty .sigline today -- 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()
On Fri, Sep 01, 2006 at 11:12:59AM +0100, Dave Korn wrote: > > Is it just me or is cygwin fork(), or a support syscall underneath, > > terribly slow for some reason? > > Some reason == "lack of O/S support". Yes I can understand that. I'm assuming there is some CreateProcess() magic happening behind the scenes. However, what I've noticed is that it is WAY slower than one would think it to be. -cl -- 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/
cron job don't work correct
Hi All, With cygwin i want run a daily script that should build my source every day. I want do that with a cron job. On my system the cron service is running.In win xp i am log in as a domain-user with administrator rights (member in the administrator group). In cygwin i am log in as a domain-user with administrator rights. So i'm also included in the administrator group id 544 under cygwin. My crontab file C:\Programme\cygwin\var\cron\tabs\todde is a member in the administrator group. My script that i want to start with a cron job script is located in /home/todde/checkout.sh. This file is also a member in the administrator group. One examle: Basicly i can say the cron job works ! Here is a simple script that cron job works. Here is my Crontab: */1 * * * * /home/todde/cronscript.sh Example cronscript.sh: -- #!/bin/bash touch mytest.txt Every minute i get a file called mytest.txt. So far so good. Here is the problem: But i.e. if i call another script from the cronscript.sh it don't work as a cronjob but it work when i enter it on the command line. cronscript.sh: -- #!/bin/bash check.sh check.sh: -- #!/bin/bash touch hello.txt Or another example: Example cronscript.sh: - #!/bin/bash touch /home/mytest.txt -- This example don't work with cronjob but work from the command line . Ok. I know on a real Linux system that don't work regarding write permissions. But under cygwin it should work!! Last example that work on command line but not with cronjob: #!/bin/bash export CVSDIR=c: cd $CVSDIR export BUILD1=s export BUILD2=e export CVSROOT=:pserver:user:[EMAIL PROTECTED]:/local/cvsrepository cvs login cvs -q -z3 update -d -P -r BRANCH_TEST source cvs logout -- All scripts has the user flags rwx. (chmod u+rwx) Any ideas why the behaviour is so different between command line and cron job ?? Thanks for answers. Todde -- View this message in context: http://www.nabble.com/cron-job-don%27t-work-correct-tf2201821.html#a6096299 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/
RE: cygwin fork()
On 01 September 2006 11:22, [EMAIL PROTECTED] wrote: > On Fri, Sep 01, 2006 at 11:12:59AM +0100, Dave Korn wrote: >>> Is it just me or is cygwin fork(), or a support syscall underneath, >>> terribly slow for some reason? >> >> Some reason == "lack of O/S support". > > Yes I can understand that. I'm assuming there is some CreateProcess() > magic happening behind the scenes. However, what I've noticed is that it > is WAY slower than one would think it to be. Why, how slow were *you* expecting it to be? I was expecting it to be 7. cheers, DaveK -- Can't think of a witty .sigline today -- 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()
On Fri, Sep 01, 2006 at 11:12:59AM +0100, Dave Korn wrote: > On 01 September 2006 11:02, [EMAIL PROTECTED] wrote: > > > Is it just me or is cygwin fork(), or a support syscall underneath, > > terribly slow for some reason? > > Some reason == "lack of O/S support". Basically, this is what I'm talking about: Opteron 180, fast disks, ran make clean, make 4 times or so to keep the disk/mem/cpu caches hot; no extraneous system usage going on: $ ( make clean; time make -j1 ; make clean; time make -j8 ) >/dev/null real2m20.062s user0m13.252s sys 0m37.139s real0m45.654s user0m15.968s sys 0m49.201s That's a huge difference, and it's only like 6300 lines of code! I've narrowed it down to something between 20060309 and 20060313 snapshots. Every snapshot since 20060313 has had this incredible slowness issue with fork(). The dual-coreness isn't going to make a huge difference here as I can get the same factor of speed up just by using 20060309's dll and the exact same make jobs. Nor is it a case of minor differences in times. I've tried different versions of libtool, gcc, etc. Everything just goes back to 20060309 vs 20060313. -cl -- 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/
EGSnrc & cygwin
Hi, I am trying to install and run EGSnrc and Cygwin on my Windows XP machine following a document by Brian Wilfley back in April 2003 and am not having any luck. Is there an updated installation document to install and run? Thanks! Kayla -- Kayla N. Kielar University of Florida Department of Nuclear and Radiological Engineering 202 Nuclear Sciences Center PO Box 118300 Gainesville, FL 32611 (352) 392-1401 ext. 336 ALRADS - Advanced Laboratory for Radiation Dosimetry Studies Website: alrads.nre.ufl.edu -- 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: EGSnrc & cygwin
On 01 September 2006 14:49, Kayla Kielar wrote: > Hi, > > > > I am trying to install and run EGSnrc and Cygwin on my Windows XP machine > following a document by Brian Wilfley back in April 2003 and am not having > any luck. Is there an updated installation document to install and run? You'd better ask Brian Wilfley. There's no such thing as "EGSnrc" in the cygwin distribution. cheers, DaveK -- Can't think of a witty .sigline today -- 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: cron job don't work correct
On Fri, 1 Sep 2006, Todde wrote: > With cygwin i want run a daily script that should build my source every day. > I want do that with a cron job. > [snip] > > Here is the problem: > But i.e. if i call another script from the cronscript.sh it don't work > as a cronjob but it work when i enter it on the command line. > > [snip] > Any ideas why the behaviour is so different between command line and cron > job ?? Cron runs with different environment settings than your command line (which uses a login shell). You will need to either specify paths to executables explicitly in your cron scripts, or run them using the login bash shell (e.g., use this in your cron script: /bin/bash -l -c "check.sh" ). It's usually better to go with explicit paths, though. HTH, Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] | [EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_Igor Peshansky, Ph.D. (name changed!) |,4- ) )-,_. ,\ ( `'-' old name: Igor Pechtchanski '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! "Las! je suis sot... -Mais non, tu ne l'es pas, puisque tu t'en rends compte." "But no -- you are no fool; you call yourself a fool, there's proof enough in that!" -- Rostand, "Cyrano de Bergerac" -- 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()
On Fri, 1 Sep 2006, clayne wrote: > Is it just me or is cygwin fork(), or a support syscall underneath, > terribly slow for some reason? While building projects using libtool > (which using heavy sh, hence fork() calls) I regularly have to fire off > 'make -j16's just to get around waiting ages when using a single make job. While Cygwin is an *emulation* layer, and emulation is inherently slower than straight execution, there are other potential reasons for the slowness. Check your anti-virus and firewall software settings. If possible, exclude the Cygwin filesystem from checking by those tools... Even little things (like making the tool aware of the often-used Cygwin programs and telling it to not check "outbound email messages" (!) sent by those programs) can help speed up Cygwin... A one-sentence rant: even with those changes, whenever I run a Cygwin shell script, the stupid vsmon process takes up 100% of the CPU. No known solution. Sigh... Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] | [EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_Igor Peshansky, Ph.D. (name changed!) |,4- ) )-,_. ,\ ( `'-' old name: Igor Pechtchanski '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! "Las! je suis sot... -Mais non, tu ne l'es pas, puisque tu t'en rends compte." "But no -- you are no fool; you call yourself a fool, there's proof enough in that!" -- Rostand, "Cyrano de Bergerac" -- 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: Color Schemes
George wrote: On Thu, Aug 31, 2006 at 12:59:09PM -0500, mwoehlke wrote: George wrote: On Thu, Aug 31, 2006 at 09:44:51AM -0500, mwoehlke wrote: Dave Korn wrote: [...] and I am not aware of any way to examine the terminal's "palette", nor should you need to. If a user wants to fiddle with these, it is his responsibility to keep things legible. $ grep color ~/.Xdefaults [...] Or am I missing something? Sure. Now do it for Konsole (hint: DCOP *might* let you), CUI, Console, rxvt, PuTTY, and every other terminal emulator in existence. I guess I don't understand why one would expect that to be possible, or desirable. Exactly. I don't expect it to be possible, nor do I see a purpose for it. Which is why I wondered why you went digging for how to do it with xterm. :-) So I guess we are in violent agreement? What you found is the *default* colors for *one* emulator (what happens if you override them with command-line switches?). No, those are my colors (the default colors are very different) and are used by any emulator that makes uses of .Xdefaults, which includes rxvt and standard xterms. Command-line switches for both are mostly in a one-to-one correspondence with the directives in .Xdefaults. "Defaults" as in "unless command-line args are used to override them". I did notice that they looked decidedly 'non-standard'. :-) Dave and I were talking about being able to query the terminal emulator in a standardized way, and I am pretty sure there is no such way. Sorry for the noise. Eh, don't worry about it. Now I know where to tinker with rxvt's "default" settings. :-) Never know who might get something out of this... -- Matthew Do not expose to hippos. Doing so may void your warranty. -- 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: nfs in client mode (winxp => linux)
[EMAIL PROTECTED] wrote: I see lots of past messages here about setting up NFS in server mode, but very little in the other direction. Going far enough back there was quite a long thread about SFU (Services for unix) but I haven't been able to get that NFS client to work. In fact I can't even really do anything with ksh shell it provides. Every command gets a tty error. So has anything changed since the release of SFU 3.5? That has been a good while. Is there still no cygwin NFS client for windows? I use both SFU (3.5, pre-2003R2) and SUA (5.2, Win2003R2 and later) NFS clients without too much trouble (nothing that doesn't seem to be general sharing problems, anyway; mostly it works about as well as anything over ssh - i.e. poorly). The trick is getting user name mapping set up correctly. You might want to ask on the Interix forums (http://www.interopsystems.com/tools/default.aspx) if things aren't working. Unfortunately there is no NFS client (not that I've ever heard of, anyway) that plays nicely with Cygwin (true symlink and permissions support, for example). -- Matthew Do not expose to hippos. Doing so may void your warranty. -- 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()
On Fri, 1 Sep 2006, clayne wrote: > On Fri, Sep 01, 2006 at 11:12:59AM +0100, Dave Korn wrote: > > On 01 September 2006 11:02, [EMAIL PROTECTED] wrote: > > > > > Is it just me or is cygwin fork(), or a support syscall underneath, > > > terribly slow for some reason? > > > > Some reason == "lack of O/S support". > > Basically, this is what I'm talking about: > > Opteron 180, fast disks, ran make clean, make 4 times or so to keep the > disk/mem/cpu caches hot; no extraneous system usage going on: > > $ ( make clean; time make -j1 ; make clean; time make -j8 ) >/dev/null > > real2m20.062s > user0m13.252s > sys 0m37.139s > > real0m45.654s > user0m15.968s > sys 0m49.201s > > That's a huge difference, and it's only like 6300 lines of code! I've > narrowed it down to something between 20060309 and 20060313 snapshots. Every > snapshot since 20060313 has had this incredible slowness issue with fork(). > > The dual-coreness isn't going to make a huge difference here as I can get > the same factor of speed up just by using 20060309's dll and the exact > same make jobs. Nor is it a case of minor differences in times. I've tried > different versions of libtool, gcc, etc. Everything just goes back to > 20060309 vs 20060313. Ok, but now you're in a perfect position to debug this further. There were only 6 sets of changes between those two snapshots (see the cygwin-cvs archives). If you can build Cygwin as of those times and pinpoint the change that made the difference, that in itself would probably be helpful in diagnosing the problem. Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] | [EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_Igor Peshansky, Ph.D. (name changed!) |,4- ) )-,_. ,\ ( `'-' old name: Igor Pechtchanski '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! "Las! je suis sot... -Mais non, tu ne l'es pas, puisque tu t'en rends compte." "But no -- you are no fool; you call yourself a fool, there's proof enough in that!" -- Rostand, "Cyrano de Bergerac" -- 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: Re: Problem when using variable assignment, backticks in shell script
On Fri, Sep 01, 2006 at 09:22:53AM +0200, CARTER Alan wrote: >>Whether you typed it yourself or not, those type of disclaimers are >>actually not allowed in mail to mailing lists at this site: > >>http://sourceware.org/lists.html > >OK. I can't post. My mistake was attempting to make a suggestion to a >person asking for help - which is more than you did. What a waste of >time. Your mistake was apparently not understanding that I was telling you that you were breaking site policy by sending your messages. >Unsubscribing. Moron. I appreciate your unsubscribing. I hope the name-calling helped you. If you, or anyone feels compelled to indulge in more of this type of flamage, I'd suggest taking it to the cygwin-talk list. cgf -- 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()
On Fri, Sep 01, 2006 at 10:33:47AM -0400, Igor Peshansky wrote: > While Cygwin is an *emulation* layer, and emulation is inherently slower > than straight execution, there are other potential reasons for the > slowness. Check your anti-virus and firewall software settings. If > possible, exclude the Cygwin filesystem from checking by those tools... > Even little things (like making the tool aware of the often-used Cygwin > programs and telling it to not check "outbound email messages" (!) sent by > those programs) can help speed up Cygwin... It's definitely none of those as I don't run any firewall or antivirus software whatsoever on this box. Windows 2003 Server, minimal set of services. The machine literally sits at 0% CPU unless I'm using it. > A one-sentence rant: even with those changes, whenever I run a Cygwin > shell script, the stupid vsmon process takes up 100% of the CPU. No known > solution. Sigh... Don't know what vsmon is.. A likely solution sounds to get rid of vsmon ;). Also, not to break out the ole Linux vs Cygwin time comparisons type deal, because we all know hot it's apples and oranges, in this case it's a bit absurd a difference and I kinda have to. On a Celeron 2gz Linux box w/512M RAM (which is WAY slower than a dual core Opteron 180 w/ 4GB of RAM): real0m11.507s user0m9.100s sys 0m2.320s 11s! For the same "make -j1" vs the 2m20s I got with "make -j1" on my 20060718 Cygwin box. 11s is about 1/4th the time of the best I could get my opteron to do with 'make -j8'. This is with all the exact same code. Now we know libtool is intensive, but the libtool being used is the exact same script (the build script is running a local generated version e.g. "/bin/sh ../libtool "). All I did was copy the exact same build directory to my linux host, cleaned it out, and ran the tests. Yes apples to oranges for sure, but let's look at some figures here: Linux 2.6.17.11, Celeron 2ghz/512MB/IDE drive,11.507s (make -j1) Cygwin 20060718, Opteron [EMAIL PROTECTED]/4GB/U320SCSI, 2m20s (make -j1) Cygwin 20060718, Opteron [EMAIL PROTECTED]/4GB/U320SCSI, 45.654s (make -j8) This is what specifically makes me wonder what is up. Just one small segment of the build which I copied the commands from one to the other: Linux (Celeron): [EMAIL PROTECTED] lib]$ time if /bin/sh ../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../lib-march=pentium4 -mtune=pentium4 -mcpu=pentium4 -Os -MT network.lo -MD -MP -MF ".deps/network.Tpo" -c -o network.lo network.c; then mv -f ".deps/network.Tpo" ".deps/network.Plo"; else rm -f ".deps/network.Tpo"; exit 1; fi gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../lib -march=pentium4 -mtune=pentium4 -mcpu=pentium4 -Os -MT network.lo -MD -MP -MF .deps/network.Tpo -c network.c -fPIC -DPIC -o .libs/network.o gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../lib -march=pentium4 -mtune=pentium4 -mcpu=pentium4 -Os -MT network.lo -MD -MP -MF .deps/network.Tpo -c network.c -o network.o >/dev/null 2>&1 real0m1.254s user0m1.140s sys 0m0.110s [EMAIL PROTECTED] lib]$ time gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../lib -march=pentium4 -mtune=pentium4 -mcpu=pentium4 -Os -MT network.lo -MD -MP -MF .deps/network.Tpo -c network.c -fPIC -DPIC -o .libs/network.o real0m0.549s user0m0.520s sys 0m0.030s [EMAIL PROTECTED] lib]$ time gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../lib -march=pentium4 -mtune=pentium4 -mcpu=pentium4 -Os -MT network.lo -MD -MP -MF .deps/network.Tpo -c network.c -o network.o >/dev/null 2>&1 real0m0.522s user0m0.510s sys 0m0.010s Cygwin (Opteron): $ time if /bin/sh ../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../lib-march=pentium4 -mtune=pentium4 -mcpu=pentium4 -Os -MT network.lo -MD -MP -MF ".deps/network.Tpo" -c -o network.lo network.c; then mv -f ".deps/network.Tpo" ".deps/network.Plo"; else rm -f ".deps/network.Tpo"; exit 1; fi gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../lib -march=pentium4 -mtune=pentium4 -mcpu=pentium4 -Os -MT network.lo -MD -MP -MF .deps/network.Tpo -c network.c -DPIC -o .libs/network.o gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../lib -march=pentium4 -mtune=pentium4 -mcpu=pentium4 -Os -MT network.lo -MD -MP -MF .deps/network.Tpo -c network.c -o network.o >/dev/null 2>&1 real0m8.032s user0m1.166s sys 0m2.216s $ time gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../lib -march=pentium4 -mtune=pentium4 -mcpu=pentium4 -Os -MT network.lo -MD -MP -MF .deps/network.Tpo -c network.c -DPIC -o .libs/network.o real0m0.506s user0m0.249s sys 0m0.061s $ time gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../lib -march=pentium4 -mtune=pentium4 -mcpu=pentium4 -Os -MT network.lo -MD -MP -MF .deps/network.Tpo -c network.c -o network.o >/dev/null 2>&1 real0m0.506s user0m0.233s sys 0m0.062s Obviously it's not gcc, or the execution of binary code that is slow, Same libtool, different systems, 8 times slower. Just as a crude test, I dumped the output of
Re: cygwin fork()
On Fri, Sep 01, 2006 at 08:37:09AM -0700, [EMAIL PROTECTED] wrote: > > 1157123322 + echo blah1 > 1157123322 blah1 > <3 seconds of doing absolutely nothing here> > 1157123325 + test -z '' > 1157123325 + echo blah2 > 1157123325 blah2 I just also copied the same libtool to 3 different hard drives, one even a slow usb drive. Same results everytime. Even recompiling bash and specifying that instead of /bin/sh. Same. -cl -- 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: mp3 player from cygwin
umen wrote: Hello all , is there any thing like that ? mp3 player from cygwin? not graphic or graphic command line that working ? thanks No, not as a package in the distribution. I remember some talk about, I believe, mplayer a while back on the list but I may be mistaken. -- Larry Hall http://www.rfk.com RFK Partners, Inc. (508) 893-9779 - RFK Office 216 Dalton Rd. (508) 893-9889 - FAX Holliston, MA 01746 -- 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()
On Fri, Sep 01, 2006 at 08:37:09AM -0700, [EMAIL PROTECTED] wrote: >On Fri, Sep 01, 2006 at 10:33:47AM -0400, Igor Peshansky wrote: >> While Cygwin is an *emulation* layer, and emulation is inherently slower >> than straight execution, there are other potential reasons for the >> slowness. Check your anti-virus and firewall software settings. If >> possible, exclude the Cygwin filesystem from checking by those tools... >> Even little things (like making the tool aware of the often-used Cygwin >> programs and telling it to not check "outbound email messages" (!) sent by >> those programs) can help speed up Cygwin... > >It's definitely none of those as I don't run any firewall or antivirus >software whatsoever on this box. Windows 2003 Server, minimal set of >services. The machine literally sits at 0% CPU unless I'm using it. Try using binary mounts instead of text mounts. cgf -- 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 cron service
On 09/01/2006, A Hemaraj wrote: I have attached the file "cygcheck.txt" which has the output of "cygcheck -srv" and "cron.txt" which is the job assigned for crontab. Actually no, you apparently forgot to do that. -- Larry Hall http://www.rfk.com RFK Partners, Inc. (508) 893-9779 - RFK Office 216 Dalton Rd. (508) 893-9889 - FAX Holliston, MA 01746 -- 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()
On Fri, Sep 01, 2006 at 11:54:03AM -0400, Christopher Faylor wrote: > >It's definitely none of those as I don't run any firewall or antivirus > >software whatsoever on this box. Windows 2003 Server, minimal set of > >services. The machine literally sits at 0% CPU unless I'm using it. > > Try using binary mounts instead of text mounts. > > cgf Wish it were that easy. $ mount C:\cygwin\bin on /usr/bin type system (binmode) C:\cygwin\lib on /usr/lib type system (binmode) C:\cygwin on / type system (binmode) c: on /c type system (binmode,noumount) d: on /d type system (binmode,noumount) e: on /e type system (binmode,noumount) m: on /m type system (binmode,noumount) -cl -- 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()
On Fri, Sep 01, 2006 at 09:09:11AM -0700, [EMAIL PROTECTED] wrote: > On Fri, Sep 01, 2006 at 11:54:03AM -0400, Christopher Faylor wrote: > > >It's definitely none of those as I don't run any firewall or antivirus > > >software whatsoever on this box. Windows 2003 Server, minimal set of > > >services. The machine literally sits at 0% CPU unless I'm using it. > > > > Try using binary mounts instead of text mounts. > > > > cgf BTW: I started up filemon to watch what was going on from it's standpoint, and it shows a huge number of READs on libtool, all SUCCESS, but the offset is always 1 higher than previous, with a length of 1. Like it's literally reading the file 1 byte at a time, then incrementing the offset - until it has fully been read. -cl -- 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()
On Fri, 1 Sep 2006, Christopher Faylor wrote: > On Fri, Sep 01, 2006 at 08:37:09AM -0700, [EMAIL PROTECTED] wrote: > >On Fri, Sep 01, 2006 at 10:33:47AM -0400, Igor Peshansky wrote: > >> While Cygwin is an *emulation* layer, and emulation is inherently > >> slower than straight execution, there are other potential reasons for > >> the slowness. Check your anti-virus and firewall software settings. > >> If possible, exclude the Cygwin filesystem from checking by those > >> tools... Even little things (like making the tool aware of the > >> often-used Cygwin programs and telling it to not check "outbound > >> email messages" (!) sent by those programs) can help speed up > >> Cygwin... > > > >It's definitely none of those as I don't run any firewall or antivirus > >software whatsoever on this box. Windows 2003 Server, minimal set of > >services. The machine literally sits at 0% CPU unless I'm using it. > > Try using binary mounts instead of text mounts. This thread already had two suggestions for possibly speeding up Cygwin... Does anyone, as a service to the community, want to start a "Cygwin performance tuning" web page and keep track? It might even end up in the User's Guide eventually... Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] | [EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_Igor Peshansky, Ph.D. (name changed!) |,4- ) )-,_. ,\ ( `'-' old name: Igor Pechtchanski '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! "Las! je suis sot... -Mais non, tu ne l'es pas, puisque tu t'en rends compte." "But no -- you are no fool; you call yourself a fool, there's proof enough in that!" -- Rostand, "Cyrano de Bergerac" -- 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()
On Fri, Sep 01, 2006 at 09:34:15AM -0700, [EMAIL PROTECTED] wrote:
> BTW:
> I started up filemon to watch what was going on from it's standpoint, and it
> shows a huge number of READs on libtool, all SUCCESS, but the offset is always
> 1 higher than previous, with a length of 1. Like it's literally reading the
> file
> 1 byte at a time, then incrementing the offset - until it has fully been read.
>
> -cl
So right smack dab in the middle of _evalfile() under bash-3.1:
#if defined (__CYGWIN__) && defined (O_TEXT)
setmode (fd, O_TEXT);
#endif
Also in read_comsub():
#ifdef __CYGWIN__
setmode (fd, O_TEXT); /* we don't want CR/LF, we want Unix-style */
#endif
And most importantly in open_shell_script():
/* Open the script. But try to move the file descriptor to a randomly
large one, in the hopes that any descriptors used by the script will
not match with ours. */
fd = move_to_high_fd (fd, 0, -1);
#if defined (__CYGWIN__) && defined (O_TEXT)
setmode (fd, O_TEXT);
#endif
The high fd part jives with the '255' seen in the readv() strace output as well.
This post from 2000 looks related:
http://ecos.sourceware.org/ml/cygwin/2000-10/msg00213.html
In regards to setting the fd to textmode as a way of stripping CRs. Only problem
is that it's making 213,110 syscalls for a 213k libtool script. That cannot be
an
efficient way to remove CRs from input.
Found the old references to that too:
#if 0
#if defined (__CYGWIN__)
if (c == '\n' && istring_index > 1 && istring[istring_index - 2] == '\r')
{
istring_index--;
istring[istring_index - 1] = '\n';
}
#endif
#endif
I've since removed the setmode() calls within a bash build and am testing now.
UPDATE:
SOLVED.
Filemon now shows bash reading in 8k chunks. There is now no 3 second delay on
reading the rest of the bash script (which I evidenced earlier as well).
p.s. Seriously old stuff in there, for example:
#if defined (__CYGWIN__)
/* Under CygWin 1.1.0, the unlink will fail if the file is
open. This hack will allow the previous action of silently
ignoring the error, but will still leave the file there. This
needs some kind of magic. */
if (r == EACCES)
return (fd2);
#endif /* __CYGWIN__ */
--
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()
On Fri, Sep 01, 2006 at 10:04:51AM -0700, [EMAIL PROTECTED] wrote: > I've since removed the setmode() calls within a bash build and am testing now. > > UPDATE: > SOLVED. > > Filemon now shows bash reading in 8k chunks. There is now no 3 second delay on > reading the rest of the bash script (which I evidenced earlier as well). I also changed the input buffer size to be 32768, as opposed to 8192, and additionally enabled mmap() (since bash source had a stone age define in there indicating cygwin did not support mmap()). New 'make -j8': real0m16.806s user0m6.458s sys 0m13.328s vs. 44 seconds previously. -- 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()
On Fri, Sep 01, 2006 at 10:04:51AM -0700, [EMAIL PROTECTED] wrote: >On Fri, Sep 01, 2006 at 09:34:15AM -0700, [EMAIL PROTECTED] wrote: >> BTW: >> I started up filemon to watch what was going on from it's standpoint, and it >> shows a huge number of READs on libtool, all SUCCESS, but the offset is >> always >> 1 higher than previous, with a length of 1. Like it's literally reading the >> file >> 1 byte at a time, then incrementing the offset - until it has fully been >> read. >> >> -cl > >So right smack dab in the middle of _evalfile() under bash-3.1: > >#if defined (__CYGWIN__) && defined (O_TEXT) > setmode (fd, O_TEXT); >#endif > >Also in read_comsub(): > >#ifdef __CYGWIN__ > setmode (fd, O_TEXT); /* we don't want CR/LF, we want Unix-style */ >#endif > >And most importantly in open_shell_script(): > > /* Open the script. But try to move the file descriptor to a randomly > large one, in the hopes that any descriptors used by the script will > not match with ours. */ > fd = move_to_high_fd (fd, 0, -1); > >#if defined (__CYGWIN__) && defined (O_TEXT) > setmode (fd, O_TEXT); >#endif > >The high fd part jives with the '255' seen in the readv() strace output as >well. > >This post from 2000 looks related: > >http://ecos.sourceware.org/ml/cygwin/2000-10/msg00213.html > >In regards to setting the fd to textmode as a way of stripping CRs. >Only problem is that it's making 213,110 syscalls for a 213k libtool >script. That cannot be an efficient way to remove CRs from input. Opening a file with O_TEXT should not, AFAIK, cause a bunch of one-byte reads. A simple test case (tm) seems to confirm that. cgf -- 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()
On Fri, Sep 01, 2006 at 01:24:57PM -0400, Christopher Faylor wrote:
> >In regards to setting the fd to textmode as a way of stripping CRs.
> >Only problem is that it's making 213,110 syscalls for a 213k libtool
> >script. That cannot be an efficient way to remove CRs from input.
>
> Opening a file with O_TEXT should not, AFAIK, cause a bunch of one-byte
> reads.
>
> A simple test case (tm) seems to confirm that.
>
> cgf
You're right. I also verified this.
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__ */
/* Take FD, a file descriptor, and create and return a buffered stream
corresponding to it. If something is wrong and the file descriptor
is invalid, return a NULL stream. */
BUFFERED_STREAM *
fd_to_buffered_stream (fd)
int fd;
{
char *buffer;
size_t size;
struct stat sb;
if (fstat (fd, &sb) < 0)
{
close (fd);
return ((BUFFERED_STREAM *)NULL);
}
size = (fd_is_seekable (fd)) ? min (sb.st_size, MAX_INPUT_BUFFER_SIZE) : 1;
if (size == 0)
size = 1;
buffer = (char *)xmalloc (size);
return (make_buffered_stream (fd, buffer, size));
}
--
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/
bash problems ? (was Re: cygwin fork())
I'm just changing the subject so that Eric will, with luck, notice
and comment on what's going on here.
cgf
On Fri, Sep 01, 2006 at 10:47:13AM -0700, [EMAIL PROTECTED] wrote:
>On Fri, Sep 01, 2006 at 01:24:57PM -0400, Christopher Faylor wrote:
>> >In regards to setting the fd to textmode as a way of stripping CRs.
>> >Only problem is that it's making 213,110 syscalls for a 213k libtool
>> >script. That cannot be an efficient way to remove CRs from input.
>>
>> Opening a file with O_TEXT should not, AFAIK, cause a bunch of one-byte
>> reads.
>>
>> A simple test case (tm) seems to confirm that.
>
>You're right. I also verified this.
>
>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__ */
>
>/* Take FD, a file descriptor, and create and return a buffered stream
> corresponding to it. If something is wrong and the file descriptor
> is invalid, return a NULL stream. */
>BUFFERED_STREAM *
>fd_to_buffered_stream (fd)
> int fd;
>{
> char *buffer;
> size_t size;
> struct stat sb;
>
> if (fstat (fd, &sb) < 0)
>{
> close (fd);
> return ((BUFFERED_STREAM *)NULL);
>}
>
> size = (fd_is_seekable (fd)) ? min (sb.st_size, MAX_INPUT_BUFFER_SIZE) : 1;
> if (size == 0)
>size = 1;
> buffer = (char *)xmalloc (size);
>
> return (make_buffered_stream (fd, buffer, size));
>}
--
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()
On 01 September 2006 18:47, [EMAIL PROTECTED] 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 #define fd_is_seekable(fd) fd_is_in_binary_not_text_mode(fd) ...although of course I'm paraphrasing there. Anyway, congratulations, well tracked down! Definitely one to raise with upstream... cheers, DaveK -- Can't think of a witty .sigline today -- 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()
On Fri, Sep 01, 2006 at 06:57:10PM +0100, Dave Korn wrote: >On 01 September 2006 18:47, [EMAIL PROTECTED] 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. cgf -- 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/
tar 1.5.error: lone zero block
I'm unpacking a tar that contains a linux root filesystem on my cygwin machine. I get a complaint about a "lone zero block" and the tar is not completely extracted. This is with tar 1.15.91-1, if I roll back to 1.15.1-4, then the problem goes away. Appears to be a bug. The same thing happened for me on several different tars. I attached both sucessful and failure logs to this email. Note that the messages about filenames that contain ":", etc are expected, since that is an illegal filename on windows. You'll see those in both logs. While I'm mentioning tar, I think I'll bring up again that I'm also still seeing the following problem on both 1.15.1-4 and 1.15.91-1. I'm no longer running the snapshot, this is with the normal "released" versions of everything. http://sourceware.org/ml/cygwin/2006-05/msg00738.html Thanks, Jeremiah Lott TimeSys Corporation tar-1.15.1.log Description: tar-1.15.1.log tar-1.15.91.log Description: tar-1.15.91.log -- 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-gui version of the cygwin setup?
When cygwin is installed in a bunch of boxes already, is there a way to ssh into the box (ssh is already setup, etc) and execute Cygwin's setup.exe to have setup pull updated packages from an internal, local mirror? Mike -- 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: cygwin fork()
"Gary R. Van Sickle" wrote: > > 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." FWIW, mingw's lseek() (which is actually Microsoft's, since mingw targets MSVCRT.DLL) is horribly broken when seeking on a file opened in text mode. But it's documented as such on MSDN, so at least there's that. So there is some precedence for the concept that "this won't work on windows platforms." But Cygwin's should work fine, and if it means saving a bazillion 1-byte syscalls then I think bash should be patched to remove this sillyness ASAP. 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/
Re: cygwin fork()
Brian Dessent wrote: "Gary R. Van Sickle" wrote: 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." FWIW, mingw's lseek() (which is actually Microsoft's, since mingw targets MSVCRT.DLL) is horribly broken when seeking on a file opened in text mode. But it's documented as such on MSDN, so at least there's that. So there is some precedence for the concept that "this won't work on windows platforms." But Cygwin's should work fine, and if it means saving a bazillion 1-byte syscalls then I think bash should be patched to remove this sillyness ASAP. I'll *emphatically* second the 'doing something about it'; I'm also cursed by really slow builds. (Assuming I understand what is going on, anyway :-)) -- Matthew Do not expose to hippos. Doing so may void your warranty. -- 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()
On Fri, Sep 01, 2006 at 05:07:49PM -0500, Gary R. Van Sickle wrote: >> 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." AFAIK, lseek is supposed to work. There was some old pre-DJ code which I believe was ifdef'ed out up until around 2002 when Corinna introduced 64-bit support. However, I'm sure there are probably corner cases where it breaks down. However, determining the position in a file using lseek and then seeking to that position later should work ok. cgf -- 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: non-gui version of the cygwin setup?
On Fri, 1 Sep 2006, Mike wrote: > When cygwin is installed in a bunch of boxes already, > is there a way to ssh into the box (ssh is already setup, > etc) and execute Cygwin's setup.exe to have setup pull > updated packages from an internal, local mirror? If you allow the sshd service to interact with the desktop, you *should* be able to run Cygwin setup.exe in unattended mode (run "setup --help" and look in the log for the option summary). However, I would recommend first doing it on a machine that you have console access to, just in case the "Installation complete" popup is still displayed in unattended mode or something. Also, you will not be able to update any files that sshd itself uses (which includes cygwin1.dll) unless you also execute a "shutdown -r" from your ssh session. HTH, Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] | [EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_Igor Peshansky, Ph.D. (name changed!) |,4- ) )-,_. ,\ ( `'-' old name: Igor Pechtchanski '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! "Las! je suis sot... -Mais non, tu ne l'es pas, puisque tu t'en rends compte." "But no -- you are no fool; you call yourself a fool, there's proof enough in that!" -- Rostand, "Cyrano de Bergerac" -- 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: non-gui version of the cygwin setup?
On Fri, 01 Sep 2006, Igor Peshansky might have said: > On Fri, 1 Sep 2006, Mike wrote: > > > When cygwin is installed in a bunch of boxes already, > > is there a way to ssh into the box (ssh is already setup, > > etc) and execute Cygwin's setup.exe to have setup pull > > updated packages from an internal, local mirror? > > If you allow the sshd service to interact with the desktop, you *should* > be able to run Cygwin setup.exe in unattended mode (run "setup --help" and > look in the log for the option summary). However, I would recommend first > doing it on a machine that you have console access to, just in case the > "Installation complete" popup is still displayed in unattended mode or > something. Also, you will not be able to update any files that sshd > itself uses (which includes cygwin1.dll) unless you also execute a > "shutdown -r" from your ssh session. > HTH, > Igor That helps a bunch. Silly me I kept trying the windows convention asking for help (/?) instead of the unix one. Mike -- 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()
> But Cygwin's should work fine, and if it means saving a bazillion 1-byte > syscalls then I think bash should be patched to remove this sillyness > ASAP. I get the hint! Look for a new release of bash in the near future; and once I get the cygport build going, I will also try to get the bash-3.2 alpha up as well. -- Eric Blake volunteer cygwin bash maintainer -- 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/
