RE: Problems starting rxvt from startxwin.bat
Jose Luis wrote: I can start xterm from startxwin.bat: %RUN% xterm -e /usr/bin/bash -l but no rxvt: %RUN% rxvt -bg white -fg black -e /bin/bash although it can be started from command line: jlfd...@jlfdiazwxp ~ $ rxvt -bg white -fg black -e /bin/bash Why does rvxt starting from startxwin.bat fail? This is almost certainly a timing issue. The line in the batch file that starts the server uses %RUN% to start it in the background. This means that the following commands in the batch file may execute before the X server has completed (or even started) its initialisation. I suspect that the reason the two terminals behave differently is that, xterm tries to connect to the server a number of times before giving up, whereas rxvt gives up at the first failure. Because the time taken to initialise the X server can vary, rather than using just sleep, I have added the following: REM wait up to 30 seconds for the X server set /a COUNT=0 :WAITFORX checkx -d %DISPLAY% if not errorlevel 1 goto FINISHOFF set /a COUNT+=1 if %COUNT% GEQ 30 goto NOX echo Waiting for X on display %DISPLAY% ... sleep 1 goto WAITFORX :NOX echo WARNING: X doesn't appear to have started exit /B 1 :FINISHOFF Jon/Yaakov, could this be added to the distributed startxwin.bat? Perhaps the warning could be extended to include instructions to check the log. Phil -- This email has been scanned by Ascribe Ltd using Microsoft Antigen for Exchange. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
winsup/cygwin ChangeLog select.cc
CVSROOT:/cvs/uberbaum Module name:winsup Changes by: c...@sourceware.org 2009-09-01 14:25:10 Modified files: cygwin : ChangeLog select.cc Log message: * select.cc (peek_console): Always check window size when there is ANY keyboard activity. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/winsup/cygwin/ChangeLog.diff?cvsroot=uberbaumr1=1.4640r2=1.4641 http://sourceware.org/cgi-bin/cvsweb.cgi/winsup/cygwin/select.cc.diff?cvsroot=uberbaumr1=1.153r2=1.154
src/winsup/mingw ChangeLog include/stdio.h
CVSROOT:/cvs/src Module name:src Changes by: keithmarsh...@sourceware.org2009-09-01 20:41:55 Modified files: winsup/mingw : ChangeLog winsup/mingw/include: stdio.h Log message: Avoid multiple link time definitions of _printf() for C++ Patches: http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/winsup/mingw/ChangeLog.diff?cvsroot=srcr1=1.447r2=1.448 http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/winsup/mingw/include/stdio.h.diff?cvsroot=srcr1=1.40r2=1.41
Re: [Patch] Allow to disable root privileges with CYGWIN=noroot
On Aug 30 21:38, Christian Franke wrote: Corinna Vinschen wrote: If you plan to run a Cygwin application with restricted rights from your administrative account, the IMHO right way would be to start the Cygwin application through another application which creates a *really* restricted user token using the Win32 function CreateRestrictedToken and then call cygwin_set_impersonation_token/execv to start the restricted process. A Cygwin tool which accomplishes that would be much more useful and much more generic than this patch, IMHO. I agree, let's forget the patch. But I'm not sure how cygwin_set_impersonation_token() could be of any help here. This function sets user.external_token which is only used in seteuid32(). Setuid/seteuid() cannot be used because the restricted token is not related to another user id. I had a quick look into the seteuid code and I see the problem. I don't see a quick way around it, unfortunately. I'll have a deeper look into it when I'm back from vacation. A quick test with native calls works for me: HANDLE t, rt; OpenProcessToken (GetCurrentProcess (), TOKEN_ALL_ACCESS, t); CreateRestrictedToken (t, DISABLE_MAX_PRIVILEGE, 0, ..., 0, rt); CreateProcessAsUser (rt, 0, c:/cygwin/bin/mintty..., ...); Cool. Some stuff in the child won't work though since the entire exec(2) magic is missing. BTW: CreateRestrictedToken is apparently missing in /usr/include/w32api/*.h, but it is present in libadvapi32.a PTC. The w32api files always need a lot of work. Microsoft adds stuff with every new OS release. It's hard to stay on top. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: GNU screen hangs
On 2009-08-31, Christopher Faylor cgf-use-the-mailinglist-ple...@cygwin.com wrote: Apparently you don't know who I am. An even bigger pile of shit than this project. A project leader pretending to be an army sergeant with users rookies required to follow his ridiculous commands. I guess I'm going to complete my transition from Linux to Windows, and ditch Cygwin too. It has no hope with such piles of shit at the top. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: GNU screen hangs
TV wrote: On 2009-08-31, Christopher Faylor cgf-use-the-mailinglist-ple...@cygwin.com wrote: Apparently you don't know who I am. An even bigger pile of Don't kid yourself: it's you that's at fault, not the whole rest of the world. You've been rude and arrogant from your first post. It's certainly not just him who thinks so, I was going to reply about three separate times until I saw what you were doing. Posting people's email addresses gets them spammed. It's not just a petty rule, it's a verified fact proven by scientific experimentation and measurement. Here's proof: http://www.cdt.org/speech/spam/030319spamreport.shtml Deliberately violating list netiquette and morphing your From: line to evade a ban is regarded as network abuse pretty much everywhere. It's certainly anti-social. DaveK -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: GNU screen hangs
On 2009-09-01, Dave Korn da...@googlemail.com wrote: Don't kid yourself: it's you that's at fault, not the whole rest of the world. You've been rude and arrogant from your first post. Oh, this is must be a cultural thing about americans and their tanned tongues. Can't stay to the facts, have to make everything dripping with sugar, otherwise it's considered rude. Posting people's email addresses gets them spammed. And the addresses are right there in the From-fields. -- Be an early adopter! Beat the herd! Choose Windows today! -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: GNU screen hangs
On Tue, Sep 01, 2009 at 10:23:58AM +, TV wrote: On 2009-09-01, Dave Korn da...@googlemail.com wrote: Don't kid yourself: it's you that's at fault, not the whole rest of the world. You've been rude and arrogant from your first post. Oh, this is must be a cultural thing about americans and their tanned tongues. Can't stay to the facts, have to make everything dripping with sugar, otherwise it's considered rude. Heh. DaveK is an American now. When did that happen? cgf -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
[OT] Re: GNU screen hangs
TV wrote: On 2009-09-01, Dave Korn wrote: Wow. You kind of quoted my email address, but then you went and changed it into some poor innocent bystander's account. Whoever that is won't be pleased with you. this space left blank for Tuomo to explain why that's the innocent bystander's fault, and not his for using a buggy newsreader Don't kid yourself: it's you that's at fault, not the whole rest of the world. You've been rude and arrogant from your first post. Oh, this is must be a cultural thing about americans and their tanned tongues. I'm not even a little bit American, you silly little bigot. Can't stay to the facts, have to make everything dripping with sugar, otherwise it's considered rude. Nonsense, it's got nothing to do with the way you say it, it's the content of your message that nobody likes: self-regarding vanity, arrogance and me-first egotism. Unwarranted self-importance, much? Posting people's email addresses gets them spammed. And the addresses are right there in the From-fields. Spammers don't subscribe to mailing lists to harvest addresses. They scrape them off the web archives. The headers are munged in the archives. The bodies are not. You're just trying to justify lazy selfishness. DaveK -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: [OT] Re: GNU screen hangs
Ah, censorship. The Official Truth will become the Truth, when the opposition is censored. On 2009-09-01, Dave Korn davek.spamt...@googlemail.com wrote: Nonsense, it's got nothing to do with the way you say it, it's the content of your message that nobody likes: self-regarding vanity, arrogance and me-first egotism. Unwarranted self-importance, much? You clearly read the messages through some anti-tuomov glasses, as most of the FOSS herd does. It's not like I'm liked much for pointing out where it's all heading, and my anti-distro licensing. So the herd attacks the message thanks to the messenger. Spammers don't subscribe to mailing lists to harvest addresses. They scrape them off the web archives. The headers are munged in the archives. The bodies are not. You're just trying to justify lazy selfishness. Any sane archive will obfuscate both content and headers, if it all. This list is archived at http://news.gmane.org/gmane.os.cygwin/, and available by NNTP through news.gmage.org, both of which spammers can use. The former poorly obfuscates both (with @ replaced by at), the latter doesn't. Gmane can be configured to fully obsfuscate addresses, but nobody has done it for this list. And yet people carelessly post their real addresses in the headers... as if it's worth the effort of trying to keep addresses out of spammers' hands. Better stay of the 'net. No, the real reason for complaining about quoting an address has nothing to do with spam. You just wanted some excuse for attacking me with some nitpicky rules... on a list that is listed as the only place for users to report bugs, trying to help both the project and themselves. But, no, the attitude among FOSS developers these days is tha their project has no bugs, and they don't want to hear about it, so it's made extremely difficult to report them... registering on some suckzilla, subscribing on a mailing list (because apparently accessing through NNTP isn't really allowed, even when available), listening to power-blind assholes complain about some ridiculous directives hidden in some tome of Sacred Etiquette. Signing off. Pitäkää tunkkinne! -- Tuomo -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: [OT] Re: GNU screen hangs
One more time wrote: Ah, censorship. zOMG we is suppressing your freedumb of speach! O noes! Call for the WH-bulance! Seriously, that is the kind of pathetic nonsense spammers come out with. You clearly read the messages through some anti-tuomov glasses, as most of the FOSS herd does. It's not like I'm liked much for pointing out where it's all heading, and my anti-distro licensing. So the herd attacks the message thanks to the messenger. Oh, so you are a noble fighter for freedom, a voice crying out in the wilderness, and anyone who thinks you're a jerk is just a gullible fool with no independent thought, following the herd. Ha ha, no. Sure, they laughed at Galileo, they laughed at Copernicus, they laughed at Columbus and Newton and Einstein. But they also laughed at Bozo the Clown. You're not trying to help anyone out or point the way. You posted a RRAGEE-filled angry self-pitying rant. And then you expect to be treated as some kind of hero. Like I said, narcissistic vanity. It makes you an unpleasant person to be around. Face the facts: I have never met or heard of you before; it's entirely down to the unpleasant tone of your first post and your subsequent descent into full-on trollhood. I am not following any herd, I made my own mind up, and long before you started being deliberately rude for no reason over the issue of quoting people's email addresses; it's precisely because I have an independent mind that I think you're a jerk. I've set the Followup-to header to the suitable list for continuing this off-topic discussion. DaveK -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: BitDefender again
Or you can go the easy route, and follow the instructions they have provided to rebase cygwin.dll. I shall try their instructions and report back. (There must be other BitDefender users similarily inconvenienced by version 2010 :) -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
1.7.0-60: diff -qr crashes
Hi, I've installed Cygwin Beta 1.7.0 (version -51) around mid of July. Currently, version -60 is installed. Now (at least since version -53 or so) I repeatedly encounter a bug with diff (diffutils 2.8.7-1). I use diff to compare my working directory with the files on an usb stick. The exact command line is diff -qr . /cygdrive/w/user/schuetze/work/2009 Note that the 32 GByte usb stick (cygdrive w) is encrypted with truecrypt 6.2a and formatted as FAT32. (Don't know if this matters. But the error occurs with other directories as well.) Depending on the exact place in the file system I'll get a core dump immediately or first some errors and then the core dump. bash-3.2$ pwd /cygdrive/e/user/schuetze/work/2009 bash-3.2$ diff -qr . /cygdrive/w/user/schuetze/work/2009 1 [main] diff 2376 sig_send: error sending signal -34 to pid 2376, pipe handle 0x750, Win32 error 998 Segmentation fault (core dumped) One folder downwards the file hierarchy everything works fine, at least today. But with bash-3.2$ pwd /cygdrive/e/user/schuetze/work/2008 bash-3.2$ diff -qr . /cygdrive/w/user/schuetze/work/2008 1 [main] diff 3692 _cygtls::handle_exceptions: Error while dumping state (probably corrupted stack) Segmentation fault (core dumped) I will attach both diff.exe.stackdump, the core file from the folder 2009 as diff.exe.stackdump-1, the one from the 2008 folder as diff.exe.stackdump-2. Note, that there are no errors with Cygwin 1.5 (cygwin 1.5.24). My questions are: - Is this a known error with Cygwin 1.7.0-60? - What can I do about it? Is there a fix available? - Is the stack dump helpful or should I compile diff with debug symbols and gdb diff? If required I can provide the output of cygcheck -s -v -r Torsten Exception: STATUS_ACCESS_VIOLATION at eip=C128 eax= ebx= ecx=0022B3BC edx=7C90E514 esi= edi= ebp=0022B3C8 esp=0022B3C8 program=C:\cygwin\bin\diff.exe, pid 2376, thread main cs=001B ds=0023 es=0023 fs=003B gs= ss=0023 Stack trace: Frame Function Args 0022B3C8 C128 (0728, EA60, 00A4, 0022B4BC) 0022B4D8 610B9C85 (6120C50C, 0001, 003B0023, 0023) 0022B598 610BA53A (0001, 0022B654, 10062738, 610CA724) 0022B5A8 610BA5CF (, 0001, 0022B5F8, ) 10062738 610CA724 (6F632F41, 4F2F6564, 536E6570, 682F4143) End of stack trace Exception: STATUS_ACCESS_VIOLATION at eip=C128 eax= ebx= ecx=0022BEFC edx=7C90E514 esi= edi= ebp=0022BF08 esp=0022BF08 program=C:\cygwin\bin\diff.exe, pid 3692, thread main cs=001B ds=0023 es=0023 fs=003B gs= ss=0023 Stack trace: Frame Function Args 0022BF08 C128 (072C, EA60, 00A4, 0022BFFC) 0022C018 610B9C85 (6120910C, 0001, , ) 0022C0D8 610BA53A (6120C81C, , 10061250, 610CA724) 0022C0E8 610BA5CF (, , 0022C158, 6100229F) 10061250 610CA724 (7463656C, 73657275, 6369702F, 65727574) 1 [main] diff 3692 _cygtls::handle_exceptions: Error while dumping state (probably corrupted stack) -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: GNU screen hangs
TV wrote: Oh, this is must be a cultural thing about americans and their tanned tongues. Excuse me, I'm off to the tongue tanning salon... ;-) -- Andrew DeFaria http://defaria.com The gene pool sure could use a little chlorine. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: GNU screen hangs
On Tue, Sep 01, 2009 at 07:12:51AM -0700, Andrew DeFaria wrote: TV wrote: Oh, this is must be a cultural thing about americans and their tanned tongues. Excuse me, I'm off to the tongue tanning salon... ;-) Ok. I've got to stop drinking coffee while reading the cygwin list... cgf -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: 1.7.0-60: diff -qr crashes
On Tue, Sep 01, 2009 at 04:01:06PM +0200, Torsten Sch?tze wrote: Hi, I've installed Cygwin Beta 1.7.0 (version -51) around mid of July. Currently, version -60 is installed. Now (at least since version -53 or so) I repeatedly encounter a bug with diff (diffutils 2.8.7-1). I use diff to compare my working directory with the files on an usb stick. The exact command line is diff -qr . /cygdrive/w/user/schuetze/work/2009 Note that the 32 GByte usb stick (cygdrive w) is encrypted with truecrypt 6.2a and formatted as FAT32. (Don't know if this matters. But the error occurs with other directories as well.) Depending on the exact place in the file system I'll get a core dump immediately or first some errors and then the core dump. bash-3.2$ pwd /cygdrive/e/user/schuetze/work/2009 bash-3.2$ diff -qr . /cygdrive/w/user/schuetze/work/2009 1 [main] diff 2376 sig_send: error sending signal -34 to pid 2376, pipe handle 0x750, Win32 error 998 Segmentation fault (core dumped) I guess this is my excuse to roll a new version of Cygwin. Since Corinna doesn't include the .dbg file in her releases, I can't decode the stack traces from the attached .stackdump files. Or, hmm. It guess it would be better if I released a snapshot before a new release. Could you try to duplicate this with today's snapshot from: http://cygwin.com/snapshots/ I'm generating it now. Please wait for the September 1 snapshot to show up before trying anything. cgf -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: 1.7.0-60: diff -qr crashes
Christopher Faylor wrote: On Tue, Sep 01, 2009 at 04:01:06PM +0200, Torsten Sch?tze wrote: Hi, I've installed Cygwin Beta 1.7.0 (version -51) around mid of July. Currently, version -60 is installed. Now (at least since version -53 or so) I repeatedly encounter a bug with diff (diffutils 2.8.7-1). I use diff to compare my working directory with the files on an usb stick. The exact command line is diff -qr . /cygdrive/w/user/schuetze/work/2009 Note that the 32 GByte usb stick (cygdrive w) is encrypted with truecrypt 6.2a and formatted as FAT32. (Don't know if this matters. But the error occurs with other directories as well.) Depending on the exact place in the file system I'll get a core dump immediately or first some errors and then the core dump. bash-3.2$ pwd /cygdrive/e/user/schuetze/work/2009 bash-3.2$ diff -qr . /cygdrive/w/user/schuetze/work/2009 1 [main] diff 2376 sig_send: error sending signal -34 to pid 2376, pipe handle 0x750, Win32 error 998 Segmentation fault (core dumped) I guess this is my excuse to roll a new version of Cygwin. Since Corinna doesn't include the .dbg file in her releases, I can't decode the stack traces from the attached .stackdump files. Or, hmm. It guess it would be better if I released a snapshot before a new release. Could you try to duplicate this with today's snapshot from: http://cygwin.com/snapshots/ I'm generating it now. Please wait for the September 1 snapshot to show up before trying anything. Okay, here we are. Using the 2009-09-01 snapshot (cygwin1-20090901.dll.bz2, cygwin1-20090901.dbg.bz2) I obtain: First, in directory 2009 (corresponds to diff.exe.stackdump-1), see attachment diff.exe.stackdump-1-new Exception: STATUS_ACCESS_VIOLATION at eip=C128 eax= ebx= ecx=0022B3BC edx=7C90E514 esi= edi= ebp=0022B3C8 esp=0022B3C8 program=C:\cygwin\bin\diff.exe, pid 260, thread main cs=001B ds=0023 es=0023 fs=003B gs= ss=0023 Stack trace: Frame Function Args 0022B3C8 C128 (0724, EA60, 00A4, 0022B4BC) 0022B4D8 610B9EA5 (6120BFEC, 0001, 003B0023, 0023) 0022B598 610BA75A (0001, 0022B654, 10062718, 610CA934) 0022B5A8 610BA7EF (, 0001, 0022B5F8, ) 10062718 610CA934 (6F632F41, 4F2F6564, 536E6570, 682F4143) End of stack trace In directory 2008 the list of warnings and errors is much longer now, but it doesn't core dump now. bash-3.2$ cd ../2008 bash-3.2$ diff -qr . /cygdrive/w/user/schuetze/work/2008 1 [main] diff 3760 sig_send: error sending signal -34 to pid 3760, pipe handle 0x750, Win32 error 998 11319792 [main] diff 3760 sig_send: error sending signal -34 to pid 3760, pipe handle 0x750, Win32 error 998 21282830 [main] diff 3760 sig_send: error sending signal -34 to pid 3760, pipe handle 0x750, Win32 error 998 23541033 [main] diff 3760 sig_send: error sending signal -34 to pid 3760, pipe handle 0x750, Win32 error 998 Only in .: diff.exe.stackdump-2 52864686 [main] diff 3760 sig_send: error sending signal -34 to pid 3760, pipe handle 0x750, Win32 error 998 52866298 [main] diff 3760 sig_send: error sending signal -34 to pid 3760, pipe handle 0x750, Win32 error 998 52869051 [main] diff 3760 sig_send: error sending signal -34 to pid 3760, pipe handle 0x750, Win32 error 998 52871923 [main] diff 3760 sig_send: error sending signal -34 to pid 3760, pipe handle 0x750, Win32 error 998 52874798 [main] diff 3760 sig_send: error sending signal -34 to pid 3760, pipe handle 0x750, Win32 error 998 52879422 [main] diff 3760 sig_send: error sending signal -34 to pid 3760, pipe handle 0x750, Win32 error 998 52882299 [main] diff 3760 sig_send: error sending signal -34 to pid 3760, pipe handle 0x750, Win32 error 998 53111327 [main] diff 3760 sig_send: error sending signal -34 to pid 3760, pipe handle 0x750, Win32 error 998 53143058 [main] diff 3760 sig_send: error sending signal -34 to pid 3760, pipe handle 0x750, Win32 error 998 53144671 [main] diff 3760 sig_send: error sending signal -34 to pid 3760, pipe handle 0x750, Win32 error 998 54526911 [main] diff 3760 sig_send: error sending signal -34 to pid 3760, pipe handle 0x750, Win32 error 998 54531401 [main] diff 3760 sig_send: error sending signal -34 to pid 3760, pipe handle 0x750, Win32 error 998 bash-3.2$ Hope this helps Torsten Exception: STATUS_ACCESS_VIOLATION at eip=C128 eax= ebx= ecx=0022B3BC edx=7C90E514 esi= edi= ebp=0022B3C8 esp=0022B3C8 program=C:\cygwin\bin\diff.exe, pid 260, thread main cs=001B ds=0023 es=0023 fs=003B gs= ss=0023 Stack trace: Frame Function Args 0022B3C8 C128 (0724, EA60, 00A4, 0022B4BC) 0022B4D8 610B9EA5 (6120BFEC, 0001, 003B0023, 0023) 0022B598 610BA75A (0001, 0022B654, 10062718, 610CA934) 0022B5A8 610BA7EF (, 0001, 0022B5F8, ) 10062718 610CA934 (6F632F41, 4F2F6564, 536E6570, 682F4143) End of stack trace -- Problem reports: http
Re: [ANNOUNCEMENT] Updated: screen, now with 256-color support!
Andy Koppe andy.koppe at gmail.com writes: Andrew Schulman: Instructions for starting screen with 256 color support are in /usr/share/doc/screen/README.Cygwin. In brief, you have to invoke screen as TERM=screen-256color screen I don't think that's quite right. Screen needs to be told what terminal it is itself running in. This means xterm-256color for xterm, PuTTY and MinTTY, and rxvt-256color for rxvt. Inside screen, however, the TERM variable does need to be set to screen-256color to tell termcap/terminfo-using programs that they are running in a 256-color-enabled screen. The -T option can be used for that. So, for example: TERM=xterm-256color screen -T screen-256color Andy, thanks. Yes, you're right. When I run screen as you suggest, several color artifacts disappear. In particular I get 16 system colors instead of just 8. Instead of specifying -T screen-256color every time, one can just put 'term screen-256color' into .screenrc. I'll update the docs to show this when I make the release current. Andrew. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: 1.7.0-60: diff -qr crashes
On Tue, Sep 01, 2009 at 04:47:16PM +0200, Torsten Sch?tze wrote: Christopher Faylor wrote: Okay, here we are. Using the 2009-09-01 snapshot (cygwin1-20090901.dll.bz2, cygwin1-20090901.dbg.bz2) I obtain: First, in directory 2009 (corresponds to diff.exe.stackdump-1), see attachment diff.exe.stackdump-1-new Exception: STATUS_ACCESS_VIOLATION at eip=C128 eax= ebx= ecx=0022B3BC edx=7C90E514 esi= edi= ebp=0022B3C8 esp=0022B3C8 program=C:\cygwin\bin\diff.exe, pid 260, thread main cs=001B ds=0023 es=0023 fs=003B gs= ss=0023 Stack trace: Frame Function Args 0022B3C8 C128 (0724, EA60, 00A4, 0022B4BC) 0022B4D8 610B9EA5 (6120BFEC, 0001, 003B0023, 0023) 0022B598 610BA75A (0001, 0022B654, 10062718, 610CA934) 0022B5A8 610BA7EF (, 0001, 0022B5F8, ) 10062718 610CA934 (6F632F41, 4F2F6564, 536E6570, 682F4143) End of stack trace Hmm. Not much help. From looking at the code it looks like a corrupted stack except the stack obviously isn't corrupted. Is there any chance that you could send me the contents of the two directories that you're diffing? I understand if this is proprietary stuff but I don't think I'm going to get much from a stackdump or strace. Assuming it's possible, please send a compressed .tar.bz2 file to cgf at cygwin dot com cgf -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
std::arg() bug : not repetitive ?
Hi DaveK,
the following test case on complex numbers
is producing, puzzling result on cygwin (both 1.5 and 1,7)
with gcc-4.3.2 (and also 3.4.4), while working on other platform:
#include iostream
#include oct-cmplx.h
int main ()
{
Complex z1 (1.0, 1.0), z2 (1.0, 1.0);
std::cout (arg(z1)) '\n';
std::cout (arg(z2)) '\n';
std::cout (arg(z1)arg(z2)) '\n';
std::cout (arg(z1)-arg(z2)) '\n';
}
$ g++-4 comp_2.cc -o0 -o comp_2
$ ./comp_2
0.785398
0.785398
1
-3.06287e-17-- arg(1+i) is lower then arg(1+i) !!
Using different complex numbers is also possible to get
arg(-1-i) bigger then arg(-1-i)
Any idea what could cause it ? newlib ?
Thanks
Marco
oct-cmplx.h
Description: Binary data
comp_2.cc
Description: Binary data
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: [ANNOUNCEMENT] Updated: screen, now with 256-color support!
TERM=xterm-256color screen -T screen-256color Instead of specifying -T screen-256color every time, one can just put 'term screen-256color' into .screenrc. I'll update the docs to show this when I make the release current. Is there any reason that I shouldn't put this command into the default /etc/screenrc file? Are there terminal types for which it would cause problems? I just tried this with a DOS terminal, which doesn't support 256 colors AFAIK. It didn't make any difference that I could tell. Maybe I'll put out another test release with that change, and see if anyone complains. A. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: [ANNOUNCEMENT] Updated: screen, now with 256-color support!
Andrew Schulman: TERM=xterm-256color screen -T screen-256color Instead of specifying -T screen-256color every time, one can just put 'term screen-256color' into .screenrc. I'll update the docs to show this when I make the release current. Is there any reason that I shouldn't put this command into the default /etc/screenrc file? 'fraid so. Prompted by this thread I wondered the same thing about mintty: why not set TERM to xterm-256color by default? Answer: because /etc/termcap doesn't know about it, and other programs that read the TERM variable might not recognise it either. Furthermore, user startup scripts that compare TERM to xterm or screen would break. Shame. Andy -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: [ANNOUNCEMENT] Updated: screen, now with 256-color support!
Andrew Schulman: TERM=xterm-256color screen -T screen-256color Instead of specifying -T screen-256color every time, one can just put 'term screen-256color' into .screenrc. I'll update the docs to show this when I make the release current. Is there any reason that I shouldn't put this command into the default /etc/screenrc file? 'fraid so. Prompted by this thread I wondered the same thing about mintty: why not set TERM to xterm-256color by default? Answer: because /etc/termcap doesn't know about it, and other programs that read the TERM variable might not recognise it either. Furthermore, user startup scripts that compare TERM to xterm or screen would break. You're talking about setting e.g. TERM=xterm-256color in the environment by default, but I was asking whether it would cause any harm to put 'term screen-256color' into the default /etc/screenrc. Know any reason that I shouldn't? -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: GNU screen hangs
Christopher Faylor wrote: On Tue, Sep 01, 2009 at 07:12:51AM -0700, Andrew DeFaria wrote: TV wrote: Oh, this is must be a cultural thing about americans and their tanned tongues. Excuse me, I'm off to the tongue tanning salon... ;-) Ok. I've got to stop drinking coffee while reading the cygwin list... Or wear noseplugs. cheers, DaveK -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: std::arg() bug : not repetitive ?
Marco Atzeri wrote:
Hi DaveK,
the following test case on complex numbers
is producing, puzzling result on cygwin (both 1.5 and 1,7)
with gcc-4.3.2 (and also 3.4.4), while working on other platform:
#include iostream
#include oct-cmplx.h
int main ()
{
Complex z1 (1.0, 1.0), z2 (1.0, 1.0);
std::cout (arg(z1)) '\n';
std::cout (arg(z2)) '\n';
std::cout (arg(z1)arg(z2)) '\n';
std::cout (arg(z1)-arg(z2)) '\n';
}
$ g++-4 comp_2.cc -o0 -o comp_2
$ ./comp_2
0.785398
0.785398
1
-3.06287e-17-- arg(1+i) is lower then arg(1+i) !!
Using different complex numbers is also possible to get
arg(-1-i) bigger then arg(-1-i)
Any idea what could cause it ? newlib ?
Or maybe it's PR323 (excess precision) in some aspect. Don't know yet, I'll
have to have a look into it.
cheers,
DaveK
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
struct dirent.d_reclen
Wish list (probably post 7.1): As long as we are making struct dirent more like Linux with the recent addition of d_type, we should probably also burn two of the remaining 3 __d_unused1 bytes to declare unsigned short d_reclen, whose value is always strlen(d_name), so that applications could get by with fewer strlen calls. Coreutils ls would certainly benefit from this optimization. P.S. This is an interesting thread related to struct dirent - it shows that for once, cygwin is doing something more POSIX-y than Linux (ie. POSIX 2008 added a requirement that readdir d_ino always match stat st_ino, even for mount points), and therefore Cygwin actually gets to benefit from a coreutils optimization when Linux doesn't! http://lists.gnu.org/archive/html/bug-coreutils/2009-08/msg00320.html http://lists.gnu.org/archive/html/bug-coreutils/2009-08/msg00331.html http://marc.info/?l=linux-kernelm=125181054102075 -- Eric Blake -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: GNU screen hangs
Andrew DeFaria wrote: Excuse me, I'm off to the tongue tanning salon... ;-) Crazy Americans! Tanning one end while bleaching the other! What's going on in this country?! -- Mark J. Reed markjr...@gmail.com -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: std::arg() bug : not repetitive ?
--- Mar 1/9/09, Dave Korn ha scritto:
Da: Dave Korn
Oggetto: Re: std::arg() bug : not repetitive ?
A: cygwin cygwin.com
Data: Martedì 1 settembre 2009, 19:14
Marco Atzeri wrote:
Hi DaveK,
the following test case on complex numbers
is producing, puzzling result on cygwin (both 1.5 and
1,7)
with gcc-4.3.2 (and also 3.4.4), while working on
other platform:
#include iostream
#include oct-cmplx.h
int main ()
{
Complex z1 (1.0, 1.0), z2 (1.0,
1.0);
std::cout (arg(z1))
'\n';
std::cout (arg(z2))
'\n';
std::cout
(arg(z1)arg(z2)) '\n';
std::cout (arg(z1)-arg(z2))
'\n';
}
$ g++-4 comp_2.cc -o0 -o comp_2
$ ./comp_2
0.785398
0.785398
1
-3.06287e-17 -- arg(1+i) is lower
then arg(1+i) !!
Using different complex numbers is also possible to
get
arg(-1-i) bigger then arg(-1-i)
Any idea what could cause it ? newlib ?
Or maybe it's PR323 (excess precision) in some
aspect. Don't know yet, I'll
have to have a look into it.
cheers,
DaveK
Dave,
thanks for the hint,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323#c2
$g++-4 -ffloat-store comp_2.cc -O3 -o comp_4
./comp_4
0.785398
0.785398
0
0
Regards
Marco
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: std::arg() bug : not repetitive ?
Marco Atzeri wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323#c2 $g++-4 -ffloat-store comp_2.cc -O3 -o comp_4 ./comp_4 0.785398 0.785398 0 0 Ah, good, thanks for the diagnosis. IIUC this is basically fixed in GCC HEAD now and 4.5.0 shouldn't suffer the same problem. cheers, DaveK -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: [ANNOUNCEMENT] Updated: screen, now with 256-color support!
Andrew Schulman: Instead of specifying -T screen-256color every time, one can just put 'term screen-256color' into .screenrc. I'll update the docs to show this when I make the release current. Is there any reason that I shouldn't put this command into the default /etc/screenrc file? 'fraid so. Prompted by this thread I wondered the same thing about mintty: why not set TERM to xterm-256color by default? Answer: because /etc/termcap doesn't know about it, and other programs that read the TERM variable might not recognise it either. Furthermore, user startup scripts that compare TERM to xterm or screen would break. You're talking about setting e.g. TERM=xterm-256color in the environment by default, but I was asking whether it would cause any harm to put 'term screen-256color' into the default /etc/screenrc. Know any reason that I shouldn't? Well, yes. 'term screen-256color' sets TERM=screen-256color in the environment of programs running inside screen, hence any program or script that recognises screen but not screen-256color will no longer work as expected. Furthermore, 'term screen-256color' (or '-T screen-256color') does not activate 256-color mode in screen. It it screen querying terminfo and finding that it is itself running in a 256-color terminal that does that. Hence, when screen is started with the usual TERM setting of xterm or rxvt, you'd end up telling programs running inside screen that 256 colors are available when that isn't actually the case. Andy -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: [ANNOUNCEMENT] Updated: screen, now with 256-color support!
You're talking about setting e.g. TERM=xterm-256color in the environment by default, but I was asking whether it would cause any harm to put 'term screen-256color' into the default /etc/screenrc. Know any reason that I shouldn't? Well, yes. 'term screen-256color' sets TERM=screen-256color in the environment of programs running inside screen, hence any program or script that recognises screen but not screen-256color will no longer work as expected. Furthermore, 'term screen-256color' (or '-T screen-256color') does not activate 256-color mode in screen. It it screen querying terminfo and finding that it is itself running in a 256-color terminal that does that. Hence, when screen is started with the usual TERM setting of xterm or rxvt, you'd end up telling programs running inside screen that 256 colors are available when that isn't actually the case. Got it. Thanks. Andrew. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: [ANNOUNCEMENT] Updated: screen, now with 256-color support!
'term screen-256color' sets TERM=screen-256color in the environment of programs running inside screen, hence any program or script that recognises screen but not screen-256color will no longer work as expected. Btw, a different approach to enabling 256 colour support by default, which doesn't suffer from the problem above and which wouldn't require any faffing about with the TERM variable, would be to bump the 'colors' capability in the xterm, rxvt and screen terminfo entries from 8 to 256. Unfortunately that's not without compatibility issues either though, which affect remote connections. When connecting from Cygwin to a host where those terminfo entries still say 8 colours, 256 colour support would be lost again. Not really a problem though, more just a limitation. The other way round is slightly more problematic. When connecting from another host to Cygwin, the other system's xterm, rxvt or screen might not actually support 256-colour sequences. Yet the application running on Cygwin would think that it did based on the local terminfo entry. This would likely result in no colours at all. Then again, with the 256 colour codes having been around for quite a long time, and Cygwin not exactly being a popular server platform, this scenario seems rather unlikely. (The underlying issue here is that the whole $TERM/termcap/terminfo design is fundamentally broken. The sensible thing to do would be for applications to directly ask the terminal they're actually connected to about its capabilities, rather than consult a humungous local database of mostly long-forgotten terminal types that's pretty much guaranteed to be out-of-date.) Andy -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: std::arg() bug : not repetitive ?
Dave Korn wrote: IIUC this is basically fixed in GCC HEAD now and 4.5.0 shouldn't suffer the same problem. Just for completeness... With 4.5-20090827 snapshot, it does: $ g++-4.5 arg_bug.cpp -o0 -o arg_bug $ ./arg_bug.exe 0.785398 0.785398 1 -3.06287e-17 being (on 1.7): $ g++-4.5 -v Using built-in specs. Target: i686-pc-cygwin Configured with: /tmp/gcc-4.5-20090827/configure --prefix=/usr/local/gfortran --exec-prefix=/usr/local/gfortran --sysconfdir=/usr/local/gfortran/etc --libdir=/usr/local/gfortran/lib --libexecdir=/usr/local/gfortran/lib --mandir=/usr/local/gfortran/share/man --infodir=/usr/local/gfortran/share/info --program-suffix=-4.5 --enable-bootstrap --enable-checking=release --enable-decimal-float=bid --enable-languages=c,c++,fortran --enable-libgomp --enable-libssp --enable-nls --enable-threads=posix --enable-version-specific-runtime-libs --disable-fixed-point --disable-libmudflap --disable-shared --disable-sjlj-exceptions --disable-win32-registry --with-arch=i686 --with-dwarf2 --with-system-zlib --with-tune=generic --without-included-gettext --without-x Thread model: posix gcc version 4.5.0 20090827 (experimental) (GCC) Cheers, Angelo. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: struct dirent.d_reclen
On Tue, Sep 01, 2009 at 05:39:02PM +, Eric Blake wrote: Wish list (probably post 7.1): As long as we are making struct dirent more like Linux with the recent addition of d_type, we should probably also burn two of the remaining 3 __d_unused1 bytes to declare unsigned short d_reclen, whose value is always strlen(d_name), so that applications could get by with fewer strlen calls. Coreutils ls would certainly benefit from this optimization. Defining d_*rec*len as strlen(d_name) would not be correct since that is supposed to be the length of the record not the name. That's why linux has macros that look like this: # define _D_ALLOC_NAMLEN(d) (((char *) (d) + (d)-d_reclen) - (d)-d_name[0]) Maybe you mean d_namlen? It is not a given that adding d_reclen would speed anything up since it cause every single program that uses dirent to effectively perform a strlen on every record returned by readdir whether it needed that field or not. Making sure that field was filled out would also complicate Cygwin's internal logic. cgf -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: How to install QT in CYGWIN
On 25/08/2009 11:19, Larry Hall (Cygwin) wrote: On 08/25/2009 04:28 AM, Pok Wilson wrote: I am intending to use QT4.5.3 to create my GUI. 4.5.3? The latest upstream release is 4.5.2. Sorry my mistake, you're right its QT 4.5.2. I'm no QT expert (and I actually haven't even touched it in years) but from what I can see, only QT3 is available as part of the release. Correct. http://sourceware.org/ml/cygwin-apps/2007-07/msg00125.html I did manage to get Qt4 working some time ago. Cygwin Ports provides Qt 4.4.3 for Cygwin 1.5 and 4.5.2 for 1.7. Not sure how far he got, since Cygwin Ports (cygwinports.dotsrc.org) isn't accessible to me at the moment. So perhaps there is a QT4 floating around for Cygwin 1.5.x on that site. If not, you'd have to build it yourself. SunSITE stopped their project hosting some time ago; Ports' new home is: http://cygwinports.org/ I went to the cygwinports website. As I am quite new to this, I dont really understand what to do. There are some steps to follow. 1. Use the current Cygwin setup.exe. 2. Launch setup.exe, and Download Without Installing from your favourite Cygwin mirror as normal. 3. Launch setup.exe again with the -X flag and choose Download Without Installing. 4. Add and select ftp://sourceware.org/pub/cygwinports (or a sourceware mirror) in the mirror list. 5. Select the packages of your choice and their dependencies and updates for download. 6. From a Cygwin shell, run this command: sed -i -e /^setup-timestamp:/ s/ \(.*\)/ $(date +%s)/ \ $(cygpath -u $(cat /etc/setup/last-cache))/ftp%3a%2f%2fsourceware.org%2fpub%2fcygwinports/setup.ini 7. Launch setup.exe once more and Install from Local Directory. I'm stuck at point number 3. How do i lauch setup again with the -X flag? So is it after following this steps i can install QT4 in Cygwin? If it is possible, can someone who has done this before provide a step-by step instructions on exactly what i must do? Yaakov Cygwin Ports I'm just curious that nowadays applications are all GUI.. I was thinking many people will be facing this same issue as me.. How do you guys compile GUI application in Cygwin? Please note that Ports packages are supported on their own mailing list. And to answer the inevitable question: I can't ITP this yet because there are a number of dependencies still missing from the distro. Where can I still get QT 3 if QT 4 fails? There is this message from Yaakov a while back about QT4: New Email names for you! Get the Email name you#39;ve always wanted on the new @ymail and @rocketmail. Hurry before someone else does! http://mail.promotions.yahoo.com/newdomains/sg/ -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: std::arg() bug : not repetitive ?
Angelo Graziosi wrote: Dave Korn wrote: IIUC this is basically fixed in GCC HEAD now and 4.5.0 shouldn't suffer the same problem. Just for completeness... With 4.5-20090827 snapshot, it does: $ g++-4.5 arg_bug.cpp -o0 -o arg_bug $ ./arg_bug.exe 0.785398 0.785398 1 -3.06287e-17 Thanks for checking up on this. It's possible we might need to add some kind of fpu mode init to the CRT. On the other hand, comment #127 in the PR suggests to me that maybe we need to use the new command-line flag. Hang on a minute... -fexcess-precision=standard works only for C and ObjC. $ g++-4 comp_2.cc -o0 -o comp_2 -I /usr/include/octave-3.2.0/octave $ ./comp_2.exe 0.785398 0.785398 1 -3.06287e-17 $ g++-4 comp_2.cc -o0 -o comp_2 -I /usr/include/octave-3.2.0/octave -fexcess-pr ecision=standard cc1plus: sorry, unimplemented: -fexcess-precision=standard for C++ $ Bah. Still, at least the -ffloat-store workaround still helps, for this case at any rate. Also, if you get GCC to use SSE instructions, there's no issue with excess precision: $ g++-4 comp_2.cc -o0 -o comp_2 -I /usr/include/octave-3.2.0/octave -march=pent ium4 -msse -mfpmath=sse $ ./comp_2.exe 0.785398 0.785398 0 0 $ However it does look like it's not going to get fully fixed for C++ until someone with some serious language-lawyering skills can spend some time defining the exact semantics. cheers, DaveK -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: struct dirent.d_reclen
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Christopher Faylor on 9/1/2009 5:37 PM: Maybe you mean d_namlen? Yes; serves me right for confusing readdir(2) and readdir(3) man pages. It is not a given that adding d_reclen would speed anything up since it cause every single program that uses dirent to effectively perform a strlen on every record returned by readdir whether it needed that field or not. Not so. For example, fhandler_disk_file::readdir_helper is already doing a sys_wcstombs to populate the d_name buffer, and that returns the length as a side effect. In other words, the cost of providing the length to the client is an O(1) single assignment of an already-existing value per entry (and when you consider that we are already assigning __d_unused1 to 0, that means no net increase in cost to clients that don't care about the length); whereas the current situation requires clients that care about the length to use O(n) strlen() and duplicate something that was previously calculated by cygwin1.dll. - -- Don't work too hard, make some time for fun as well! Eric Blake e...@byu.net -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkqdxfwACgkQ84KuGfSFAYC25wCgukOyTo5JpQ5c1wMk2HhpcJtD MrUAn2qUnrv2+w4SsGjf6BKzjawc6ndA =q8gE -END PGP SIGNATURE- -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: struct dirent.d_reclen
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Eric Blake on 9/1/2009 7:10 PM: According to Christopher Faylor on 9/1/2009 5:37 PM: Maybe you mean d_namlen? Yes; serves me right for confusing readdir(2) and readdir(3) man pages. Actually, it looks like Linux has only d_reclen (and that d_namlen is a documentation bug): http://www.kernel.org/doc/man-pages/online/pages/man3/readdir.3.html and that Linus prefers d_reclen over d_namlen from the kernel side of things (where, in the Linux kernel, d_reclen is always aligned, such that adjusting d_reclen by offsetof(struct dirent,d_name) can be larger than strlen(d_name)): http://lkml.indiana.edu/hypermail/linux/kernel/9506/0033.html So Linux doesn't provide d_namlen, and coreutils can't optimize for known lengths on Linux. But BSD does: http://www.gsp.com/cgi-bin/man.cgi?section=5topic=dir At any rate, coreutils uses a macro _D_EXACT_NAMELEN(dirent), which evaluates to either d_namlen, a calculation on d_reclen (if d_reclen is accurate enough*), or a call to strlen() if all else fails; so that it is portable to whichever the underlying semantics happen to be. * If d_reclen minimally rounds up to an aligned size, for example if it is only at most 8 bytes larger than strlen(d_name), then it is still faster to do a strchr(,0)-d_name from a starting point 8 bytes before where d_reclen says the record ends, rather than strlen(d_name[0]). - -- Don't work too hard, make some time for fun as well! Eric Blake e...@byu.net -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkqdzKQACgkQ84KuGfSFAYBtsQCgvYcI8Y7CLJOYxPKIySgwCpJn dvAAoIVO47y0+F24lGktxBAF6gbj0rlh =Zctr -END PGP SIGNATURE- -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: GNU screen hangs
Mark J. Reed wrote: Andrew DeFaria wrote: Excuse me, I'm off to the tongue tanning salon... Â ;-) Crazy Americans! Tanning one end while bleaching the other! What's going on in this country?! Here in America we treat both black and white equally! ;-) Now what was I supposed to be bleaching again... -- Andrew DeFaria http://defaria.com Can fat people go skinny-dipping? -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
