Re: [RFC] Making Cygwin README optional
On Thu, Mar 17, 2011 at 10:28:49PM -0500, Yaakov (Cygwin/X) wrote: I wish to propose that Cygwin READMEs no longer be absolutely required for Cygwin packages, for several reasons: AFAIK, they never were absolutely required. Hardly any of my packages have one. cgf
Re: RFU: mercurial-1.8.1-1
On Mar 18 01:20, Jari Aalto wrote: New upstream release: wget --recursive --no-host-directories --cut-dirs=3 \ http://cante.net/~jaalto/tmp/cygwin/mercurial/mercurial-1.8.1-1-src.tar.bz2 \ http://cante.net/~jaalto/tmp/cygwin/mercurial/mercurial-1.8.1-1.tar.bz2 \ http://cante.net/~jaalto/tmp/cygwin/mercurial/setup.hint Uploaded. Can I remove old versions before 1.7.5-1? Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: RFU: bzr-2.3.1-1
On Mar 18 01:22, Jari Aalto wrote: New upstream release: wget --recursive --no-host-directories --cut-dirs=3 \ http://cante.net/~jaalto/tmp/cygwin/bzr/bzr-2.3.1-1-src.tar.bz2 \ http://cante.net/~jaalto/tmp/cygwin/bzr/bzr-2.3.1-1.tar.bz2 \ http://cante.net/~jaalto/tmp/cygwin/bzr/setup.hint Uploaded. Can I remove versions before 2.3.0-1? Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: [RFC] Making Cygwin README optional
On 3/17/2011 11:28 PM, Yaakov (Cygwin/X) wrote: I wish to propose that Cygwin READMEs no longer be absolutely required for Cygwin packages, for several reasons: OK by me, in general. That being said, I quibble about some of the rationale, below... * Most of the information contained therein is duplicated elsewhere: - the package description is in setup.int a) Nobody can easily SEE the ldesc; AFAIK there is no way to convince setup.exe to show it, and the individual setup.hints are not downloaded. You can look in $DOWNLOAD_DIR/setup.ini, but... b) Even the ldesc in setup.hint is severely truncated in many cases, since each ldesc adds to the already unwieldy length of setup.ini. So, I don't really think the ldesc in setup.hint is a suitable replacement for a more long-format description somewhere else. HOWEVER, I still agree that this should be the maintainer's decision, and not imposed by policy (especially if the maintainer thinks that /usr/share/doc/$PKG/README is already good enough, to not require an additional /usr/share/doc/Cygwin/$PKG.README) - runtime deps are handled by setup; - rebuild instructions for cygport-based packages are already covered in cygport's documentation, and in any case, how to rebuild the source package is not really relevant to the *binary* package; - the package contents are available through cygcheck; - changes in the latest release are already in announcements, and in many cases, there may not be any Cygwin-specific changes, just upstream ones already covered by ChangeLog/NEWS/etc. I do like the field that newer cyg-specific readmes have detailing the license of each package by name: License: MIT/X (or BSD or LGPLv3+ or whatever) Makes it convenient for me, rather than looking for /usr/share/doc/$PKG/Copying, COPYING, LICENSE, buried in README, etc. But that minor benefit (not even present in all current cyg-specific readmes) is certainly not reason enough to require one. Although maybe an optional (free-text) field in setup.hint for this purpose might be nice? license: 2-clause BSD The Language field is kinda useless...it used to be interesting as it indicated which compiler or interpreter you'd need, but...that info is available in other ways. That leaves build-time deps and long-term package history. For those, I would suggest the following: * I'm working on a method to add build deps to .cygport(5) files and have cygport(1) verify their presence. That would be great! * Each package would get a git repository on sourceware for its .cygport, .hint, and other packaging files, as in Fedora and as I started doing in Ports. Maybe that is what it would take for me to finally start using source control on these things, instead of unpacking the prev release's -src each time... :-) -- Chuck
Re: RFU: bzr-2.3.1-1
2011-03-18 12:48 Corinna Vinschen corinna-cygwin-rdbxbdvo6bxqt0dzr+a...@public.gmane.org: | On Mar 18 01:22, Jari Aalto wrote: | | | New upstream release: | | wget --recursive --no-host-directories --cut-dirs=3 \ | http://cante.net/~jaalto/tmp/cygwin/bzr/bzr-2.3.1-1-src.tar.bz2 \ | http://cante.net/~jaalto/tmp/cygwin/bzr/bzr-2.3.1-1.tar.bz2 \ | http://cante.net/~jaalto/tmp/cygwin/bzr/setup.hint | | Uploaded. Can I remove versions before 2.3.0-1? Yes, the 2.3 is long term support branch. Jari
Re: RFU: bzr-2.3.1-1
On Mar 18 17:58, Jari Aalto wrote: 2011-03-18 12:48 Corinna Vinschen corinna-cygwin-rdbxbdvo6bxqt0dzr+a...@public.gmane.org: | On Mar 18 01:22, Jari Aalto wrote: | | | New upstream release: | | wget --recursive --no-host-directories --cut-dirs=3 \ | http://cante.net/~jaalto/tmp/cygwin/bzr/bzr-2.3.1-1-src.tar.bz2 \ | http://cante.net/~jaalto/tmp/cygwin/bzr/bzr-2.3.1-1.tar.bz2 \ | http://cante.net/~jaalto/tmp/cygwin/bzr/setup.hint | | Uploaded. Can I remove versions before 2.3.0-1? Yes, the 2.3 is long term support branch. Done. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: RFU: mercurial-1.8.1-1
On Mar 18 18:00, Jari Aalto wrote: 2011-03-18 12:31 Corinna Vinschen corinna-cygwin-rdbxbdvo6bxqt0dzr+a...@public.gmane.org: | On Mar 18 01:20, Jari Aalto wrote: | | | New upstream release: | | wget --recursive --no-host-directories --cut-dirs=3 \ | http://cante.net/~jaalto/tmp/cygwin/mercurial/mercurial-1.8.1-1-src.tar.bz2 \ | http://cante.net/~jaalto/tmp/cygwin/mercurial/mercurial-1.8.1-1.tar.bz2 \ | http://cante.net/~jaalto/tmp/cygwin/mercurial/setup.hint | | Uploaded. Can I remove old versions before 1.7.5-1? Yes. Done. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
[ RFU ] base-files-4.0-6
Hello, Please upload base-files-4.0-6. It contains corrections for the errors reported regarding PRINTER setting and non-POSIX tests in /etc/profile. http://crapsteak.org/cygwin/release/base-files/base-files-4.0-6.tar.bz2 http://crapsteak.org/cygwin/release/base-files/base-files-4.0-6.tar.bz2.sig Thanks. -- Huella de clave primaria: 0FDA C36F F110 54F4 D42B D0EB 617D 396C 448B 31EB signature.asc Description: Digital signature
Re: [ RFU ] base-files-4.0-6
On Mar 18 18:08, David Sastre wrote: Hello, Please upload base-files-4.0-6. It contains corrections for the errors reported regarding PRINTER setting and non-POSIX tests in /etc/profile. http://crapsteak.org/cygwin/release/base-files/base-files-4.0-6.tar.bz2 http://crapsteak.org/cygwin/release/base-files/base-files-4.0-6.tar.bz2.sig Done. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: [RFC] Making Cygwin README optional
On 3/18/2011 12:06 AM, Christopher Faylor wrote: On Thu, Mar 17, 2011 at 10:28:49PM -0500, Yaakov (Cygwin/X) wrote: I wish to propose that Cygwin READMEs no longer be absolutely required for Cygwin packages, for several reasons: AFAIK, they never were absolutely required. One could take this, from http://cygwin.com/setup.html, as a commandment: In your binary package, include a file /usr/share/doc/Cygwin/foo-vendor-suffix.README
Re: [RFC] Making Cygwin README optional
On Fri, Mar 18, 2011 at 02:20:51PM -0600, Warren Young wrote: On 3/18/2011 12:06 AM, Christopher Faylor wrote: On Thu, Mar 17, 2011 at 10:28:49PM -0500, Yaakov (Cygwin/X) wrote: I wish to propose that Cygwin READMEs no longer be absolutely required for Cygwin packages, for several reasons: AFAIK, they never were absolutely required. One could take this, from http://cygwin.com/setup.html, as a commandment: In your binary package, include a file /usr/share/doc/Cygwin/foo-vendor-suffix.README Ok, point taken. I disagree that we should be putting information on how to rebuild a package (as the rest of that sentence states) in /usr/share/doc anyway. That's just a waste of space. cgf
Re: ssh -X user@host konsole opens a tunneled konsole, but then the tunnel lapses
Bump? Should I try a noisier forum, or one for a different layer of the system? On Fri, Mar 4, 2011 at 10:29 AM, Phlip phlip2...@gmail.com wrote: CygWinners: For years I have enjoyed one desktop with everything I need on it. Then ssh -X stopped working. Sometimes, if I start a remote konsole, and immediately start some new X window app, it runs thru the tunnel. But now it trivially bombs, as if there were no remote X to attach to: kate: cannot connect to X server localhost:10.0 Is there a timeout setting, somewhere, for the X tunnel? or some similar setting to look at? The host is any Win32 or Win64, and the client is Ubuntu... I also tried manually setting the DISPLAY environmental variable... -- Phlip http://c2.com/cgi/wiki?ZeekLand -- Phlip http://c2.com/cgi/wiki?ZeekLand -- 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/
src/winsup/cygwin ChangeLog mmap.cc
CVSROOT:/cvs/src Module name:src Changes by: cori...@sourceware.org 2011-03-18 13:38:35 Modified files: winsup/cygwin : ChangeLog mmap.cc Log message: * mmap.cc (mmap_record::page_map): Define as variable array rather than as pointer. (mmap_record::alloc_page_map): Remove. (mmap_record::free_page_map): Remove. (mmap_record::init_page_map): New method. (mmap_record::add_record): Take mmap_record parameter by reference rather than by value. (mmap_record::map_pages): Fix comment. (mmap_list::add_record): Allocate space for mmap_record including the page_map in a single ccalloc call. Call init_page_map afterwards. (mmap_list::del_record): Remove call to mmap_record::free_page_map. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/ChangeLog.diff?cvsroot=srcr1=1.5193r2=1.5194 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/mmap.cc.diff?cvsroot=srcr1=1.163r2=1.164
src/winsup/cygwin ChangeLog mmap.cc
CVSROOT:/cvs/src Module name:src Changes by: cori...@sourceware.org 2011-03-18 13:42:03 Modified files: winsup/cygwin : ChangeLog mmap.cc Log message: * mmap.cc (class mmap_record): Pack 4 byte-aligned. Convert member dev to plain int. (mmap_record::alloc_fh): Create temporary device from dev and use in call to build_fh_dev. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/ChangeLog.diff?cvsroot=srcr1=1.5194r2=1.5195 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/mmap.cc.diff?cvsroot=srcr1=1.164r2=1.165
src/winsup/cygwin ChangeLog mmap.cc
CVSROOT:/cvs/src Module name:src Changes by: cori...@sourceware.org 2011-03-18 13:56:57 Modified files: winsup/cygwin : ChangeLog mmap.cc Log message: * mmap.cc (mmap_record::alloc_fh): Initialize nmae strings in fdev to empty strings or suffer a SEGV. Drop second parameter in call to build_fh_dev. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/ChangeLog.diff?cvsroot=srcr1=1.5195r2=1.5196 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/mmap.cc.diff?cvsroot=srcr1=1.165r2=1.166
src/winsup/cygwin ChangeLog cygwin.sc
CVSROOT:/cvs/src Module name:src Changes by: cori...@sourceware.org 2011-03-18 18:16:37 Modified files: winsup/cygwin : ChangeLog cygwin.sc Log message: * cygwin.sc: Raise default cygheap size to 2 Megs. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/ChangeLog.diff?cvsroot=srcr1=1.5198r2=1.5199 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/cygwin.sc.diff?cvsroot=srcr1=1.27r2=1.28
src/winsup/cygwin ChangeLog cygwin.sc
CVSROOT:/cvs/src Module name:src Branch: cv-post-1_7_9 Changes by: cori...@sourceware.org 2011-03-18 18:16:42 Modified files: winsup/cygwin : ChangeLog cygwin.sc Log message: * cygwin.sc: Raise default cygheap size to 2 Megs. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/ChangeLog.diff?cvsroot=srconly_with_tag=cv-post-1_7_9r1=1.5189.2.18r2=1.5189.2.19 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/cygwin.sc.diff?cvsroot=srconly_with_tag=cv-post-1_7_9r1=1.27r2=1.27.2.1
Re: ld: fatal error - cmalloc would have returned NULL
On Fri, Mar 18, 2011 at 05:47:04AM +, Dave Korn wrote: On 11/03/2011 13:53, Rainer Emrich wrote: I have to be more clear. I increased the heap_chunk_in_mb to 1792 using: regtool -i set /HKLM/Software/Cygwin/heap_chunk_in_mb 1792 I run with this setting all the time, I guess that's why I haven't seen this problem. Before I did that (couple of years back) I also used to get crashes building libjava. That setting should have nothing to do with cmalloc(). cmalloc is for Cygwin's internal heap which has nothing to do with that setting. Didn't Corinna already mention this? 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: Problems with terminal doesn't display visual elements properly
On 17 March 2011 22:09, Diego Queiroz wrote: Hello. I need some help. My terminal started with a very strange behavior today. Many programs are not displaying correctly and I don't know why. I uploaded this picture: http://img851.imageshack.us/i/screenshotfc.png/ The two windows at the top are displaying the nano and top programs using putty. The two windows at the bottom are displaying the same programs using cygwin, respectively. As you can see, the visual of the applications is different, and that's not all. I'm really not able to work with these applications because of this problem. Actually, any visual enhancement is not working properly. Even grep with --color option isn't working correctly. In the image, both programs are connected to the same server thru ssh, so IMO the problem is not related with server configuration or any tool specific setting. The problem also occurs when using cygwin in the local machine. I'm almost sure the problem is related with the dos emulator, but I don't have an idea whats wrong. The problem started when I did the last cygwin update (but I also updated many programs in the machine together, so I don't know if cygwin caused this). What's the server? Are you connecting with cygwin ssh (i.e. /usr/bin/ssh)? What's the TERM setting on the server? It should be 'cygwin'. or, if the server doesn't know that, 'vt100' should do. You might also want to try mintty (where TERM should be 'xterm'). 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: ITP dos2unix 5.2.1-1
Charles Wilson schreef, Op 17-3-2011 21:36: On 3/17/2011 4:08 PM, Eric Blake wrote: On 03/17/2011 01:56 PM, Erwin Waterlander wrote: I'm willing to maintain patches for Cygwin, to make the transition easier. But if there is no chance that the package gets accepted, I rather save myself the trouble. There's two sets of patches being talked about here: 1) What temporary (3-month?) patches are needed to make the dos2unix package a drop-in replacement to the existing cygwin dos2unix, so that people can start testing if it really was a drop-in. 2) What patches (permanent) are worth adding to upstream, to fix deficiencies in the usability of upstream when compared to what cygwin has. OK, everybody, time out for a minute. Rather than talk vapor, I'll develop the patches necessary. The first one, or first set (e.g. #2, above), I'll propose that official upstream dos2unix accept *for all platforms*. It will not change upstream's behavior in any way, except for offering some new options. The second one (#1, above), I'll propose that Erwin use as part of his initial cygwin package offering. This one would be only a transitional measure, and would be slated to be dropped from a later cygwin package after a certain amount of time has passed. Hi, I will create a branch for cygwin. I think that for temporary and redundant options it may be better to silently accept them and not document them. Existing scripts will not break, but usage of temporary options is discouraged and it saves work on translations. Usage of such an option may even trigger a warning that it will be removed in a future release. Then people have time to adapt. Useful options will end up in trunk. In the end there will be a single source for Cygwin and Linux, and both will take advantage of it. With regards to the d2u/u2d aliases, for now I'd just modify the cygport script to create those as hardlinks, and not modify or patch the package source at all. Standby... Do you want d2u/u2d to run conv, or the new dos2unix/unix2dos? Erwin -- 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: ITP dos2unix 5.2.1-1
On 3/17/2011 4:36 PM, Charles Wilson wrote: OK, everybody, time out for a minute. Rather than talk vapor, I'll develop the patches necessary. Fair warning: I've developed this patch set, and made a cygport-based package...but I have NOT TESTED the apps at all. More later, but it's way past my bed time... The first one, or first set (e.g. #2, above), I'll propose that official upstream dos2unix accept *for all platforms*. It will not change upstream's behavior in any way, except for offering some new options. 01-avoid-hardlink-exist-error.patch 02-cygwin-defines-win32-but-isnt.patch 03-add--safe-option.patch 04-add-follow-no-follow--infile-only.patch 05-rationalize-logic-flow.patch 06-add-ResolveSymbolicLink-function.patch 07-support-follow-no-follow--outfile.patch 08-use-canonicalize-file-name-glibc24-cygwin17.patch === 01-avoid-hardlink-exist-error.patch Makefile |2 ++ 1 file changed, 2 insertions(+) === 02-cygwin-defines-win32-but-isnt.patch dos2unix.c | 10 +- unix2dos.c | 10 +- 2 files changed, 10 insertions(+), 10 deletions(-) === 03-add--safe-option.patch dos2unix.c |3 +++ unix2dos.c |3 +++ 2 files changed, 6 insertions(+) === 04-add-follow-no-follow--infile-only.patch dos2unix.c | 25 ++--- unix2dos.c | 25 ++--- 2 files changed, 44 insertions(+), 6 deletions(-) === 05-rationalize-logic-flow.patch dos2unix.c | 27 --- unix2dos.c | 27 --- 2 files changed, 32 insertions(+), 22 deletions(-) === 06-add-ResolveSymbolicLink-function.patch dos2unix.c | 94 ++ unix2dos.c | 94 ++ 2 files changed, 188 insertions(+) === 07-support-follow-no-follow--outfile.patch dos2unix.c | 72 +-- unix2dos.c | 72 +-- 2 files changed, 132 insertions(+), 12 deletions(-) === 08-use-canonicalize-file-name-glibc24-cygwin17.patch dos2unix.c | 13 + unix2dos.c | 13 + 2 files changed, 26 insertions(+) Assuming they work (natch) I think these are suitable for upstream. The second one (#1, above), I'll propose that Erwin use as part of his initial cygwin package offering. This one would be only a transitional measure, and would be slated to be dropped from a later cygwin package after a certain amount of time has passed. === dos2unix-5.2.1-1.src.patch dos2unix.c |2 +- unix2dos.c |2 +- 2 files changed, 2 insertions(+), 2 deletions(-) Obviously, this one would eventually disappear, and would never go upstream. Then, of course, there's the purely packaging related patch: === dos2unix-5.2.1-1.cygwin.patch dos2unix.README | 95 setup.hint |7 2 files changed, 102 insertions(+) With regards to the d2u/u2d aliases, for now I'd just modify the cygport script to create those as hardlinks, and not modify or patch the package source at all. cygport script handles this. So... http://cygwin.cwilson.fastmail.fm/dos2unix-5.2.1-1-src.tar.bz2 http://cygwin.cwilson.fastmail.fm/dos2unix-5.2.1-1.tar.bz2 ...but be warned...ZERO testing so far. -- Chuck -- 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
How to setup cygwin to use always testmode
I'm using cygwin under windows to change text-files with windows line-endings (CR and LF). I wrote a lot of shell-scripts which call each other. The filenames in those scripts are sometimes given als windows filenames (e.g. c:\temp\file.txt) sometimes relative (e.g. ../tmp/file.txt) sometimes as unix filenames (e.g. /c/temp/file.txt) and sometimes without any directory (e.g. file.txt) The current versions of cygwin now only use entries from fstab to determine the mode but this will break all my scripts because the same file will sometimes be treated as binary (filename c:\temp\file.txt) and sometimes as text (filename /c/temp/file.txt). So is there a way to say 'use always textmode' like it was possible in former releases? -- 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: ITP dos2unix 5.2.1-1
Op 18-3-2011 7:53, Charles Wilson schreef: On 3/17/2011 4:36 PM, Charles Wilson wrote: OK, everybody, time out for a minute. Rather than talk vapor, I'll develop the patches necessary. Fair warning: I've developed this patch set, and made a cygport-based package...but I have NOT TESTED the apps at all. More later, but it's way past my bed time... The first one, or first set (e.g. #2, above), I'll propose that official upstream dos2unix accept *for all platforms*. It will not change upstream's behavior in any way, except for offering some new options. 01-avoid-hardlink-exist-error.patch 02-cygwin-defines-win32-but-isnt.patch 03-add--safe-option.patch 04-add-follow-no-follow--infile-only.patch 05-rationalize-logic-flow.patch 06-add-ResolveSymbolicLink-function.patch 07-support-follow-no-follow--outfile.patch 08-use-canonicalize-file-name-glibc24-cygwin17.patch === 01-avoid-hardlink-exist-error.patch Makefile |2 ++ 1 file changed, 2 insertions(+) === 02-cygwin-defines-win32-but-isnt.patch dos2unix.c | 10 +- unix2dos.c | 10 +- 2 files changed, 10 insertions(+), 10 deletions(-) === 03-add--safe-option.patch dos2unix.c |3 +++ unix2dos.c |3 +++ 2 files changed, 6 insertions(+) === 04-add-follow-no-follow--infile-only.patch dos2unix.c | 25 ++--- unix2dos.c | 25 ++--- 2 files changed, 44 insertions(+), 6 deletions(-) === 05-rationalize-logic-flow.patch dos2unix.c | 27 --- unix2dos.c | 27 --- 2 files changed, 32 insertions(+), 22 deletions(-) === 06-add-ResolveSymbolicLink-function.patch dos2unix.c | 94 ++ unix2dos.c | 94 ++ 2 files changed, 188 insertions(+) === 07-support-follow-no-follow--outfile.patch dos2unix.c | 72 +-- unix2dos.c | 72 +-- 2 files changed, 132 insertions(+), 12 deletions(-) === 08-use-canonicalize-file-name-glibc24-cygwin17.patch dos2unix.c | 13 + unix2dos.c | 13 + 2 files changed, 26 insertions(+) Assuming they work (natch) I think these are suitable for upstream. The second one (#1, above), I'll propose that Erwin use as part of his initial cygwin package offering. This one would be only a transitional measure, and would be slated to be dropped from a later cygwin package after a certain amount of time has passed. === dos2unix-5.2.1-1.src.patch dos2unix.c |2 +- unix2dos.c |2 +- 2 files changed, 2 insertions(+), 2 deletions(-) Obviously, this one would eventually disappear, and would never go upstream. Then, of course, there's the purely packaging related patch: === dos2unix-5.2.1-1.cygwin.patch dos2unix.README | 95 setup.hint |7 2 files changed, 102 insertions(+) With regards to the d2u/u2d aliases, for now I'd just modify the cygport script to create those as hardlinks, and not modify or patch the package source at all. cygport script handles this. So... http://cygwin.cwilson.fastmail.fm/dos2unix-5.2.1-1-src.tar.bz2 http://cygwin.cwilson.fastmail.fm/dos2unix-5.2.1-1.tar.bz2 ...but be warned...ZERO testing so far. Hi Chuck, Thank you very much for your hard work! I will have a look at it and do some testing. Erwin -- 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
gcc4 outstanding issues (was Re: Cygport woes: CHOST not defined.)
On Fri, 2011-03-18 at 05:18 +, Dave Korn wrote: On 18/03/2011 02:50, Yaakov (Cygwin/X) wrote: BTW, do you need me to resend my patches for 4.5.2? Couldn't hurt, I know I had some stuff to dig through my inbox looking for but if you wouldn't mind... g My outstanding issues with gcc4: 1) /lib/cpp symlink for FHS compliance: http://cygwin.com/ml/cygwin/2010-01/msg00601.html 2) fix-libtool-scripts-for-latest-gcc-runtimes.sh does nothing; 3) libgnat import libs are not installed; 4) Ada programs linked against shared libgnat do not terminate: http://cygwin.com/ml/cygwin/2010-08/msg00412.html 5) Patch to fix Java NIO (*NOT* the patch above): http://cygwin.com/ml/cygwin/2010-10/msg00562.html 6) Binaries should be linked against shared libintl: http://cygwin-ports.git.sourceforge.net/git/gitweb.cgi?p=cygwin-ports/gcc4;a=blob_plain;f=config-rpath.patch Except for (1) and (4), these are all fixed in Ports 4.5.2-1, and I've been quite pleased with the results. BTW, I wonder if we can begin mitigating (2) by not shipping the .la files with GCC. This would stop those paths from being hardcoded into other .la files, so that eventually only the libtool scripts will need to be fixed. Once I've got linker plugin stuff sorted out upstream for gcc-4.6/binutils-2.21.1, I'll build a 4.5.2 for the distro (and promote it to curr, leaving 4.3.4-4 as prev) then start working on a 4.6.0 test package. The sooner you can rebuild 4.5.2, the better; I've been using it for so long now that I can't update some of my distro packages because they depend on the newer GCC libraries. Let me know if I can help in any way. Yaakov -- 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
last snapshot (2011-03-13)
Hello, Please consider http://cygwin.com/ml/cygwin/2011-03/msg00436.html In fhandler.h i changed DEFAULT_PIPEBUFSIZE back to contain PREFERRED_IO_BLKSIZE (instead of 31*1024*1024), installed the new cygwin1.dll and of course, no more problem. I also performed extended tests on another Windows NT SP3, but couldn't observe any problem, not even once. BLODA? or subtle differences between two Windows? Denis Excoffier. This message was sent using IMP, the Internet Messaging Program. -- 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: ld: fatal error - cmalloc would have returned NULL
On Mar 18 02:08, Christopher Faylor wrote: On Fri, Mar 18, 2011 at 05:47:04AM +, Dave Korn wrote: On 11/03/2011 13:53, Rainer Emrich wrote: I have to be more clear. I increased the heap_chunk_in_mb to 1792 using: regtool -i set /HKLM/Software/Cygwin/heap_chunk_in_mb 1792 I run with this setting all the time, I guess that's why I haven't seen this problem. Before I did that (couple of years back) I also used to get crashes building libjava. That setting should have nothing to do with cmalloc(). cmalloc is for Cygwin's internal heap which has nothing to do with that setting. Didn't Corinna already mention this? In this case the bigger heap seems to avoid the aggressive use of small mmap chunks which in turn disallows to raise the cygheap size. Without analyzing the whole situation there's not much else to say or do. This is YA case which screams loudly for a testcase... Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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: last snapshot (2011-03-13)
On Mar 18 10:25, EXCOFFIER Denis wrote: Hello, Please consider http://cygwin.com/ml/cygwin/2011-03/msg00436.html In fhandler.h i changed DEFAULT_PIPEBUFSIZE back to contain PREFERRED_IO_BLKSIZE (instead of 31*1024*1024), installed the new cygwin1.dll and of course, no more problem. I also performed extended tests on another Windows NT SP3, but couldn't observe any problem, not even once. NT SP3? Is that NT4? BLODA? or subtle differences between two Windows? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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: last snapshot (2011-03-13)
On Mar 18 11:26, Corinna Vinschen wrote: On Mar 18 10:25, EXCOFFIER Denis wrote: Hello, Please consider http://cygwin.com/ml/cygwin/2011-03/msg00436.html In fhandler.h i changed DEFAULT_PIPEBUFSIZE back to contain PREFERRED_IO_BLKSIZE (instead of 31*1024*1024), installed the new cygwin1.dll and of course, no more problem. I also performed extended tests on another Windows NT SP3, but couldn't observe any problem, not even once. NT SP3? Is that NT4? Uh, I see, XP SP3. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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
last snapshot (2011-03-13)
This message follows http://cygwin.com/ml/cygwin/2011-03/msg00539.html Both system are Microsoft Windows XP Professional Version 2002 Service Pack 3. The system that produces the File too large error is: Intel(R) Core(TM)2 Duo CPU E6850 @ 3.00GHz 3.00 GHz, 3.48 GB of RAM The system where i'm unable to obtain the message is: Intel(R) Core(TM)2 Duo CPU T9600 @ 2.80GHz 2.79 GHz, 1.97 GB of RAM Hope this helps. This message was sent using IMP, the Internet Messaging Program. -- 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: Start a crontab service
On Thu, Mar 17, 2011 at 6:07 PM, Marc Girod marc.gi...@gmail.com wrote: Hello, I tried to install cron locally on my laptop, and could not find instructions to proceed. I understand. I tried so many different things trying to get this to work a year or two ago and never was successful in getting it to work. If you find a sequence of steps that gets it working correctly, please let me know. I am about to start the process of trying to get it to work again. -- Tcl - The glue of a new generation. http://wiki.tcl.tk/ Larry W. Virden http://www.facebook.com/lvirden/ Even if explicitly stated to the contrary, nothing in this posting should be construed as representing my employer's opinions. -- 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: Problems with the new base-files-4.0-5?
From: David Sastre
Please test if
[ -e ${p} ] read -r PRINTER ${p} PRINTER=${PRINTER%%,*}
works as expected.
No, it doesn't work, probably due to bash subshell or something,
as separating the final assignment from the command line *does*
work:
$ [ -e ${p} ] read -r PRINTER ${p} PRINTER=${PRINTER%%,*}
$ echo $PRINTER
\\tmsdc2\TMSEngineering,winspool,Ne02:
$ PRINTER=${PRINTER%%,*}
$ echo $PRINTER
\\tmsdc2\TMSEngineering
$
--Ken Nellis
Re: ITP dos2unix 5.2.1-1
On 3/18/2011 2:47 AM, Erwin Waterlander wrote: I will create a branch for cygwin. I think that for temporary and redundant options it may be better to silently accept them and not document them. We are still not communicating. I do NOT propose that the new options -- whether you call the redundant or not -- be temporary or cygwin specific. I propose that they be adopted, wholesale, for all platforms. I think the --follow option is a valuable alternate behavior that is different and distinct from anything the current option set allows. I believe --no-follow and --safe, being opposites of the new option and and existing option, respectively, are necessary for proper CLI design. Just like rm has both -i and -f. The ONLY part that I propose be temporary, and /NOT/ be committed to any source repository anyway, and simply carried as part of the cygwin packaging until no longer needed, is the bit that switches the default behavior on cygwin from --no-follow (as everywhere else) to --follow. Existing scripts will not break, but usage of temporary options is discouraged and it saves work on translations. Usage of such an option may even trigger a warning that it will be removed in a future release. Then people have time to adapt. Since I propose that the new options all stay, and propagate, I realize this means extra translation work. I'm not qualified for that, but I CAN cut-n-paste in all the translations those that correspond to new lines of code which were themselves cut-n-pasted from existing lines of code (several of the new error messages are cut-n-paste like this). I didn't have time to do this last night, and I can't help with the entirely new tranlatable strings, but I figured code first, .pot files later. In discussing these: 01-avoid-hardlink-exist-error.patch 02-cygwin-defines-win32-but-isnt.patch 03-add--safe-option.patch 04-add-follow-no-follow--infile-only.patch 05-rationalize-logic-flow.patch 06-add-ResolveSymbolicLink-function.patch 07-support-follow-no-follow--outfile.patch 08-use-canonicalize-file-name-glibc24-cygwin17.patch ignore the fact that some were developed to mimic cygutils' existing behavior. Some are just plan bugfixes (01, 02). One (05) is an attempt to make the code flow in *NewFile() and *OldFile() similar (and bugfix: set error retval even when Quiet, if there's an error). The rest (03, 04, 06-08) add new and IMO valuable options to the dos2unix package without changing current behavior. Don't bother with a special cygwin-only branch. Let's just discuss these patches, for trunk, on their own merits. BTW, do you have a more appropriate forum for those discussions, than this mailing list? A dedicated list or something? Useful options will end up in trunk. In the end there will be a single source for Cygwin and Linux, and both will take advantage of it. As I said, I see no need for a branch, that differs from trunk only by: - pFlag-Follow = 0; + pFlag-Follow = 1; in two places. With regards to the d2u/u2d aliases, for now I'd just modify the cygport script to create those as hardlinks, and not modify or patch the package source at all. Standby... Do you want d2u/u2d to run conv, or the new dos2unix/unix2dos? The new versions. -- Chuck -- 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: gcc4 outstanding issues (was Re: Cygport woes: CHOST not defined.)
On 3/18/2011 5:06 AM, Yaakov (Cygwin/X) wrote: BTW, I wonder if we can begin mitigating (2) by not shipping the .la files with GCC. This would stop those paths from being hardcoded into other .la files, so that eventually only the libtool scripts will need to be fixed. Yes, please. I think this should be done, upstream (4.7?), as well. There is no need for runtime libraries to have .la files IMO -- having them needlessly complicates, and provides no benefit (is it even supported, by gcc-devs, to dlopen/ltopen a runtime library, on all platforms?) -- Chuck -- 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: Problems with the new base-files-4.0-5?
On Fri, Mar 18, 2011 at 12:46:26AM +0100, Cyrille Lefevre wrote:
Le 17/03/2011 23:43, Angelo Graziosi a écrit :
p='/proc/registry/HKEY_CURRENT_USER/Software/Microsoft/Windows
NT/CurrentVersion/Windows/Device'
[ -e ${p} ] read -r PRINTER ${p} PRINTER=${PRINTER%%,*}
read -r $p returns 1 bcoz The return code is zero, unless
end-of-file is encountered...
alternative :
[ -e ${p} ] IFS=',' read -r PRINTER dummy ${p}
Works in bash, posh, mksh and zsh, but fails (at least for me) in
dash.
As it seems I can't find a short-circuiting option that works, I'll
use the `if' statement, since it appears to work for all shells.
All [[, have been changed to a portable [ test.
I've changed `test -a' for a portable `test -e', and the -a operator
in the user's home ownership test to a chained test:
elif [ ! -O ${HOME} ] [ ${HOME#/home/} != ${HOME} ]; then ...
which works for all shells but still fails for posh since posh does
not implement the -O test either (as per POSIX compliance, right?).
This is not easy to solve without rethinking that test, so I plan to
release 4.0-6 with this known bug, with the following workaround:
the code block that sets $HOME is now enclosed in a function that
tests for posh and returns before the ownership test.
The functionality is lost for those who use posh as a login shell (hopefully,
not too many...).
It would be included in the announcement message as well.
This has to be reported to the posh maintainer as well, but:
a) As stated in the manpage, posh -li should read /etc/profile, but it
doesn't (and that's why it doesn't complain about [[ presence in
/etc/profile)
b) It fails to source some of the /etc/profile.d/*.sh scripts due to not
finding its documented alias builtin:
$ . /etc/profile.d/mc.sh
posh: /etc/profile.d/mc.sh:1: alias: not found
$ builtin alias
posh: builtin: alias: not a builtin
To workaround this, posh won't source them, it's been explicitly disabled.
c) $POSH_VERSION returns literally POSH_VERSION (FWIW, both in cygwin
and GNU/Linux), instead of its version identifier, as bash and mksh do.
Maybe it's the expected (though uninformative) behaviour or a known
bug.
Last, can someone confirm that calling `dash -i' from mksh results in
`dash: Bad substitution' errors? (IOW, make mksh your login shell, and
run dash -i from your prompt).
--
Huella de clave primaria: 0FDA C36F F110 54F4 D42B D0EB 617D 396C 448B 31EB
signature.asc
Description: Digital signature
Re: How to setup cygwin to use always testmode
On 03/18/2011 01:43 AM, Ralf wrote: I'm using cygwin under windows to change text-files with windows line-endings (CR and LF). I wrote a lot of shell-scripts which call each other. The filenames in those scripts are sometimes given als windows filenames (e.g. c:\temp\file.txt) sometimes relative (e.g. ../tmp/file.txt) sometimes as unix filenames (e.g. /c/temp/file.txt) and sometimes without any directory (e.g. file.txt) The current versions of cygwin now only use entries from fstab to determine the mode but this will break all my scripts because the same file will sometimes be treated as binary (filename c:\temp\file.txt) and sometimes as text (filename /c/temp/file.txt). So is there a way to say 'use always textmode' like it was possible in former releases? Use cygpath to convert the filename to POSIX style, so that you never open a DOS path. -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: Problems with the new base-files-4.0-5?
On 18 March 2011 13:46, David Sastre wrote:
All [[, have been changed to a portable [ test.
I've changed `test -a' for a portable `test -e', and the -a operator
in the user's home ownership test to a chained test:
elif [ ! -O ${HOME} ] [ ${HOME#/home/} != ${HOME} ]; then ...
Even though that home ownership test was partly my idea, I think it
should simply be dropped, because it doesn't actually address the
security issue it was supposed to address and the warning is likely to
cause unnecessary alarm to users with unusual yet legitimate setups.
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: last snapshot (2011-03-13)
On Fri, Mar 18, 2011 at 10:25:38AM +0100, EXCOFFIER Denis wrote: Hello, Please consider http://cygwin.com/ml/cygwin/2011-03/msg00436.html I read it. I hadn't had time to look into it. In fhandler.h i changed DEFAULT_PIPEBUFSIZE back to contain PREFERRED_IO_BLKSIZE (instead of 31*1024*1024), installed the new cygwin1.dll and of course, no more problem. You say change it back as if that was the only change. It wasn't. The meaning changed in recent snapshots. I was trying to wrap my head around the fact that people reported failure with the recent snapshot which wrote fewer bytes to the pipe but I suppose that was because the buffer size was too large for their system to handle. Anyway, I've checked in a change which sets the size to 64K mib and a snapshot will be available with that change soon. This means that there will be an unfortunate speed degradation in pipe I/O with large buffers. I don't know how much that will be or if it will be noticeable but we can all thank Windows XP for making this workaround necessary. Thanks for confirming that this works. Can anyone else who had problems also confirm? 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: ld: fatal error - cmalloc would have returned NULL
On Mar 18 11:23, Corinna Vinschen wrote:
On Mar 18 02:08, Christopher Faylor wrote:
On Fri, Mar 18, 2011 at 05:47:04AM +, Dave Korn wrote:
On 11/03/2011 13:53, Rainer Emrich wrote:
I have to be more clear. I increased the heap_chunk_in_mb to 1792 using:
regtool -i set /HKLM/Software/Cygwin/heap_chunk_in_mb 1792
I run with this setting all the time, I guess that's why I haven't seen
this
problem. Before I did that (couple of years back) I also used to get
crashes
building libjava.
That setting should have nothing to do with cmalloc(). cmalloc is for
Cygwin's internal heap which has nothing to do with that setting.
Didn't Corinna already mention this?
In this case the bigger heap seems to avoid the aggressive use of small
mmap chunks which in turn disallows to raise the cygheap size. Without
analyzing the whole situation there's not much else to say or do. This
is YA case which screams loudly for a testcase...
I created an extensive testcase(*) and it turned out that the current
algorithm to allocate memory on the cygheap is wasting a lot of memory.
Actually it organizes the memory in buckets, each of which cares for a
specific size as a power of 2. So memory on the cygheap is always
allocated in chunks of 4 byte, 8 byte, 16 byte, 32 byte, etc. Plus,
every chunk needs extra 8 byte for bookkeeping.
Now, mmap has to keep a per-mmap record on the cygheap to maintain mmaps
across munmap and fork. The problem is that the size of the mmap record
so far is 64 bytes plus a 4 byte page bitmap per 128K of allocated memory.
So each mmap(64K) requires a 68 byte record. Due to the way the cygheap
allocation works, this takes actually 128 bytes on the cygheap. In my
testcase, after about 8500 mmaps, the required size of the mmap records
on the cygheap is 128*8500 = 1088000 bytes. Now we're out of space on
the cygheap, but it's not possible to raise the size of the cygheap
since the space beyond is taken by the mmaped regions. Consequentially
mmap fails, even though there's still space left in the processes
address space.
I applied a patch (actually three patches) to Cygwin now, which are
supposed to drop the cygheap usage of mmap. The size of a mmap record
is now only 48 bytes. A 64K mmap requires another 4 bytes for the page
bitmap. Plus 8 bytes bookkeeping for the allocation algorithm. Total
of 60 bytes. This happens to fit in a 64 bit chunk on the cygheap.
64*8500 = 544000 bytes, so there's still a lot of space left on the
cygheap.
The result in the below testcase(*) is now that cygheap is exhausted
only after 14826 calls to mmap(64K).
I've create a new snapshot with this change. Please test the latest
snapshot from http://cygwin.com/snapshots/
If this doesn't fix your issue with ld, then you would have to raise the
size of the cygheap before running ld. This requires a change to the
Cygwin DLL, but you can do this without rebuilding the DLL. Just using
objcopy should help to do it. A cygheap size of 2 Megs should be
sufficient to exhaust the application's address space faster than the
cygheap.
Corinna
(*) #include stdio.h
#include sys/mman.h
int
main ()
{
unsigned long i = 0;
void *m2 = NULL, *m1;
while ((m1 = mmap (NULL, 65536, PROT_READ | PROT_WRITE,
MAP_PRIVATE | MAP_ANONYMOUS, -1, 0)) != MAP_FAILED)
{
m2 = m1;
++i;
}
if (m2)
munmap (m2, 65536); /* Otherwise printf fails. */
printf (%d\n, i);
return 0;
}
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat
--
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: ld: fatal error - cmalloc would have returned NULL
On Fri, Mar 18, 2011 at 03:40:48PM +0100, Corinna Vinschen wrote: On Mar 18 11:23, Corinna Vinschen wrote: On Mar 18 02:08, Christopher Faylor wrote: On Fri, Mar 18, 2011 at 05:47:04AM +, Dave Korn wrote: On 11/03/2011 13:53, Rainer Emrich wrote: I have to be more clear. I increased the heap_chunk_in_mb to 1792 using: regtool -i set /HKLM/Software/Cygwin/heap_chunk_in_mb 1792 I run with this setting all the time, I guess that's why I haven't seen this problem. Before I did that (couple of years back) I also used to get crashes building libjava. That setting should have nothing to do with cmalloc(). cmalloc is for Cygwin's internal heap which has nothing to do with that setting. Didn't Corinna already mention this? In this case the bigger heap seems to avoid the aggressive use of small mmap chunks which in turn disallows to raise the cygheap size. Without analyzing the whole situation there's not much else to say or do. This is YA case which screams loudly for a testcase... I created an extensive testcase(*) and it turned out that the current algorithm to allocate memory on the cygheap is wasting a lot of memory. Actually it organizes the memory in buckets, each of which cares for a specific size as a power of 2. So memory on the cygheap is always allocated in chunks of 4 byte, 8 byte, 16 byte, 32 byte, etc. Plus, every chunk needs extra 8 byte for bookkeeping. Right. That's a fairly classic implementation of malloc which was, in this case, implemented by DJ Delorie. I chose that from a few other implementations because it was, at the time, supposed to be the best tradeoff between speed and memory usage. But, back when I implemented the cygheap it wasn't used as much as it is now, which I guess is fairly obvious. 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 setup cygwin to use
Eric Blake eblake at redhat.com writes: On 03/18/2011 01:43 AM, Ralf wrote: I'm using cygwin under windows to change text-files with windows line-endings (CR and LF). I wrote a lot of shell-scripts which call each other. The filenames in those scripts are sometimes given als windows filenames (e.g. c:\temp\file.txt) sometimes relative (e.g. ../tmp/file.txt) sometimes as unix filenames (e.g. /c/temp/file.txt) and sometimes without any directory (e.g. file.txt) The current versions of cygwin now only use entries from fstab to determine the mode but this will break all my scripts because the same file will sometimes be treated as binary (filename c:\temp\file.txt) and sometimes as text (filename /c/temp/file.txt). So is there a way to say 'use always textmode' like it was possible in former releases? Use cygpath to convert the filename to POSIX style, so that you never open a DOS path. So I have to go to all my shell scripts (some 1000 lines) and have to find out which parameters are filenames and which ones not. This will take some weeks. Is there no global flag to control this? I can not understand why this feature has been dropped. In an windows environment the new behaviour is very confusing. Here an example how sh.exe behaves: C:\sw\binmount C:/unix/bin on /usr/bin type ntfs (binary,auto) C:/unix/lib on /usr/lib type ntfs (binary,auto) C:/unix on / type ntfs (binary,auto) C: on /c type ntfs (text,posix=0,user,noumount,auto) D: on /d type ntfs (text,posix=0,user,noumount,auto) S: on /s type ntfs (text,posix=0,user,noumount,auto) Z: on /z type ntfs (text,posix=0,user,noumount,auto) C:\sw\binsh twg.sh ok C:\sw\binsh ./twg.sh ok C:\sw\binsh .\twg.sh .\twg.sh: line 2: syntax error near unexpected token `$'in\r'' '\twg.sh: line 2: ` case $funk in C:\sw\binsh c:\sw\bin\twg.sh c:\sw\bin\twg.sh: line 2: syntax error near unexpected token `$'in\r'' ':\sw\bin\twg.sh: line 2: ` case $funk in C:\sw\bin I know d2u c:\sw\bin\twg.sh will solve this particular problem but this will not solve the problems with all the windows files twg.sh reads and writes. I understand that it can be helpful to make it dependent from the filesystem but if you use cygwin as an helpful tool in an pure windows environment it's now confusing and error-prone. In the past I didn't have to pay attention to line endings. All programs (windows and cygwin) used CR LF. But now I have to look at each called program do find out wich line-endings are written. I think it's hard to understand that the same input gives different results depending on filenames. You can see a lot of posts here which are about this problem. So is there a chance to get back the global setting of textmode, or is there a way to get textmode without changing all the scripts? -- 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 setup cygwin to use
On 03/18/2011 09:11 AM, ralf wrote: I can not understand why this feature has been dropped. What feature? Cygwin was designed with POSIX pathnames in mind. If DOS pathnames work, it is a fortunate side-effect, but not the primary design goal, and not subject to stay the same in future releases. The only way to guarantee sane behavior from cygwin is to always use POSIX pathnames. C:\sw\binsh twg.sh ok POSIX path. C:\sw\binsh ./twg.sh ok POSIX path. C:\sw\binsh .\twg.sh .\twg.sh: line 2: syntax error near unexpected token `$'in\r'' '\twg.sh: line 2: ` case $funk in DOS path - don't do that if you don't want surprises. And if you want bash to ignore \r, then reread the bash release announcements for several ideas for doing this (including 'set -o igncr' or setting the SHELLOPTS environment variable before bash is started). http://cygwin.com/ml/cygwin-announce/2011-02/msg00027.html C:\sw\binsh c:\sw\bin\twg.sh c:\sw\bin\twg.sh: line 2: syntax error near unexpected token `$'in\r'' ':\sw\bin\twg.sh: line 2: ` case $funk in DOS path - don't do that if you don't want surprises. In the past I didn't have to pay attention to line endings. All programs (windows and cygwin) used CR LF. But now I have to look at each called program do find out wich line-endings are written. If you are writing files for cygwin, then it is much preferred that you omit CR, since cygwin emulates Linux which omits CR. But if you must interact with text mode files, then use a text mode mount or tell bash that you plan on working with text mode and that bash should ignore CR. So is there a chance to get back the global setting of textmode, or is there a way to get textmode without changing all the scripts? /etc/fstab and set textmode mount points on the directories where you want it. But you _don't_ want it globally - for example it's great for data files elsewhere in windows, but a bad idea for cygwin's /bin. -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
/etc/profile in base-files 4.0-5
Hi,
Just upgraded, and got a new glitch:
/etc/profile: line 39: ${p}: ambiguous redirect
It sounds ${p} should be quoted to take care of possible spaces in the path
to the Windows device:
# Define default printer
p='/proc/registry/HKEY_CURRENT_USER/Software/Microsoft/Windows
NT/CurrentVersion/Windows/Device'
([[ -e ${p} ]] read -r PRINTER ${p}) PRINTER=${PRINTER%%,*}
Marc
--
View this message in context:
http://old.nabble.com/-etc-profile-in-base-files-4.0-5-tp31182191p31182191.html
Sent from the Cygwin list mailing list archive at Nabble.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
Migrating home dir
I'm going to be migrating to win7 in a few weeks. When I do I'll be logging in with a different userid. What's the best way to migrate my existing install and home dir to the new userid? Thanks - Tod -- 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: Migrating home dir
On 3/18/2011 10:28, Tod wrote: I'm going to be migrating to win7 in a few weeks. When I do I'll be logging in with a different userid. What's the best way to migrate my existing install and home dir to the new userid? My recommendation is that you back up only your Cygwin home directory contents, perhaps even with Cygwin's zip program. Then install a fresh Cygwin installation on the new system. Finally extract the home directory backup to your new Cygwin home directory. Speaking from personal experience, trying to transplant an existing Cygwin installation wholesale can be tricky and error prone, and it is not a supported operation for installation. You should avoid that if possible. -Jeremy -- 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: ld: fatal error - cmalloc would have returned NULL
On Mar 18 10:56, Christopher Faylor wrote: On Fri, Mar 18, 2011 at 03:40:48PM +0100, Corinna Vinschen wrote: On Mar 18 11:23, Corinna Vinschen wrote: On Mar 18 02:08, Christopher Faylor wrote: On Fri, Mar 18, 2011 at 05:47:04AM +, Dave Korn wrote: On 11/03/2011 13:53, Rainer Emrich wrote: I have to be more clear. I increased the heap_chunk_in_mb to 1792 using: regtool -i set /HKLM/Software/Cygwin/heap_chunk_in_mb 1792 I run with this setting all the time, I guess that's why I haven't seen this problem. Before I did that (couple of years back) I also used to get crashes building libjava. That setting should have nothing to do with cmalloc(). cmalloc is for Cygwin's internal heap which has nothing to do with that setting. Didn't Corinna already mention this? In this case the bigger heap seems to avoid the aggressive use of small mmap chunks which in turn disallows to raise the cygheap size. Without analyzing the whole situation there's not much else to say or do. This is YA case which screams loudly for a testcase... I created an extensive testcase(*) and it turned out that the current algorithm to allocate memory on the cygheap is wasting a lot of memory. Actually it organizes the memory in buckets, each of which cares for a specific size as a power of 2. So memory on the cygheap is always allocated in chunks of 4 byte, 8 byte, 16 byte, 32 byte, etc. Plus, every chunk needs extra 8 byte for bookkeeping. Right. That's a fairly classic implementation of malloc which was, in this case, implemented by DJ Delorie. I chose that from a few other implementations because it was, at the time, supposed to be the best tradeoff between speed and memory usage. But, back when I implemented the cygheap it wasn't used as much as it is now, which I guess is fairly obvious. Maybe we should modify the implementation at one point, but for now I'm wonderin if we shouldn't just raise the cygheap size to 2 Megs. It's still not much memory given today's RAM sizes, and it's only a fraction of the application's address space. But it is enough so that ld's address space will be exhausted before the cygheap is exhausted. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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: /etc/profile in base-files 4.0-5
On Fri, Mar 18, 2011 at 08:22:01AM -0700, Marc Girod wrote:
/etc/profile: line 39: ${p}: ambiguous redirect
It sounds ${p} should be quoted to take care of possible spaces in the path
to the Windows device:
Thanks for reporting.
A fix is on its way. See
http://cygwin.com/ml/cygwin/2011-03/msg00503.html
for reference.
--
Huella de clave primaria: 0FDA C36F F110 54F4 D42B D0EB 617D 396C 448B 31EB
signature.asc
Description: Digital signature
Re: Start a crontab service
Larry W. Virden-2 wrote: If you find a sequence of steps that gets it working correctly, please let me know. Not yet... but found some doc I had missed: /usr/share/doc/Cygwin/cron-4.1-59.README as part of the cron package (I looked at the crontab one so far...). This sends me to: http://cygwin.com/cygwin-ug-net/ntsec.html#ntsec-nopasswd1 Still reading... Marc -- View this message in context: http://old.nabble.com/Start-a-crontab-service-tp31176889p31182509.html Sent from the Cygwin list mailing list archive at Nabble.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: How to setup cygwin to use always textmode
Eric Blake eblake at redhat.com writes: On 03/18/2011 09:11 AM, ralf wrote: I can not understand why this feature has been dropped. What feature? Cygwin was designed with POSIX pathnames in mind. If DOS pathnames work, it is a fortunate side-effect, but not the primary design goal, and not subject to stay the same in future releases. The only way to guarantee sane behavior from cygwin is to always use POSIX pathnames. During setup of cygwin you could choose between UNIX ending und DOS ending. I choosed DOS (CR LF) endings and so I was able to mix cywin (my shell scripts) batch-files and windows executables and the naming of files didn't matter. After updating to the current release most of my scripts failed!!! Windows programs can't read the output of my scrips and my scripts can't read most of my text-files successfully. C:\sw\binsh twg.sh ok POSIX path. C:\sw\binsh ./twg.sh ok POSIX path. C:\sw\binsh .\twg.sh .\twg.sh: line 2: syntax error near unexpected token `$'in\r'' '\twg.sh: line 2: ` case $funk in DOS path - don't do that if you don't want surprises. And if you want bash to ignore \r, then reread the bash release announcements for several ideas for doing this (including 'set -o igncr' or setting the SHELLOPTS environment variable before bash is started). http://cygwin.com/ml/cygwin-announce/2011-02/msg00027.html And how can I get bash to write always CR? Adding \r to each echo,cat,awk ... ? Only finding the places where this is necessary will take weeks. C:\sw\binsh c:\sw\bin\twg.sh c:\sw\bin\twg.sh: line 2: syntax error near unexpected token `$'in\r'' ':\sw\bin\twg.sh: line 2: ` case $funk in DOS path - don't do that if you don't want surprises. I don't want to do it this way. It's the way it is done in my scripts (lots of them not only written by me). What can I do to get then to work without recoding all? In the past I didn't have to pay attention to line endings. All programs (windows and cygwin) used CR LF. But now I have to look at each called program do find out wich line-endings are written. If you are writing files for cygwin, then it is much preferred that you omit CR, since cygwin emulates Linux which omits CR. But if you must interact with text mode files, then use a text mode mount or tell bash that you plan on working with text mode and that bash should ignore CR. So is there a chance to get back the global setting of textmode, or is there a way to get textmode without changing all the scripts? /etc/fstab and set textmode mount points on the directories where you want it. But you _don't_ want it globally - for example it's great for data files elsewhere in windows, but a bad idea for cygwin's /bin. Textmode mount points don't solve the problem if depending on the filename cygwin behaves different. I have to change all filenames in all sripts. Windows programs writing filenames now have to write unix filenams for script files and windows filenames for other windows programs. Shell-scripts now have to write Windows-filenames for windows programs and unix filenames for other shell scipts and so on. How do I have to write filenames to a file when unix and windows programs read this file? Thank you very much for your patience but despite of all our usefull hints I think this does not solve my problem. So are there other features to get back textmode like in earlier releases? -- 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: Start a crontab service
Marc Girod wrote: Still reading... Actually... in my very simple case, running: /usr/bin/cron-config and accepting the defaults (recording my own password) was enough to get cron the work... $ cygrunsrv -L cron $ crontab ~/cron/mg $ crontab -l # DO NOT EDIT THIS FILE - edit the master and reinstall. # (/home/emagiro/cron/mg installed on Fri Mar 18 16:05:28 2011) # (Cron version V5.0 -- $Id: crontab.c,v 1.12 2004/01/23 18:56:42 vixie Exp $) */5 * * * * /usr/bin/wget -q --no-proxy -T5 -t1 -O/tmp/wget.out http://eieatx016:8080/ Marc -- View this message in context: http://old.nabble.com/Start-a-crontab-service-tp31176889p31182598.html Sent from the Cygwin list mailing list archive at Nabble.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: Problems with the new base-files-4.0-5?
From: David Sastre
On Fri, Mar 18, 2011 at 12:46:26AM +0100, Cyrille Lefevre wrote:
Le 17/03/2011 23:43, Angelo Graziosi a écrit :
p='/proc/registry/HKEY_CURRENT_USER/Software/Microsoft/Windows
NT/CurrentVersion/Windows/Device'
[ -e ${p} ] read -r PRINTER ${p} PRINTER=${PRINTER%%,*}
read -r $p returns 1 bcoz The return code is zero, unless
end-of-file is encountered...
alternative :
[ -e ${p} ] IFS=',' read -r PRINTER dummy ${p}
While you're at it, it would probably be a good idea to:
$ unset p
when you're done with it.
--Ken Nellis
Re: last snapshot (2011-03-13)
On Mar 18 12:03, EXCOFFIER Denis wrote: This message follows http://cygwin.com/ml/cygwin/2011-03/msg00539.html Both system are Microsoft Windows XP Professional Version 2002 Service Pack 3. The system that produces the File too large error is: Intel(R) Core(TM)2 Duo CPU E6850 @ 3.00GHz 3.00 GHz, 3.48 GB of RAM The system where i'm unable to obtain the message is: Intel(R) Core(TM)2 Duo CPU T9600 @ 2.80GHz 2.79 GHz, 1.97 GB of RAM Maybe it has something to do with the nonpaged pool size? MSDN states: Every time a named pipe is created, the system creates the inbound and/or outbound buffers using nonpaged pool, which is the physical memory used by the kernel. [...] The input and output buffer sizes are advisory. The actual buffer size reserved for each end of the named pipe is either the system default, the system minimum or maximum, or the specified size rounded up to the next allocation boundary. The buffer size specified should be small enough that your process will not run out of nonpaged pool, but large enough to accommodate typical requests. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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 setup cygwin to use always textmode
On 03/18/2011 10:00 AM, ralf wrote: Eric Blake eblake at redhat.com writes: On 03/18/2011 09:11 AM, ralf wrote: I can not understand why this feature has been dropped. What feature? Cygwin was designed with POSIX pathnames in mind. If DOS pathnames work, it is a fortunate side-effect, but not the primary design goal, and not subject to stay the same in future releases. The only way to guarantee sane behavior from cygwin is to always use POSIX pathnames. During setup of cygwin you could choose between UNIX ending und DOS ending. Which was a bug in the GUI for offering it in the first place, because it basically set the text-mode mount flag on every single directory, including /bin, which is counterproductive. But you didn't need the setup.exe radio button to get the same effect, instead, just change your mounts manually (/etc/fstab) to set the text-mode mount flag on the subset of directories where it matters to you. I choosed DOS (CR LF) endings and so I was able to mix cywin (my shell scripts) batch-files and windows executables and the naming of files didn't matter. After updating to the current release most of my scripts failed!!! Windows programs can't read the output of my scrips and my scripts can't read most of my text-files successfully. Then tell bash that you want it to ignore CR (set -o igncr, or set SHELLOPTS in the environment before invoking bash). And how can I get bash to write always CR? Adding \r to each echo,cat,awk ... ? Only finding the places where this is necessary will take weeks. That's why we don't recommend text-mode mounts for cygwin-owned directories. dos2unix can also do some smart conversions (it has smarts to avoid corrupting binary files while still converting text files). -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: Problems with the new base-files-4.0-5?
On Fri, Mar 18, 2011 at 02:17:14PM +, Andy Koppe wrote:
On 18 March 2011 13:46, David Sastre wrote:
All [[, have been changed to a portable [ test.
I've changed `test -a' for a portable `test -e', and the -a operator
in the user's home ownership test to a chained test:
elif [ ! -O ${HOME} ] [ ${HOME#/home/} != ${HOME} ]; then ...
Even though that home ownership test was partly my idea, I think it
should simply be dropped, because it doesn't actually address the
security issue it was supposed to address and the warning is likely to
cause unnecessary alarm to users with unusual yet legitimate setups.
IIRC, the point was that some apps expect $HOME to be owned by the
user in order to operate correctly.
--
Huella de clave primaria: 0FDA C36F F110 54F4 D42B D0EB 617D 396C 448B 31EB
signature.asc
Description: Digital signature
last snapshot (2011-03-18)
This follows http://cygwin.com/ml/cygwin/2011-03/msg00549.html You say change it back as if that was the only change. It wasn't. The meaning changed in recent snapshots. In fact, i created a snapshot 20110313++, where the only change wrt 20110313 was to replace 31*1024*1024 with PREFERRED_IO_BLKSIZE. Ok, the snapshot 20110313 failed with File too large on some machine (even the command `cat /dev/zero | wc` failed with that message), but i'm still not convinced that it is not BLODA's fault: - i have McAfee installed (cannot uninstall, sorry) - the failure was intermittent: - cat /dev/zero | wc always failed - cat file-of-32-Mb | wc: almost always failed - cat file-of-31-Mb | wc: failed less often - cat file-of-30-Mb | wc: failed about 50% of the time - smaller files: never failed - it never failed on a similar Windows XP (with more or less similar BLODA), i mean even with `cat /dev/zero | wc` Therefore, we definitely need more opinions. I've installed the last snapshot (2011-03-18 10:29:21) on both machines, no problems until now. Denis Excoffier. This message was sent using IMP, the Internet Messaging Program. -- 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: Problems with the new base-files-4.0-5?
On Fri, Mar 18, 2011 at 11:14:09AM -0500, Nellis, Kenneth wrote: While you're at it, it would probably be a good idea to: $ unset p when you're done with it. Indeed. Already applied. In fact, there was another one (fDest, used in a loop to copy skel files). Thanks. -- Huella de clave primaria: 0FDA C36F F110 54F4 D42B D0EB 617D 396C 448B 31EB signature.asc Description: Digital signature
Re: Problems with the new base-files-4.0-5?
On 18 March 2011 16:23, David Sastre wrote:
On Fri, Mar 18, 2011 at 02:17:14PM +, Andy Koppe wrote:
On 18 March 2011 13:46, David Sastre wrote:
All [[, have been changed to a portable [ test.
I've changed `test -a' for a portable `test -e', and the -a operator
in the user's home ownership test to a chained test:
elif [ ! -O ${HOME} ] [ ${HOME#/home/} != ${HOME} ]; then ...
Even though that home ownership test was partly my idea, I think it
should simply be dropped, because it doesn't actually address the
security issue it was supposed to address and the warning is likely to
cause unnecessary alarm to users with unusual yet legitimate setups.
IIRC, the point was that some apps expect $HOME to be owned by the
user in order to operate correctly.
Originally at least it was supposed to address this:
http://www.cygwin.com/ml/cygwin-developers/2010-09/msg7.html
The $HOME warning doesn't address this because for example a
maliciously prepared /home/$USER/.bash_profile would still get
sourced.
I can't remember other reasons.
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
last snapshot (2011-03-13)
This follows http://cygwin.com/ml/cygwin/2011-03/msg00563.html Maybe it has something to do with the nonpaged pool size? MSDN states: Every time a named pipe is created, the system creates the inbound and/or outbound buffers using nonpaged pool, which is the physical memory used by the kernel. [...] The input and output buffer sizes are advisory. The actual buffer size reserved for each end of the named pipe is either the system default, the system minimum or maximum, or the specified size rounded up to the next allocation boundary. The buffer size specified should be small enough that your process will not run out of nonpaged pool, but large enough to accommodate typical requests. We could be in the right direction: i've open Task manager on both machines and the non-failing one has Nonpaged=98Mb and the failing one has Nonpaged=36Mb (only). Of course, these values are constantly moving, but seem to remain within an interval of a few Mb. Denis Excoffier. This message was sent using IMP, the Internet Messaging Program. -- 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 setup cygwin to use always textmode
Eric Blake eblake at redhat.com writes: On 03/18/2011 10:00 AM, ralf wrote: During setup of cygwin you could choose between UNIX ending und DOS ending. Which was a bug in the GUI for offering it in the first place, because it basically set the text-mode mount flag on every single directory, including /bin, which is counterproductive. But you didn't need the setup.exe radio button to get the same effect, instead, just change your mounts manually (/etc/fstab) to set the text-mode mount flag on the subset of directories where it matters to you. In releases with this radio button files with windows filenames were opened as text-files like files which were on a filesystem with text-mode mount flag. Now they are always opened as binary files. I have no chance to open a file with windows-filename as text-file. This feature (open-mode of files with windows-filenames) has been lost, or do I misunderstand something? And how can I get bash to write always CR? Adding \r to each echo,cat,awk? Only finding the places where this is necessary will take weeks. That's why we don't recommend text-mode mounts for cygwin-owned directories. dos2unix can also do some smart conversions (it has smarts to avoid corrupting binary files while still converting text files). So your advice is to recode all scipts. Is that right? -- 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: Problems with the new base-files-4.0-5?
On Fri, Mar 18, 2011 at 04:41:49PM +, Andy Koppe wrote:
On 18 March 2011 16:23, David Sastre wrote:
On Fri, Mar 18, 2011 at 02:17:14PM +, Andy Koppe wrote:
On 18 March 2011 13:46, David Sastre wrote:
All [[, have been changed to a portable [ test.
I've changed `test -a' for a portable `test -e', and the -a operator
in the user's home ownership test to a chained test:
elif [ ! -O ${HOME} ] [ ${HOME#/home/} != ${HOME} ]; then ...
Even though that home ownership test was partly my idea, I think it
should simply be dropped, because it doesn't actually address the
security issue it was supposed to address and the warning is likely to
cause unnecessary alarm to users with unusual yet legitimate setups.
IIRC, the point was that some apps expect $HOME to be owned by the
user in order to operate correctly.
Originally at least it was supposed to address this:
http://www.cygwin.com/ml/cygwin-developers/2010-09/msg7.html
The $HOME warning doesn't address this because for example a
maliciously prepared /home/$USER/.bash_profile would still get
sourced.
I can't remember other reasons.
OK. I'll drop it then.
--
Huella de clave primaria: 0FDA C36F F110 54F4 D42B D0EB 617D 396C 448B 31EB
signature.asc
Description: Digital signature
Re: last snapshot (2011-03-13)
On Fri, Mar 18, 2011 at 05:43:40PM +0100, EXCOFFIER Denis wrote: This follows http://cygwin.com/ml/cygwin/2011-03/msg00563.html Maybe it has something to do with the nonpaged pool size? MSDN states: Every time a named pipe is created, the system creates the inbound and/or outbound buffers using nonpaged pool, which is the physical memory used by the kernel. [...] The input and output buffer sizes are advisory. The actual buffer size reserved for each end of the named pipe is either the system default, the system minimum or maximum, or the specified size rounded up to the next allocation boundary. The buffer size specified should be small enough that your process will not run out of nonpaged pool, but large enough to accommodate typical requests. We could be in the right direction: i've open Task manager on both machines and the non-failing one has Nonpaged=98Mb and the failing one has Nonpaged=36Mb (only). Of course, these values are constantly moving, but seem to remain within an interval of a few Mb. Sorry. The lack of threading and over-cutting of comments has me a little confused. AFAICT, we're now responding to my comment: On Fri, 18 Mar 2011 10:31:15 -0400 cgf wrote: I suppose that was because the buffer size was too large for their system to handle. Or, are you saying that you still see failures when setting the buffer size down to 64K? -- 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: last snapshot (2011-03-13)
Le 18 mars 2011 à 19:02, Christopher Faylor a écrit : Or, are you saying that you still see failures when setting the buffer size down to 64K? With a buffer 64k all is fine. With a buffer 31*1024*1024, that's different. It seems that all pipes open at the same time add their buffers up to an upper limit (the nonpaged value) which cannot be exceeded. This also explains a failure i had this afternoon, on the CPU which was normally non-failing: i launched 5 xz-compressions at the same time (not big ones, but you must know that xz-compression can be rather slow even on small files, so it is very likely that the 5 were concurrent); and 3 of them failed unexpectedly. I understand now that 5 open pipes at the same time would use 5*31*1024*1024 bytes, which is too much for a CPU that has nonpaged=98Mb as i said in my previous message. Now, i suppose that with a 64k buffer, you would not be able to exceed 98Mb/64kb=1568 open pipes at the same time. Denis Excoffier. -- 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
Cygwin (1.7.8 and other versions) problems with globbing when invoked from DOS/Windows with nested quotes
Hi,
Short summary: getting nested quotes in an argument through to a
Cygwin process from DOS is problematic, and there does not seem to be
any detailed spec for how to escape quotes correctly. Backslash
characters seem to be spuriously generated.
I'm working on a build system (GNU make, Windows build), which invokes
the Cygwin shell to run commands, like so:
sh.exe -c command arg1 arg2 etc
I've run into some serious problems when command is a DOS path (e.g.
c:/qtpath/moc.exe) and one of the arg's is quoted.
Naturally, the problem could be at two points:
1) the Windows code in make could be escaping things incorrectly for
the Cygwin loader to interpret
2) the Cygwin loader does not handle this case correctly.
A simple test **
I made the following simple Cygwin program, to better show what sh.exe
would be getting from make:
#include stdio.h
int main(int argc, char **argv) {
int i;
for (i = 1; i argc; i++) printf(%d : %s\n, i, argv[i]);
return 0;
}
-- Normal program name --
c:\cygwin\home\akhripinargs foo 1 2 3 4
1 : foo 1 2 3 4
-- DOS'y program name --
c:\cygwin\home\akhripinargs c:/foo 1 2 3 4
1 : c:/foo 1 \2 3\ 4
As you can see, the second case causes \ escape characters to show up
- and the worst thing, one of them is now escaping a space - so the
above would be further split up as c:/foo 1 2 3 4 -- completely
changing which arguments were grouped together.
The noglob option **
When I turn on CYGWIN=noglob, there seems to be no way at all to get a
double quote through to the test program - no amount of escaping or
single quotes does the trick. As such, that does not seem to be an
option available to me.
Is the above a bug? **
I cannot find any mailing list entries or documentation on how quotes
are processed. I looked at the cygwin source (winsup/sources/dcrt0.cc)
and it looks like it enables special processing when an argument
starts with Letter-Colon. I'm sure that's there for good reasons - but
is that processing correct for cases with quotes?
Basically, my question boils down to: is this a Cygwin problem that
can be fixed, or should I pursue a fix to Windows make?
Correct escaping **
From what I've been able to determine, there is no consistent way to
escape and \ characters that works both for arguments that are
normal and those that look like DOS paths. If that is the intent,
that's fine - I've been working on a patch for make.
My conclusion is that for escaping normal arguments, the current
approach of turning nested into and \ into \\ works fine.
For arguments that look like DOS paths, it looks like the right answer
is pretty complex: enclose the whole argument in if it is not, then
use '' for and \ for \; what this does is close the current
double quoted statement, insert the desired character, and resume the
double quoted statement
--
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: ssh-keygen command not doing anything OR github problem
I have the precisely same problem - were you able to resolve this? I have tried reinstalling, looked online for others w/a similar issue, but thus far have run across no solution. Thanks! mearrex wrote: In my cygwin installation, I cannot seem to use github.com. However, here are the problems I am seeing. When I type in: git remote add origin g...@github.com:username/first_app.git I got no issue. However, when I type in: git push origin master I get an error: fatal: The remote end hung up unexpectedly I have tried to do that using these instructions: http://help.github.com/msysgit-key-setup/ http://help.github.com/troubleshooting-ssh/ However, when I type in the commands ssh ssh-keygen ssh-keygen -t rsa -C xxx...@xxx.com ssh g...@github.com ssh -v g...@github.com nothing happens. It just returns a new line. I am attaching a screenshot. What am I doing wrong? What do I need to do to get this to work? http://old.nabble.com/file/p30829947/screenshot.jpg -- View this message in context: http://old.nabble.com/ssh-keygen-command-not-doing-anything-OR-github-problem-tp30829947p31183959.html Sent from the Cygwin list mailing list archive at Nabble.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
[ANNOUNCEMENT] Updated base-files-4.0-6
Version 4.0-6 of base-files has been uploaded. Base-files is a set of system configuration and setup files. Change Log -- 4.0-6 * Re-corrected PRINTER setting. * Dropped non-POSIX tests in /etc/profile - Eric Blake * Dropped user's homedir ownership test. *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO *** If you want to unsubscribe from the cygwin-announce mailing list, look at the List-Unsubscribe: tag in the email header of this message. Send email to the address specified there. It will be in the format: cygwin-announce-unsubscribe-you=yourdomain@cygwin.com If you need more information on unsubscribing, start reading here: http://sourceware.org/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. -- Huella de clave primaria: 0FDA C36F F110 54F4 D42B D0EB 617D 396C 448B 31EB signature.asc Description: Digital signature
Re: last snapshot (2011-03-13)
On Fri, Mar 18, 2011 at 07:39:39PM +0100, Denis Excoffier wrote: Le 18 mars 2011 ? 19:02, Christopher Faylor a ?crit : Or, are you saying that you still see failures when setting the buffer size down to 64K? With a buffer 64k all is fine. With a buffer 31*1024*1024, that's different. It seems that all pipes open at the same time add their buffers up to an upper limit (the nonpaged value) which cannot be exceeded. Ok, if I'm reading this right, you're saying that the current snapshot works. I'm looking for verification of that. I understood why the previous snapshot probably wasn't working when I first responded today. We don't need to rehash that. Now, i suppose that with a 64k buffer, you would not be able to exceed 98Mb/64kb=1568 open pipes at the same time. Since the allocation of the buffer is now no longer different than previous versions of 1.7.x there shouldn't be any new behavior wrt the memory set aside for pipes. Cygwin should now just work around the potential for seeing ERROR_NO_SYSTEM_RESOURCES when writing large buffers. 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: Cygwin (1.7.8 and other versions) problems with globbing when invoked from DOS/Windows with nested quotes
On 3/18/2011 2:39 PM, Alex Khripin wrote: Hi, Short summary: getting nested quotes in an argument through to a Cygwin process from DOS is problematic, and there does not seem to be any detailed spec for how to escape quotes correctly. Backslash characters seem to be spuriously generated. If you're using a native Windows 'make' with a Cywgin shell, you're better off making your tools consistent. Quoting mechanisms for Windows do not align with those used by Cygwin/Linux/Unix, so things are already problematic. Passing in a DOS path to a Cygwin shell and expecting the output to be properly quoted for a Windows version of 'make' is just asking for trouble. So I'd recommend staying on one side of the fence or the other if you want to minimize headaches. -- Larry _ A: Yes. Q: Are you sure? A: Because it reverses the logical flow of conversation. Q: Why is top posting annoying in email? -- 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: ssh-keygen command not doing anything OR github problem
On 3/18/2011 2:45 PM, sclaussen wrote: I have the precisely same problem - were you able to resolve this? I have tried reinstalling, looked online for others w/a similar issue, but thus far have run across no solution. If you're using msysgit, you want to talk to Mingw folks. -- Larry _ A: Yes. Q: Are you sure? A: Because it reverses the logical flow of conversation. Q: Why is top posting annoying in email? -- 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.8 and other versions) problems with globbing when invoked from DOS/Windows with nested quotes
On Fri, Mar 18, 2011 at 6:00 PM, Larry Hall (Cygwin) wrote: On 3/18/2011 2:39 PM, Alex Khripin wrote: If you're using a native Windows 'make' with a Cywgin shell, you're better off making your tools consistent. Quoting mechanisms for Windows do not align with those used by Cygwin/Linux/Unix, so things are already problematic. Passing in a DOS path to a Cygwin shell and expecting the output to be properly quoted for a Windows version of 'make' is just asking for trouble. So I'd recommend staying on one side of the fence or the other if you want to minimize headaches. That's the expected - and generally reasonable - answer from the Cygwin side, but it's worth noting that GNU make documents this combo as being workable. From the README.W32 file in the source package: Good news! Make now has native support for Cygwin sh. To enable, define the HAVE_CYGWIN_SHELL in config.h and rebuild make from scratch. This version of make tested with B20.1 of Cygwin. Do not define BATCH_MODE_ONLY_SHELL if you use HAVE_CYGWIN_SHELL. -dsb -- 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.8 and other versions) problems with globbing when invoked from DOS/Windows with nested quotes
On 3/18/2011 11:47 PM, David Boyce wrote: From the README.W32 file in the source package: Good news! Make now has native support for Cygwin sh. To enable, define the HAVE_CYGWIN_SHELL in config.h and rebuild make from scratch. This version of make tested with B20.1 of Cygwin. Wow. I suspect bit rot, as B20.1 dates back to 1998: http://cygwin.com/ml/cygwin/1998-12/msg00093.html Any path conversion that this specially-configured make might do, in order to turn its native DOS-ish paths into something CYGWIN_SHELL might understand, is probably (a) a crude heuristic that no longer applies, (b) uses now-deprecated functions, or (c) relies on explicitly calling system(cygpath ) on every PATH, every time a shell command is invoked (yikes). -- Chuck -- 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
Updated base-files-4.0-6
Version 4.0-6 of base-files has been uploaded. Base-files is a set of system configuration and setup files. Change Log -- 4.0-6 * Re-corrected PRINTER setting. * Dropped non-POSIX tests in /etc/profile - Eric Blake * Dropped user's homedir ownership test. *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO *** If you want to unsubscribe from the cygwin-announce mailing list, look at the List-Unsubscribe: tag in the email header of this message. Send email to the address specified there. It will be in the format: cygwin-announce-unsubscribe-you=yourdomain@cygwin.com If you need more information on unsubscribing, start reading here: http://sourceware.org/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. -- Huella de clave primaria: 0FDA C36F F110 54F4 D42B D0EB 617D 396C 448B 31EB signature.asc Description: Digital signature
