Re: Printing locally.
On Sat, Mar 02, 2002 at 11:40:47PM -0500, David Means wrote: > I don't have my cygwin machine handy, so I've got to ask: > > how about this: > > cat a.txt > /cygdrive/c/WINNT/lpt1 > > that's probably not the ultimate solution, but does it work? No. It reports nothing and does nothing. There is nothing in any printer queue. PRINT a.txt reports that /a.txt is currently being printed, but again nothing happens and there is nothing in the queues. Thanks for the suggestion. I remain very puzzled. Brian. > David > > > > On Sat, 2002-03-02 at 21:52, Brian Salter-Duke wrote: > > On Sat, Mar 02, 2002 at 02:45:57AM -0500, Paul McFerrin wrote: > > > Brian: > > > > > > I used to be able to print from cygwin by refering to /dev/lpt1 > > > > > > -paul mcferrin > > > > There is no /dev directory! "which lpt1" gives "/cygdrive/c/WINNT/lpt1", > > but typing "lpt1 file" gives permission denied and looking in WINNT with > > Windows Explorer I do not find it. I'm even more puzzled. > > > > Cheers, Brian. > > > > [my original query about how to print to a local printer deleted.] > > > > -- > >Brian Salter-Duke (Brian Duke) [EMAIL PROTECTED] > > Honorary Fellow in Chemistry, NT University, Darwin, NT 0909, Australia. > > Phone 08-89881600.Fax 08-89881302.http://lacebark.ntu.edu.au/ > > > > -- > > Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple > > Bug reporting: http://cygwin.com/bugs.html > > Documentation: http://cygwin.com/docs.html > > FAQ: http://cygwin.com/faq/ > -- > > No trees were killed in the sending of this message. However, > a large number of electrons were terribly inconvenienced. -- Brian Salter-Duke (Brian Duke) [EMAIL PROTECTED] Honorary Fellow in Chemistry, NT University, Darwin, NT 0909, Australia. Phone 08-89881600.Fax 08-89881302.http://lacebark.ntu.edu.au/ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
ICEWM Window manager for cygwin XFree86
Hi there, I have managed to get Cygwin to work, but am stuck with the default window manager for XFree86 (twm). I have downloaded icewm 1.0.9-2 via the link on xfree86.cygwin.com. Whilst it apperars to be installed and I have replaced all refferences to twm with icewm, the default is all I get when I start X (via any method)... Any help appreciated. Also, I have used Winaxe before and manage to remotely start kwrite from my BSD box and display on my windows (XP) box. Whilst other X programs on the BSD box start fine with the Cywin XFree, kstart -display myXPBox:0 kwrite does not. again, any ideas appreciated. Thanks Mike -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: "start" for Cygwin
So just call it differently. It would be nice if this could replace my little shell script "st": #!/bin/bash for i do start "$(cygpath -w "$i")" done (start being /c/Windows/command/start.exe) Gruesse, Carsten -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: Is the Cygwin 1.3.2 DLL Win 2000 compatible?
On Friday 1 Mar 02, Larry Hall (RFK Partners, Inc) writes: > Perhaps. It's an esoteric one. The original poster of this question wanted > to know if Cygwin 1.3.2 would work with Win2000. I replied with the FAQ > entry that says Cygwin works with 9x/Me/NT/W2K/XP. The reply I got back > from the poster then was that he had seen this entry but thought it > referenced only the current Cygwin DLL (1.3.9 at that point). So the only > question I was raising was whether you think it would be more or less > confusing to people to add some wording to the FAQ entry that specifies > that any recent Cygwin DLL works with Windows, not just the latest. > It's not clear to me that this additional wording wouldn't raise more > questions than it answers. Judging by your response, I think leaving things > as is may be the best option. What do you think? I think it's best to leave this entry as it is. Thanks, David -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: "start" for Cygwin
On Saturday 2 Mar 02, Stephan Mueller writes: > Note though, that on Win9x, start is a standalone file (I forget if it's > start.exe or start.com) on the path. > Cygwin still supports 9x, so fears about consternation in some quarters > still apply (it's just that they're different quarters than Charles > originally had in mind :-) I use Win9x, and I don't think it's a problem for the cygutils package to introduce /usr/bin/start. People who install the cygutils package can probably figure out what's going on. My opinion, anyway. David -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Printing locally
What about this? Any good? If the file a.txt is DOS terminated, try cp a.txt prn OR cat a.txt > prn and if a.txt is Unix-terminated, try cat a.txt | unix2dos > prn Fergus -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: "start" for Cygwin
I think cygstart or something like that will eliminate the potiential for touble. Rob > -Original Message- > From: David Starks-Browning [mailto:[EMAIL PROTECTED]] > Sent: Sunday, March 03, 2002 8:32 PM > To: [EMAIL PROTECTED] > Subject: RE: "start" for Cygwin > > > On Saturday 2 Mar 02, Stephan Mueller writes: > > Note though, that on Win9x, start is a standalone file (I forget if > > it's start.exe or start.com) on the path. Cygwin still > supports 9x, so > > fears about consternation in some quarters still apply > (it's just that > > they're different quarters than Charles originally had in mind :-) > > I use Win9x, and I don't think it's a problem for the > cygutils package to introduce /usr/bin/start. People who > install the cygutils package can probably figure out what's going on. > > My opinion, anyway. > > David > > > -- > Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple > Bug reporting: http://cygwin.com/bugs.html > Documentation: http://cygwin.com/docs.html > FAQ: http://cygwin.com/faq/ > > -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: "start" for Cygwin
On Sunday 3 Mar 02, Robert Collins writes: > I think cygstart or something like that will eliminate the potiential > for touble. Indeed, that would solve it! David -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
<<冰箱空调省电器>>招商(Introductory toAiYong energy saver)
×ð¾´µÄÏÈÉú/Ůʿ£º ÄúºÃ£¡Èç¹ûÎÒÃǵÄÓʼþ¸øÄú´øÀ´²»±ã£¬ÇëÄú°ïÎÒÃÇɾ³ý£¡ °®ÓÃÅÆÊ¡µçÆ÷--<<±ùÏä¿Õµ÷Ê¡µçÆ÷>> ³ÏÕ÷È«¹ú¸÷Ê¡ÊдúÀíÉÌ Ò»ÖÖÐÂÐ͵ĽڵçÆ÷-±ùÏä¿Õµ÷Ê¡µçÆ÷ÃæÊÀÁË£¬¸Ã²úÆ·ÊǸù¾Ý¹ú¼Ò×îÐÂרÀû<<±ùÏä¡¢¿Õµ÷Æ÷µÄÊ¡µç×°ÖÃ>>Éè¼Æ¶ø³É£¨×¨ÀûºÅ£ºZL99212326.7£©,ÈÙ»ñÏã¸ÛÖлª×¨Àû²©ÀÀ»á½ð½±ºÍÊÀ½ç·¢Ã÷¼Ò¹ú¼Êлá°ä·¢µÄ¹ú¼Ê·¢Ã÷½ð½±£»ÀûÓÃÊý×Ö¼¯³Éµç·µÈ¸ßм¼Êõʹ½ÚµçÂʸߴï30%×óÓÒ£¬²¢¾ßÓÐÀ´µçÑÓʱÆô¶¯±£»¤¹¦ÄÜ£¬ÄÜÑÓ³¤±ùÏä¡¢¿Õµ÷µÈÓõçÆ÷µÄʹÓÃÊÙÃü£¬Äܹ㷺ӦÓÃÓÚ¼ÒÍ¥¡¢±ö¹Ý¡¢É̳¡¡¢¹¤³§µÈÓÐÖÆÀäÉ豸ºÍµçÈÈÉ豸µÄ³¡Ëù¡£ ÊÊÓ÷¶Î§£º AÐÍ£ºÊÊÓÃÓÚ±ùÏ䡢ѩ¹ñ¡¢ÒûË®»ú¡¢µçÈÈ̺¡¢µçůÆ÷µÈ¡£ BÐÍ£ºÊÊÓÃÓÚ´°ÐÍ¡¢¹Òʽ¡¢¹ñʽ¿Õµ÷¼°¸÷ÀàÀ䶳»úµÈ¡£ ÏÖÎÒ³§³ÏÕ÷È«¹ú¸÷Ê¡ÊдúÀíÉÌ£¬²¢¿ªÕ¹³§¼ÛÖ±ÏúÓʹºÒµÎñ£¬ÏêÇéÇë¿´ÎÒ³§ÍøÒ³¡£ ÁªÏµÈË£ºÔø¸£ÔÆ ÔøÁÁ ×Éѯµç»°£º86-20-84613439 86-013802832046 86-013609685760 ÍøÖ·£ºwww.aysdq.com.cn E-mail£º[EMAIL PROTECTED] Dear gentleman /lady£º How do you do! If the mails of we bring to you inconvenient and please help us to delete! The energy saver -- The electricity saving instrument for refrigerator and aircondition. (Advertise for the national each province and municipality sincerely and act as agent and develop the business of mail-ordering) This product is designed and produced based on the latest standard of national refrigerator(patent No£ºZL99212326.7)£»Awarded gold prize from HK-and-To meet the demand of national and international market. New design£¬Easy operation and effective energy saving(Saving rate 15%-30%)¡£ Scope of application£º A type£ºSuitable for refrigerator, snow cupboard, drinking machine, electric blanket, electric heater,etc.. B type£ºSuitable for window type, hanging type, the cupboard type air conditioner and all kinds of refrigerators,etc.. Now our factory advertise for national each province and municipality agents sincerely, develop price at factory mail-order business by direct selling, details think our factory webpage. Contact person£º ZengFuYun ZengLiang The consulting telephone£º86-20-84613439 86-013802832046 86-013609685760 The website£ºwww.aysdq.com.cn E-mail£º[EMAIL PROTECTED] -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: "start" for Cygwin
At 06:16 3-3-2002, Charles Wilson wrote: >Michael Schaap wrote: > >Hmmm...how does this differ from the "run" utility here: > >http://www.neuro.gatech.edu/users/cwilson/cygutils/unversioned/run/ > >It may be entirely different; I'm not sure. Certainly they were written >for different purposes. Run was intended to hide the console for GUI >programs that still expect a stdout/stderr console. Well, they seem somewhat related, but they do play different roles, and I don't think one can replace the other. (The code is very different, by the way. They use different APIs - "start" is essentially just a wrapper around the ShellExecute function.) >Run doesn't use popt :-( so it doesn't have pretty help, but it can be >compiled as a native windows app :-) > >Anyway, I personally have no objection to including start in cygutils -- >but the sudden appearance of a 'start.exe' command in /usr/bin (which >could hide WINNT/start.exe) may cause consternation in some quarters. > >FYI, I've just completed the following HOW-TO-CONTRIBUTE (to cygutils) >document. It will show up in /usr/doc/cygutils-X.Y.Z/ in the next release >of cygutils. OK, once the discussion settles, and the final name is decided, I'll make a contribution according to this document. Thanks, - Michael -- I always wondered about the meaning of life. So I looked it up in the dictionary under "L" and there it was - the meaning of life. It was not what I expected. - Dogbert -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: "start" for Cygwin
At 09:45 3-3-2002, Dr. Carsten Bormann wrote: >So just call it differently. > >It would be nice if this could replace my little shell script "st": > >#!/bin/bash >for i >do > start "$(cygpath -w "$i")" >done > >(start being /c/Windows/command/start.exe) It would. (Only, your "st" script treats multiple arguments as multiple documents/programs to open, "start" uses the second and following arguments as arguments to the program/document to open.) I see that you are using Windos 9x/ME. Have you tried my "start", and if so, is it working? I believe it is _supposed_ to work under Win9x, but we'd better make sure before this is included in cygutils... Thanks, - Michael -- I always wondered about the meaning of life. So I looked it up in the dictionary under "L" and there it was - the meaning of life. It was not what I expected. - Dogbert -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: "start" for Cygwin
At 12:58 3-3-2002, David Starks-Browning wrote: >On Sunday 3 Mar 02, Robert Collins writes: > > I think cygstart or something like that will eliminate the potiential > > for touble. > >Indeed, that would solve it! It would. I have mixed feelings about this, though. On the one hand, calling it "start" may cause problems for people using Win9x/Me, who put ...\cygwin\bin at the front of their path in AUTOEXEC.bat, and try to run "start" from command.com. On the other hand, this is really a Cygwin version of the cmd.exe builtin (or Win9x external command) "start", and it would be really nice if people could just run "start myfile.ext" OOTB. Anyway, I prefer "start", but can live with "cygstart". The "Cygwin community" should decide. (cgf or Corinna, any opinions?) Thanks, - Michael -- I always wondered about the meaning of life. So I looked it up in the dictionary under "L" and there it was - the meaning of life. It was not what I expected. - Dogbert -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: fetchmail 5.9.8 and maildrop 1.3.7
Jason, On Sat, Mar 02, 2002 at 09:47:19PM -0500, Jason Tishler wrote: > Rui, > > > I was under the impression that recv() bugs had been twiddled in > > 1.3.10... Or did the changes in recv() not address MSG_PEEK? > > Hmm, I will look into this. It would be great if my patch just became > obsolete. The release notes (post by Cristopher: http://sources.redhat.com/ml/cygwin/2002-02/msg01350.html) mention recv() explicitly: > - Implement socket read/write using recv/send. (corinna) Bit vague, though, so I don't know if Corinna tackled the MSG_PEEK issue. Mind you, the thought has crossed my mind that XP has a tweaked TCP/IP stack, but we're getting into Twilight Zone stuff here... I'll probably filter my e-mail to another box for a few weeks (build up a REAL large mailbox), then let my 'clean' build of fetchmail have a go at 100 or so megs of mail a couple of times, and diff the results ;) > > I'm also not entirely sure that fetchmail is not the one inserting > > (or handing over, or whatever) the extra blank line upon mailbox creation > > (appends work fine...). I'll have to check later. > > My WAG would be on the MDA (i.e., maildrop) not fetchmail. BTW, I have > had no such problems with procmail regardless of mailbox creation or > appending. Well... Since it's a single blank line, it might actually come from anywhere. I've run maildrop from the command line, faked all the right inputs, and it workedfine (no blank line). But then, I'm not an MTA, so I might have screwed up someplace. Again, I use mutt mostly over IMAP-SSL (and need to access my e-mail from far too many boxes to feel comfortable with it being fetched just to my laptop), so I'm not going to look into this much further for now. > > Anyway, if you've been using fetchmail + procmail since September, > > what's keeping it from being added to the packages list? :) Is it the > > BIND issue? > > No, it's not BIND -- it's just laziness on my part. I really would like > to contribute fetchmail and procmail. Unfortunately, it appears that I > have chosen unwisely selecting the packages that I currently maintain -- > PostgreSQL and Python. These two seem to keep me quite busy. Ouch. :) > Maybe I should have chosen packages that no one ever uses. You know... > Shelfware. That would have minimized my support efforts. :,) LOL. Well, I got ion (http://www.students.tut.fi/~tuomov/ion/), the minimalistic screen-like X window manager to run properly under cygwin-xfree, and would hearltily recommend it as one such package :) (Actually, I find ion pretty useful, although my build of GTKYahoo - yes, under Cygwin - it CAN be done... - tends to freak out under it.) > > (I'd be glad to lend a hand, mind you...) > > If you would like to contribute BIND, fetchmail, or procmail, please let > me know. I will supply you with my build recipes and help you in anyway > that I can. Okay. Here's the deal: I'm going to dive into rxvt (the cursor display corruption bug is really annoying for me, since I _want_ to use Lucida Console as a display font under TrueType), and if I can get anywhere, I'll probably take up your offer on fetchmail. (procmail is far too arcane for me, I must admit) Rui Carmo -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
setup.exe (cinstall) bugfixes + minor new feature
I've been working with the setup code, and have discovered some bugs in the
current (just updated) CVS version.
I'm posting a patch here for comments, whilst I join cygwin-patches, and
study the Contributing instructions.
The patch does the following:
BugFix: io_stream::mkpath_p(isadir, path) misuse
mkpath_p is supposed to take a path with either a file:// or a cygfile://
prefix, but it is fed a path with no prefix in some places. The patch adds a
file:// prefix where needed.
This was causing some directories not to be created, including the Cygwin
directory in the start menu.
BugFix: add backslash call to make_link, in desktop.cc
This was causing the start menu shortcut to be called
'Programs/Cygwin/Cygwin Bash Shell' instead of being in the correct
directory structure
Feature Addition: Use files /etc/setup/inhibit-{startmenu,desktop}-icon to
remeber user de-selection of the create icon checkboxes on the last page of
setup.
Max.
currwork.patch
Description: Binary data
smime.p7s
Description: application/pkcs7-signature
w32api bugfix (was: Currently, CVS setup.exe does not compile, due to warnings with 'warnings as errors' in effect. How best to change code to avoid warnings?)
> Hmm, does C++ support the same feature? If not then an ifdef __cplusplus > might do it. > Rob Unfortunately not - the problem is the differing interpretation of the line 'typedef int (WINAPI *FARPROC)();' in 3 sets of circumstances: 1) C++ 'int proc();' and 'int proc(void);' are synonyms. No problem. 2) C, -Wstrict-prototypes NOT in effect 'int proc();' means: use no compiler type checking for the parameters if proc 'int proc(void);' means: proc takes no parameters 3) C, -Wstrict-prototypes in effect 'int proc();' means: ditto AND causes a warning (which, since setup is compiled with 'warnings as errors' on, stops the build) 'int proc(void);' means: ditto Summary: The construct 'typedef int (WINAPI *FARPROC)();' in w32api causes an error with -Wstrict-prototypes -Werror. This can be worked around by adding 'void' in the empty brackets. Downside: This breaks C code where people were using the w32api types FARPROC, NEARPROC, PROC, to call procedures without typechecking the arguments. I think this is totally irrelevant, as deliberately bypassing the compiler type checking is very silly, and I doubt anyone does that anymore. Anyway, before I go submitting a patch which breaks backward compatibility, even in such a rare and unused case, I want to raise this issue here. Max. smime.p7s Description: application/pkcs7-signature
Re: "start" for Cygwin
I think there was a start.exe in Win9x/Me (i.e. it was not a command.com builtin), but my Win9x days are mercifully over, so I can't say for sure. Nevertheless, a cygutils start could be a useful scripting tool. > Ah -- and that explains why one previously had to do "cmd /c start foo" > from a bash shell. Okay, according to my tests (I put a 'start' shell > script in my /usr/bin directory.) From bash, 'start foo' causes my > script to run. From cmd, 'start foo' causes the builtin cmd command to > run (even tho D:/cygwin/bin is in the front of my PATH). > > This is good -- I withdraw my objection (such as it was). > > Anybody else think this is a good cygutil? I think it *probably* is... > > --Chuck > > > Robert Collins wrote: > > > Start is a cmd builtin - there is no start.exe > > > > Rob > > > > > > > > > >>-Original Message- > >>From: Charles Wilson [mailto:[EMAIL PROTECTED]] > >> > > Anyway, I personally have no objection to including start in cygutils -- > > > > but the sudden appearance of a 'start.exe' command in /usr/bin (which > > could hide WINNT/start.exe) may cause consternation in some quarters. > > > > FYI, I've just completed the following HOW-TO-CONTRIBUTE (to cygutils) > > document. It will show up in /usr/doc/cygutils-X.Y.Z/ in the next > > release of cygutils. > > > > --Chuck > > > > > > > > > > -- > Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple > Bug reporting: http://cygwin.com/bugs.html > Documentation: http://cygwin.com/docs.html > FAQ: http://cygwin.com/faq/ > > -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
terminal emulation problem
Has anyone executed the FTP command client and issued the shell escape '!' recently ? This worked fine in 1.3.3 but in the updates (including 1.3.10), there are garbage characters displayed by the bash shell, and after any command. There seems to be some change in the terminal settings. This is breaking a number of scripts I have that rely on using the FTP client to automate some remote operations... If anyone knows a fix or setting change to correct this, please post. Thanks -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: setup.exe (cinstall) bugfixes + minor new feature
Thanks Max.
> -Original Message-
> From: Max Bowsher [mailto:[EMAIL PROTECTED]]
> Sent: Monday, March 04, 2002 4:54 AM
> To: [EMAIL PROTECTED]
> Subject: setup.exe (cinstall) bugfixes + minor new feature
>
>
> I've been working with the setup code, and have discovered
> some bugs in the current (just updated) CVS version.
>
> I'm posting a patch here for comments, whilst I join
> cygwin-patches, and study the Contributing instructions.
>
> The patch does the following:
>
> BugFix: io_stream::mkpath_p(isadir, path) misuse
> mkpath_p is supposed to take a path with either a file:// or
> a cygfile:// prefix, but it is fed a path with no prefix in
> some places. The patch adds a file:// prefix where needed.
> This was causing some directories not to be created,
> including the Cygwin directory in the start menu.
I know about these - they are fixed in setup200202 - when that goes live
I'll be backporting some key bugs.
> BugFix: add backslash call to make_link, in desktop.cc
> This was causing the start menu shortcut to be called
> 'Programs/Cygwin/Cygwin Bash Shell' instead of being in the
> correct directory structure
Does this affect setup200202? I haven't checked yet. I'm trying to
encpasulate the path specific knowledge - so whilst this solution works,
I'd rather refactor make_link to leverage io_stream, and make this a
method or variant of the file:// io_stream. Also '/' separated paths are
valid to pass to the WIN32 API, so I'm curious why this is suddenly
become a problem. (Quite a lot of setup expects '/' separated paths, and
I see no reason to change that at this point.
> Feature Addition: Use files
> /etc/setup/inhibit-{startmenu,desktop}-icon to remeber user
> de-selection of the create icon checkboxes on the last page of setup.
This approach is too simple - it will only remember turning them off.
The settings should go in /etc/setup/setup.conf as something like
"desktop_icon = yes|no".
Thanks for the patch though, I look forward to an update.
Cheers,
Rob
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
RE: w32api bugfix (was: Currently, CVS setup.exe does not compile, due to warnings with 'warnings as errors' in effect. How best to change code to avoid warnings?)
> -Original Message- > From: Max Bowsher [mailto:[EMAIL PROTECTED]] > Sent: Sunday, March 03, 2002 9:36 PM > To: [EMAIL PROTECTED] > Subject: w32api bugfix (was: Currently, CVS setup.exe does > not compile, due to warnings with 'warnings as errors' in > effect. How best to change code to avoid warnings?) > > > > Hmm, does C++ support the same feature? If not then an ifdef > > __cplusplus might do it. > > Unfortunately not - the problem is the differing > interpretation of the line 'typedef int (WINAPI *FARPROC)();' > in 3 sets of circumstances: > > 1) C++ > 'int proc();' and 'int proc(void);' are synonyms. No problem. Does the error trigger under g++ ? IIRC your original post correctly, it does. If so, then gcc's warning is flawed. > 2) C, -Wstrict-prototypes NOT in effect > 'int proc();' means: use no compiler type checking > for the parameters if proc > 'int proc(void);' means: proc takes no parameters Ah, this is the killer then. Do we actually hit this during a C file compilation? We've only a couple of C files - autoload and mklink2. I wonder if we can detect that -Wstrict-prototypes is on in the header - something like #if !pramga(strict-on) || defined (_cplusplus) ... #endif > Summary: > The construct 'typedef int (WINAPI *FARPROC)();' in w32api > causes an error with -Wstrict-prototypes -Werror. This can be > worked around by adding 'void' in the empty brackets. > Downside: > This breaks C code where people were using the w32api types > FARPROC, NEARPROC, PROC, to call procedures without > typechecking the arguments. I think this is totally > irrelevant, as deliberately bypassing the compiler type > checking is very silly, and I doubt anyone does that anymore. Actually, they do. Someone turned the (void) off again after I'd put it in there because the X code needed it. > Anyway, before I go submitting a patch which breaks backward > compatibility, even in such a rare and unused case, I want to > raise this issue here. Thank you. Rob -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
bash in Explorer Context menu (like "DOS here")
Hi there, I'd like to know whether it is possible to have the abitlity to open a bash shell from a folder's context menu in Windows Explorer (like the MS powertool 'doshere')? thx INF, hans -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
missed one...
The news group is: http://groups.google.com/groups?hl=en&group=alt.baldspot -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: missed one...
Sorry. I selected newgroup post instead of new mail in OE ! "Phil Smith" <[EMAIL PROTECTED]> wrote in message news:a5u69h$phr$[EMAIL PROTECTED].; > The news group is: > > http://groups.google.com/groups?hl=en&group=alt.baldspot > > > > > > -- > Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple > Bug reporting: http://cygwin.com/bugs.html > Documentation: http://cygwin.com/docs.html > FAQ: http://cygwin.com/faq/ > > -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: terminal emulation problem
Phil, I cannot confirm what you say using BASH under either a Windows console or RXVT. Everything seems to work as expected. Tell us more about your shell / emulator configuration, what you're doing and the specific unwanted characters that appear. By the way, is your $SHELL setting consistent with the shell you use for interactive use? I'm pretty sure the ftp program is going to use $SHELL as the shell that executes "!" commands. Another thing, are your .profile / .bashrc (or whichever get executed by your shell during startup) properly written to be quiet when operating non-interactively? Randall Schulz Mountain View, CA USA At 13:09 2002-03-03, Phil Smith wrote: >Has anyone executed the FTP command client and issued the shell escape '!' >recently ? This worked fine in 1.3.3 but in the updates (including >1.3.10), there are garbage characters displayed by the bash shell, and >after any command. There seems to be some change in the terminal settings. >This is breaking a number of scripts I have that rely on using the FTP >client to automate some remote operations... If anyone knows a fix or >setting change to correct this, please post. > >Thanks -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: "start" for Cygwin
> I see that you are using Windos 9x/ME. Have you tried my "start", and if > so, is it working? I believe it is _supposed_ to work under Win9x, but > we'd better make sure before this is included in cygutils... Will do the next time I have time to kill (i.e., not too soon). Gruesse, Carsten -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: "start" for Cygwin
Michael Schaap <[EMAIL PROTECTED]> writes: > Hi, > > I've written a little "start" utility, which is similar to "cmd /c > start", only better. Just tried it under Win98SE -- looks like it works great. I'm all for adding this to cygutils (but I definitely think "cygstart" is a smarter name choice -- saves confusion). -- scott evans :: www.antisleep.com -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
adding a new program to cygwin?
hello! i have written a small game, and it would be a great honour for me to see it as an official package bundled with cygwin. the game's name is nInvaders, its homepage is http://dettus.dyndns.org/ninvaders.; check it out, it only needs ncurses to run. -- __ / / __/__ __/__ __/ / / // _/ / / / _/ / // / / /_/ /_\ \ /___/___/ /_//_/ /_// (est 1991) keep up good work! -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: adding a new program to cygwin?
Thomas Dettbarn wrote: > > hello! > > i have written a small game, and it would be a great honour for me to see it > as an official package bundled with cygwin. the game's name is nInvaders, its > homepage is http://dettus.dyndns.org/ninvaders. check it out, it only needs > ncurses to run. If you're interested in contributing and mantaining this game as a cygwin package please follow the steps outlined in the Cygwin Package Contributors Guide page (http://cygwin.com/setup.html) > -- > __ > / / __/__ __/__ __/ / / // _/ >/ / / _/ / // / / /_/ /_\ \ > /___/___/ /_//_/ /_// (est 1991) > keep up good work! > -- Med venlig hilsen / Kind regards Hack Kampbjørn -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
long delays on fhandler_base::open with cygwin 1.3.10
I'm using Cygwin 1.3.10 DLL and I occasionally get long delays (>2s !) when fhandler_base::open is called on a disk file. This occurs sporadically and is not dependant on the file being opened. I've included a little strace snippet below. Just look how long fhandler_base::open takes to return! No other CPU intensive programs are running and, no, I'm not selecting text in the console window and not realising it... :-) Regards Chris 2992 6679406 [main] base 2324 symlink_info::check: not a symlink 1060 6680466 [main] base 2324 symlink_info::check: 0 = symlink.check (C:\cygwin \opt\kde2\lib\cygkcm_background.dll, 0x22F4B4) (0xA) 1579 6682045 [main] base 2324 path_conv::check: root_dir(C:\), this->path(C:\cy gwin\opt\kde2\lib\cygkcm_background.dll), set_has_acls(8) 1575 6683620 [main] base 2324 dtable::build_fhandler: fd -1, fh 0x61561FA8 1248 6684868 [main] base 2324 stat_worker: (lib/cygkcm_background.dll, 0x22FD34 , 1, 0x22F984), file_attributes 32 1911 6686779 [main] base 2324 fhandler_base::open: (C:\cygwin\opt\kde2\lib\cygk cm_background.dll, 0x11) 18893877 25580656 [main] base 2324 fhandler_base::open: 0x100 = CreateFileA (C:\ cygwin\opt\kde2\lib\cygkcm_background.dll, 0x8000, 0x7, 0x22F764, 0x3, 0x200 0080, 0) 688795 26269451 [main] base 2324 fhandler_base::open: filemode set to binary 841 26270292 [main] base 2324 fhandler_base::open: 1 = fhandler_base::open (C: \cygwin\opt\kde2\lib\cygkcm_background.dll, 0x11) 1312 26271604 [main] base 2324 fhandler_disk_file::open: 1 = fhandler_disk_file ::open (C:\cygwin\opt\kde2\lib\cygkcm_background.dll, 0x11) 1366 26272970 [main] base 2324 fhandler_disk_file::fstat_helper: 1 = GetFileInf ormationByHandle (C:\cygwin\opt\kde2\lib\cygkcm_background.dll, 256) 2345 26275315 [main] base 2324 fhandler_disk_file::fstat_helper: 0 = fstat (, 0 x22FD34) st_atime=3C82BC77 st_size=549376, st_mode=0x81ED, st_ino=360793, sizeof =64 2054 26277369 [main] base 2324 fhandler_base::close: closing 'lib/cygkcm_backgr ound.dll' handle 0x100 1377 26278746 [main] base 2324 stat_worker: 0 = (lib/cygkcm_background.dll, 0x2 2FD34) -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Printing locally
On Sun, Mar 03, 2002 at 10:49:53AM -, fergus at bonhard dot uklinux dot net wrote: > What about this? Any good? > If the file a.txt is DOS terminated, try > cp a.txt prn > OR > cat a.txt > prn > and if a.txt is Unix-terminated, try > cat a.txt | unix2dos > prn > Fergus This was a good suggestion but it still does not work. It just does nothing as does directing the output to PRINT or LPT1. The file a.txt if put into Notepad either in dos or unix format prints fine. Cheers, Brian. -- Brian Salter-Duke (Brian Duke) [EMAIL PROTECTED] Honorary Fellow in Chemistry, NT University, Darwin, NT 0909, Australia. Phone 08-89881600.Fax 08-89881302.http://lacebark.ntu.edu.au/ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: long delays on fhandler_base::open with cygwin 1.3.10
Chris, Are you sure that this is a Cygwin issue? My system exhibits pauses like this and they affect many, possibly all, executing programs. I have noticed nothing that suggests this is a Cygwin issue, though I must admit, I have a Cygwin BASH running at all times. I know only the symptom: Total momentary loss of responsiveness in interactive programs. If I look at the "Performance" pane of the "Windows Task Manager" after one of these pauses occurs (it has to be running when the symptom occurs, naturally), I'll see a spike up to 100% (of one CPU) in kernel CPU consumption (you have to have "Show Kernel Times" enabled in the "View" menu to see this). Perhaps you can use the more detailed performance grapher (Start -> Programs -> Administrative Tools -> Performance, on Windows 2000) to see where the time is going. I'm not adept at using it, and one would have to have some idea of which probes to monitor to get any meaningful information. Randall Schulz Mountain View, CA USA At 16:19 2002-03-03, Chris January wrote: >I'm using Cygwin 1.3.10 DLL and I occasionally get long delays (>2s !) >when fhandler_base::open is called on a disk file. This occurs >sporadically and is not dependant on the file being opened. I've included >a little strace snippet below. Just look how long fhandler_base::open >takes to return! No other CPU intensive programs are running and, no, I'm >not selecting text in the console window and not realisingit... :-) > >Regards >Chris -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: Strange behavior
> From: Chuck Allison [mailto:[EMAIL PROTECTED]]
>
> I have a simple Rational number class and have discovered
> weird behavior
> with Cygwin's g++. If you look at the very short main program in file
> rtest2.cpp, you will see by the output that g++ get's the
> wrong answer for
>
> r1 / r2 == Rational(2,3); // should be true
>
> even though it prints as 2/3! Borland and Microsoft get it
> right. Any ideas?
> All code atached.
[relevant bit of code]
inline bool operator==(const Rational& r1, const Rational& r2)
{
return r1.toDouble() == r2.toDouble();
}
This is nothing to do with Cygwin, or g++ for that matter. You're
comparing floating point numbers. Of course it's not reliable! If
other compilers happened to give you an exact equality on that
particular combination of arguments, it was pure luck.
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
RE: Strange behavior
Ross,
To call that result "pure luck" denies the fact that digital computers,
when properly functioning, are 100% deterministic.
Of course, it's not proper floating-point programming, but that doesn't
mean "luck" is involved.
Randall Schulz
Mountain View, CA USA
At 18:04 2002-03-03, Ross Smith wrote:
> > From: Chuck Allison [mailto:[EMAIL PROTECTED]]
> >
> > I have a simple Rational number class and have discovered
> > weird behavior
> > with Cygwin's g++. If you look at the very short main program in file
> > rtest2.cpp, you will see by the output that g++ get's the
> > wrong answer for
> >
> > r1 / r2 == Rational(2,3); // should be true
> >
> > even though it prints as 2/3! Borland and Microsoft get it
> > right. Any ideas?
> > All code atached.
>
>[relevant bit of code]
>
>inline bool operator==(const Rational& r1, const Rational& r2)
>{
>return r1.toDouble() == r2.toDouble();
>}
>
>This is nothing to do with Cygwin, or g++ for that matter. You're
>comparing floating point numbers. Of course it's not reliable! If other
>compilers happened to give you an exact equality on that particular
>combination of arguments, it was pure luck.
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Re: More security issues
At 11:19 PM 2/23/2002 +0100, Corinna Vinschen wrote:
>> I am still looking at that. On 2001-10-31 you added RevertToSelf() in
>> dtable.cc (dtable::vfork_child_dup). Do you remember why?
>
>Yes! It's very important. Without that RevertToSelf(), the
>process has no access to it's own open socket handles if a setuid()
>has been called before. Go figure!
Hi Corinna,
OK, that's good to know! I am almost done, just some cleanup and more
testing needed. Before starting on that I would like to get your
comments on what I did, and I have a few questions.
1) To solve my original impersonation token access problem
on NT, the easiest way is to change the default DACL of the
process (the impersonation token will get the right default).
The alternative is to set the token sd explicitly, but this
must be redone after every RevertToSelf().
To set the dacl I use the dacl part from __sec_user(), which
I have put in a separate function sec_dacl() (in shared.cc).
2) To make sure Windows process use the right default group,
the default group must be set both in the process token
(using RevertToSelf() if needed), and in the primary token
(for CreateProcessAsUser) (syscalls.cc).
3) after a sequence setegid(newg1), seteuid(newuid),
seteuid(original), the process has an unused primary token,
which can be used again if there is another setegid(newg2),
seteuid(newuid).
However that token may not be appropriate, depending on newg1
and newg2. If the token is internal and newg1 was not in the
"natural groups" of newuid, then newg2 must be the same as
newg1. Otherwise it is enough that newg2 be in the token groups.
[what is there now is too strict for internal tokens, but not
strict enough for tokens from cygwin_logon_user()]
That is checked in a new function verify_token()
(in security.cc), called from seteuid().
4) the primary group that was used when creating an internal token
is now saved in the token sd. This allows to set the token default
primary group appropriately if the user calls setegid() after
creating the token, e.g. seteuid(uid1) setegid(gid1)
[can this order be legitimate ?].
5) internal_getlogin() is called in seteuid(). Why is it necessary
to call it again after CreateProcessAsUser()? Won't the environment
already be OK?
6) The role of/need for the last creator/owner ACE in __sec_user()
is not clear to me. Are we ever in situations to propagate
permissions?
7) The current call to __sec_user() from spawn.cc gives access twice to
the new user, but not to the original user. However it doesn't seem
to matter. So the code can be simplified. Also, no need to RevertToSelf().
8) Also in spawn.cc, I believe that the following code
static BOOL first_time = TRUE;
if (first_time)
{
set_process_privilege (SE_RESTORE_NAME);
first_time = FALSE;
}
isn't robust. The static variable could be FALSE in a forked process
if the parent had spawned something before.
My suggestion is to delete those lines and modify registry.cc as follows:
--- registry.cc.org Tue Feb 19 20:39:44 2002
+++ registry.cc Thu Feb 21 10:56:32 2002
@@ -235,12 +235,13 @@
/* Check if user hive is already loaded. */
cygsid csid (psid);
csid.string (sid);
- if (!RegOpenKeyExA (HKEY_USERS, csid.string (sid), 0, KEY_READ, &hkey))
+ if (!RegOpenKeyExA (HKEY_USERS, sid, 0, KEY_READ, &hkey))
{
debug_printf ("User registry hive for %s already exists", sid);
RegCloseKey (hkey);
return;
}
+ set_process_privilege (SE_RESTORE_NAME);
if (get_registry_hive_path (psid, path))
{
strcat (path, "\\NTUSER.DAT");
9) get_dacl() (in security.cc) gives no access to admins if the
user is not in the admins group. I don't understand the logic.
My suggestion is to call instead the new sec_dacl() (see above),
which always has system, admins, sid1, [sid2] and creator/owner.
10) It's also possible to optimize fork.cc to avoid calling sec_user()
twice.
11) Can cygwin_logon_user() be called by a user not in admins?
[If so, I will test that case].
Pierre
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Re: Strange behavior
OK. I'm no IA32 expert can someone explain the following results. (Do
the floating point registers
use guard bits, randomly initialized perhaps?)
bool operator==(const Rational& r1, const Rational& r2)
{
double a=r1.toDouble(), b=r2.toDouble();
cout << ?== a " << a << " " << ?== b " << b << endl;
return a == b;
// return r1.toDouble() == r2.toDouble();
/* return ( r1.numerator == r2.numerator && r1.denominator ==
r2.denominator ); */
}
5/4
== a 1.25 == b 1.25
1
-1/4
== a -0.25 == b -0.25
1
3/8
== a 0.375 == b 0.375
1
2/3
== a 0.67 == b 0.67
0 // return
r1.toDouble() == r2.toDouble();
5/4
== a 1.25 == b 1.25
1
-1/4
== a -0.25 == b -0.25
1
3/8
== a 0.375 == b 0.375
1
2/3
== a 0.67 == b 0.67
1return a == b;
But since the Rational are always reduced the "right" answer is
return ( r1.numerator == r2.numerator && r1.denominator ==
r2.denominator );
No?
Rich.
Randall R Schulz wrote:
> Ross,
>
> To call that result "pure luck" denies the fact that digital
> computers, when properly functioning, are 100% deterministic.
>
> Of course, it's not proper floating-point programming, but that
> doesn't mean "luck" is involved.
>
> Randall Schulz
> Mountain View, CA USA
>
>
> At 18:04 2002-03-03, Ross Smith wrote:
>
>> > From: Chuck Allison [mailto:[EMAIL PROTECTED]]
>> >
>> > I have a simple Rational number class and have discovered
>> > weird behavior
>> > with Cygwin's g++. If you look at the very short main program in file
>> > rtest2.cpp, you will see by the output that g++ get's the
>> > wrong answer for
>> >
>> > r1 / r2 == Rational(2,3); // should be true
>> >
>> > even though it prints as 2/3! Borland and Microsoft get it
>> > right. Any ideas?
>> > All code atached.
>>
>> [relevant bit of code]
>>
>> inline bool operator==(const Rational& r1, const Rational& r2)
>> {
>>return r1.toDouble() == r2.toDouble();
>> }
>>
>> This is nothing to do with Cygwin, or g++ for that matter. You're
>> comparing floating point numbers. Of course it's not reliable! If
>> other compilers happened to give you an exact equality on that
>> particular combination of arguments, it was pure luck.
>
>
>
> --
> Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
> Bug reporting: http://cygwin.com/bugs.html
> Documentation: http://cygwin.com/docs.html
> FAQ: http://cygwin.com/faq/
>
>
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Re: Strange behavior
That's the point. They're always redued, so in both cases, the expression
2.0/3.0 is evaluated. How can that be non-deterministic?
- Original Message -
From: "Richard R. Malloy" <[EMAIL PROTECTED]>
To: "Randall R Schulz" <[EMAIL PROTECTED]>
Cc: "Ross Smith" <[EMAIL PROTECTED]>; "'Chuck Allison'"
<[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Sunday, March 03, 2002 9:47 PM
Subject: Re: Strange behavior
> OK. I'm no IA32 expert can someone explain the following results. (Do
> the floating point registers
> use guard bits, randomly initialized perhaps?)
>
> bool operator==(const Rational& r1, const Rational& r2)
> {
> double a=r1.toDouble(), b=r2.toDouble();
> cout << ?== a " << a << " " << ?== b " << b << endl;
> return a == b;
> // return r1.toDouble() == r2.toDouble();
> /* return ( r1.numerator == r2.numerator && r1.denominator ==
> r2.denominator ); */
> }
>
> 5/4
> == a 1.25 == b 1.25
> 1
> -1/4
> == a -0.25 == b -0.25
> 1
> 3/8
> == a 0.375 == b 0.375
> 1
> 2/3
> == a 0.67 == b 0.67
> 0 // return
> r1.toDouble() == r2.toDouble();
>
> 5/4
> == a 1.25 == b 1.25
> 1
> -1/4
> == a -0.25 == b -0.25
> 1
> 3/8
> == a 0.375 == b 0.375
> 1
> 2/3
> == a 0.67 == b 0.67
> 1return a == b;
>
>
> But since the Rational are always reduced the "right" answer is
>
> return ( r1.numerator == r2.numerator && r1.denominator ==
> r2.denominator );
>
> No?
>
> Rich.
>
> Randall R Schulz wrote:
>
> > Ross,
> >
> > To call that result "pure luck" denies the fact that digital
> > computers, when properly functioning, are 100% deterministic.
> >
> > Of course, it's not proper floating-point programming, but that
> > doesn't mean "luck" is involved.
> >
> > Randall Schulz
> > Mountain View, CA USA
> >
> >
> > At 18:04 2002-03-03, Ross Smith wrote:
> >
> >> > From: Chuck Allison [mailto:[EMAIL PROTECTED]]
> >> >
> >> > I have a simple Rational number class and have discovered
> >> > weird behavior
> >> > with Cygwin's g++. If you look at the very short main program in file
> >> > rtest2.cpp, you will see by the output that g++ get's the
> >> > wrong answer for
> >> >
> >> > r1 / r2 == Rational(2,3); // should be true
> >> >
> >> > even though it prints as 2/3! Borland and Microsoft get it
> >> > right. Any ideas?
> >> > All code atached.
> >>
> >> [relevant bit of code]
> >>
> >> inline bool operator==(const Rational& r1, const Rational& r2)
> >> {
> >>return r1.toDouble() == r2.toDouble();
> >> }
> >>
> >> This is nothing to do with Cygwin, or g++ for that matter. You're
> >> comparing floating point numbers. Of course it's not reliable! If
> >> other compilers happened to give you an exact equality on that
> >> particular combination of arguments, it was pure luck.
> >
> >
> >
> > --
> > Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
> > Bug reporting: http://cygwin.com/bugs.html
> > Documentation: http://cygwin.com/docs.html
> > FAQ: http://cygwin.com/faq/
> >
> >
>
>
>
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
IA64
Hi, Has anyone ported cygwin to the IA64 yet? Thanks, -Edward (Please cc my e-mail as I won't be able to regular check messages here) -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: Strange behavior
Floating point comparisons should _always_ be done via a confidence
interval, not bitwise equality. As for determinism, I don't know what
the logic circuits look like, so can't and won't comment :}.
Rob
> -Original Message-
> From: Chuck Allison [mailto:[EMAIL PROTECTED]]
> Sent: Monday, March 04, 2002 4:08 PM
> To: Richard R. Malloy; Randall R Schulz
> Cc: Ross Smith; [EMAIL PROTECTED]
> Subject: Re: Strange behavior
>
>
> That's the point. They're always redued, so in both cases,
> the expression 2.0/3.0 is evaluated. How can that be
> non-deterministic?
>
> - Original Message -
> From: "Richard R. Malloy" <[EMAIL PROTECTED]>
> To: "Randall R Schulz" <[EMAIL PROTECTED]>
> Cc: "Ross Smith" <[EMAIL PROTECTED]>; "'Chuck Allison'"
> <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
> Sent: Sunday, March 03, 2002 9:47 PM
> Subject: Re: Strange behavior
>
>
> > OK. I'm no IA32 expert can someone explain the following
> results. (Do
> > the floating point registers use guard bits, randomly initialized
> > perhaps?)
> >
> > bool operator==(const Rational& r1, const Rational& r2)
> > {
> > double a=r1.toDouble(), b=r2.toDouble();
> > cout << ?== a " << a << " " << ?== b " << b << endl;
> > return a == b;
> > // return r1.toDouble() == r2.toDouble();
> > /* return ( r1.numerator == r2.numerator && r1.denominator ==
> > r2.denominator ); */ }
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
RE: Strange behavior
>Floating point comparisons should _always_ be done via a confidence
>interval, not bitwise equality. As for determinism, I don't know what
>the logic circuits look like, so can't and won't comment :}.
>
>Rob
confidence intervals are indeed the only way...
but as to determinism ... its a function of your compiler I believe.
Differences will likely arrise with or without optimisation.
Which coincidently - is also the difference between the 2 situations below,
1 is an optimisation of the other, the assembly produced, even without an
optimisation flag, will be different, which means different results (one
case needs temporary variables - other one does not). So it should be
deterministic for a single set of assembly, for a given system type...
although someone could easily of made a processor in which I am wrong.
Gareth
>
>
>
> > -Original Message-
> > From: Chuck Allison [mailto:[EMAIL PROTECTED]]
> > Sent: Monday, March 04, 2002 4:08 PM
> > To: Richard R. Malloy; Randall R Schulz
> > Cc: Ross Smith; [EMAIL PROTECTED]
> > Subject: Re: Strange behavior
> >
> >
> > That's the point. They're always redued, so in both cases,
> > the expression 2.0/3.0 is evaluated. How can that be
> > non-deterministic?
> >
> > - Original Message -
> > From: "Richard R. Malloy" <[EMAIL PROTECTED]>
> > To: "Randall R Schulz" <[EMAIL PROTECTED]>
> > Cc: "Ross Smith" <[EMAIL PROTECTED]>; "'Chuck Allison'"
> > <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
> > Sent: Sunday, March 03, 2002 9:47 PM
> > Subject: Re: Strange behavior
> >
> >
> > > OK. I'm no IA32 expert can someone explain the following
> > results. (Do
> > > the floating point registers use guard bits, randomly initialized
> > > perhaps?)
> > >
> > > bool operator==(const Rational& r1, const Rational& r2)
> > > {
> > > double a=r1.toDouble(), b=r2.toDouble();
> > > cout << ?== a " << a << " " << ?== b " << b << endl;
> > > return a == b;
> > > // return r1.toDouble() == r2.toDouble();
> > > /* return ( r1.numerator == r2.numerator && r1.denominator ==
> > > r2.denominator ); */ }
>
>--
>Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
>Bug reporting: http://cygwin.com/bugs.html
>Documentation: http://cygwin.com/docs.html
>FAQ: http://cygwin.com/faq/
>
_
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp.;
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
nondeterministic results of uname -n
I want to make it clear that I'm neither complaining nor asking for a change - just reporting something I've noticed in case it's of interest to anyone basically, the nodename reported by uname is sometimes uppercase, sometimes lowercase - i.e. on my laptop sometimes I see: CYGWIN_NT-5.0 ubik 1.3.10(0.51/3/2) 2002-02-25 11:14 i686 unknown and sometimes: CYGWIN_NT-5.0 UBIK 1.3.10(0.51/3/2) 2002-02-25 11:14 i686 unknown I only noticed only because I do stuff like: host = $(shell uname -n) ifeq (blorp,$(findstring blorp,$(host))) foo = bar endif in my makefiles, and I have to be careful about the case -John -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: bash in Explorer Context menu (like "DOS here")
Hallo ! On Sun, 3 Mar 2002, Hans Horn wrote: > I'd like to know whether it is possible to have the abitlity to open a bash > shell from a folder's context menu in Windows Explorer (like the MS > powertool 'doshere')? Yes, I have a skript (*.bat & *.sh) that does this. If used via "send to" on a folder, it opens a bash in that folder (UNC-Path as well as local drives supported). if used on a file, it asks to open the file in $EDITOR or to open a bash in the parent dir. If someone is interested, I will clean up the code and post it here. Bjoern -- +-+ | Dipl.-Phys. Bjoern Kahl +++ AG Embedded Systems and Robotics (RESY) | | Informatics Faculty +++ Building 48 +++ University of Kaiserslautern| | phone: +49-631-205-2654 +++ www: http://resy.informatik.uni-kl.de | +-+ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
