Re: history (was Re: base-files: LOGNAME)
Cyrille Lefevre writes: sunos, login(1) both set USER and LOGNAME using pwd-pw_name ... solaris, login(1) only set LOGNAME ... sys5r4, same as solaris, but ... irix, login(1) and logname(1) does as sunos ... osf1, login(1) does as sunos, logname(1) as solaris At least historically, HP-UX login(1) set LOGNAME but not USER. On the other hand, historically some su programs set USER but not LOGNAME. -- Eric Backus -- 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: 'cp' utility bug when lt;dest-namegt;.exe file exist.
Eric Blake writes: A first step would be teaching gcc to not append .exe. Many configure scripts (certainly almost all scripts based on autoconf) determine $(EXEEXT) based on gcc behavior, and will just do the right thing throughout the rest of the build with $(EXEEXT) empty (as evidenced by their behavior on Linux). But even with that gcc change, we'd have to keep .exe magic in cygwin1.dll until everything in the distro has been rebuilt without an .exe suffix. However, I'm starting to like the idea, if we can get buy-in from the gcc packager. Dave? This is really an interesting discussion. I too find some of the existing behavior strange, and perhaps there is room for improvement. However, when I see this kind of thing, I try to remember what Cygwin really is (for me anyway). It is not *just* a POSIX environment. If I wanted *just* a POSIX environment, I'd run Linux, perhaps in a virtual machine, and I would have a better POSIX environment than Cygwin can ever provide. For me, Cygwin is a nearly-POSIX environment that cooperates and interoperates nicely with the Windows operating system. In Windows, executables end in .exe, and Windows shells (and other Windows programs) rely on that. If you want to be able to execute a cygwin executable from a Windows shell, you need that .exe. Sure, we've seen some interesting ways to configure some windows shells to work around this, but 99.9% of users won't know that (I certainly didn't until now). So this reasoning leads me to think that the .exe magic is probably a good idea, though it may still need tweaking to make is as benign as possible. As a side note, this same kind of reasoning is why I think Cygwin bash should default the igncr option to on. Also why Cygwin symlinks should probably default to using real Windows symlinks. And why Cygwin should probably go back to reading/setting/clearing the DOS read-only attribute. And why more effort should be put into supporting text-mode mounts. There, is that enough controversy? -- Eric Backus -- 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: Bug: cygport fails when the working directory pathname contains spaces
Marco Atzeri marco_atzeri at yahoo.it writes: Don't use filename with a space inside is a WELL KNOWN rule of any UNIX system. If MS made a stupid decision, we should not follow it. Regards Marco It really doesn't matter to me whether cygport supports filenames with spaces. And it is certainly true that filenames with spaces are relatively common on Windows systems, but relatively rare on unix systems. Nevertheless, there is no rule about this. Actually I believe POSIX allows filenames to have *any* character in them except a directory separator '/' or a terminating null '\0'. It is well known that *robust* scripts should use proper quoting to allow for things like spaces in filenames. -- Eric -- 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: floating-point math problem in Cygwin 1.7?
Linh Phan linhphan at usc.edu writes: I have wondering why when I do floating-point math in Cygwin 1.7, Cygwin does not output the correct result, eg: qca = [-0.623718486146499718, 0.736824293298044886, -0.260654850643024127, 0.011147182658310384] CORRECT (LINUX/SOLARIS) qca = [-0.623718486146499607, 0.736824293298044886, -0.260654850643024072, 0.011147182658310373] NOT CORRECT (CYGWIN) These variables are declared double. On cygwin, and Linux, and probably Solaris, that means they are 64-bit IEEE floating-point values, with 53 bits of mantissa. That gives the values only about 16 digits of precision, and the values you show do seem to match for roughly that many digits. So, I think technically nothing is very wrong here. Why are the values different? The root of this is the x86 floating-point processor, which internally does calculations with 80-bit floating-point registers (with 64-bit mantissa). Depending on when and how these 80-bit values are converted back to 64-bit doubles and stored in memory, you can get slightly different answers. You might try looking at the command-line options you're giving to the compiler. There might be some setting which allows the processor to keep values in the 80-bit floating-point registers longer, thus keeping more accuracy. You might try -ffast-math and see if that helps. Maybe even just turning on optimization (-O2 or -O3) might help. You might try using long double instead of double, but be careful because I think Cygwin still doesn't have full support for long double. These errors accumulate and eventually builds up so much that the my simulation result is totally wrong when running under cygwin. It is possible that this points to problems with your simulation itself, if it is this sensitive to accumulated errors that are this small. -- Eric -- 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: gcc -ffast-math defect with tan(x)
Eric Backus eric_backus at agilent.com writes: Dave Korn dave.korn.cygwin at googlemail.com writes: This will require a newlib patch and a new cygwin dll release to solve, it'll take a little while I'm afraid. Impressive, 5 hours from defect report to complete debugging and understanding of an assembly language problem. Thanks Dave! I look forward to the patch release when they are available. I just wanted to confirm that cygwin-1.7.0-65 fixed my problem. Thanks again for your work! -- Eric -- 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] [1.7] Updated: {ncurses/libncurses9/libncurses-devel/ncurses-demo}-5.7-15
Charles Wilson cygwin at cwilson.fastmail.fm writes: Charles Wilson wrote: Eric Backus wrote: $ tput sgr0 Segmentation fault (core dumped) this is wrong The seg fault didn't happen with the previous version. Should be fixed in ncurses-5.7-16. Yes, it is fixed. Thank you! -- Eric -- 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: gcc -ffast-math defect with tan(x)
Dave Korn dave.korn.cygwin at googlemail.com writes: Thanks for the STC. The difference between -ffast-math and -fno-fast-math is that the fast version calls the _f_tan newlib fast math function rather than tan. I think this is likely to be a calling-convention issue but I'm still debugging it. cheers, DaveK One experiment that I did, which confused me more than anything else, is replace the calls to tan() with calls to log() (and change all the 0.0 values to something OK for log() like 1.0). The generated assembly code appears to be identical except that _f_tan is replaced by _f_log, but the program works correctly. That would mean that the generated assembly code is correct, and the defect is in _f_tan? -- Eric -- 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: gcc -ffast-math defect with tan(x)
Dave Korn dave.korn.cygwin at googlemail.com writes: Needs moar 'ffree st(0)'. This will require a newlib patch and a new cygwin dll release to solve, it'll take a little while I'm afraid. cheers, DaveK Impressive, 5 hours from defect report to complete debugging and understanding of an assembly language problem. Thanks Dave! I look forward to the patch release when they are available. -- Eric -- 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] Updated: cygwin-1.7.0-63
Corinna Vinschen corinna-cygwin at cygwin.com writes: On Nov 7 20:38, Eric Backus wrote: Jim Reisert AD1C jjreisert at alum.mit.edu writes: How do I make this work, while maintaining: LANG=en_US.UTF-8 - Jim You might try LANG=en_us.UTF-8 (Note the lower-case us). It seems to That's not correct. The result is that the locale will still be C. The above LANG setting will be refused since the territory part of the locale specifier must be uppercase. See http://cygwin.com/1.7/cygwin-ug-net/setup-locale.html#setup-locale-ov Corinna OK, my bad. Sorry. I must say I find the ls behavior quite confusing. It appears that *any* valid setting of LANG other than C results in the iso time style, and --time- style=locale never has any effect regardless of the setting of LANG. Feature? or defect? -- Eric -- 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] Updated: cygwin-1.7.0-63
Jim Reisert AD1C jjreisert at alum.mit.edu writes: Thanks, Eric. I tried this but could not get what I wanted: LTDENA-REISERT:c/Home ls -al --time-style=posix-long-iso -rwx-- 1 reisertDomain Users3326 2009-10-30 12:51 .XWinrc -rwx-- 1 reisertUsers663 2009-02-26 10:37 .Xdefaults From the info link you sent me, it says: `posix-STYLE' List POSIX-locale timestamps if the `LC_TIME' locale category is POSIX, STYLE timestamps otherwise. For example, the `posix-long-iso' style lists timestamps like `Mar 30 2002' and `Mar 30 23:45' when in the POSIX locale, and like `2002-03-30 23:45' otherwise. I must not be in a POSIX LOCALE, then. LC_TIME isn't defined, nor is LOCALE. How do I make this work, while maintaining: LANG=en_US.UTF-8 - Jim You might try LANG=en_us.UTF-8 (Note the lower-case us). It seems to change the time formatting used by ls. But I don't understand how or why, nor do I know if it will break whatever else you're using LANG for. -- Eric Backus -- 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: Cygwin 1.7, who version 7.0 does not respond with a value
Larry Hall (Cygwin reply-to-list-only-lh at cygwin.com writes: On 10/28/2009 10:04 AM, Larry W. Virden wrote: when I type the who command within a Cygwin window, only an empty line is returned. ... It looks, to me, as if perhaps we are missing some setup that results in entries being written to utmp when a local Cygwin window is opened. I've just not been able to determine what that is yet. 'cygwin.bat' does not login to anything, so you won't see user login data for sessions logged in this way. If you want to see actual logged in users, you will need to use 'login' or 'ssh' to really log them in. On the other hand, rxvt will create utmp entries, and so will mintty if told to with the -u option. Presumably xterm also creates utmp entries. Even screen creates utmp entries for it's separate windows. So if you try using one of these programs instead of just the default windows command window, you can get who to return a list of sessions. -- Eric -- 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: Howto set default text file type to DOS/Text under release 1.7 BETA
Niels Hallenberg nhallenberg at gmail.com writes: I have a lot of scripts that won't run under bash as long as the extra CR's are not removed. I know of the tool doc2unix, however there are other obstacles too so having the auto-conversion is the best solution for me. I have also tried to use the extra argument -nocr to bash, however that doesn't work either. Any ideas? Best Niels I too often find it inconvenient that bash won't ignore CRs. The best fix I've found is to put a file igncr.sh into /etc/profile.d. This file contains: (shopt -s igncr) 2/dev/null shopt -s igncr # comment is needed if crlf export SHELLOPTS Once this file is in place, shell scripts will ignore CR characters. I've used this solution ever since bash was changed to complain about CR by default, and it has worked well for me. I was going to make some comment about ANSI C/C++ recognising that line endings can legitimately be something other than just LF, and text files on the system defaulting to CR/LF line endings, and bash shell scripts being text files, and cygwin providing useful tools to interoperate with the native OS. But then I thought it better to just offer the solution above. :) -- Eric -- 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] [1.7] Updated: {ncurses/libncurses9/libncurses-devel/ncurses-demo}-5.7-15
Charles Wilson cygwin at cwilson.fastmail.fm writes: ncurses is a package that provides character and terminal handling libraries, including 'gui-like' panels and menus. It is often used instead of termcap. This is a packaging bug fix, and an update to latest upstream. [[ compiled using gcc-4.3.4-1 ]] CHANGES since 5.7-14 o Update to 20091024 patchset o Rename ncurses9-config file to ncurses5-config o Moved ncurses*-config file to -devel package o Compiled using gcc-4.3.4-1 I'm getting a segmentation fault when I try to use tput. The program runs successfully if you just ask it for a version number, or if asked for a non- existent capability, but gets a seg fault when asked about a real capability. $ tput sgr0 Segmentation fault (core dumped) this is wrong $ tput -V ncurses 5.7.20091024 OK, latest version $ tput garbage tput: unknown terminfo capability 'garbage' OK, this is correct $ type tput tput is hashed (/bin/tput) The seg fault didn't happen with the previous version. Is there anything else I should try to debug this? Would you like cygcheck output? -- Eric Backus -- 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: mintty-0.5.1-1
Andy Koppe andy.koppe at gmail.com writes: The obvious method would be to check $TERM, but of course that doesn't work... ... and I can't change it to mintty, because even if entries for it were added to Cygwin's termcap and terminfo, any other system would say what?. Yes. Though you could set a different variable ($MINTTY_VERSION perhaps) that would allow users to explicitly test whether they're running under mintty. I don't know if this is a good idea or not. Possibly better would be some generic variable (TERM_IMPLEMENTATION? TERM_EMULATOR? I can't think of anything that looks very good) that other programs could use too. You could change it though, e.g.: mintty env TERM=mintty /bin/bash -l This is an excellent idea. Thanks! I ended up using: mintty --title=bash env MINTTY_VERSION=0.5.1 bash --login Then my .profile can test for MINTTY_VERSION and unset the variable when done. Alternatively, mintty can be recognised by querying the secondary device attribute. If you send \e[c, it will currently reply with \e[77;501;0c. The 77 (ASCII 'M') identifies mintty, the 501 is the version number, and the last field is unused. Cool, I never knew about this. I can make it work, but things are a little messy so I'll stick with the environment variable method above. Btw, how do you deal with the problem that the 'kbs' terminfo entry on the remote machine doesn't necessarily fit the terminal on your local machine? There's not much I can do about it, so I don't deal with it. I don't use terminals on remote machines very often, so it hasn't been a problem for me. I guess the long-term right answer is for everyone to agree on the same definition of what xterm really means. By the way, thanks for your efforts on mintty, it works really well and I have enjoyed using it. -- Eric -- 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: mintty-0.5.1-1
Andy Koppe andy.koppe at gmail.com writes: CHANGES === Keyboard: - The default backspace keycode now is ^? rather than ^H, to make Ctrl+H available as a shortcut for other purposes, particularly as the help key in emacs. The backspace keycode option is gone. Instead, the DECBKM control sequence for changing the backspace keycode is now supported. Unfortunately, cygwin's terminfo/termcap entries for XTERM say that the backspace key returns ^H. This can be seen by looking in /etc/termcap for xterm, and finding the 'kb' property for that entry, or by running 'infocmp xterm' and looking for the 'kbs' property. So, by default, mintty now does not match the terminfo/termcap entries. Is there any way to fix this? I hesitate to suggest changing the terminfo/termcap entries, since they should match the real xterm. But actually I don't run X11, so I don't know if the current terminfo/termcap really match xterm - the date on /etc/termcap at least is fairly old. -- Eric -- 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: mintty-0.5.1-1
Andy Koppe andy.koppe at gmail.com writes: 2009/10/16 Eric Backus: Unfortunately, cygwin's terminfo/termcap entries for XTERM say that the backspace key returns ^H. This can be seen by looking in /etc/termcap for xterm, and finding the 'kb' property for that entry, or by running 'infocmp xterm' and looking for the 'kbs' property. So, by default, mintty now does not match the terminfo/termcap entries. Is there any way to fix this? I hesitate to suggest changing the terminfo/termcap entries, since they should match the real xterm. But actually I don't run X11, so I don't know if the current terminfo/termcap really match xterm - the date on /etc/termcap at least is fairly old. xterm does still send ^H, but I agree both xterm and its termcap entry ought to be changed to match the new Cygwin 1.7 default and the Linux world. I should have a look at how to do that. I suppose that is probably the best solution, but it does require changes in three different packages: termcap, terminfo and xterm. In passing, I'll note that xterm on my very old and out-of-date SuSE linux installation uses DEL, so matches your new version of mintty. Have you come across an application that stumbles over this? All the one's I've tried seemed to go by the stty setting rather than the termcap entry anyway. Off the top of my head, I don't know of any application that has a problem. As you say, I think most use stty rather than terminfo. My problem, and the reason I stumbled on this, is historical and of my own making. Over the years, I've used many different terminal emulators on HP-UX, Linux, and Windows, and they haven't always started with the correct stty setting for the backspace key. Several programs rely on the stty setting, including 'less' and 'emacs', so I wanted to correct the stty setting. To do that, I have code like this in my .profile: x=`tput kbs | od -to1 -An` x=`echo $x` if [ -n $x ]; then stty erase 0$x; fi unset x Basicly, this sets the stty erase character to match what the terminfo database says is correct. This code has worked reasonably well for quite some years now, and should be a no-op if everything is working correctly. But this is what is causing my problem with mintty, since now I'm overwriting the stty setting (which was correct) with the incorrect value from terminfo. Since this problem is unlikely to affect people who simply ignore terminfo, I suppose it should not be high priority. The workaround is to stick the following somewhere in your startup files: echo $'\e[?67h' stty erase '^H' Sure, if I know that the terminal that I'm using is mintty, that is a good workaround. But I try to use the same .profile on both my linux and cygwin environments, and I'd prefer it to work with other terminals than just mintty. If there was a portable way to determine whether I'm running within mintty, I could use the above escape sequence, but I don't know of a good way to determine if I'm in mintty. The obvious method would be to check $TERM, but of course that doesn't work... ps: Oh gawd, how I hate this issue. Oh, believe me, I feel your pain. Like DOS 8.3 filenames, everyone hates it, but it never really goes away. -- 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 dave.korn.cygwin at googlemail.com writes: 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 I guess I'm in the minority here, but I'll go out on a limb and say that the original behavior does NOT seem like a defect to me. My reasoning: 1. Compilers are free to use and/or not use excess precision within expressions. I believe the standard requires the excess precision to get thrown away when a value is stored into a variable, but that's not happenning here. I think -ffloat-store tells gcc to strictly follow the standard, but (again, if my understanding is correct) since the values of arg(z1) and arg (z2) are not stored into variables, it won't necessarily help. Note that there is a performance penalty to strictly following the standard, as compared with freely using excess precision when convenient, so in many (most?) cases it is desirable to let the compiler go ahead and do that. Also in many (most?) cases, excess precision only helps, so the default may be to let the compiler do what it wants for speed. 2. In general, you should not be comparing equality of floating-point values. This is true even if you get rid of the excess precision stuff above. Sure, in this particular case, if you get rid of excess precision, the values will be exactly equal, but direct comparison is a bad habit to get into. -- Eric Backus -- 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: Moving Cygwin
Tim Visher writes: On 2009-04-30 12:27Z, Tim Visher wrote: I originally installed cygwin in the default `C:\cygwin` directory. I'd like to move it from there to `C:\`. Is there any easy way to do this? Maybe the context for my question would help. I'm attempting to follow advice from [Steve Yegge's My .emacs File article](http://steve.yegge.googlepages.com/my-dot-emacs-file) in order to get useful cygwin bash interaction from within NT Emacs. He seems to be of the opinion that the gentleman who responded in the comments about having the path interpolation code and installing cygwin in the default directory was mislead about what you need to get it to work. Are there A) Practical responses to Yegge's way of using Cygwin and NT Emacs? or B) A proven way to do what I'm trying to do without messing with cygwin's install directory (I would prefer this as I would like to keep cygwin safely secluded). Thanks in advance! I have cygwin under C:/cygwin, and I run NT Emacs. I'm very happy with this setup. To help get them to work well together, I downloaded cygwin-mount.el from http://www.emacswiki.org/cgi-bin/wiki/cygwin-mount.el, and I include the following in my .emacs file: (if (equal system-type 'windows-nt) (progn (if (require 'cygwin-mount nil t) (progn (setq cygwin-mount-cygwin-bin-directory C:/cygwin/bin) (cygwin-mount-activate))) ;; These don't work because of crlf issues? ;;(setq shell-file-name bash) ;;(setenv SHELL shell-file-name) ;;(setq explicit-shell-file-name shell-file-name) (setenv PATH (concat C:\\cygwin\\bin; (getenv PATH))) (setq exec-path (cons c:/cygwin/bin exec-path This setup works quite well for me. However, I never try to run a shell from within emacs, so I don't know if that will work correctly. I seem to remember running into crlf issues (as mentioned in the above comments) that I didn't bother trying to track down and fix. If you're using Emacs 21 or older, you might also try: (setq archive-zip-use-pkzip nil); Even on windows, we use zip/unzip Not sure if this will matter to you, but at least at one time I found this useful. I think this is no longer necessary with NT Emacs 22.3. And at one time I found the following useful for getting printing to work: ;; Some of this is specific to Agilent Everett Seaway site (if (equal system-type 'windows-nt) (progn (setq lpr-command C:/WINDOWS/system32/lpr.exe) ; Defaulted to dump to PRN: (setq printer-name evt0005) ; Defaulted to PRN (setq server-name evt0005) ; Not a system variable (setq lpr-switches (list -S server-name)) ; Defaulted to (setq lpr-headers-switches nil))) ; So we can use pr ;; This defaulted to 66 lines, didn't fit on page, but may be Everett-specific (setq lpr-page-header-switches (quote (-F -l59))) Good luck... Eric Backus -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: PING: Deprecation of -mno-cygwin.
Christopher Faylor cgf-use-the-mailinglist-please at cygwin.com writes: On Mon, Mar 23, 2009 at 02:22:03PM +, Greg Chicares wrote: On 2009-03-23 14:00Z, Steve Thompson wrote: On Mon, 23 Mar 2009, Dave Korn wrote: It's a bit of a kludge compared to having a real honest-to-god cross-compiler. It's never worked entirely right in terms of keeping cygwin and mingw headers and libs completely separate. That's very interesting. I've been using -mno-cygwin for several years, having done many many thousands of compiles and links using it, and I have never had a problem with either headers or libraries! Is there a recommended alternative? The recommended alternative is the forthcoming mingw cross-compiler. I think Yaakov's right to recommend a clean break with the past: ... which would put all the confusion to rest. Big DITTO. As Dave said, the option is already gone... Moving to a better solution is great! But isn't it customary to have some overlap period where the deprecated solution still works (but with ugly warnings) while the new solution is available? I've used -mno-cygwin for many years, quite successfully, with no problems from headers or libraries. I'm willing to upgrade all my Makefiles, but it would be nice to avoid a period where my Makefiles are broken and the new solution is not yet available. -- Eric Backus -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: symbolic link untar issue
Eric Blake ebb9 at byu.net writes: Most .exe magic is already inside cygwin. In particular, CVS cygwin (which will become 1.7.0) has a transparent_exe option that makes this all even cleaner, without application specific knowledge. But the real problem reported by this thread has nothing to do with .exe magic after all. Rather, it had to do with a non-compliant implementation of open(O_CREAT|O_EXCL). Ah. OK, thanks for the update, and all your hard work. -- Eric -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: symbolic link untar issue
Eric Blake ebb9 at byu.net writes: No, it is not an old-style link, because it has the .lnk suffix when viewed via Windows. However, it is not a link that would normally be created by the current coreutils, since I have added some .exe magic into ln when symlinking against existing .exes: From this I guess that the .exe magic is currently in the code for each program that might create a symlink. Is there any way that the .exe magic could be moved to inside the symlink() function call, so that it automatically works for all programs that create symlinks? Or does that introduce other problems? -- Eric Backus -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: redefining $HOME
Gustavo Seabra gustavo.seabra at gmail.com writes: Hi all, I was wondering if it is possible to use the windows folder My Documents or even C:\Documents and Settings\USERNAME (or some dir inside those) as the hoe directory in Cygwin. I though about substituting the user directory inside /home by a symlink to one of the above. Is there any reason that wouldn't work? Is there a better way to do it? The reason I am thinking about it is just practical: I want to have all my files (Windows or Cygwin) under one root. Thanks a lot Gustavo. Yes, you can do this. I've done this for years by putting /cygdrive/c/Documents and Settings/ericjb/My Documents into /etc/passwd. This works well, though every once in awhile you might find a shell script which doesn't correctly handle spaces in paths. (Such a script is broken, and should be fixed.) I can't even remember the last time I ran into that though, most scripts don't use $HOME. -- Eric -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Unable to run even simple batch scripts any more
Matthew Woehlke mw_triad at users.sourceforge.net writes: Dennis Simpson wrote: Three of us updated to latest windows cygwin last week, and none can run even simple .sh scripts any more. Prior version was 6 months ago. http://cygwin.com/ml/cygwin-announce/2006-12/msg00026.html Next time RTFRA. Oh, and STFLA; this particular horse died a *lng* time ago. Obviously, the horse is still alive and attempting to limp along. I predict it'll stay alive for quite some time longer. * Bash's current treatment of crlf causes unexpected breakage of things that worked for years, and which most naive users expect to continue to work. * Workaround using text mounts fails because lots of cygwin commands don't work right under text mounts (gzip for example, but there's lots more). * Workaround by exporting SHELLOPTS breaks things because it put interactive things like history expansion into non-interactive shells (try calling man bash after exporting SHELLOPTS with igncr, for example). * Workaround inserting set -o igncr is impractical when there are lots of scripts. * Workaround calling d2u is impractical when there are lots of scripts, and breaks if the scripts must work with non-cygwin shells. I know, cygwin developers are not interested in fixing this, which is certainly their right. But you can be sure that reports of this problem will continue to arrive. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
