Re: CFA: pseudo-reloc v2
[ redirected from cygwin-developers. ]
On 04/10/2009 05:11, Charles Wilson wrote:
[ thread seriously necro'd! ]
Dave Korn wrote:
Charles Wilson wrote:
120 void
121 _pei386_runtime_relocator ()
122 {
123 static int was_init = 0;
124 if (was_init)
125 return;
126 ++was_init;
127 do_pseudo_reloc
(__RUNTIME_PSEUDO_RELOC_LIST__,__RUNTIME_PSEUDO_RELOC_LIST_END__,_image_base__);
128 }
Maybe that static should be NO_COPY? If everything gets remapped in the
forkee, do the relocs need rerunning? (I'm not sure about the behaviour of
NtCreateProcess w.r.t modified .text section pages.)
Good guess! With the following patch, all of these fork tests perform
as expected.
Aha, not so good as all that after all! We need to re-apply relocs in the
forkee - but only if they *don't* point to regions covered by the .data/.bss
section copying at startup. Argh!
One oddity; it turns out that __INSIDE_CYGWIN__ is not
defined inside pseudo-reloc.c, so I used __CYGWIN__ as a guard.
Dunno if we ever went into that, but it's right; pseudo-reloc.o is part of
the CRT in winsup/cygwin/lib/, and is linked statically into every exe and
(user) dll, but is not part of the cygwin1 dll. Hence not inside Cygwin.
So, the attached is my proposed fix. It resolves the problem reported on
the main list the other day(*) and the supplied testcases all work once it's
applied. There are two things that people might want to change: the minor one
is that I let a couple of the lines get a bit long, but no longer than we
already have in the definition of NO_COPY at the top of the file, so I didn't
wrap them for the sake of one trailing word. The slightly bigger one is that,
if I remember, the reason for having non-#if-CYGWIN code in the file at all is
to make any potential future merges from upstream MinGW sources theoretically
easier, but now that I've had to diverge the internal interfaces anyway, is
there any reason not to just delete the whole lot?
winsup/cygwin/ChangeLog:
lib/pseudo-reloc.c (memskip_t): New struct and typedef.
(__write_memory): Accept an optional memskip_t argument and avoid
writing to any memory ranges mentioned in the linked list.
(do_pseudo_reloc): Accept an optional memskip_t argument and pass
it through in all calls to __write_memory.
(_pei386_runtime_relocator): When reapplying relocs in a forked
child process, avoid doubly-relocating the .data and .bss sections
that were copied from the parent.
cheers,
DaveK
--
(*) - http://cygwin.com/ml/cygwin/2010-04/msg00957.html
Index: winsup/cygwin/lib/pseudo-reloc.c
===
RCS file: /cvs/src/src/winsup/cygwin/lib/pseudo-reloc.c,v
retrieving revision 1.4
diff -p -u -r1.4 pseudo-reloc.c
--- winsup/cygwin/lib/pseudo-reloc.c 26 Oct 2009 14:50:09 - 1.4
+++ winsup/cygwin/lib/pseudo-reloc.c 5 May 2010 16:04:46 -
@@ -78,6 +78,20 @@ typedef struct {
DWORD version;
} runtime_pseudo_reloc_v2;
+/* This trivial struct is passed right down through do_pseudo_reloc
+ to __write_memory where it is used to avoid re-relocating those
+ memory areas that we know will have been pre-relocated by copying
+ from the parent of a forked child process. Since there will only
+ ever be two ranges it's not worth worrying hugely about making it
+ efficient so a simple singly-linked list will do; if we ever start
+ encountering user applications with more than a few hundred or so
+ pseudo-relocs, there might come a time to rethink this. */
+typedef struct memskip {
+ DWORD start;
+ DWORD end;
+ const struct memskip *next;
+} memskip_t;
+
static void ATTRIBUTE_NORETURN
__report_error (const char *msg, ...)
{
@@ -169,7 +183,7 @@ __report_error (const char *msg, ...)
* is folded into the (writable) .data when --enable-auto-import.
*/
static void
-__write_memory (void *addr, const void *src, size_t len)
+__write_memory (void *addr, const void *src, size_t len, const memskip_t *skipranges)
{
MEMORY_BASIC_INFORMATION b;
DWORD oldprot;
@@ -177,6 +191,13 @@ __write_memory (void *addr, const void *
if (!len)
return;
+ while (skipranges)
+{
+ if ((skipranges-start = (DWORD)addr) (skipranges-end (DWORD)addr))
+ return;
+ skipranges = skipranges-next;
+}
+
if (!VirtualQuery (addr, b, sizeof(b)))
{
__report_error ( VirtualQuery failed for %d bytes at address %p,
@@ -198,7 +219,7 @@ __write_memory (void *addr, const void *
#define RP_VERSION_V2 1
static void
-do_pseudo_reloc (void * start, void * end, void * base)
+do_pseudo_reloc (void * start, void * end, void * base, const memskip_t *skipranges)
{
ptrdiff_t addr_imp, reldata;
ptrdiff_t reloc_target = (ptrdiff_t) ((char *)end - (char*)start);
@@ -259,7 +280,7 @@ do_pseudo_reloc (void * start, void * en
DWORD newval;
reloc_target = (ptrdiff_t) base + o-target;
Re: CFA: pseudo-reloc v2
On Wed, May 05, 2010 at 05:54:29PM +0100, Dave Korn wrote:
[ redirected from cygwin-developers. ]
On 04/10/2009 05:11, Charles Wilson wrote:
[ thread seriously necro'd! ]
Dave Korn wrote:
Charles Wilson wrote:
120 void
121 _pei386_runtime_relocator ()
122 {
123 static int was_init = 0;
124 if (was_init)
125 return;
126 ++was_init;
127 do_pseudo_reloc
(__RUNTIME_PSEUDO_RELOC_LIST__,__RUNTIME_PSEUDO_RELOC_LIST_END__,_image_base__);
128 }
Maybe that static should be NO_COPY? If everything gets remapped in the
forkee, do the relocs need rerunning? (I'm not sure about the behaviour of
NtCreateProcess w.r.t modified .text section pages.)
Good guess! With the following patch, all of these fork tests perform
as expected.
Aha, not so good as all that after all! We need to re-apply relocs in the
forkee - but only if they *don't* point to regions covered by the .data/.bss
section copying at startup. Argh!
One oddity; it turns out that __INSIDE_CYGWIN__ is not
defined inside pseudo-reloc.c, so I used __CYGWIN__ as a guard.
Dunno if we ever went into that, but it's right; pseudo-reloc.o is part of
the CRT in winsup/cygwin/lib/, and is linked statically into every exe and
(user) dll, but is not part of the cygwin1 dll. Hence not inside Cygwin.
So, the attached is my proposed fix. It resolves the problem reported on
the main list the other day(*) and the supplied testcases all work once it's
applied. There are two things that people might want to change: the minor one
is that I let a couple of the lines get a bit long, but no longer than we
already have in the definition of NO_COPY at the top of the file, so I didn't
wrap them for the sake of one trailing word. The slightly bigger one is that,
if I remember, the reason for having non-#if-CYGWIN code in the file at all is
to make any potential future merges from upstream MinGW sources theoretically
easier, but now that I've had to diverge the internal interfaces anyway, is
there any reason not to just delete the whole lot?
winsup/cygwin/ChangeLog:
lib/pseudo-reloc.c (memskip_t): New struct and typedef.
(__write_memory): Accept an optional memskip_t argument and avoid
writing to any memory ranges mentioned in the linked list.
(do_pseudo_reloc): Accept an optional memskip_t argument and pass
it through in all calls to __write_memory.
(_pei386_runtime_relocator): When reapplying relocs in a forked
child process, avoid doubly-relocating the .data and .bss sections
that were copied from the parent.
cheers,
DaveK
--
(*) - http://cygwin.com/ml/cygwin/2010-04/msg00957.html
Index: winsup/cygwin/lib/pseudo-reloc.c
===
RCS file: /cvs/src/src/winsup/cygwin/lib/pseudo-reloc.c,v
retrieving revision 1.4
diff -p -u -r1.4 pseudo-reloc.c
--- winsup/cygwin/lib/pseudo-reloc.c 26 Oct 2009 14:50:09 - 1.4
+++ winsup/cygwin/lib/pseudo-reloc.c 5 May 2010 16:04:46 -
@@ -78,6 +78,20 @@ typedef struct {
DWORD version;
} runtime_pseudo_reloc_v2;
+/* This trivial struct is passed right down through do_pseudo_reloc
+ to __write_memory where it is used to avoid re-relocating those
+ memory areas that we know will have been pre-relocated by copying
+ from the parent of a forked child process. Since there will only
+ ever be two ranges it's not worth worrying hugely about making it
+ efficient so a simple singly-linked list will do; if we ever start
+ encountering user applications with more than a few hundred or so
+ pseudo-relocs, there might come a time to rethink this. */
+typedef struct memskip {
+ DWORD start;
+ DWORD end;
+ const struct memskip *next;
+} memskip_t;
+
static void ATTRIBUTE_NORETURN
__report_error (const char *msg, ...)
{
@@ -169,7 +183,7 @@ __report_error (const char *msg, ...)
* is folded into the (writable) .data when --enable-auto-import.
*/
static void
-__write_memory (void *addr, const void *src, size_t len)
+__write_memory (void *addr, const void *src, size_t len, const memskip_t
*skipranges)
{
MEMORY_BASIC_INFORMATION b;
DWORD oldprot;
@@ -177,6 +191,13 @@ __write_memory (void *addr, const void *
if (!len)
return;
+ while (skipranges)
+{
+ if ((skipranges-start = (DWORD)addr) (skipranges-end
(DWORD)addr))
+ return;
+ skipranges = skipranges-next;
+}
+
if (!VirtualQuery (addr, b, sizeof(b)))
{
__report_error ( VirtualQuery failed for %d bytes at address %p,
@@ -198,7 +219,7 @@ __write_memory (void *addr, const void *
#define RP_VERSION_V2 1
static void
-do_pseudo_reloc (void * start, void * end, void * base)
+do_pseudo_reloc (void * start, void * end, void * base, const memskip_t
*skipranges)
{
ptrdiff_t addr_imp, reldata;
ptrdiff_t reloc_target = (ptrdiff_t) ((char *)end - (char*)start);
@@ -259,7 +280,7 @@ do_pseudo_reloc (void * start, void * en
Re: CFA: pseudo-reloc v2
On 05/05/2010 18:56, Christopher Faylor wrote: I like the idea but I have a few problems with this, some stylistic and some implementation. Stylistic: Those all make sense to me, but I won't rework it yet until we've seen your PoC/discussed further. Implementation: I don't like keeping a list of places we know we need to ignore separate from the Cygwin DLL. That means that if there is something new added besides data/bss this function becomes obsolete. I think this argues for most of this functionality being moved to the Cygwin DLL itself so that an application gets improvements for free. I should have suggested that when this function first made its way into the libcygwin.a (or maybe I did and someone will enlighten me about why that won't work). I'll see I can come up with a proof-of-concept of what I'm talking about soon. Btw, don't we have to worry about data/bss for DLLs too? Is that handled by this change or is that not an issue? We do have to worry and it is handled. This code gets linked statically into each DLL and EXE, each instance referring just to its own pseudo-reloc tables. The Cygwin DLL copies all the data and bss for both DLLs and EXEs (at process attach time), then they all run their own pseudo-relocs (at first thread attach time). This only works /because/ the module is linked into each executable image (i.e., DLL or EXE, and henceforth 'EI') separately. While we could move the core code into the Cygwin DLL, we'd still have to have a statically linked object in each EI to capture the module's definitions of __RUNTIME_PSEUDO_RELOC_LIST__ and __RUNTIME_PSEUDO_RELOC_LIST_END__, and so it's also a valid place to capture the local module's __data/bss_start/end_ definitions (as indeed is already done in _cygwin_crt0_common where it sets up the per_process userdata structure). So we could move the core __write_memory and do_pseudo_relocs routines into the DLL, and adjust the code in _cygwin_crt0_common to pass the per_process struct to _pei386_runtime_relocator which could pass it and the reloc list start/end pointers through to the code in the DLL, and it could then be code in the DLL that knows which memory ranges it copied and should avoid re-relocating. Is that the kind of structure you were thinking of? The problem I saw with any kind of approach based on actually knowing which ranges were actually copied (as opposed to simply inferring that it was the data and bss sections between their start and end labels) is that that all takes place in the parent rather than the child, so how to communicate it to the child where the relocating is taking place would be pretty tricky, I thought. cheers, DaveK
Re: CFA: pseudo-reloc v2
On Wed, May 05, 2010 at 07:58:20PM +0100, Dave Korn wrote: On 05/05/2010 18:56, Christopher Faylor wrote: I like the idea but I have a few problems with this, some stylistic and some implementation. Stylistic: Those all make sense to me, but I won't rework it yet until we've seen your PoC/discussed further. Implementation: I don't like keeping a list of places we know we need to ignore separate from the Cygwin DLL. That means that if there is something new added besides data/bss this function becomes obsolete. I think this argues for most of this functionality being moved to the Cygwin DLL itself so that an application gets improvements for free. I should have suggested that when this function first made its way into the libcygwin.a (or maybe I did and someone will enlighten me about why that won't work). I'll see I can come up with a proof-of-concept of what I'm talking about soon. Btw, don't we have to worry about data/bss for DLLs too? Is that handled by this change or is that not an issue? We do have to worry and it is handled. This code gets linked statically into each DLL and EXE, each instance referring just to its own pseudo-reloc tables. The Cygwin DLL copies all the data and bss for both DLLs and EXEs (at process attach time), then they all run their own pseudo-relocs (at first thread attach time). Yeah, I realized that two seconds after sending the message. However, is this particular problem really an issue for DLLs? DLLs should get their data/bss updated after _pei386_runtime_relocator() is called. So it seems like you'd get the same thing being written twice. It's not optimal but it shouldn't be fatal. The program's data/bss is different since that gets copied during DLL initialization and before _pei386_runtime_relocator() is (was) called. So I could see how it could be screwed up. So we could move the core __write_memory and do_pseudo_relocs routines into the DLL, and adjust the code in _cygwin_crt0_common to pass the per_process struct to _pei386_runtime_relocator which could pass it and the reloc list start/end pointers through to the code in the DLL, and it could then be code in the DLL that knows which memory ranges it copied and should avoid re-relocating. That's basically it and I have it more-or-less coded but I haven't finished thinking about DLLs. Maybe that's more complication than is warranted. I have to do more research there. We could, and I think should, put most of the code in pseudo_reloc.c in cygwin1.dll, though, rather than duplicate it in every source file. Is that the kind of structure you were thinking of? The problem I saw with any kind of approach based on actually knowing which ranges were actually copied (as opposed to simply inferring that it was the data and bss sections between their start and end labels) is that that all takes place in the parent rather than the child, so how to communicate it to the child where the relocating is taking place would be pretty tricky, I thought. This information is all recorded for fork() so it should be doable. It is more complicated to do it outside of the program but, like I said, it allows us to fix problems by a new release of the DLL rather than telling people You must relink your program. cgf
Re: CFA: pseudo-reloc v2
On 05/05/2010 20:13, Christopher Faylor wrote: Yeah, I realized that two seconds after sending the message. However, is this particular problem really an issue for DLLs? DLLs should get their data/bss updated after _pei386_runtime_relocator() is called. So it seems like you'd get the same thing being written twice. It's not optimal but it shouldn't be fatal. The program's data/bss is different since that gets copied during DLL initialization and before _pei386_runtime_relocator() is (was) called. So I could see how it could be screwed up. Ah, right; I wasn't looking at how much later the dll sections got copied, I just figured the safest and consistent solution was just to treat everything the same. That's basically it and I have it more-or-less coded but I haven't finished thinking about DLLs. Maybe that's more complication than is warranted. I have to do more research there. We could, and I think should, put most of the code in pseudo_reloc.c in cygwin1.dll, though, rather than duplicate it in every source file. Yeh, the only thing we need in the source file is to capture the module's idea of its section start/end pointers, as we already do in the per_process; we could consider passing pointers to the pseudo-relocs in that as well, but horrible backward-compatibility problems could arise. It would make sense to inline the remnants of _pei386_runtime_relocator into _cygwin_crt0_common and do away with the pseudo-reloc.c file altogether. This information is all recorded for fork() so it should be doable. It is more complicated to do it outside of the program but, like I said, it allows us to fix problems by a new release of the DLL rather than telling people You must relink your program. Yeh. Unfortunately it's too late to help with this time, but it would help any future problem (so long as it didn't require us to capture additional data in the lib/ part of the executable but could be fixed with what we were already passing to the Cygwin DLL). cheers, DaveK
Re: CFA: pseudo-reloc v2
On Wed, May 05, 2010 at 08:48:28PM +0100, Dave Korn wrote: On 05/05/2010 20:13, Christopher Faylor wrote: Yeah, I realized that two seconds after sending the message. However, is this particular problem really an issue for DLLs? DLLs should get their data/bss updated after _pei386_runtime_relocator() is called. So it seems like you'd get the same thing being written twice. It's not optimal but it shouldn't be fatal. The program's data/bss is different since that gets copied during DLL initialization and before _pei386_runtime_relocator() is (was) called. So I could see how it could be screwed up. Ah, right; I wasn't looking at how much later the dll sections got copied, I just figured the safest and consistent solution was just to treat everything the same. That's basically it and I have it more-or-less coded but I haven't finished thinking about DLLs. Maybe that's more complication than is warranted. I have to do more research there. We could, and I think should, put most of the code in pseudo_reloc.c in cygwin1.dll, though, rather than duplicate it in every source file. Yeh, the only thing we need in the source file is to capture the module's idea of its section start/end pointers, as we already do in the per_process; we could consider passing pointers to the pseudo-relocs in that as well, but horrible backward-compatibility problems could arise. It would make sense to inline the remnants of _pei386_runtime_relocator into _cygwin_crt0_common and do away with the pseudo-reloc.c file altogether. This information is all recorded for fork() so it should be doable. It is more complicated to do it outside of the program but, like I said, it allows us to fix problems by a new release of the DLL rather than telling people You must relink your program. Yeh. Unfortunately it's too late to help with this time, but it would help any future problem (so long as it didn't require us to capture additional data in the lib/ part of the executable but could be fixed with what we were already passing to the Cygwin DLL). I have something written now. I'll dig through the cygwin archives to see if I can find the original message which started this but are there other test cases that I could use to verify that I caught all of the code paths in the DLL? Chuck? Do you have anything I could use to test what I did? What I did: 1) Move pseudo-reloc.c out of lib and into the dll (making it a c++ file in the process). 2) Record the three values needed by _pei386_runtime_relocator in the per_process structure. 3) Modify _pei386_runtime_relocator() to take a per_process * argument and to check that the api of the per_process structure supports the additional three values. 4) For fork call _pei386_runtime_relocator() before the copy of the program's data/bss in child_info_fork::handle_fork(). 5) For non-fork, call _pei386_runtime_relocator() in dll_crt0_1(). 6) For dll's, call _pei386_runtime_relocator() in dll_list::alloc(). I haven't added any optimizations to make this implementation avoid copying the data/bss but that is doable using Dave's technique. It just isn't needed now since the fork data copy should always trump _pei386_runtime_relocator(). cgf
Re: CFA: pseudo-reloc v2
On 05/05/2010 21:30, Christopher Faylor wrote: I have something written now. I'll dig through the cygwin archives to see if I can find the original message which started this but are there other test cases that I could use to verify that I caught all of the code paths in the DLL? http://cygwin.com/ml/cygwin/2010-04/msg00957.html comes with a couple of testcases attached, although you can only be sure they've worked by running them and seeing that no .stackdump file was generated in your $CWD. Chuck? Do you have anything I could use to test what I did? There were some fork-related testcases in the original thread, but I didn't refer back to them when I was revising this, so they're probably worth verifying: http://www.cygwin.com/ml/cygwin-developers/2009-10/msg00052.html What I did: 1) Move pseudo-reloc.c out of lib and into the dll (making it a c++ file in the process). 2) Record the three values needed by _pei386_runtime_relocator in the per_process structure. That bit worries me - even adding a single pointer in a place where there would never have been a field before caused us enough trouble! But, it's probably the right thing to do; it's the defined mechanism for conveying image-specific information from the module to the cygwin dll. 3) Modify _pei386_runtime_relocator() to take a per_process * argument and to check that the api of the per_process structure supports the additional three values. Changing per_process was not as easy as I had hoped when I did it! 4) For fork call _pei386_runtime_relocator() before the copy of the program's data/bss in child_info_fork::handle_fork(). 5) For non-fork, call _pei386_runtime_relocator() in dll_crt0_1(). 6) For dll's, call _pei386_runtime_relocator() in dll_list::alloc(). Re-ordering startup is the thing I didn't want to approach. The separation, serialisation and ordering between process attach and first thread attach is probably as reliable as anything we could hope for though. I haven't added any optimizations to make this implementation avoid copying the data/bss but that is doable using Dave's technique. It just isn't needed now since the fork data copy should always trump _pei386_runtime_relocator(). Well, as long as it works it must make sense; it's just a matter of which we figure is more long-term reliable and maintainable: your approach depends on inferences about which things happen in which order during startup, mine depends on inferences about which sections of the EI get copied from the parent during a fork. So, this post is a commentary, rather than an objection. cheers, DaveK
Re: CFA: pseudo-reloc v2
On 5/5/2010 3:13 PM, Christopher Faylor wrote: That's basically it and I have it more-or-less coded but I haven't finished thinking about DLLs. Maybe that's more complication than is warranted. I have to do more research there. We could, and I think should, put most of the code in pseudo_reloc.c in cygwin1.dll, though, rather than duplicate it in every source file. I disagree with this statement. I spent a lot of effort trying to synchronize our version of pseudo_reloc.c with the mingw and mingw64 versions -- specifically so that we could leverage Kai's v2 efforts. If we -- meaning cygwin -- move most of the guts into the cygwin DLL, then ... we either (1) fork our version from the mingw[32|64] version permanently, and lose the possibility of easy code sharing between the three projects, or (2) this portion of the code lives in both places (pseudo_reloc.c and some-other-cygwin-dll-source-file), but is #ifdef'ed in pseudo_reloc.c when compiled on cygwin, because there's this other identical copy over in some-other-cygwin-dll-source-file. Yuck. (I don't mind losing the effort I put in, because whatever happens we now have v2 support. But...why make it harder if somebody in mingw-land invents v3? Or make it harder on them, if WE do?) -- Chuck
Re: CFA: pseudo-reloc v2
On 5/5/2010 4:30 PM, Christopher Faylor wrote: Chuck? Do you have anything I could use to test what I did? Yes, most recent version attached. (embedded READMEs describe expected output). -- Chuck pseudo-reloc-tests-v3.tar.bz2 Description: Binary data
Re: Cygwin make target is never determined up to date
On 05/05/2010 06:04, Jeremy Bopp wrote: MichaelKim wrote: Prerequisite `../bin/build/chrome' is newer than target `../bin/build/chrome/alt.jar'. Must remake target `../bin/build/chrome/alt.jar'. So let me get this straight. The JAR file you're trying to build is within a directory which is listed as a prerequisite of that JAR file? Unless I'm completely off base, it would seem to be that this is expected behavior then. If you mess with the contents of a directory, such as by adding a file to it, the last modified timestamp of the directory is going to be updated. I would expect that to happen after the file is added to the directory which could very well be *after* the last modified timestamp of the file is set. Thus the directory will appear newer than the file. Yep: $(chrome_jar_file): $(jar_sources) $(jar_target_dir) The idea is supposed to be to make the jar file depend on the output dir, so that if the output dir doesn't exist, the $(jar_target_dir) rule will get invoked to mkdir it; but it doesn't anticipate that the timestamp of an existing dir changes everytime you touch the files within it. For a discussion of better ways to create an output dir in make, see: http://www.cmcrossroads.com/cm-articles/columns/ask-mr-make The particular article you're looking for is #26, Making directories in GNU Make: http://www.cmcrossroads.com/ask-mr-make/6936-making-directories-in-gnu-make I don't know why this would be working on the old XP machine, unless it's running an older version of cygwin that had a bug or didn't implement updating directory timestamps. cheers, DaveK -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: V1.7 and endless loops triggerd by junction points
On May 5 06:21, Andy Koppe wrote: Matthias Meyer wrote: 2) In the opposite to V1.5.25 ls -alh /cygdrive/c/users/ shows the Vista Junction points like linux soft links. That is nice :-) But the Windows Program attrib /S /D will follow this symbolic links and therefore it comes into an endless loop. e.g.: C:\Documents and Settings\All Users\Application Data\Application Data\.. This behaviour will take place too if I run it with cmd /c attrib Both above means by running it within a bash shell. If I run attrib from a cmd box it work correct. I don't see how that could possibly be the fault of Cygwin or bash. It's a Windows program dealing with a Windows filesystem feature. Sure you're actually running the same 'attrib' in both environments? It could be a result of running attrib once in a normal and once in an elevated shell. Otherwise, the only difference as far as I can see is the fact that the user token attrib inherited from the Cygwin shell has more user rights enabled. Namely the backup and restore rights, which allows to access files and directories which are not available by default. However, this only works in an elevated shell, too. However, it's not Cygwin's fault that attrib is not up to speed with circular symlinks on an OS which allows them. 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: [PMX:#] Re: Error opening terminal: cygwin. when attempting to start lynx
Greetings, Ken Brown! Surprized... It show nothing, although the setup.exe states that lynx 2.8.5-4 is installed. And only lynx that could be installed is a Cygwin one, i'm not using any other unix tools packages. I think it's the time to reinstall it all... yet again... I just did it when 1.7 came out, but seems it wasn't enough. Since you're having problems, wouldn't it make sense to do a standard installation in C:/cygwin? It is installed in C:\Programs\Cygwin, which in turn located on the different partition. -- WBR, Andrey Repin (anrdae...@freemail.ru) 05.05.2010, 12:28 Sorry for my terrible english... -- 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
SSH + Cygwin + Msiexec
Hey, I am trying to run a ssh command to install something silently. However, when it tries to install it says File Cannot Be Found. However, I believe its more of a 'No permission to do this', as the file exists. I can run the Msiexec command manually (remote desktop + CMD) and it will install. I will just add that ssh will also uninstall the product, just not install it. I will add that the location is networked but I believe this is not the problem as the problem persists even when I copy the program to a local location. I think this is the right place to post! Found it a little difficult navigating! TIA, Lokolo -- View this message in context: http://old.nabble.com/SSH-%2B-Cygwin-%2B-Msiexec-tp28458224p28458224.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
reading /proc/registry/ causes Segmentation fault.
Hi all,
The script below worked without problems last month. But now I get
Segmentation fault (core dumped).
If I use the lines which begins with
#this works fine
instead of the one with GetWordExe it works fine.
I tested it with the latest update
Sorry that it is not shorter but it is the shortes form to get it work.
Have a nice day
Norbert
###
#! /usr/bin/perl -w
use IO::File;
my $RegistryOffice =
'/proc/registry/HKEY_LOCAL_MACHINE/SOFTWARE/Microsoft/Office/';
my ($Reg_Word_Exe,$Reg_Office_Ver,$Reg_Word_Path);
sub GetOfficeVer
{
if($Reg_Office_Ver)
{
return($Reg_Office_Ver);
}
opendir( my $ww, $RegistryOffice);
my @a = grep{m/\d+\.\d+/}readdir($ww);
closedir($ww);
foreach my $tr(@a)
{
my $w = $RegistryOffice.$tr.'/Word/InstallRoot/Path';
if( -f $w)
{
$Reg_Office_Ver = $tr;
my $ww = IO::File-new( $w);
$Reg_Word_Path = $ww;
$ww-close();
$Reg_Word_Path =~ s/\r*\n//;
$Reg_Word_Path =~ s/\x0//;
last;
}
}
return($Reg_Office_Ver);
}
sub GetWordExe
{
if($Reg_Word_Exe)
{
return($Reg_Word_Exe);
}
if(!$Reg_Office_Ver)
{
GetOfficeVer();
}
opendir(my $ww,$Reg_Word_Path);
my @wa = grep{ m/^.*word\.exe/i} readdir($ww);
closedir($ww);
if(!...@wa)
{
return(undef);
}
$Reg_Word_Exe = $Reg_Word_Path.$wa[0];
return( $Reg_Word_Exe);
}
### here the script start working
my $myDir = /cygdrive/g/somedir;
my $myDoc = ' aname.doc /mamacro';
my $WordExe = Cygwin::win_to_posix_path(GetWordExe(),1);
#this works fine my $xx = 'C:\Programme\Microsoft Office\Office12\WINWORD.EXE';
#this works fine my $WordExe= Cygwin::win_to_posix_path($xx,1);
$WordExe=~s/ /\\ /g;
$WordExe.=$myDoc ;
system('cd '.$somedir.;\n.$WordExe);
sleep(3);
while(1)
{
print *;
my $ls = IO::File-new(ps -Wa |);
my @l = grep{ s/\n// m/WINWORD\.EXE/ }$ls;
if(! @l)
{
last;
}
$ls-close();
}
exit;
##
--
Dipl. Phys.
Norbert Zacharias
Wind Measurements Power Curve Measurements
DEWI GmbH
Ebertstrasse 96
26382 Wilhelmshaven
Germany
Tel.: +49 4421 4808 876
Fax:+49 4421 4808 843
Email: n.zachar...@dewi.de
Home: http://http://www.dewi.de
DEWI GmbH - Deutsches Windenergie-Institut, Wilhelmshaven
Commercial Register No.: Amtsgericht Oldenburg, HRB 130241
Managing Director: Jens Peter Molly
Chairman of the supervisory board: Ministerialrat Dr. Niels Kämpny
P Please consider the environment before printing this 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: reading /proc/registry/ causes Segmentation fault.
On May 5 10:57, DEWI - N. Zacharias wrote: Hi all, The script below worked without problems last month. But now I get Segmentation fault (core dumped). If I use the lines which begins with #this works fine instead of the one with GetWordExe it works fine. I tested it with the latest update Sorry that it is not shorter but it is the shortes form to get it work. Did you try with the Cygwin DLL from a recent developer snapshot from http://cygwin.com/snapshots/ ? There was a buffer overflow in wide character string allocation which broke /proc/registry access. It has been fixed one day after releasing Cygwin 1.7.5. 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: cpu usage capped?
On 5/5/10, Mark Geisert m...@maxrnd.com wrote: I have some code that takes advantage of 8 cores on my machine using OpenMP. Under plain ol windows, this code causes all the CPUs to max on some computers you can get things like virus protection software to do thta. LOL. My point of course, inline with comments below, is that CPU usage doesn't equate to getting anything useful done. This could be time spent doing thread-threed communications, who knows. out at 99%. But when recompiled for cygwin, each core jumps to about 85%. The rest is not being used by other processes. Could someone explain why this is the case? Usually this is VM or IO or maybe lock starvation. In all seriousness, this could occur if the compiled code is significantly better although last time I looked years ago the MS compilers were supposed to be better, and INTC compiler the best but it depends on options etc. You need to do a wall clock performance test here. Also these things can be quite sensitive to specific conditions, your mileage may vary. Obviously, Cygwin gets the job done with less CPU utilization, handing you back 15% of your machine. And you're complaining? ..mark P.S. A more helpful response can likely only occur if you spell out more specifically which varieties of apples and oranges you're comparing. For starters: plain ol windows, is that MSVC or MinGW? Is disk I/O involved? What OS and environment (e.g., VM? TS?). I'm pretty sure I'm only scratching the surface here. We don't know what your code does other than use OpenMP. -- 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 -- marchy...@gmail.com note new address 2009-12-16: Mike Marchywka 1975 Village Round Marietta GA 30064 415-264-8477 (w)- use this 404-788-1216 (C)- leave message 989-348-4796 (P)- emergency only marchy...@hotmail.com Note: If I am asking for free stuff, I normally use for hobby/non-profit information but may use in investment forums, public and private. Please indicate any concerns if applicable. Note: hotmail is censoring incoming mail using random criteria beyond my control and often hangs my browser but all my subscriptions are here..., try also marchy...@yahoo.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: Error opening terminal: cygwin. when attempting to start lynx
On 5/5/2010 4:28 AM, Andrey Repin wrote: Greetings, Ken Brown! Surprized... It show nothing, although the setup.exe states that lynx 2.8.5-4 is installed. And only lynx that could be installed is a Cygwin one, i'm not using any other unix tools packages. I think it's the time to reinstall it all... yet again... I just did it when 1.7 came out, but seems it wasn't enough. Since you're having problems, wouldn't it make sense to do a standard installation in C:/cygwin? It is installed in C:\Programs\Cygwin, which in turn located on the different partition. I'm trying to guess what you did, based on your cygcheck output and the path you showed in an earlier post. It looks like you installed cygwin in C:\Programs\Cygwin, then copied C:\Programs\Cygwin\bin into C:\bin, and then put the latter at the beginning of your path. Is that correct? If so, I'm not surprised that cygwin programs aren't working as you expect and that cygcheck can't find your installed packages. Ken P.S. Please reply only to the list, not to both me and the list. -- 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
AW: [bulk] - Re: reading /proc/registry/ causes Segmentation fault.
Hi Corinna, Von: Corinna Vinschen [mailto:corinna-cyg...@cygwin.com] Gesendet: Mittwoch, 5. Mai 2010 11:39 An: cygwin@cygwin.com Betreff: [bulk] - Re: reading /proc/registry/ causes Segmentation fault. On May 5 10:57, DEWI - N. Zacharias wrote: Hi all, The script below worked without problems last month. But now I get Segmentation fault (core dumped). If I use the lines which begins with #this works fine instead of the one with GetWordExe it works fine. I tested it with the latest update Sorry that it is not shorter but it is the shortes form to get it work. Did you try with the Cygwin DLL from a recent developer snapshot from http://cygwin.com/snapshots/ ? Because I run an update this morning my assumption was that I had the newest one. Have a nice day Norbert There was a buffer overflow in wide character string allocation which broke /proc/registry access. It has been fixed one day after releasing Cygwin 1.7.5. 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 -- Dipl. Phys. Norbert Zacharias Wind Measurements Power Curve Measurements DEWI GmbH Ebertstrasse 96 26382 Wilhelmshaven Germany Tel.: +49 4421 4808 876 Fax:+49 4421 4808 843 Email: n.zachar...@dewi.de Home: http://http://www.dewi.de DEWI GmbH - Deutsches Windenergie-Institut, Wilhelmshaven Commercial Register No.: Amtsgericht Oldenburg, HRB 130241 Managing Director: Jens Peter Molly Chairman of the supervisory board: Ministerialrat Dr. Niels Kämpny P Please consider the environment before printing this 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: cron visual output looks funny
On 02.05.2010 17:52, Johannes Müller wrote: Johannes Müller wrote: Hi, I installed and use cron on windows xp using cygwin. It works fine for non-GUI applications, but for instance notepad does not seem to start at all. And a popup-window-script I wrote in python does appear and react to userinput, but is not displayed correctly, as I can not see a button on the window (although it fires the associated action, when being pressed). I configured the cron service to be able to interact with the desktop and tried to find an answer to my question on the net/FAQ/Mailinglist but could not find more than the hint to somehow configure the environment for cron. I set DISPLAY=:0 as it is suggested in the ubuntu-wiki to start GUI-apps from cron. I also used a system-owned-shell to install cron with cron-config, but this did not seem to work out: The group membership of your cron table file should be ADMINISTRATORS. Here is your cron table file listing: -rw-r- 1 SYSTEM Administratoren 332 2010-05-02 14:05 /var/cron/tabs/SYSTEM This rule does not apply if the daemon runs with nontsec. You can change the group membership setting with: chgrp 0 /var/cron/tabs/SYSTEM Please change your cron table's group membership. So my question is, how do I configure cygwin and cron, so that cron can start and display GUI-applications correctly? Sorry if I understood something wrong and annoy you, but I am new to cygwin and cron and I really tried to solve the problem by myself for quite some time. I appreciate your help, Johannes Müller -- 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 I included the cronbug.txt if this is of any help. Johannes Müller Hi again, Sorry for the flooding, I thought Attachments would be viewed as Links to the file rather than plain text. I could still not figure out the problem. I tried to work around the problem by starting the GUI-program with nohub, but nothing changes. I hope you can give me a hint, since I am pretty clueless at the moment. Johannes -- 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: [bulk] - Re: reading /proc/registry/ causes Segmentation fault.
On May 5 14:02, DEWI - N. Zacharias wrote: Hi Corinna, Von: Corinna Vinschen [mailto:...] http://cygwin.com/acronyms/#PCYMTNQREAIYR Did you try with the Cygwin DLL from a recent developer snapshot from http://cygwin.com/snapshots/ ? Because I run an update this morning my assumption was that I had the newest one. That's a strange assumption. The developer snapshots are not offical releases. And the last official release was 1.7.5-1 from 2010-04-12. Did you try the latest developer snapshot in the meantime? 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: Signal support under Cygwin
On 28/04/2010 4:25 p.m., Nicholas Sherlock wrote: Is this supposed to work? Nobody knows if Cygwin signals work? Could anybody reproduce the crash from my example code at least on their machines? Cheers, Nicholas Sherlock -- 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: Signal support under Cygwin
On Thu, May 06, 2010 at 02:20:54AM +1200, Nicholas Sherlock wrote: On 28/04/2010 4:25 p.m., Nicholas Sherlock wrote: Is this supposed to work? Nobody knows if Cygwin signals work? Could anybody reproduce the crash from my example code at least on their machines? Investigating this is on my todo list. cgf -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
AW: [bulk] - Re: [bulk] - Re: reading /proc/registry/ causes Segmentation fault.
Hi Corinna, Von: Corinna Vinschen Gesendet: Mittwoch, 5. Mai 2010 14:32 An: cygwin@cygwin.com Betreff: [bulk] - Re: [bulk] - Re: reading /proc/registry/ causes Segmentation fault. On May 5 14:02, DEWI - N. Zacharias wrote: Hi Corinna, Von: Corinna Vinschen [mailto:...] http://cygwin.com/acronyms/#PCYMTNQREAIYR Sorry! Forgot to delete the mail address Did you try with the Cygwin DLL from a recent developer snapshot from http://cygwin.com/snapshots/ ? Because I run an update this morning my assumption was that I had the newest one. That's a strange assumption. Ok, I'm a strange person ;-) so sometimes I have strange thoughts. The developer snapshots are not offical releases. And the last official release was 1.7.5-1 from 2010-04-12. Did you try the latest developer snapshot in the meantime? Yepp! I did and now it works ! Thanks for the hint. Schönen Tag noch Norbert 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 -- Dipl. Phys. Norbert Zacharias Wind Measurements Power Curve Measurements DEWI GmbH Ebertstrasse 96 26382 Wilhelmshaven Germany Tel.: +49 4421 4808 876 Fax:+49 4421 4808 843 Email: n.zachar...@dewi.de Home: http://http://www.dewi.de DEWI GmbH - Deutsches Windenergie-Institut, Wilhelmshaven Commercial Register No.: Amtsgericht Oldenburg, HRB 130241 Managing Director: Jens Peter Molly Chairman of the supervisory board: Ministerialrat Dr. Niels Kämpny P Please consider the environment before printing this 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
Using Log4cxx (libapr, libapr-util) full functionality
Hi, I’m working on windows XP with Cygwin, I have download libapr1-devel-1.3.8-1 and libaprutil1-devel-1.3.9-1 for use and compile the logger log4cxx from apache. Basic functions (basic logger, appender and configuration) works pretty well, but when I decide to use the method log4cxx::PropertyConfigurator::configureAndWatch(logger.conf,timeout) instead of the simple configure( ), I give a undefined reference at linkage. This method starts a thread, which periodically watches the conf file to be able to dynamically take change of configuration. My first analyze is: the file apr.h define APR_HAS_THREADS to 0 that why the configureAndWatch method is not present in log4cxx.a I don’t understand why the apr library isn’t compile with APR_HAS_THREADS set to 1? Is there a solution to recompile the apr lib for using more functionality of log4cxx like configureAndWatch and appender ( socketAppender ). Regards, Jean-Hervé Quéau -- 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: Resizing a terminal window
Thomas Wolff t...@towo.net writes: Am 04.05.2010 16:03, schrieb J. David Boyd: ... Locally, I can use the mouse to resize a window, and the $COLUMNS and $LINES variables are automatically filled in. On many remote xterm sessions, they aren't. Does anyone have any idea where to start figuring out what is wrong, and what I can do to correct it? LINES and COLUMNS are legacy mechanisms which may serve as a workaround if the system doesn't otherwise handle screen size changes properly. They should not be needed on modern systems where the tty driver maintains the information. (You may note that mintty has not set them initially but they get set on resize - by whatever means... - while in a cygwin console they are not used at all.) So if you happen to have these variables set on a system which does not maintain them, they don't get changed on resize and confuse your environment. In most cases the best remedy is to just unset them - does that help? -- Thomas Sadly enough, the system I am connecting to, SUSE Linux, does use them, and the checkwinsize shopt BASH function, but, somehow, not correctly -- 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: Using Log4cxx (libapr, libapr-util) full functionality
On 5/5/2010 7:40 AM, jeanherve.qu...@free.fr wrote: Hi, I’m working on windows XP with Cygwin, I have download libapr1-devel-1.3.8-1 and libaprutil1-devel-1.3.9-1 for use and compile the logger log4cxx from apache. Basic functions (basic logger, appender and configuration) works pretty well, but when I decide to use the method log4cxx::PropertyConfigurator::configureAndWatch(logger.conf,timeout) instead of the simple configure( ), I give a undefined reference at linkage. This method starts a thread, which periodically watches the conf file to be able to dynamically take change of configuration. My first analyze is: the file apr.h define APR_HAS_THREADS to 0 that why the configureAndWatch method is not present in log4cxx.a I don’t understand why the apr library isn’t compile with APR_HAS_THREADS set to 1? Is there a solution to recompile the apr lib for using more functionality of log4cxx like configureAndWatch and appender ( socketAppender ). libapr1 has been compiled without thread support for a long time, from before I inherited the package. I tried enabling it the last time I spun a release. It built fine, but some of the tests failed. Most importantly, building subversion against it produced an unusable subversion executable. Apparently, the build process for subversion detects a threaded libapr1 and does some different things, and these completely break subversion on Cygwin. Frankly, I don't have the time or the knowledge to debug the threading in libapr1. You can try to enable it if you want to experiment. As I recall, it requires a pretty simple patch to configure.in, although I don't have it anymore. I'd be happy to take any patches you create to get threading in libapr1 working. -- David Rothenberger daver...@acm.org QOTD: Wouldn't it be wonderful if real life supported control-Z? -- 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: Resizing a terminal window
Andy Koppe andy.ko...@gmail.com writes: J. David Boyd wrote: I don't think it is a Cygwin issue at all. And, I'm certain it is a remote server problem, as it works on many boxes. I was just looking for some help and ideas, and the Cygwin list seemed a good place to start since I use Cygwin. Right. This list is all about the misery of using Cygwin though. I re-discovered the shopt parameter of checkwinsize, which is what controls Bash monitoring the window size from my prior message. Bash also sets LINES and COLUMNS when it receives a SIGWINCH (window change) signal, apparently independent of 'checkwinsize'. Only the foreground process gets that signal though. So without 'checkwinsize', the setting of those variables depends on whether bash was in the foreground when the terminal was resized. Andy It is, as I am clicking the window I want to resize, and using the mouse to drag the bottom right corner to the dimensions that I want. SSHing in to my Mandriva box, it works perfectly. SSHing in to my SUSE Linux box, I have to do an eval `resize`. SSHing in to my Ubuntu 9.10 box, it works perfectly. Something must be broken in SUSE Linux Dave -- 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: Resizing a terminal window
On 5/5/2010 8:28 AM, J. David Boyd wrote: Thomas Wolfft...@towo.net writes: Am 04.05.2010 16:03, schrieb J. David Boyd: ... Locally, I can use the mouse to resize a window, and the $COLUMNS and $LINES variables are automatically filled in. On many remote xterm sessions, they aren't. Does anyone have any idea where to start figuring out what is wrong, and what I can do to correct it? LINES and COLUMNS are legacy mechanisms which may serve as a workaround if the system doesn't otherwise handle screen size changes properly. They should not be needed on modern systems where the tty driver maintains the information. (You may note that mintty has not set them initially but they get set on resize - by whatever means... - while in a cygwin console they are not used at all.) So if you happen to have these variables set on a system which does not maintain them, they don't get changed on resize and confuse your environment. In most cases the best remedy is to just unset them - does that help? -- Thomas Sadly enough, the system I am connecting to, SUSE Linux, does use them, and the checkwinsize shopt BASH function, but, somehow, not correctly Just for curiosity: are you using 'expect' to log to the remote system? If so, you'd need you modify your expect script to handle SIGWINCH properly. Let me know... H. -- 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
rxvt : 1.5 vs. 1.7
Constantly stalling when exiting rxvt in [1.7] (as previously reported; and still don't understand why, or why this list isn't full of Me toos). This never happens in 1.5. I really prefer rxvt over all other shells incl mintty. So I copied rxvt.exe from /bin[1.5] to /bin[1.7] overwriting the version there. What a horrid fix! But it seems to work just fine. Fergus -- 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
cygpath from emacs
I often find myself running a piece of software from within emacs that expects, and spits out, Windows-style paths (C:\...). Handling sending it Windows paths based on the Cygwin ones is fine, I just use a script. Of course, the tool returning Windows paths is a PITA, because it means I can't do M-x next-error :( Is there a solution, a way to capture them and transform them before they end up in the emacs buffer, maybe? I feel I should be able to work this out myself, but my brain refuses to bend around it :( -- Gary Non-kook (allegedly) -- 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: cygpath from emacs
On 05/05/2010 19:24, Gary wrote: I often find myself running a piece of software from within emacs that expects, and spits out, Windows-style paths (C:\...). Handling sending it Windows paths based on the Cygwin ones is fine, I just use a script. Of course, the tool returning Windows paths is a PITA, because it means I can't do M-x next-error :( Is there a solution, a way to capture them and transform them before they end up in the emacs buffer, maybe? I feel I should be able to work this out myself, but my brain refuses to bend around it :( So you have a script that transforms the paths on the command-line and launches the app... why doesn't the script /also/ capture the output and transform it back? cheers, DaveK -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: V1.7 and endless loops triggerd by junction points
Andy Koppe wrote: Matthias Meyer wrote: I've installed cygwin 1.7 in Vista and have two problems, not known prior with cygwin 1.5.25: 1) If I login in a shell (e.g. sh --login -i) I can not use cursor or backspace keys. It seems that the cursor can't go into the left direction. Cursor up will resolve in one line like: $ tail /cygdrive/c/Attrib/attributes$ ls -alh /cygdrive/c/Attrib/attributes instead two different lines like $ tail /cygdrive/c/Attrib/attributes $ ls -alh /cygdrive/c/Attrib/attributes Weird. Messed up tty settings perhaps. How and where are you running that shell? What's the output of 'stty -a'? Also, cygcheck output as requested at http://cygwin.com/problems.html might be helpful. I running this shell by ssh (with private/public key authentication) or by sh --login -i from windows cmd. The same behaviour in both types of shell. As far as I know I've not configured anything for a shell. $ stty -a speed 38400 baud; rows 25; columns 80; line = 0; intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = undef; eol2 = undef; swtch = ^Z; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 0; -parenb -parodd cs8 -hupcl -cstopb cread -clocal -crtscts -ignbrk brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl -ixon -ixoff -iuclc -ixany -imaxbel opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 isig icanon iexten echo echoe echok -echonl -noflsh -tostop echoctl echoke br Matthias -- Don't Panic -- 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: V1.7 and endless loops triggerd by junction points
Corinna Vinschen wrote: On May 5 06:21, Andy Koppe wrote: Matthias Meyer wrote: 2) In the opposite to V1.5.25 ls -alh /cygdrive/c/users/ shows the Vista Junction points like linux soft links. That is nice :-) But the Windows Program attrib /S /D will follow this symbolic links and therefore it comes into an endless loop. e.g.: C:\Documents and Settings\All Users\Application Data\Application Data\.. This behaviour will take place too if I run it with cmd /c attrib Both above means by running it within a bash shell. If I run attrib from a cmd box it work correct. I don't see how that could possibly be the fault of Cygwin or bash. It's a Windows program dealing with a Windows filesystem feature. Sure you're actually running the same 'attrib' in both environments? It could be a result of running attrib once in a normal and once in an elevated shell. Sorry for my english ;-( An elevated shell means a shell with enhanced privileges? Otherwise, the only difference as far as I can see is the fact that the user token attrib inherited from the Cygwin shell has more user rights enabled. Namely the backup and restore rights, which allows to access files and directories which are not available by default. However, this only works in an elevated shell, too. However, it's not Cygwin's fault that attrib is not up to speed with circular symlinks on an OS which allows them. Corinna It seems to be the backup and restore rights. I can run a cmd as administrator and attrib don't run into the endless loop. Also I can run sh from a normal user and attrib will work right. Only if I run attrib within a process with the backup and restore rights attrib will run into this endless loop :-( Thanks Matthias -- Don't Panic -- 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: cygpath from emacs
Amazingly enough I solved this problem for myself just yesterday. ;; Add to your .emacs file. ;; Handle locating files containing errors for compilers that report using DOS style paths. (when (eq system-type 'cygwin) (require 'compile) (setq compilation-parse-errors-filename-function '(lambda (path) (replace-regexp-in-string \n (shell-command-to-string (concat cygpath --unix ' path ')) On Wed, May 5, 2010 at 1:00 PM, Dave Korn dave.korn.cyg...@googlemail.com wrote: On 05/05/2010 19:24, Gary wrote: I often find myself running a piece of software from within emacs that expects, and spits out, Windows-style paths (C:\...). Handling sending it Windows paths based on the Cygwin ones is fine, I just use a script. Of course, the tool returning Windows paths is a PITA, because it means I can't do M-x next-error :( Is there a solution, a way to capture them and transform them before they end up in the emacs buffer, maybe? I feel I should be able to work this out myself, but my brain refuses to bend around it :( So you have a script that transforms the paths on the command-line and launches the app... why doesn't the script /also/ capture the output and transform it back? cheers, DaveK -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple -- 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.1 : search inside more returns Regular expression botch;
Fabrice PLATEL fplatel at orinux.com writes: While I am viewing a file with the more utility, if I want to search any expression inside the file by typing / then the expression, it doesn't search and just displays the message Regular expression botch. Am I the only one having this behaviour ? What does it mean ?? how to fix it ? Fabrice I'm having the same problem. Yes I could just use less but I'd like to know why this is happening... -- 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: cygpath from emacs
Not sure why it line wrapped the second comment when I sent this. The part reading using DOS style paths. is part of the comment line above it. On Wed, May 5, 2010 at 1:42 PM, Steven Collins spc.for@gmail.com wrote: Amazingly enough I solved this problem for myself just yesterday. ;; Add to your .emacs file. ;; Handle locating files containing errors for compilers that report using DOS style paths. (when (eq system-type 'cygwin) (require 'compile) (setq compilation-parse-errors-filename-function '(lambda (path) (replace-regexp-in-string \n (shell-command-to-string (concat cygpath --unix ' path ')) On Wed, May 5, 2010 at 1:00 PM, Dave Korn dave.korn.cyg...@googlemail.com wrote: On 05/05/2010 19:24, Gary wrote: I often find myself running a piece of software from within emacs that expects, and spits out, Windows-style paths (C:\...). Handling sending it Windows paths based on the Cygwin ones is fine, I just use a script. Of course, the tool returning Windows paths is a PITA, because it means I can't do M-x next-error :( Is there a solution, a way to capture them and transform them before they end up in the emacs buffer, maybe? I feel I should be able to work this out myself, but my brain refuses to bend around it :( So you have a script that transforms the paths on the command-line and launches the app... why doesn't the script /also/ capture the output and transform it back? cheers, DaveK -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
1.7.1: Replacement for mount -f -u -b c: /
In the previous release, some of our engineers would change: /cygwin/c/export/home/ To /export/home To eliminate the /c they would use Mount -f -u -b c: / This no longer works and I haven't figured out a work around. Tried playing with fstab with no luck. Thanks Mathew -- 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.1: Replacement for mount -f -u -b c: /
On 5/5/2010 2:57 PM, Mathew Shember wrote: In the previous release, some of our engineers would change: /cygwin/c/export/home/ To /export/home To eliminate the /c they would use Mount -f -u -b c: / This no longer works and I haven't figured out a work around. Tried playing with fstab with no luck. A symlink should work: $ ln -s /cygwin/c/export /export A mount will also work: $ mkdir /export # To silence mount warnings... $ mount C:/export /export If what you really want is to dynamically map the entire contents of C: into the Cygwin root directory, I don't have any suggestions. People have been known to install Cygwin directly to C:\ before, and that would basically get you the mapping for free, but doing so is frowned upon here. -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: 1.7.1: Replacement for mount -f -u -b c: /
On 5/5/2010 3:08 PM, Jeremy Bopp wrote: On 5/5/2010 2:57 PM, Mathew Shember wrote: In the previous release, some of our engineers would change: /cygwin/c/export/home/ To /export/home To eliminate the /c they would use Mount -f -u -b c: / This no longer works and I haven't figured out a work around. Tried playing with fstab with no luck. A symlink should work: $ ln -s /cygwin/c/export /export ^^ I typo'd the default cygdrive path. The above should be /cygdrive/c/export. Sorry for any confusion. -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: Signal support under Cygwin
On 6/05/2010 2:23 a.m., Christopher Faylor wrote: On Thu, May 06, 2010 at 02:20:54AM +1200, Nicholas Sherlock wrote: On 28/04/2010 4:25 p.m., Nicholas Sherlock wrote: Is this supposed to work? Nobody knows if Cygwin signals work? Could anybody reproduce the crash from my example code at least on their machines? Investigating this is on my todo list. cgf Okay, thanks :) Cheers, Nicholas Sherlock -- 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
Problem install CPAN module: perl (5.10.1) is installed, but we need version = 5.6
Hi, Im not sure if this is a cygwin specific problem or a perl/CPAN issue. Im trying to install the Net::Proxy module and Im getting the following error: perl (5.10.1) is installed, but we need version = 5.6 Im not sure why CPAN cant figure out that 5.10.1 is 5.6. Below is the install output. Any help is appreciated. Thanks, J cpan[1] install Net::Proxy CPAN: Storable loaded ok (v2.20) Going to read '/cygdrive/f/.cpan/Metadata' Database was generated on Wed, 05 May 2010 22:27:07 GMT Running install for module 'Net::Proxy' CPAN: YAML loaded ok (v0.71) Running make for B/BO/BOOK/Net-Proxy-0.12.tar.gz CPAN: Digest::SHA loaded ok (v5.47) CPAN: Compress::Zlib loaded ok (v2.024) Checksum for /cygdrive/f/.cpan/sources/authors/id/B/BO/BOOK/Net-Proxy-0.12.tar.gz ok Scanning cache /cygdrive/f/.cpan/build for sizes DONE CPAN: Archive::Tar loaded ok (v1.52) Net-Proxy-0.12/ Net-Proxy-0.12/t/ Net-Proxy-0.12/t/90compile.t Net-Proxy-0.12/t/Util.pm Net-Proxy-0.12/t/35hook_dual.t Net-Proxy-0.12/t/pod.t Net-Proxy-0.12/t/11proxy_accessor.t Net-Proxy-0.12/t/36tcp_ctssl.t Net-Proxy-0.12/t/21connect.t Net-Proxy-0.12/t/10proxy_new.t Net-Proxy-0.12/t/test.key Net-Proxy-0.12/t/40tcp_fail.t Net-Proxy-0.12/t/36ssl_tcp.t Net-Proxy-0.12/t/14proxy_debug.t Net-Proxy-0.12/t/30tcp_tcp.t Net-Proxy-0.12/t/13proxy_stat.t Net-Proxy-0.12/t/35signal.t Net-Proxy-0.12/t/00load.t Net-Proxy-0.12/t/34hook_in.t Net-Proxy-0.12/t/33dual.t Net-Proxy-0.12/t/31tcp_tcp_multi.t Net-Proxy-0.12/t/37connectssl_tcp.t Net-Proxy-0.12/t/05connector.t Net-Proxy-0.12/t/test.cert Net-Proxy-0.12/t/pod-coverage.t Net-Proxy-0.12/t/36tcp_ssl.t Net-Proxy-0.12/t/22dual.t Net-Proxy-0.12/t/34hook_out.t Net-Proxy-0.12/t/20dummy.t Net-Proxy-0.12/t/32tcp_connect.t Net-Proxy-0.12/t/36ctssl_tcp.t Net-Proxy-0.12/t/41listen_fail.t Net-Proxy-0.12/t/12proxy_connectors.t Net-Proxy-0.12/lib/ Net-Proxy-0.12/lib/Net/ Net-Proxy-0.12/lib/Net/Proxy/ Net-Proxy-0.12/lib/Net/Proxy/Connector.pm Net-Proxy-0.12/lib/Net/Proxy/Tutorial.pod Net-Proxy-0.12/lib/Net/Proxy/Connector/ Net-Proxy-0.12/lib/Net/Proxy/Connector/dual.pm Net-Proxy-0.12/lib/Net/Proxy/Connector/connect.pm Net-Proxy-0.12/lib/Net/Proxy/Connector/connect_ssl.pm Net-Proxy-0.12/lib/Net/Proxy/Connector/tcp.pm Net-Proxy-0.12/lib/Net/Proxy/Connector/ssl.pm Net-Proxy-0.12/lib/Net/Proxy/Connector/dummy.pm Net-Proxy-0.12/lib/Net/Proxy.pm Net-Proxy-0.12/README Net-Proxy-0.12/Changes Net-Proxy-0.12/Build.PL Net-Proxy-0.12/Makefile.PL Net-Proxy-0.12/META.yml Net-Proxy-0.12/script/ Net-Proxy-0.12/script/sslh Net-Proxy-0.12/script/connect-tunnel Net-Proxy-0.12/MANIFEST CPAN: File::Temp loaded ok (v0.22) CPAN: Module::Build loaded ok (v0.3603) CPAN.pm: Going to build B/BO/BOOK/Net-Proxy-0.12.tar.gz 0 [main] perl 25536 C:\cygwin\bin\perl.exe: *** fatal error - unable to remap C:\cygwin\bin\cygncurses-9.dll to same address as parent: 0xA3 != 0xB1 0 [main] perl 11052 fork: child 25536 - died waiting for dll loading, errno 11 cygwin warning: MS-DOS style path detected: \Users\jmoon Preferred POSIX equivalent is: /cygdrive/f/Users/jmoon CYGWIN environment variable option nodosfilewarning turns off this warning. Consult the user's guide for more details about POSIX paths: http://cygwin.com/cygwin-ug-net/using.html#using-pathnames Checking prerequisites... requires: ! perl (5.10.1) is installed, but we need version = 5.6 recommends: * IO::Socket::SSL is not installed ERRORS/WARNINGS FOUND IN PREREQUISITES. You may wish to install the versions of the modules indicated above before proceeding with this installation Creating new 'MYMETA.yml' with configuration results Creating new 'Build' script for 'Net-Proxy' version '0.12' BOOK/Net-Proxy-0.12.tar.gz requires perl '5.6'; you have only 5.010001; giving up BOOK/Net-Proxy-0.12.tar.gz [prereq] -- NOT OK Running Build test Can't test without successful make Running Build install Make had returned bad status, install seems impossible Failed during this command: BOOK/Net-Proxy-0.12.tar.gz : make NO requires perl '5.6' cpan[2] install CPAN CPAN is up to date (1.9402). cpan[3] cygcheck.out Description: Binary data -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Cygwin make target is never determined up to date
Yes, that's the problem, I am not supposed to update prerequisite file inside of prerequisite dir. But it's not related to WinXP or Win7, because it also worked _incorrectly_ on other Win7. So what is happening that in some cases the mtime of directory is exactly the mtime of the file created. This is confusing. @DaveK: I'll check the article for sure, thanks! Dave Korn-6 wrote: On 05/05/2010 06:04, Jeremy Bopp wrote: MichaelKim wrote: Prerequisite `../bin/build/chrome' is newer than target `../bin/build/chrome/alt.jar'. Must remake target `../bin/build/chrome/alt.jar'. So let me get this straight. The JAR file you're trying to build is within a directory which is listed as a prerequisite of that JAR file? Unless I'm completely off base, it would seem to be that this is expected behavior then. If you mess with the contents of a directory, such as by adding a file to it, the last modified timestamp of the directory is going to be updated. I would expect that to happen after the file is added to the directory which could very well be *after* the last modified timestamp of the file is set. Thus the directory will appear newer than the file. Yep: $(chrome_jar_file): $(jar_sources) $(jar_target_dir) The idea is supposed to be to make the jar file depend on the output dir, so that if the output dir doesn't exist, the $(jar_target_dir) rule will get invoked to mkdir it; but it doesn't anticipate that the timestamp of an existing dir changes everytime you touch the files within it. For a discussion of better ways to create an output dir in make, see: http://www.cmcrossroads.com/cm-articles/columns/ask-mr-make The particular article you're looking for is #26, Making directories in GNU Make: http://www.cmcrossroads.com/ask-mr-make/6936-making-directories-in-gnu-make I don't know why this would be working on the old XP machine, unless it's running an older version of cygwin that had a bug or didn't implement updating directory timestamps. cheers, DaveK -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple -- View this message in context: http://old.nabble.com/Cygwin-make-target-is-never-determined-up-to-date-tp28454344p28467628.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: Signal support under Cygwin
On 05/05/2010 23:57, Nicholas Sherlock wrote: On 6/05/2010 2:23 a.m., Christopher Faylor wrote: On Thu, May 06, 2010 at 02:20:54AM +1200, Nicholas Sherlock wrote: On 28/04/2010 4:25 p.m., Nicholas Sherlock wrote: Is this supposed to work? Nobody knows if Cygwin signals work? Could anybody reproduce the crash from my example code at least on their machines? Investigating this is on my todo list. cgf Okay, thanks :) I have confirmed that the bug exists on w2ksp4, so it's not a Win7, 64-bit or UAC or DEP thing; looks like a real bug in the Cygwin DLL. cheers, DaveK -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Cygwin make target is never determined up to date
On 06/05/2010 00:23, MichaelKim wrote: But it's not related to WinXP or Win7, because it also worked _incorrectly_ on other Win7. So what is happening that in some cases the mtime of directory is exactly the mtime of the file created. This is confusing. There have definitely been fixes in this department for greater POSIX compatibility; if your machines are running different versions of the Cygwin DLL, that would explain it. If not, then it is a definite mystery! cheers, DaveK -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Cygwin make target is never determined up to date
At the moment I have Win7 with version 1.7.5. Most of the time the timestamps of dir and inside file are exactly same. Have WinXP with version 1.5.19 where the timestamps are _always_ the same. The one at home Win7, which is _always_ dir has newer timestamp I believe again 1.7.5, same as the one I mentioned above. Dave Korn-6 wrote: On 06/05/2010 00:23, MichaelKim wrote: But it's not related to WinXP or Win7, because it also worked _incorrectly_ on other Win7. So what is happening that in some cases the mtime of directory is exactly the mtime of the file created. This is confusing. There have definitely been fixes in this department for greater POSIX compatibility; if your machines are running different versions of the Cygwin DLL, that would explain it. If not, then it is a definite mystery! cheers, DaveK -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple -- View this message in context: http://old.nabble.com/Cygwin-make-target-is-never-determined-up-to-date-tp28454344p28467801.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: Cygwin make target is never determined up to date
On 06/05/2010 00:46, MichaelKim wrote: At the moment I have Win7 with version 1.7.5. Most of the time the timestamps of dir and inside file are exactly same. Ah. The fact that the timestamps *look* the same when shown in the output of a dir or ls command doesn't mean they're actually the same when compared to the nearest 100ns, which is the accuracy of the underlying NTFS file timestamps. Have WinXP with version 1.5.19 where the timestamps are _always_ the same. The one at home Win7, which is _always_ dir has newer timestamp I believe again 1.7.5, same as the one I mentioned above. I think that's probably the cause of the difference. I haven't double-checked in the archives, but I'm reasonably sure that's it: old 1.5 never used to update the directory timestamps - as is actually required by the POSIX spec, so 1.7 is doing the right thing, even though it's in some ways less convenient! cheers, DaveK -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Cygwin make target is never determined up to date
I'm using stats right after creating the jar Creating chrome JAR file. Done! stat /cygdrive/e/tmp/alt/bin/build/chrome /cygdrive/e/tmp/alt/bin/build/chrome/alt.jar File: `/cygdrive/e/tmp/alt/bin/build/chrome' Size: 0 Blocks: 0 IO Block: 1024 directory Device: bef281h/12513921d Inode: 8444249301500971 Links: 2 Access: (0755/drwxr-xr-x) Uid: ( 1003/a) Gid: ( 513/None) Access: 2010-05-06 07:57:25.47000 +0900 Modify: 2010-05-06 07:57:25.47000 +0900 Change: 2010-05-06 07:57:25.47000 +0900 File: `/cygdrive/e/tmp/alt/bin/build/chrome/alt.jar' Size: 28860 Blocks: 32 IO Block: 1024 regular file Device: bef281h/12513921d Inode: 9570149208343597 Links: 1 Access: (0644/-rw-r--r--) Uid: ( 1003/a) Gid: ( 513/None) Access: 2010-05-06 07:57:25.47000 +0900 Modify: 2010-05-06 07:57:25.47000 +0900 Change: 2010-05-06 07:57:25.47000 +0900 This output is from 1.7.5 on Win7, which I downloaded/installed 2 days ago. The timestamps are equal most of the time, just sometimes it may happen be different. Dave Korn-6 wrote: On 06/05/2010 00:46, MichaelKim wrote: At the moment I have Win7 with version 1.7.5. Most of the time the timestamps of dir and inside file are exactly same. Ah. The fact that the timestamps *look* the same when shown in the output of a dir or ls command doesn't mean they're actually the same when compared to the nearest 100ns, which is the accuracy of the underlying NTFS file timestamps. Have WinXP with version 1.5.19 where the timestamps are _always_ the same. The one at home Win7, which is _always_ dir has newer timestamp I believe again 1.7.5, same as the one I mentioned above. I think that's probably the cause of the difference. I haven't double-checked in the archives, but I'm reasonably sure that's it: old 1.5 never used to update the directory timestamps - as is actually required by the POSIX spec, so 1.7 is doing the right thing, even though it's in some ways less convenient! cheers, DaveK -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple -- View this message in context: http://old.nabble.com/Cygwin-make-target-is-never-determined-up-to-date-tp28454344p28467975.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: Cygwin make target is never determined up to date
On 06/05/2010 01:16, MichaelKim wrote: The timestamps are equal most of the time, just sometimes it may happen be different. Well, from make's point of view, it has to take the safe assumption that if timestamps are equal, the file /could/ be out of date, so I think that explains the behaviour? Maybe take a look at the documentation for `.LOW_RESOLUTION_TIME' in the make info page, it discusses related issues. cheers, DaveK -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Cygwin make target is never determined up to date
Just to make sure we are on the same page.. Whenever the timestamps are equal, it doesn't consider target as out of date, hence nothing happens. Dave Korn-6 wrote: On 06/05/2010 01:16, MichaelKim wrote: The timestamps are equal most of the time, just sometimes it may happen be different. Well, from make's point of view, it has to take the safe assumption that if timestamps are equal, the file /could/ be out of date, so I think that explains the behaviour? Maybe take a look at the documentation for `.LOW_RESOLUTION_TIME' in the make info page, it discusses related issues. cheers, DaveK -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple -- View this message in context: http://old.nabble.com/Cygwin-make-target-is-never-determined-up-to-date-tp28454344p28468153.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: Cygwin make target is never determined up to date
On 06/05/2010 01:45, MichaelKim wrote: Just to make sure we are on the same page.. Whenever the timestamps are equal, it doesn't consider target as out of date, hence nothing happens. Heh, it's as well you said that, I had it the wrong way around. I'm not clear now: the subject says 'never' up to date, but do you also mean that sometimes it gets it right anyway? That would be strange. cheers, DaveK -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Cygwin make target is never determined up to date
Well, it's confusing because I have 3 machines. 1. WinXP (cygwin 1.5.19) - once built, the timestamps are equal and no problem( happy with that, but I got the point that this is wrong makefile design) 2. Win7 (cygwin 1.7.5) - once built, the timestamps are equal, and no further build required if files are intact. However, sometimes the timestamps are not equal and it doesn't consider targets up to date. 3. Another Win7 (cygwin 1.7.5, I can check exactly later) - timestamps are always different, hence it's NEVER up to date. This is the original case I was talking about. Hope it's clear now. Sorry for misleading and confusing you ^^ Dave Korn-6 wrote: On 06/05/2010 01:45, MichaelKim wrote: Just to make sure we are on the same page.. Whenever the timestamps are equal, it doesn't consider target as out of date, hence nothing happens. Heh, it's as well you said that, I had it the wrong way around. I'm not clear now: the subject says 'never' up to date, but do you also mean that sometimes it gets it right anyway? That would be strange. cheers, DaveK -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple -- View this message in context: http://old.nabble.com/Cygwin-make-target-is-never-determined-up-to-date-tp28454344p28468326.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: Cygwin make target is never determined up to date
On 06/05/2010 02:15, MichaelKim wrote: Well, it's confusing because I have 3 machines. 1. WinXP (cygwin 1.5.19) - once built, the timestamps are equal and no problem( happy with that, but I got the point that this is wrong makefile design) 2. Win7 (cygwin 1.7.5) - once built, the timestamps are equal, and no further build required if files are intact. However, sometimes the timestamps are not equal and it doesn't consider targets up to date. 3. Another Win7 (cygwin 1.7.5, I can check exactly later) - timestamps are always different, hence it's NEVER up to date. This is the original case I was talking about. Hope it's clear now. Yes, I see; so the thing we need to understand (from posix compatibility point of view) is why on the first win7 machine, the timestamps are not /always/ unequal! Sorry for misleading and confusing you ^^ No need to apologise, I spend most of my life confused, it's only when I get too certain that I really know something that I may make a mistake :) cheers, DaveK -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Cygwin make target is never determined up to date
You've got my point and I'll report the exact dll version later today. However, I redesigned the makefile in order to avoid such bad dependency. Dave Korn-6 wrote: On 06/05/2010 02:15, MichaelKim wrote: Well, it's confusing because I have 3 machines. 1. WinXP (cygwin 1.5.19) - once built, the timestamps are equal and no problem( happy with that, but I got the point that this is wrong makefile design) 2. Win7 (cygwin 1.7.5) - once built, the timestamps are equal, and no further build required if files are intact. However, sometimes the timestamps are not equal and it doesn't consider targets up to date. 3. Another Win7 (cygwin 1.7.5, I can check exactly later) - timestamps are always different, hence it's NEVER up to date. This is the original case I was talking about. Hope it's clear now. Yes, I see; so the thing we need to understand (from posix compatibility point of view) is why on the first win7 machine, the timestamps are not /always/ unequal! Sorry for misleading and confusing you ^^ No need to apologise, I spend most of my life confused, it's only when I get too certain that I really know something that I may make a mistake :) cheers, DaveK -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple -- View this message in context: http://old.nabble.com/Cygwin-make-target-is-never-determined-up-to-date-tp28454344p28468372.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: rxvt : 1.5 vs. 1.7
On 5/5/2010 12:01 PM, Fergus wrote: Constantly stalling when exiting rxvt in [1.7] (as previously reported; and still don't understand why, or why this list isn't full of Me toos). This never happens in 1.5. I really prefer rxvt over all other shells incl mintty. So I copied rxvt.exe from /bin[1.5] to /bin[1.7] overwriting the version there. What a horrid fix! But it seems to work just fine. There was very little code change between rxvt-20050409-10 (the most recent cygwin-1.5 version of rxvt) and rxvt-20050409-21 (the most recent cygwin-1.7 version of rxvt). Any change in behavior like you describe is, I think, due to one of two things; 1) something different in the cygwin DLL itself 2) or, when configuring and building rxvt from source *on a cygwin-1.7 system*, the configure process detects something -- some newly supported feature, function, typedef, etc -- and that causes the rxvt compiled on cygwin-1.7 to actually call different functions, or call them in different ways, than if the same source code was compiled on a cygwin-1.5 system. Now, I *have* seen the behavior you describe -- but only intermittently. This makes it tricky to figure out exactly why it occurs and what is triggering it. To test this second hypothesis, I could take rxvt-20050409-21 and try to rebuild it on a cygwin-1.5 installation...but, I just don't care that much. Rxvt has *major* problems on cygwin-1.7, that *just can't be fixed* -- unless we rip out all of the UTF-8 and i18n stuff that was put into cygwin-1.7 in the first place. If you like rxvt, I'd recommend using rxvt-unicode. It *does* require an Xserver, unlike the old rxvt, but (a) our cygwin Xserver is pretty good these days, and (b) fairly easy to set up. For the ultimate in simple setup, you could install the Xming Xserver -- one-click and you're done. There's no reason you can't use cygwin X clients and Colin's native win32 Xming Xserver, if cygwin's xserver scares you. -- Chuck rxvt maintainer -- 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.1: Replacement for mount -f -u -b c: /
Thank you! This might be a case of I want it that way Basically the user is not happy to see /c/export/home when he does a pwd. The old mount command eliminated the /c Thanks! -Original Message- From: cygwin-ow...@cygwin.com [mailto:cygwin-ow...@cygwin.com] On Behalf Of Jeremy Bopp Sent: Wednesday, May 05, 2010 1:08 PM To: cygwin@cygwin.com Subject: Re: 1.7.1: Replacement for mount -f -u -b c: / On 5/5/2010 2:57 PM, Mathew Shember wrote: In the previous release, some of our engineers would change: /cygwin/c/export/home/ To /export/home To eliminate the /c they would use Mount -f -u -b c: / This no longer works and I haven't figured out a work around. Tried playing with fstab with no luck. A symlink should work: $ ln -s /cygwin/c/export /export A mount will also work: $ mkdir /export # To silence mount warnings... $ mount C:/export /export If what you really want is to dynamically map the entire contents of C: into the Cygwin root directory, I don't have any suggestions. People have been known to install Cygwin directly to C:\ before, and that would basically get you the mapping for free, but doing so is frowned upon here. -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 -- 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: V1.7 and endless loops triggerd by junction points
Matthias Meyer: Andy Koppe wrote: Matthias Meyer wrote: I've installed cygwin 1.7 in Vista and have two problems, not known prior with cygwin 1.5.25: 1) If I login in a shell (e.g. sh --login -i) I can not use cursor or backspace keys. It seems that the cursor can't go into the left direction. Cursor up will resolve in one line like: $ tail /cygdrive/c/Attrib/attributes$ ls -alh /cygdrive/c/Attrib/attributes instead two different lines like $ tail /cygdrive/c/Attrib/attributes $ ls -alh /cygdrive/c/Attrib/attributes Weird. Messed up tty settings perhaps. How and where are you running that shell? What's the output of 'stty -a'? Also, cygcheck output as requested at http://cygwin.com/problems.html might be helpful. I running this shell by ssh (with private/public key authentication) or by sh --login -i from windows cmd. The same behaviour in both types of shell. As far as I know I've not configured anything for a shell. $ stty -a speed 38400 baud; rows 25; columns 80; line = 0; intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = undef; eol2 = undef; swtch = ^Z; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 0; -parenb -parodd cs8 -hupcl -cstopb cread -clocal -crtscts -ignbrk brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl -ixon -ixoff -iuclc -ixany -imaxbel opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 isig icanon iexten echo echoe echok -echonl -noflsh -tostop echoctl echoke Hmm, a few of those are different from what they are on my machine: ixon -echo -echoe -echoctl -echoke, but changing them doesn't produce the effect you're seeing. Still begs the question though why they are different. Any chance there's a mixup with different Cygwin versions or a different Unix environment? Otherwise, I'm stumped. I think 'cygcheck -svr' output is needed to get any further. Please attach, not include it, and make sure you delete any sensitive info from it first. Also, what happens if you invoke Cygwin from the desktop or start menu shortcut? You could also try installing mintty or rxvt to see whether you get the same problem there. 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: rxvt : 1.5 vs. 1.7
Fergus wrote: Constantly stalling when exiting rxvt in [1.7] (as previously reported; and still don't understand why, or why this list isn't full of Me toos). This never happens in 1.5. I really prefer rxvt over all other shells incl mintty. Always on the lookout for ways to improve mintty: what mintty shortcomings or rxvt features make you prefer rxvt? (Btw, the issue with the disappearing cursor you reported is fixed in mintty 0.7-beta1 available from the project website.) 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: Cygwin setup.exe: Clean historical setup packages
LiuYan 刘研 wrote: ... I wish the local setup directory contains only newest packages so that I can carry small-size packages to upgrade cygwin on servers which have no internet connection. I'm currently delete the old packages manually, it's a little boring and may cause dependency-missing issue. So I wish Cygwin setup.exe/setup-1.7.exe can provide an option like keep only newest packages in local directory, it will be very helpful :) lftp does what you want. Type in command prompt: lftp open ftp://ftp.byfly.by/pub/cygwin/ lcd /path_to_local_cygwin_dir/cygwin/ mirror --delete --exclude-glob *-src.tar.bz2 -v -n -- View this message in context: http://old.nabble.com/Cygwin-setup.exe%3A-Clean-historical-setup-packages-tp26569064p28469451.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
