Re: [RFU] monotone-1.0-1
Corinna Vinschen wrote: On May 9 13:26, Lapo Luchini wrote: http://lapo.it/cygwin/monotone/monotone-1.0-1.tar.bz2 http://lapo.it/cygwin/monotone/monotone-1.0-1-src.tar.bz2 Uploaded. What about all the old versions? Thanks. I'd keep just 0.99.1-1 (just in case), any previous one is now unnecessary. -- Lapo Luchini - http://lapo.it/
Re: [RFU] monotone-1.0-1
On May 10 11:09, Lapo Luchini wrote: Corinna Vinschen wrote: On May 9 13:26, Lapo Luchini wrote: http://lapo.it/cygwin/monotone/monotone-1.0-1.tar.bz2 http://lapo.it/cygwin/monotone/monotone-1.0-1-src.tar.bz2 Uploaded. What about all the old versions? Thanks. I'd keep just 0.99.1-1 (just in case), any previous one is now unnecessary. Ok, I removed all 0.4x versions. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
src/winsup/doc ChangeLog setup2.sgml
CVSROOT:/cvs/src Module name:src Changes by: cori...@sourceware.org 2011-05-10 08:56:05 Modified files: winsup/doc : ChangeLog setup2.sgml Log message: * setup2.sgml (setup-env-ov): Make sure everybody knows that the CYGWIN settings are just an example. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/doc/ChangeLog.diff?cvsroot=srcr1=1.344r2=1.345 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/doc/setup2.sgml.diff?cvsroot=srcr1=1.46r2=1.47
src/winsup/lsaauth ChangeLog Makefile.in cygls ...
CVSROOT:/cvs/src Module name:src Changes by: cori...@sourceware.org 2011-05-10 10:06:51 Modified files: winsup/lsaauth : ChangeLog Makefile.in cyglsa.c cyglsa64.dll Log message: * Makefile.in: Don't override CC. * cyglsa.c: Don't include wchar.h. Declare wcscpy and wcslen instead. * cyglsa64.dll: Rebuild. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/lsaauth/ChangeLog.diff?cvsroot=srcr1=1.13r2=1.14 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/lsaauth/Makefile.in.diff?cvsroot=srcr1=1.4r2=1.5 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/lsaauth/cyglsa.c.diff?cvsroot=srcr1=1.9r2=1.10 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/lsaauth/cyglsa64.dll.diff?cvsroot=srcr1=1.6r2=1.7
src/winsup/cygwin ChangeLog environ.cc fork.cc ...
CVSROOT:/cvs/src Module name:src Changes by: cori...@sourceware.org 2011-05-10 10:17:30 Modified files: winsup/cygwin : ChangeLog environ.cc fork.cc wincap.cc wincap.h Log message: * environ.cc (set_chunksize): Remove. (parse_thing): Remove forkchunk entry. * fork.cc (child_copy): Drop handling external chunksize setting. * wincap.cc: Througout, drop chunksize. (wincapc::set_chunksize): Remove. * wincap.h (struct wincaps): Drop chunksize and declaration of set_chunksize. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/ChangeLog.diff?cvsroot=srcr1=1.5333r2=1.5334 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/environ.cc.diff?cvsroot=srcr1=1.185r2=1.186 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/fork.cc.diff?cvsroot=srcr1=1.216r2=1.217 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/wincap.cc.diff?cvsroot=srcr1=1.113r2=1.114 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/wincap.h.diff?cvsroot=srcr1=1.93r2=1.94
src/winsup/doc ChangeLog cygwinenv.sgml
CVSROOT:/cvs/src Module name:src Changes by: cori...@sourceware.org 2011-05-10 10:23:57 Modified files: winsup/doc : ChangeLog cygwinenv.sgml Log message: * cygwinenv.sgml: Move forkchunk:xxx to the removed options section. Change text accordingly. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/doc/ChangeLog.diff?cvsroot=srcr1=1.345r2=1.346 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/doc/cygwinenv.sgml.diff?cvsroot=srcr1=1.39r2=1.40
src/winsup/cygwin ChangeLog security.cc
CVSROOT:/cvs/src Module name:src Changes by: chrfra...@sourceware.org2011-05-10 17:19:38 Modified files: winsup/cygwin : ChangeLog security.cc Log message: * security.cc (check_registry_access): Handle missing security descriptor of HKEY_PERFORMANCE_DATA. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/ChangeLog.diff?cvsroot=srcr1=1.5336r2=1.5337 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/security.cc.diff?cvsroot=srcr1=1.257r2=1.258
Re: [PATCH] tcsetpgrp fails unexpectedly
On May 5 16:07, Christopher Faylor wrote: On Thu, May 05, 2011 at 08:19:24PM +0200, Corinna Vinschen wrote: On May 5 19:23, Corinna Vinschen wrote: On May 5 13:10, Christopher Faylor wrote: On Mon, Apr 04, 2011 at 12:23:00PM -0700, Tor Perkins wrote: Thanks for the patch and the report. I'll take a look at this in detail in the next couple of days. However, unfortunately, I think this is a large enough submission that it requires an assignment form. Thanks for looking into it! My assignment form is in the snail. Corinna, did you receive this? Did I miss a notification? Thanks for the reminder. The notification was supposed to go directly to you because I was on vacation at the time. I'll check. Due to, let's say, technical problems I can't answer this question before Monday. It seems the CA arrived and was signed, but somebody has to check. Ok. I'll put this in a cron job to send query email every hour until it's resolved. Resolved. Tor's copyright assignment made it to Red Hat already weeks ago. The guy I asked to keep you informed during my vacation simply forgot... Sorry about that. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: [PATCH] Fix access(/proc/registry/HKEY_PERFORMANCE_DATA, R_OK)
Corinna Vinschen wrote: Yeah, right. On second thought that looks much better. Please check in. Done Christian
Extending /proc/*/maps
Hi all,
Please find attached three patches which extend the functionality of
/proc/*/maps.
The first (proc-maps-files) makes format_process_maps report all
reserved or committed address space, rather than just the parts occupied
by dlls in the dll_list. It splits allocations when they have multiple
sets of permissions (with proper file offsets when appropriate),
displays the file name of all mapped images and files, and identifies
shared memory segments.
The second (proc-maps-heaps) adds reporting of Windows heaps (or their
bases, at least). Unfortunately there doesn't seem to be any efficient
way to identify all virtual allocations which a heap owns.
The third (proc-maps-safe) adds a safe mode and helper function which
allows to print the process map at early stages of process startup when
cygwin1.dll is not initialized yet. It is provided in case anyone finds
it helpful; I don't expect it to migrate upstream.
Changelog entries also attached...
NOTE 1: I do not attempt to identify PEB, TEB, or thread stacks. The
first could be done easily enough, but the second and third require
venturing into undocumented/private Windows APIs.
NOTE 2: If desired, we could easily extend format_process_maps further
to report section names of mapped images (linux does this for .so
files), using the pe/coff file introspection class that accompanies my
fork patches (separate email). I did not implement it because I don't
know if people want that functionality. I haven't needed it yet.
Thoughts?
Ryan
# HG changeset patch
# Parent 1420f18fd5c5647e475df8339486020b456fb9d8
diff --git a/ChangeLog b/ChangeLog
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,12 @@
+2011-05-10 Ryan Johnson ryan.john...@cs.utoronto.ca
+
+ * fhandler_process.cc (dos_drive_mappings, heap_info): New helper
classes.
+ (format_process_maps): Reworked to report all mapped address space
+ in a process (committed or reserved), identifying the nature of
+ the mapping (mapped file/image, heap, shared memory) when
+ possible.
+ * autoload.cc: Register GetMappedFileNameW (psapi.dll)
+
2011-04-15 Yaakov Selkowitz yselkow...@users.sourceforge.net
* thread.cc (pthread_setschedprio): New function.
diff --git a/autoload.cc b/autoload.cc
--- a/autoload.cc
+++ b/autoload.cc
@@ -422,6 +422,7 @@
LoadDLLfunc (CoTaskMemFree, 4, ole32)
LoadDLLfunc (EnumProcessModules, 16, psapi)
+LoadDLLfunc (GetMappedFileNameW, 16, psapi)
LoadDLLfunc (GetModuleFileNameExW, 16, psapi)
LoadDLLfunc (GetModuleInformation, 16, psapi)
LoadDLLfunc (GetProcessMemoryInfo, 12, psapi)
diff --git a/fhandler_process.cc b/fhandler_process.cc
--- a/fhandler_process.cc
+++ b/fhandler_process.cc
@@ -527,6 +527,81 @@
return len + 1;
}
+struct dos_drive_mappings {
+ struct mapping {
+mapping* next;
+int len;
+wchar_t drive_letter;
+wchar_t mapping[1];
+ };
+ mapping* mappings;
+
+ dos_drive_mappings ()
+: mappings(0)
+ {
+/* The logical drive strings buffer holds a list of (at most 26)
+ drive names separated by nulls and terminated by a double-null:
+
+ a:\\\0b:\\\0...z:\\\0
+
+ The annoying part is, QueryDosDeviceW wants only x: rather
+ than the x:\ we get back from GetLogicalDriveStringsW, so
+ we'll have to strip out the trailing slash for each mapping.
+
+ The returned mapping a native NT pathname (\Device\...) which
+ we can use to fix up the output of GetMappedFileNameW
+*/
+static unsigned const DBUFLEN = 26*4;
+wchar_t dbuf[DBUFLEN+1];
+wchar_t pbuf[NT_MAX_PATH+1];
+wchar_t drive[] = {L'x', L':', 0};
+unsigned result = GetLogicalDriveStringsW (DBUFLEN*sizeof (wchar_t), dbuf);
+if (!result)
+ debug_printf (Failed to get logical DOS drive names: %lu, GetLastError
());
+else if (result DBUFLEN)
+ debug_printf (Too many mapped drive letters: %u, result);
+else
+ for (wchar_t* cur = dbuf; (*drive=*cur); cur = wcschr (cur, L'\0')+1)
+ if (QueryDosDeviceW (drive, pbuf, NT_MAX_PATH))
+ {
+ size_t plen = wcslen (pbuf);
+ size_t psize = plen*sizeof (wchar_t);
+ debug_printf (DOS drive %ls maps to %ls, drive, pbuf);
+ mapping* m = (mapping*) cmalloc (HEAP_FHANDLER, sizeof (mapping) +
psize);
+ m-next = mappings;
+ m-len = plen;
+ m-drive_letter = *drive;
+ memcpy (m-mapping, pbuf, psize + sizeof (wchar_t));
+ mappings = m;
+ }
+ else
+ debug_printf (Unable to determine the native mapping for %ls (error
%lu),
+ drive,
+ GetLastError ());
+ }
+
+ wchar_t* fixup_if_match (wchar_t* path) {
+for (mapping* m = mappings; m; m = m-next)
+ if (!wcsncmp (m-mapping, path, m-len))
+ {
+ path += m-len-2;
+ path[0] = m-drive_letter;
+ path[1] = L':';
+ break;
+ }
+return
Help! How to find newlib?
Hallo all, i'm using cygwin 1.7 for porting of a c/c++ written program from linux on windows and want to get an executable file which is independable with cygwin. This program needs glibc (the standard c library), particuly the pread, pwrite function inside it. It is described in the cygwin user's guide that newlib instead of glibc is used in cygwin. So the questions are: Is newlib already included in cygwin? But i can't find it with the unix-command find / -name newlib in my cygwin directory. Or some packages must be selected in the cygwin to get the newlib? Please help me! best regards Xin -- 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: Who's using CYGWIN=tty and why?
On Mon, May 9, 2011 at 6:10 PM, Corinna Vinschen wrote: Hi, Chris and I are wondering how many people are using the Windows console as local console window in CYGWIN=tty mode and why. Here's why we ask: We are both not sure why anybody would use it voluntarily, given that it's I/O is extremly slow, compared to using a Windows console window in the default CYGWIN=notty mode or, even better, mintty. Actually, we only keep the console tty mode up because it was always there, 14 years or so. So, if you're using a console in tty mode, why are doing that? Did you ever notice that it's much slower? Did you ever consider to switch to mintty or any other terminal emulator instead? If not, why? Would anybody really *miss* the CYGWIN=tty mode? If so, why? What does this mode have which isn't covered by notty mode or another terminal emulator? Ever since I figured out how to configure rxvt to put the scrollbar on the right, I haven't used the run bash from cmd.exe console. Nowadays, for Cygwin I use mintty exclusively. Sometimes I run C:\cygwin17\bin\grep from the Windows prompt, but that's not affected by CYGWIN=tty, right? Anyway, I haven't had the CYGWIN env.var set for years, and never missed it. Please enlighten us, otherwise we will just rip out this terminal mode for good. What would that gain ? Would it speed up the rest of the code? Would the rest of the code become cleaner, easier to understand/maintain? Csaba -- GCS a+ e++ d- C++ ULS$ L+$ !E- W++ P+++$ w++$ tv+ b++ DI D++ 5++ The Tao of math: The numbers you can count are not the real numbers. Life is complex, with real and imaginary parts. Ok, it boots. Which means it must be bug-free and perfect. -- Linus Torvalds People disagree with me. I just ignore them. -- Linus Torvalds -- 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: Who's using CYGWIN=tty and why?
On May 9 18:36, Henry S. Thompson wrote: Corinna Vinschen writes: On May 9 17:21, Henry S. Thompson wrote: Corinna Vinschen writes: Chris and I are wondering how many people are using the Windows console as local console window in CYGWIN=tty mode and why. I am one such. Here's why we ask: We are both not sure why anybody would use it voluntarily, given that it's I/O is extremly slow, compared to using a Windows console window in the default CYGWIN=notty mode or, even better, mintty. Actually, we only keep the console tty mode up because it was always there, 14 years or so. Um, history is sticky, is I guess the answer. When I started using cygwin (a _long_ time ago), CYGWIN=tty was the recommended setting (and isn't it still there in cygwin/cygwin.bat ?). So I have No, it's not the default, and it never was, actually. Well, I guess I misunderstood the earlier version of this prose (from [1]): The CYGWIN variable is used to configure many global settings for the Cygwin runtime system. Initially you can leave CYGWIN unset or set it to tty (e.g. to support job control with ^Z etc...) using a syntax like this in the DOS shell, before launching bash. plus the prose further up Some of these settings need to be in effect prior to launching the initial Cygwin session (before starting your bash shell, for instance). They should therefore be set in the Windows environment to mean that CYGWIN=tty was recommended. Well, it was just meant as an example. And what do you use to run Cygwin apps? mintty, of course :-) Attaboy ;) Many native Windows tools don't work well in tty mode anyway. For non-Cygwin tools, the default notty mode is the most compatible one. OK, I hear that as answers along the lines of yes, and only good things to my questions: Is it time to remove it? I do use a windows console occasionally for pure Windows activities---what change(s) will I see? The Wayback machine [2] suggests that the prose quoted above hasn't changed for nearly 11 years -- perhaps it's due for an update? Ok, I just did so in CVS. 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: Help! How to find newlib?
On Tue, May 10, 2011 at 9:55 AM, Xin Jin wrote: Hallo all, i'm using cygwin 1.7 for porting of a c/c++ written program from linux on windows and want to get an executable file which is independable with cygwin. This program needs glibc (the standard c library), particuly the pread, pwrite function inside it. It is described in the cygwin user's guide that newlib instead of glibc is used in cygwin. So the questions are: Is newlib already included in cygwin? But i can't find it with the unix-command find / -name newlib in my cygwin directory. Or some packages must be selected in the cygwin to get the newlib? newlib is used to build the cygwin1.dll. As you need a stand alone version you need to look at http://sourceware.org/newlib/ Please help me! google is your friend ;-) best regards Xin Marco -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Who's using CYGWIN=tty and why?
On May 10 10:29, Csaba Raduly wrote: On Mon, May 9, 2011 at 6:10 PM, Corinna Vinschen wrote: Hi, Chris and I are wondering how many people are using the Windows console as local console window in CYGWIN=tty mode and why. Here's why we ask: We are both not sure why anybody would use it voluntarily, given that it's I/O is extremly slow, compared to using a Windows console window in the default CYGWIN=notty mode or, even better, mintty. Actually, we only keep the console tty mode up because it was always there, 14 years or so. So, if you're using a console in tty mode, why are doing that? Did you ever notice that it's much slower? Did you ever consider to switch to mintty or any other terminal emulator instead? If not, why? Would anybody really *miss* the CYGWIN=tty mode? If so, why? What does this mode have which isn't covered by notty mode or another terminal emulator? Ever since I figured out how to configure rxvt to put the scrollbar on the right, I haven't used the run bash from cmd.exe console. Nowadays, for Cygwin I use mintty exclusively. Sometimes I run C:\cygwin17\bin\grep from the Windows prompt, but that's not affected by CYGWIN=tty, right? It is affected. If this setting is in your Windows environment, then the first Cygwin process in a Cygwin process tree will set up a pseudo terminal within the console, which in turn adds a layer of pipes between the application and the console window, rather than just using the console handles for stdio. Anyway, I haven't had the CYGWIN env.var set for years, and never missed it. Please enlighten us, otherwise we will just rip out this terminal mode for good. What would that gain ? Would it speed up the rest of the code? Would the rest of the code become cleaner, easier to understand/maintain? The latter. After all, the more code and the more conditions you have to support various settings, the more complicated the code gets and the more complicated the maintainance gets. 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: Help! How to find newlib?
On May 10 09:55, Xin Jin wrote: Hallo all, i'm using cygwin 1.7 for porting of a c/c++ written program from linux on windows and want to get an executable file which is independable with cygwin. This program needs glibc (the standard c library), particuly the pread, pwrite function inside it. It is described in the cygwin user's guide that newlib instead of glibc is used in cygwin. So the questions are: Is newlib already included in cygwin? But i can't find it with the unix-command find / -name newlib in my cygwin directory. Or some packages must be selected in the cygwin to get the newlib? Newlib is an integral part of the Cygwin DLL. You can't get newlib for Windows without Cygwin. Besides, if you need pread/pwrite, you're out of luck, these functions are not implemented in newlib, only in Cygwin. 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
[ANNOUNCEMENT] Updated: monotone-1.0-1
Version 1.0-1 of monotone has been uploaded. monotone is a free distributed version control system. it provides a simple, single-file transactional version store, with fully disconnected operation and an efficient peer-to-peer synchronization protocol. You can find information about new features here: http://monotone.ca/NEWS You can find information about upgrading from previous releases here: http://monotone.ca/UPGRADE If you're not sure what version do you have you can use the following command to both check version number and integrity of the install: % cygcheck -c monotone *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO *** If you want to unsubscribe from the cygwin-announce mailing list, look at the List-Unsubscribe: tag in the email header of this message. Send email to the address specified there. It will be in the format: cygwin-announce-unsubscribe-you=yourdomain@cygwin.com If you need more information on unsubscribing, start reading here: http://sourceware.org/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. -- Lapo Luchini -- 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: strace swallows stderr?
On May 9 14:12, Ryan Johnson wrote: Hi all, It seems that when strace is running an app, that app's stderr output disappears. Indeed. I never even tried to find out why. http://cygwin.com/acronyms/#PTC :) 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: difficulties with snapshots
On May 9 16:02, EXCOFFIER Denis wrote:
Hello,
This one is a follow-up of http://cygwin.com/ml/cygwin/2011-05/msg00042.html
On 2011-05-05 11:19:56 -0400, Christopher Faylor wrote:
On Thu, May 05, 2011 at 10:47:39AM +0200, EXCOFFIER Denis wrote:
2) More importantly, i was not able to compile snapshots since about
beginning of May, with an error: wchar.h not found (in lsaauth).
The snapshot 20110420 has compiled correctly at that time (say: 21/4);
but i was not able to recompile it recently. You must know that
i update the cygwin packages every day, therefore the problem probably
comes from a recently added package.
Snapshots are provided as-is. If you can't compile it then PTC.
Please consider this hideous patch thoughtfully, it solves my wchar.h not
found problem in lsaauth, and the full cygwin tree now compiles ok
like before.
diff -cNr cygwin-snapshot-20110506-1/winsup/lsaauth/Makefile.in
cygwin-snapshot-20110506-2/winsup/lsaauth/Makefile.in
*** cygwin-snapshot-20110506-1/winsup/lsaauth/Makefile.in
2011-04-07 08:09:27.0 +0159
--- cygwin-snapshot-20110506-2/winsup/lsaauth/Makefile.in
2011-05-09 15:44:13.476681300 +0159
***
*** 29,35
CC := @CC@
CC_FOR_TARGET := $(CC)
! override CC := @NO_CYGWIN@ $(firstword ${CC})
CFLAGS := @CFLAGS@
--- 29,35
CC := @CC@
CC_FOR_TARGET := $(CC)
! #override CC := @NO_CYGWIN@ $(firstword ${CC})
CFLAGS := @CFLAGS@
Thanks. I applied this patch together with another patch which gets
rid of the #include wchar.h entirely.
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: Who's using CYGWIN=tty and why?
Corinna Vinschen sent the following at Monday, May 09, 2011 12:10 PM Chris and I are wondering how many people are using the Windows console as local console window in CYGWIN=tty mode and why. I've been using it for so long that I do not remember why - probably because I thought it was recommended. I did some testing yesterday and found that with CYGWIN=tty each console gets a unique number, as visible in /bin/tty, ps, and $(cat /proc/$$/ctty). Without it, one gets con (tty and ps) or a long, nonunique number (/proc). I use the tty number to keep track of console windows. The above testing was in console where the shortcut launches bash directly, without use of a batch file. In the past, I've played with minty and haven't felt the need to switch. I did an abbreviated test (just ps) with minty and it had tty numbers without CYGWIN=tty. So although I'd like the Windows/DOS console retain the ability to be tracked, I could switch to minty if I had to. Best wishes, - Barry Disclaimer: Statements made herein are not made on behalf of NIAID.
Re: Who's using CYGWIN=tty and why?
Christopher wrote: Ok, it sounds like there is no need whatsoever to set CYGWIN=tty with brltty. That is good news. According to what Ken wrote, emacs won't work as well. This would be very distressing, though I haven't verified it personally. I'd be pretty surprised if it was the case since if CYGWIN=tty *was* required then it seems like mintty would work too since the difference between the ptys that mintty uses and CYGWIN=tty mode is very small. According to one whole trial it's large enough to convince brltty not to deal with the window. This is suggestive but hardly conclusive. I'll try again... Has anyone tried running brltty without setting CYGWIN=tty? Just now. So far I haven't noticed any problems but this is even less significant. I guess notty was meant to say that tty should not be mentioned at all in the $CYGWIN variable. I'll remove it and see what happens. -- Lee Maschmeyer Wayne State University Computing Center 5925 Woodward, #281 Detroit MI 48202 USA -- 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: Who's using CYGWIN=tty and why?
Samuel, On May 9 22:23, Samuel Thibault wrote: Christopher Faylor, le Mon 09 May 2011 16:05:24 -0400, a écrit : Has anyone tried running brltty without setting CYGWIN=tty? I never set the CYGWIN variable nowadays, actually, and brltty works fine in that case. do you happen to know why brltty doesn't work with mintty? Is there a chance to make this work? 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
how to use windres.exe without installing cygwin?
Hi I write a script using windres.exe and want to distribute it. But I couldn't find which files schould I include in my package. It seems that windres.exe calls sh.exe and sh.exe calls gcc.exe. At first I deleted cygwin path from environment variable and copied following files in script folder. /bin/cyggcc_s-1.dll /bin/cyggmp-3.dll /bin/cygiconv-2.dll /bin/cygintl-8.dll /bin/cygmpfr-1.dll /bin/cygncursesw-10.dll /bin/cygreadline7.dll /bin/cygwin1.dll /bin/gcc-3.exe /bin/gcc-4.exe /bin/gcc.exe /bin/sh.exe /bin/windres.exe /etc/alternatives/* /lib/gcc/* Then it worked in my computer(win7). But when I tried to test in other computer(vista), it did not work, and put out following error: /bin/sh: /usr/bin/gcc: cannot execute binary file /usr/bin/windres: preprocessing failed. I tried also in cmd.exe following line, but occurred same error. c:\copiedcygwin\bin\windres.exe a.rc -o a.res For the test I copied all files under the cygwin folder from Win7 to Vista. But it does not work still. I know if I install cygwin from setup.exe to Vista, then I can use windres.exe. But I don't want to let all users to install cygwin. Is there someone who knows how to include windres.exe in a software without installing cygwin? %-| thanks -- View this message in context: http://old.nabble.com/how-to-use-windres.exe-without-installing-cygwin--tp31586006p31586006.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: Who's using CYGWIN=tty and why?
On 09-05-2011 18:10, Corinna Vinschen wrote: Chris and I are wondering how many people are using the Windows console as local console window in CYGWIN=tty mode and why. I have, perhaps unnecessarily, tty defined (as well as ntsec). My typical use of cygwin involves opening a cygwin window using a desktop shortcut (link til bat file): @echo off C: chdir C:\cygwin\bin bash --login -i I generelly use command line editing a lot (is tty necessary for that?). My other use is to open a Command window using windows explorer to have it change directory to the shown directory (shift-right click-Open Command Windows Here). From that windows I type C:\cygwin\bin\bash -l to get a cygwin prompt. There I type cd - to get back to the chosen directory to perform whatever task I need (mostly grep, find, running make, again some command line editing, rarely using an editor). If tty doesn't make a difference for my use, I have little objection to removing it. Bernhard -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: how to use windres.exe without installing cygwin?
On May 10 07:23, ironsand wrote: Hi I write a script using windres.exe and want to distribute it. I assume you are aware that all these tools including Cygwin are under the GPL and so you have to provide the sources of all tools and DLLs together with the binaries, right? But I couldn't find which files schould I include in my package. [...] I know if I install cygwin from setup.exe to Vista, then I can use windres.exe. But I don't want to let all users to install cygwin. Is there someone who knows how to include windres.exe in a software without installing cygwin? %-| You can't. Windres is a Cygwin tool using the Cygwin DLL. Gcc is a Cygwin tool using the Cygwin DLL. Either you provide *all* the stuff required to run the script (and don't forget to provide the sources as well), or you let the user install Cygwin via setup.exe. This is the preferred method anyway. 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: Who's using CYGWIN=tty and why?
On 5/10/2011 09:50, Bernhard Ege wrote: I generelly use command line editing a lot (is tty necessary for that?). General command line usage doesn't require the setting. If in doubt though, remove the setting and try things out for a bit. You'll probably find that nothing changes for your usage, but it's possible you have a use case no one else considered yet. My other use is to open a Command window using windows explorer to have it change directory to the shown directory (shift-right click-Open Command Windows Here). From that windows I type C:\cygwin\bin\bash -l to get a cygwin prompt. There I type cd - to get back to the chosen directory to perform whatever task I need (mostly grep, find, running make, again some command line editing, rarely using an editor). You should check out the chere package. It will allow you to directly open a Cygwin shell from the context menu rather than jump through the hoops you're doing 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: Who's using CYGWIN=tty and why?
On 10 May 2011 15:08, Corinna Vinschen wrote: Samuel, On May 9 22:23, Samuel Thibault wrote: Christopher Faylor, le Mon 09 May 2011 16:05:24 -0400, a écrit : Has anyone tried running brltty without setting CYGWIN=tty? I never set the CYGWIN variable nowadays, actually, and brltty works fine in that case. do you happen to know why brltty doesn't work with mintty? Is there a chance to make this work? On 9 May 2011 18:40, Lee Maschmeyer wrote: BRLTTY is a screen reading system that enables the use of refreshable braille devices (see below). It works on Linux and other unixes both in console mode and as an adjunct to the Unix GUI screen reader (Orca). It also works at the DOS command prompt, and gloriously beautifully in Cygwin. I tried mintty once and brltty would not read that window. Whether this can be changed by the developers I don't know. I've sporadically tried things like rxvt and when they didn't work right off the bat I didn't bother anymore since brltty is really splendid. I've had a quick look at the brltty source and documentation, in particular the chapter on supported screen drivers at [1]. Brltty requires access to the full screen buffer of a console or terminal. The Cygwin and native Windows versions of brltty default to using the Windows console API to access the screen buffer of console windows. Mintty, rxvt, and others of course aren't based on Windows consoles, so that method won't work there. And since there's no documented or otherwise obvious way for third party programs to implement the Windows console API, this is a dead end. However, brltty also has a driver for cooperating with GNU Screen, which can be enabled with the option '-x sn' . This requires a patch to Screen though that makes its screen buffers available to brltty via shared memory. With that, it ought to be possible to make brltty work with any terminal emulator, plus you'd get the added features of Screen. Andy [1] http://mielke.cc/brltty/doc/Manual-BRLTTY/English/BRLTTY-11.html -- 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: Who's using CYGWIN=tty and why?
On 5/10/2011 9:39 AM, Lee Maschmeyer wrote: Just now. So far I haven't noticed any problems but this is even less significant. I guess notty was meant to say that tty should not be mentioned at all in the $CYGWIN variable. I'll remove it and see what happens. Maybe it's not clear, but most $CYGWIN elements can be prefixed by no to turn them off. E.g. acl vs noacl, envcache/noenvcache, tty/notty, etc. Now, obviously, these settings ALSO have a default value -- and usually that value is off, so...in effect, no[tty,envcache,etc] are no-ops. -- Chuck -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: how to use windres.exe without installing cygwin?
On 5/10/2011 10:51 AM, Corinna Vinschen wrote: On May 10 07:23, ironsand wrote: Is there someone who knows how to include windres.exe in a software without installing cygwin? %-| You can't. Windres is a Cygwin tool using the Cygwin DLL. Gcc is a Cygwin tool using the Cygwin DLL. Either you provide *all* the stuff required to run the script (and don't forget to provide the sources as well), or you let the user install Cygwin via setup.exe. This is the preferred method anyway. Well, OUR windres is a cygwin tool. You can, of course, use the mingw.org or mingw64.sf version of windres. They each have their own list(s) of dependencies, but cygwin1.dll is not one of them. They don't grok cygwin's unix paths, tho. And, as always, the binutils tools (incl. windres) are GPL, so if you distribute the windres binary you must also distribute the binutils source code. -- Chuck -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Who's using CYGWIN=tty and why?
There is no need for CYGWIN=tty as far as my use of brltty is concerned. I can still run c:\cygwin\cygwin.bat having taken out the tty from the CYGWIN var. If I discover massive emacs malfunctions I can always defect to the vim camp. :-) I'm curious why the tty command in mintty reports /dev/ttyn but that's by-the-by and probably belongs in a different thread anyway. -- Lee Maschmeyer Wayne State University Computing Center 5925 Woodward, #281 Detroit MI 48202 USA -- 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
All clear (was Re: Don't use 2011-05-05 22:37:25 UTC snapshot)
On Fri, May 06, 2011 at 10:43:12AM -0400, Christopher Faylor wrote: Last night's snapshot has a revamp of some of the tty/console handling. It worked fine on my Windows 7 x64 system but apparently I was just lucky. Please don't use it until you hear from me that things are fixed. Any tty/console handling problems that were in this snapshot should now be fixed. So it is ok to start using snapshots again. cgf -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Who's using CYGWIN=tty and why?
On Tue, May 10, 2011 at 09:37:43AM -0400, Buchbinder, Barry (NIH/NIAID) [E] wrote: Corinna Vinschen sent the following at Monday, May 09, 2011 12:10 PM Chris and I are wondering how many people are using the Windows console as local console window in CYGWIN=tty mode and why. I've been using it for so long that I do not remember why - probably because I thought it was recommended. I did some testing yesterday and found that with CYGWIN=tty each console gets a unique number, as visible in /bin/tty, ps, and $(cat /proc/$$/ctty). Without it, one gets con (tty and ps) or a long, nonunique number (/proc). I use the tty number to keep track of console windows. If we changed the /dev/console to /dev/consN (where N is a unique number for each console window) would that address your use case? You would not be able to do something like echo foo /dev/cons4 and have foo be echoed another console window though. In the past, I've played with minty and haven't felt the need to switch. I did an abbreviated test (just ps) with minty and it had tty numbers without CYGWIN=tty. I think Corinna and I both suffered from the misperception that people were familiar with Cygwin's handling of ttys. mintty uses ptys. Cygwin's ttys and ptys are pretty much the same thing. Cygwin ttys have some extra handshaking which slows down I/O somewhat wrt ptys. And, using CYGWIN=tty means setting up extra threads in the first process starting in a console window. So, yes, you'll see /dev/ttyN as the controlling terminal in a tty application. It was in a discussion with Corinna where I was contemplating eliminating the handshaking that Corinna asked the fateful Why do we need CYGWIN=tty question. Eliminating the special case of tty handling would simplify the cygwin pty layer, shrink the size of the DLL, and generally make Cygwin a little easier to maintain. cgf -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Cygwin 1.7.x on Windows 7: Exit statuses of Win32 executables are sometimes wrong
I can still reproduce this on the latest snapshot. I also tried some different
hardware and virtual machines too, and I don't think my machine is to blame.
Has anyone else been able to reproduce this bug? Or have pointers of further
things I can do to diagnose it?
Thanks in advance,
John
On Apr 29, 2011, at 11:35 AM, John Dong wrote:
Hi,
Cygwin on Windows 7, seems to exhibit a rather peculiar behavior: Sometimes
the exit status of a Win32 process is incorrectly captured by Cygwin.
I'm running Cygwin 1.7.9(0.237/5/3) on Windows 7 64-bit, but I've reproduced
this behavior with every release of Cygwin 1.7 on both 32-bit and 64-bit
Windows 7. It does not seem to happen in XP 32-bit, and I've not tried any
other environments.
To reproduce, first I wrote a Win32 console application (using Visual Studio
2010 / cl.exe version 16 as my compiler) that exits with the status the user
passes in:
int _tmain(int argc, _TCHAR* argv[])
{
int ret = _ttoi(argv[1]);
_tprintf(_T(Exiting with %i\n), ret);
return ret;
}
Then, I wrote a shell script that called this executable (exiter.exe) with
argument 0 in an infinite loop:
#!/bin/sh
set -e
while true; do
/cygdrive/c/exiter.exe 0
echo $?
done
I expect this script to run forever, as the exit code should always be zero.
However, after running this overnight, I see the script terminate:
Exiting with 0
0
Exiting with 0
0
Exiting with 0
0
Exiting with 0
0
Exiting with 0
$ echo $?
1
The last line of output implies that exiter.exe executed return 0, but
/bin/sh saw a nonzero exit status (of 1) and thus stopped execution due to -e.
Reproducing this seems nondeterministic -- sometimes I can get it to happen
in 5 minutes, other times it takes overnight. I've tried using a different
shell (like dash), but it doesn't make a difference, leading me to suspect
this to be a lower-level issue within the Cygwin DLL. It also seems to not
happen for non-zero exit codes (e.g. checking that exiter.exe 1 returns 1
always seems to succeed), though I'm not 100% confident that I've tested this
thoroughly enough.
Again, I've not been able to reproduce this under Windows XP using any
version of Cygwin, but I have been able to reproduce it on both 32-bit and
64-bit Windows 7. I'm not running anything special on this machine -- it's a
fresh install of Windows 7 Professional, just with Cygwin installed.
Thanks in advance,
John
--
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: Who's using CYGWIN=tty and why?
On Tue, May 10, 2011 at 01:18:47PM -0400, Christopher Faylor wrote: starting in a console window. So, yes, you'll see /dev/ttyN as the controlling terminal in a tty application. pty/tty cgf -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: All clear (was Re: Don't use 2011-05-05 22:37:25 UTC snapshot)
On 10 May 2011 12:56, Christopher Faylor wrote: On Fri, May 06, 2011 at 10:43:12AM -0400, Christopher Faylor wrote: Last night's snapshot has a revamp of some of the tty/console handling. It worked fine on my Windows 7 x64 system but apparently I was just lucky. Please don't use it until you hear from me that things are fixed. Any tty/console handling problems that were in this snapshot should now be fixed. So it is ok to start using snapshots again. Does this include the 2011-05-06 snapshot, or should I wait until the next one is generated? Thank you, Chris -- Chris Sutcliffe http://emergedesktop.org http://www.google.com/profiles/ir0nh34d -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: GNU screen on Cygwin: Cannot seem to reattach, no matter what I try
Hi, Andrew: Thanks for the help, and for pointing me to this cygwin list! 1. Output of 'cygcheck -svr' appended to the end of this message. 2. I have the problem whether I run GNU screen from a cmd.exe prompt or under rxvt. I tried Peter Li's suggestion of trying to run screen under mintty -- still no joy. It does not matter if I running GNU screen from the console or if I'm logged in remotely, or if I try to detach and re-attach from the same tty or different ones. All efforts yield the same result: GNU screen cannot find anything to which to re-attach, even a session that I detached on the same tty just seconds before. 3. chmod 666 on the socket file did not work (its permissions were already 644, owned my 'morse', as shown in my original session long). HOWEVER, I am wondering: my Cygin /tmp *IS* on a FAT32 filesystem, *NOT* an NTFS filesystem. Would that matter? Are socket files properly handled by Cygwin on FAT32? (I've never used a socket-based Cygwin program on this host before, at least not to my knowledge.) Thanks, Doug On 05/08/2011 04:12 PM, Andrew Schulman wrote: Hi Doug. Thanks so much for your efforts to port and maintain the GNU screen program to Cygwin! I used to use screen all the in the pre-GUI days, and now I use ssh regularly for the occasions I need to run something on a real win32 or win64 platform. Being able to use screen again would be great, especially because I routinely get disconnected from one machine in particular due to a lousy DSL line. At any rate, although I can run screen just fine, I cannot reattach, no matter what I do, even when there's been no disconnect and I've simply manually detached (i.e., Ctrl-A d). The session log below pretty much says it all. Note that I move my .screenrc file out of the way to ensure I'm running with nothing but default settings. Also, you'll notice in the output from ps aux that the screen process, once detached, has a tty value of ?, whereas all the others have a tty number. Other than this, though, everything works just as one would expect. Processes continue to run fine under screen even when detached: I simply just cannot reattach. As you can also see below, doing a kill -15 on screen causes it do a proper shutdown and remove the socket file. snip - begin session log - morse@dougsdell ~ screen --version Screen version 4.00.03 (FAU) 23-Oct-06 morse@dougsdell ~ uname -a CYGWIN_NT-5.1 dougsdell 1.7.9(0.237/5/3) 2011-03-29 10:10 i686 Cygwin morse@dougsdell ~ mv .screenrc screenrc morse@dougsdell ~ screen [--- I press Ctrl-A d here ] [detached] morse@dougsdell ~ screen -r There is a screen on: There is no screen to be resumed. morse@dougsdell ~ screen -ls There is a screen on: 1 Socket in /tmp/uscreens/S-morse. morse@dougsdell ~ l /tmp/uscreens/S-morse/ total 16 srw-r--r-- 1 morse None 0 May 7 15:45 3932.tty1.dougsdell morse@dougsdell ~ screen -r 3932.tty1.dougsdell There is a screen on: There is no screen to be resumed matching 3932.tty1.dougsdell. morse@dougsdell ~ ps aux PIDPPIDPGID WINPID TTY UIDSTIME COMMAND 2396 12396 2396 con 1005 22:59:53 /usr/bin/rxvt I241223962412 24280 1005 22:59:53 /usr/bin/bash 208034082080 17801 1005 15:41:47 /usr/bin/bash 3932 13932 3932? 1005 15:45:49 /usr/bin/screen I337639323376 34602 1005 15:45:49 /usr/bin/bash 216820802168 22121 1005 15:46:32 /usr/bin/ps morse@dougsdell ~ kill -15 3932 morse@dougsdell ~ ps aux PIDPPIDPGID WINPID TTY UIDSTIME COMMAND 2396 12396 2396 con 1005 22:59:53 /usr/bin/rxvt I241223962412 24280 1005 22:59:53 /usr/bin/bash 208034082080 17801 1005 15:41:47 /usr/bin/bash 222820802228 20761 1005 15:46:45 /usr/bin/ps morse@dougsdell ~ screen -ls No Sockets found in /tmp/uscreens/S-morse. morse@dougsdell ~ l /tmp/uscreens/S-morse/ total 0 morse@dougsdell ~ echo help! :) help! :) - end session log - Sorry you're having trouble. I have a few suggestions/comments: * Please send output of `cygcheck -svr`, so we can see that your installation is complete. * A TTY value of ? in ps is normal for the background screen process. * Read /usr/share/doc/screen/README.Cygwin - there are descriptions there of known problems with reattachment. But mostly it has to do with using screen in a DOS terminal. * What terminal types are you using? rxvt and ssh login? Any others? Do you have the same problem with local vs. remote login, and different local terminal types? * On my host, where screen works fine, the permissions on the socket are 0600. Does 'chmod 0600 /tmp/uscreens/S-morse/*' allow you to reattach? All of this is pretty thin.
Re: All clear (was Re: Don't use 2011-05-05 22:37:25 UTC snapshot)
On Tue, May 10, 2011 at 02:43:13PM -0400, Chris Sutcliffe wrote: On 10 May 2011 12:56, Christopher Faylor wrote: On Fri, May 06, 2011 at 10:43:12AM -0400, Christopher Faylor wrote: Last night's snapshot has a revamp of some of the tty/console handling. It worked fine on my Windows 7 x64 system but apparently I was just lucky. ?Please don't use it until you hear from me that things are fixed. Any tty/console handling problems that were in this snapshot should now be fixed. ?So it is ok to start using snapshots again. Does this include the 2011-05-06 snapshot, or should I wait until the next one is generated? The snapshot that is there now has the fix. cgf -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: GNU screen on Cygwin: Cannot seem to reattach, no matter what I try
1. Output of 'cygcheck -svr' appended to the end of this message. Thanks, looks okay. 2. I have the problem whether I run GNU screen from a cmd.exe prompt or under rxvt. I tried Peter Li's suggestion of trying to run screen under mintty -- still no joy. It does not matter if I running GNU screen from the console or if I'm logged in remotely, or if I try to detach and re-attach from the same tty or different ones. All efforts yield the same result: GNU screen cannot find anything to which to re-attach, even a session that I detached on the same tty just seconds before. 3. chmod 666 on the socket file did not work (its permissions were already 644, owned my 'morse', as shown in my original session long). No, I suggested that you try 0600, on the theory that your 0640 permissions might be too permissive, and screen would refuse to use the socket. Unlikely, but worth a try. However, if your socket is on a FAT file system, I don't know if you can set 0600 permissions. HOWEVER, I am wondering: my Cygin /tmp *IS* on a FAT32 filesystem, *NOT* an NTFS filesystem. Would that matter? Are socket files properly handled by Cygwin on FAT32? (I've never used a socket-based Cygwin program on this host before, at least not to my knowledge.) Hm, that could explain it. I don't recall this coming up before. Looking at screen(1), it says that sockets can go in any mode 0700 directory, and that you can set that in $SCREENDIR. So, I suggest trying the following in order: (1) Run chmod 0700 /tmp/uscreens/S-morse chmod 0600 /tmp/uscreens/S-morse/* then try to reattach. (2) If you can't set the above permissions because /tmp is on a FAT file system, then find an NTFS directory and run export SCREENDIR=/path/to/ntfs/directory then start a new screen session, and see if you can reattach to it. -- 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: Who's using CYGWIN=tty and why?
This time with a subject; apologies if the first one gets through. We use windows native jam which spawns any number of cmd, cygwin, or studio processes. If we spawn it from a Cygwin terminal that doesn't have CYGWIN=tty set, we get: The handle is invalid. Every time output goes to the screen. If we use CYGWIN=tty, we get normal output. The only way I've figured out how to fix this is with CYGWIN=tty. If there is a better way, please enlighten me. -Len -- 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
determining what user mounted a drive
Is there a way of determining with what user credentials a share was mounted? I suppose I could touch a file on the drive and then find out who the owner is, but that's not ideal. mount will tell me that it's a user mount, but won't tell me WHICH user. Is there some way (windows native or Cygwin) of getting this information? -Len -- 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: determining what user mounted a drive
On 5/10/2011 16:25, Len Giambrone wrote: Is there a way of determining with what user credentials a share was mounted? I suppose I could touch a file on the drive and then find out who the owner is, but that's not ideal. mount will tell me that it's a user mount, but won't tell me WHICH user. Is there some way (windows native or Cygwin) of getting this information? Are you asking about shares mapped to drive letters using a Windows-native process such as net use, or are you asking about shares mapped to Cygwin paths using the mount command? -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: determining what user mounted a drive
Len Giambrone sent the following at Tuesday, May 10, 2011 5:25 PM Is there a way of determining with what user credentials a share was mounted? I suppose I could touch a file on the drive and then find out who the owner is, but that's not ideal. mount will tell me that it's a user mount, but won't tell me WHICH user. Is there some way (windows native or Cygwin) of getting this information? I do not know but here is a guess. Wouldn't any user mount be that of the current user? Isn't that the point of user mounts - I only see my own? And if I'm root, I only see system mounts? And if you want to see the user mounts of individual users, according to the UG http://cygwin.com/cygwin-ug-net/using.html#mount-table, that should be in /etc/fstab.d/user_name. Otherwise, what about the following? $ stat -c %U /mount_point But if you are talking about, something that happened before a cygwin process was lanched, I think you want to use the word mapped, not mounted and I can't say much more than that. - Barry Disclaimer: Statements made herein are not made on behalf of NIAID. -- 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: Who's using CYGWIN=tty and why?
Christopher Faylor sent the following at Tuesday, May 10, 2011 1:19 PM If we changed the /dev/console to /dev/consN (where N is a unique number for each console window) would that address your use case? Yes, it works for me if there would be a reasonably small (preferably single digit) number in the output of tty or ps. You would not be able to do something like echo foo /dev/cons4 and have foo be echoed another console window though. Since I haven't been on a real Unix/POSIX machine since the late '80s, I'd forgotten about that. Now you made me want to DO it! :-) Eliminating the special case of tty handling would simplify the cygwin pty layer, shrink the size of the DLL, and generally make Cygwin a little easier to maintain. Even if you don't accommodate me, that's OK, if your lives will be easier. As I wrote, if I find that I really miss tty identification, I can learn to use mintty. (Or maybe I should just switch - but not today.) Thank to you all for your work on cygwin. - Barry Disclaimer: Statements made herein are not made on behalf of NIAID. -- 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: Who's using CYGWIN=tty and why?
On Tue, May 10, 2011 at 06:11:35PM -0400, Buchbinder, Barry (NIH/NIAID) [E] wrote: Christopher Faylor sent the following at Tuesday, May 10, 2011 1:19 PM If we changed the /dev/console to /dev/consN (where N is a unique number for each console window) would that address your use case? Yes, it works for me if there would be a reasonably small (preferably single digit) number in the output of tty or ps. Yep. That is the plan. You would not be able to do something like echo foo /dev/cons4 and have foo be echoed another console window though. Since I haven't been on a real Unix/POSIX machine since the late '80s, I'd forgotten about that. Now you made me want to DO it! :-) Heh. I knew I shouldn't have mentioned it. This was actually one of the first things that impressed me about Cygwin when I first started using it. Of course, when I first started it only worked about half the time, but still... The way I'm implementing this you should be able if /dev/consN is actually associated with a console but you won't be able to do anything other than verify existence. Eliminating the special case of tty handling would simplify the cygwin pty layer, shrink the size of the DLL, and generally make Cygwin a little easier to maintain. Even if you don't accommodate me, that's OK, if your lives will be easier. As I wrote, if I find that I really miss tty identification, I can learn to use mintty. (Or maybe I should just switch - but not today.) I actually have the /dev/conssmall number about 3/4 finished. If we do decide to get rid of CYGWIN=tty then /dev/cons may become /dev/ttysmall number again and ptys will become /dev/ptysmall number. 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
Updated: monotone-1.0-1
Version 1.0-1 of monotone has been uploaded. monotone is a free distributed version control system. it provides a simple, single-file transactional version store, with fully disconnected operation and an efficient peer-to-peer synchronization protocol. You can find information about new features here: http://monotone.ca/NEWS You can find information about upgrading from previous releases here: http://monotone.ca/UPGRADE If you're not sure what version do you have you can use the following command to both check version number and integrity of the install: % cygcheck -c monotone *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO *** If you want to unsubscribe from the cygwin-announce mailing list, look at the List-Unsubscribe: tag in the email header of this message. Send email to the address specified there. It will be in the format: cygwin-announce-unsubscribe-you=yourdomain@cygwin.com If you need more information on unsubscribing, start reading here: http://sourceware.org/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. -- Lapo Luchini
