Re: can I buy some telephone support to get some questions answered?
No. This is a free software project, staffed by volunteers. As mentioned on the cygwin web site, http://cygwin.com/, the only way to get support is via the cygwin or cygwin-xfree mailing lists. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
can I buy some telephone support to get some questions answered?
-- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
src/winsup/cygwin ChangeLog thread.cc
CVSROOT:/cvs/src Module name:src Changes by: yselkow...@sourceware.org 2011-12-30 00:47:13 Modified files: winsup/cygwin : ChangeLog thread.cc Log message: * thread.cc: Mark pthread_rwlock_timedrdlock and pthread_rwlock_timedwrlock as not yet implemented in the list of cancellation points. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/ChangeLog.diff?cvsroot=srcr1=1.5647r2=1.5648 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/thread.cc.diff?cvsroot=srcr1=1.250r2=1.251
[PATCH] Fix cancellation points list
pthread_rwlock_timedrdlock and pthread_rwlock_timedwrlock aren't implemented yet. Patch attached. Yaakov 2011-12-30 Yaakov Selkowitz yselkowitz@... * thread.cc: Mark pthread_rwlock_timedrdlock and pthread_rwlock_timedwrlock as not yet implemented in the list of cancellation points. Index: thread.cc === RCS file: /cvs/src/src/winsup/cygwin/thread.cc,v retrieving revision 1.250 diff -u -p -r1.250 thread.cc --- thread.cc 22 Dec 2011 11:02:36 - 1.250 +++ thread.cc 30 Dec 2011 06:22:45 - @@ -810,8 +810,8 @@ pthread::cancel () psiginfo () psignal () pthread_rwlock_rdlock () - pthread_rwlock_timedrdlock () - pthread_rwlock_timedwrlock () +o pthread_rwlock_timedrdlock () +o pthread_rwlock_timedwrlock () pthread_rwlock_wrlock () putc () putc_unlocked ()
Re: [PATCH] Fix cancellation points list
On Fri, Dec 30, 2011 at 12:25:25AM -0600, Yaakov (Cygwin/X) wrote: pthread_rwlock_timedrdlock and pthread_rwlock_timedwrlock aren't implemented yet. Patch attached. Yaakov 2011-12-30 Yaakov Selkowitz yselkowitz@... * thread.cc: Mark pthread_rwlock_timedrdlock and pthread_rwlock_timedwrlock as not yet implemented in the list of cancellation points. Please apply. Thanks. cgf
[PATCH] Add getpt(3)
getpt(3) is a GNU extension which predates posix_openpt(3):
http://www.kernel.org/doc/man-pages/online/pages/man3/getpt.3.html
The code itself is quite simple, but let me preempt some questions:
1) Yes, portable code should use posix_openpt(3). Unfortunately not all
code is written with portability in mind.
2) A macro is insufficient as it will not be discovered by an Autoconf
AC_CHECK_FUNC or CMake CHECK_FUNCTION_EXISTS test (which is exactly how
I came across this issue in the first place).
Patches for winsup/cygwin and winsup/doc attached.
Yaakov
2011-12-30 Yaakov Selkowitz yselkowitz@...
* cygwin.din (getpt): Export.
* posix.sgml (std-gnu): Add getpt.
* tty.cc (getpt): New function.
* include/cygwin/stdlib.h [!__STRICT_ANSI__] (getpt): Declare.
* include/cygwin/version.h (CYGWIN_VERSION_API_MINOR): Bump.
Index: cygwin.din
===
RCS file: /cvs/src/src/winsup/cygwin/cygwin.din,v
retrieving revision 1.249
diff -u -p -r1.249 cygwin.din
--- cygwin.din 7 Nov 2011 20:05:48 - 1.249
+++ cygwin.din 17 Nov 2011 01:29:52 -
@@ -759,6 +759,7 @@ getprogname NOSIGFE
getprotobyname = cygwin_getprotobyname SIGFE
getprotobynumber = cygwin_getprotobynumber SIGFE
getprotoent = cygwin_getprotoent SIGFE
+getpt SIGFE
getpwduid NOSIGFE
_getpwduid = getpwduid NOSIGFE
getpwent SIGFE
Index: posix.sgml
===
RCS file: /cvs/src/src/winsup/cygwin/posix.sgml,v
retrieving revision 1.72
diff -u -p -r1.72 posix.sgml
--- posix.sgml 8 Nov 2011 09:24:58 - 1.72
+++ posix.sgml 17 Nov 2011 01:29:52 -
@@ -1116,6 +1116,7 @@ also IEEE Std 1003.1-2008 (POSIX.1-2008)
get_nprocs_conf
getopt_long
getopt_long_only
+getpt
getxattr
lgetxattr
listxattr
Index: tty.cc
===
RCS file: /cvs/src/src/winsup/cygwin/tty.cc,v
retrieving revision 1.91
diff -u -p -r1.91 tty.cc
--- tty.cc 30 Oct 2011 04:50:35 - 1.91
+++ tty.cc 17 Nov 2011 01:29:53 -
@@ -26,6 +26,12 @@ details. */
HANDLE NO_COPY tty_list::mutex = NULL;
extern C int
+getpt (void)
+{
+ return open (/dev/ptmx, O_RDWR | O_NOCTTY);
+}
+
+extern C int
posix_openpt (int oflags)
{
return open (/dev/ptmx, oflags);
Index: include/cygwin/stdlib.h
===
RCS file: /cvs/src/src/winsup/cygwin/include/cygwin/stdlib.h,v
retrieving revision 1.11
diff -u -p -r1.11 stdlib.h
--- include/cygwin/stdlib.h 8 Nov 2011 05:50:18 - 1.11
+++ include/cygwin/stdlib.h 17 Nov 2011 01:29:53 -
@@ -31,6 +31,7 @@ char *setstate (const char *state);
void srandom (unsigned);
char *ptsname (int);
int ptsname_r(int, char *, size_t);
+int getpt (void);
int grantpt (int);
int unlockpt (int);
#endif /*__STRICT_ANSI__*/
Index: include/cygwin/version.h
===
RCS file: /cvs/src/src/winsup/cygwin/include/cygwin/version.h,v
retrieving revision 1.356
diff -u -p -r1.356 version.h
--- include/cygwin/version.h 7 Nov 2011 20:05:49 - 1.356
+++ include/cygwin/version.h 17 Nov 2011 01:29:53 -
@@ -425,12 +425,13 @@ details. */
254: Export getgrouplist.
255: Export ptsname_r.
256: Add CW_ALLOC_DRIVE_MAP, CW_MAP_DRIVE_MAP, CW_FREE_DRIVE_MAP.
+ 257: Export getpt.
*/
/* Note that we forgot to bump the api for ualarm, strtoll, strtoull */
#define CYGWIN_VERSION_API_MAJOR 0
-#define CYGWIN_VERSION_API_MINOR 256
+#define CYGWIN_VERSION_API_MINOR 257
/* There is also a compatibity version number associated with the
shared memory regions. It is incremented when incompatible
2011-12-30 Yaakov Selkowitz yselkowitz@...
* new-features.sgml (ov-new1.7.10): Document getpt.
Index: new-features.sgml
===
RCS file: /cvs/src/src/winsup/doc/new-features.sgml,v
retrieving revision 1.94
diff -u -p -r1.94 new-features.sgml
--- new-features.sgml 13 Dec 2011 03:54:59 - 1.94
+++ new-features.sgml 30 Dec 2011 06:41:31 -
@@ -101,7 +101,7 @@ dlopen now supports the Glibc-specific R
/para/listitem
listitempara
-Other new API: clock_settime, __fpurge, getgrouplist, ppoll, psiginfo,
+Other new API: clock_settime, __fpurge, getgrouplist, getpt, ppoll, psiginfo,
psignal, ptsname_r, sys_siglist, pthread_setschedprio, sysinfo.
/para/listitem
Re: GNU Guile 1.8.7 - readline is not provided
On Thu, 29 Dec 2011, [UTF-8] Róbert Kohányi wrote: Subject: GNU Guile 1.8.7 - readline is not provided Using a fresh installation of Cygwin with GNU Guile (during the install process I've only selected this latter package explicitly) I've tried to use Guile's readline support[1] unsuccessfully. As the documentation told me to, I've created a configuration file (.guile) in my home directory and started Guile, but it raised an error (guile.out) and I don't understand why. I've searched the mailing lists and found a previous release announcement[2] where the package maintainer said that the readline support is OK (although it was a previous release of Guile -- 1.5.x) and listed the required libraries for it to work. During the install all of these libraries were installed by setup.exe transitively (cygcheck.out). Is this a bug in the release or readline support is omitted from Guile's Cygwin version on purpose? If the latter holds it would be nice to know: why?. Can't Guile be build with this feature enabled? Regards, Robert Hi Robert, I had a similar problem recently. I don't know if what you are experiencing is the same or not, but it probably is: Incomplete download and a (to my mind) broken dependency engine. Readline is fundamental, but when it was missing from my download - how, I have NO idea - none of the concluding scripts that are supposed to run after an installation completes actually ran. The solution was easy enough; Do the download part again, and explicitly include readline. Note that this mechanism of reloading also easily verified that that was in fact the problem because it didn't show up in the list of packages to possibly upgrade, delete, or whathaveyou. Merely pointing to a different repository solved the problem. I don't understand how the dependency engine lets this happen, but it does. Good luck, Richard -- Richard Troy, Chief Scientist Science Tools Corporation rt...@sciencetools.com, http://ScienceTools.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
GNU Guile 1.8.7 - readline is not provided
Using a fresh installation of Cygwin with GNU Guile (during the install process I've only selected this latter package explicitly) I've tried to use Guile's readline support[1] unsuccessfully. As the documentation told me to, I've created a configuration file (.guile) in my home directory and started Guile, but it raised an error (guile.out) and I don't understand why. I've searched the mailing lists and found a previous release announcement[2] where the package maintainer said that the readline support is OK (although it was a previous release of Guile -- 1.5.x) and listed the required libraries for it to work. During the install all of these libraries were installed by setup.exe transitively (cygcheck.out). Is this a bug in the release or readline support is omitted from Guile's Cygwin version on purpose? If the latter holds it would be nice to know: why?. Can't Guile be build with this feature enabled? Regards, Robert [1]: http://www.gnu.org/software/guile/docs/docs-1.8/guile-ref/Loading-Readline-Support.html#Loading-Readline-Support [2]: http://sourceware.org/ml/cygwin/2002-07/msg01343.html cygcheck.out Description: Binary data guile Description: Binary data guile.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: Distributed Git not compiled under Cygwin?
On 12/29/2011 04:38 AM, cxira wrote: Jeremy Bopp-3 wrote: I don't see any way around this except to either build your own Git that doesn't include the Cygwin changes or run a git config command to set core.filemode after cloning or initializing a repository. Sorry if I got your hopes up. Hopefully, the Cygwin changes aren't really a problem for you. Thanks a ton, actually. I appreciate the amount of time you spent looking into this. The link you provided answers my question exactly as to why they did it this way, as files created within the Cygwin environment adhere to the expected permissions. I realize now that my problem is more the exception than the rule, as I use the Windows gVim due to the better integration, which creates files with incorrect permissions. It seems that the best solution would be stick to compiling it myself or perhaps investigate to see if I can tweak gVim so that it will save files with the correct permissions. I never had a problem with the native gVim cooperating with Cygwin's Git (more accurately file permissions) either. Can you provide more detail about your situation? How exactly are the permissions broken, and for which application(s) are they broken? -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: Distributed Git not compiled under Cygwin?
Jeremy Bopp-3 wrote: I don't see any way around this except to either build your own Git that doesn't include the Cygwin changes or run a git config command to set core.filemode after cloning or initializing a repository. Sorry if I got your hopes up. Hopefully, the Cygwin changes aren't really a problem for you. Thanks a ton, actually. I appreciate the amount of time you spent looking into this. The link you provided answers my question exactly as to why they did it this way, as files created within the Cygwin environment adhere to the expected permissions. I realize now that my problem is more the exception than the rule, as I use the Windows gVim due to the better integration, which creates files with incorrect permissions. It seems that the best solution would be stick to compiling it myself or perhaps investigate to see if I can tweak gVim so that it will save files with the correct permissions. -- View this message in context: http://old.nabble.com/Distributed-Git-not-compiled-under-Cygwin--tp33047124p33049604.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: Distributed Git not compiled under Cygwin?
Jeremy Bopp-3 wrote: I never had a problem with the native gVim cooperating with Cygwin's Git (more accurately file permissions) either. Can you provide more detail about your situation? How exactly are the permissions broken, and for which application(s) are they broken? Here's what I see: $ gvim temp :wq $ ls -al temp -rwx--+ 1 Doug None 0 Dec 29 15:21 temp Expected: $ touch temp2 $ ls -al temp2 -rw-r--r--+ 1 Doug None 0 Dec 29 15:22 temp2 It isn't a problem that causes a conflict with anything, but if I commit these files to the repository with their file modes as 0700, other people that use the repository may have problems with them (not to mention the show in as green executables in ls). I actually pushed these files to an Apache webserver for production one time and the entire site was not working for a bit because of that. -- View this message in context: http://old.nabble.com/Distributed-Git-not-compiled-under-Cygwin--tp33047124p33052021.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: Distributed Git not compiled under Cygwin?
On 12/29/2011 02:28 PM, cxira wrote: Jeremy Bopp-3 wrote: I never had a problem with the native gVim cooperating with Cygwin's Git (more accurately file permissions) either. Can you provide more detail about your situation? How exactly are the permissions broken, and for which application(s) are they broken? Here's what I see: $ gvim temp :wq $ ls -al temp -rwx--+ 1 Doug None 0 Dec 29 15:21 temp Expected: $ touch temp2 $ ls -al temp2 -rw-r--r--+ 1 Doug None 0 Dec 29 15:22 temp2 It isn't a problem that causes a conflict with anything, but if I commit these files to the repository with their file modes as 0700, other people that use the repository may have problems with them (not to mention the show in as green executables in ls). I actually pushed these files to an Apache webserver for production one time and the entire site was not working for a bit because of that. The execute bit is the only permission that Git actually records: http://book.git-scm.com/1_the_git_object_model.html Unfortunately, it's the only one that's giving you grief here. You might try setting the noacl mount option for the Cygwin mount containing your repository: http://cygwin.com/cygwin-ug-net/using.html#mount-table Another option may be to hack a post-save action into gVim that uses Cygwin's chmod command to remove the execute bit from newly saved files: http://stackoverflow.com/questions/4627701/vim-how-to-execute-automatically-execute-a-shell-command-after-saving-a-file If all else fails, you could also install the Windows-native build of Git and use that instead. Cygwin's gVim may also make sense to use here instead of the native one, but I remember you saying that the native gVim integrates better for what you do. -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
SHELLOPTS=igncr and bash --posix
Some of my bash scripts, particularly ones that are #!/bin/bash --posix trigger a nasty warning when I have SHELLOPTS=igncr set in my ~/.zshrc: rkitover@eeebox ~/src/scala % echo $SHELLOPTS igncr rkitover@eeebox ~/src/scala % bash --posix bash: SHELLOPTS: readonly variable this is rather unsightly so I have turned off SHELLOPTS for now. Is this a bug? If so, is a fix possible? -- 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: Distributed Git not compiled under Cygwin?
Jeremy Bopp-3 wrote:
Another option may be to hack a post-save action into gVim that uses
Cygwin's chmod command to remove the execute bit from newly saved files:
http://stackoverflow.com/questions/4627701/vim-how-to-execute-automatically-execute-a-shell-command-after-saving-a-file
If all else fails, you could also install the Windows-native build of
Git and use that instead. Cygwin's gVim may also make sense to use here
instead of the native one, but I remember you saying that the native
gVim integrates better for what you do.
I moved away from msysgit because it wasn't displaying colors properly in
mintty. As for a vim script, I put together something that executes `chmod
0644` when saving new files only:
Change permissions on new files to be 0644 in cygwin
augroup filePerms
autocmd!
autocmd BufWritePre * call NewFileTest()
augroup END
function! NewFileTest()
if !filereadable(expand('afile'))
If the file cannot be found pre-write, add a post-write command
autocmd filePerms BufWritePost * call NewFileAlter()
endif
endfunction
function! NewFileAlter()
Remove command after it is executed once
autocmd! filePerms BufWritePost
Change permissions
silent execute !C:\\cygwin\\bin\\bash.exe -c \/usr/bin/chmod 0644 ' .
substitute(expand(afile), ^\\(.\\):/, /cygdrive/\\1/, ) . '\
endfunction
There's a very brief appearance of the command prompt when I save a new
file, but I think it's a suitable and portable solution. Thanks for the
help.
--
View this message in context:
http://old.nabble.com/Distributed-Git-not-compiled-under-Cygwin--tp33047124p33052301.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
broke my perlbrewed perl with rebase
I made a perl to test some stuff with perlbrew, a 5.12.0. I installed some CPAN modules into it, then I needed to rebase because of mapping errors. I made a copy of perlrebase and modified it thusly: #!/bin/sh baseaddr=0x5700 perl=`which perl` dll=$(ldd $perl | $perl -anle 'print $F[2] if /cygperl/') echo $dll rebase.lst /usr/bin/find ~/perl5 -name \*.dll rebase.lst /usr/bin/cat rebase.lst | /usr/bin/xargs chmod ug+w [ -e /usr/bin/peflags.exe ] /usr/bin/peflags -t $perl /usr/bin/rebase -v -b $baseaddr -T rebase.lst [ -e /usr/bin/peflags.exe ] /usr/bin/grep \.dll rebase.lst \ | /usr/bin/peflags -d0 -T - /dev/null perlbrew puts its stuff into ~/perl5/perlbrew I ran this script, and now my perlbrewed perl no longer works at all. It exits immediately when I run it, not even perl -v works. This is what I see in gdb `which perl` after doing a run: Starting program: /c/Users/rkitover/perl5/perlbrew/perls/perl-5.12.0/bin/perl [New Thread 8156.0x9ec] [Inferior 1 (process 8156) exited with code 0305] The perlbrew command I used was: perlbrew install -n -j 3 perl-5.12.0 -D DEBUGGING -D optimize=-ggdb3 -D usethreads Did I do something wrong with rebase here? -- 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: Distributed Git not compiled under Cygwin?
On 12/29/2011 03:44 PM, cxira wrote:
I moved away from msysgit because it wasn't displaying colors properly in
mintty. As for a vim script, I put together something that executes `chmod
0644` when saving new files only:
Change permissions on new files to be 0644 in cygwin
augroup filePerms
autocmd!
autocmd BufWritePre * call NewFileTest()
augroup END
function! NewFileTest()
if !filereadable(expand('afile'))
If the file cannot be found pre-write, add a post-write command
autocmd filePerms BufWritePost * call NewFileAlter()
endif
endfunction
function! NewFileAlter()
Remove command after it is executed once
autocmd! filePerms BufWritePost
Change permissions
silent execute !C:\\cygwin\\bin\\bash.exe -c \/usr/bin/chmod 0644 ' .
substitute(expand(afile), ^\\(.\\):/, /cygdrive/\\1/, ) . '\
endfunction
There's a very brief appearance of the command prompt when I save a new
file, but I think it's a suitable and portable solution. Thanks for the
help.
Good stuff. You can avoid the window that pops up by using the run.exe
program to kick off your chmod command rather than bash. It's available
in the run package.
-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: Distributed Git not compiled under Cygwin?
Jeremy Bopp-3 wrote: Good stuff. You can avoid the window that pops up by using the run.exe program to kick off your chmod command rather than bash. It's available in the run package. I think the window is actually cmd.exe since this is a Windows gVim. That said, I switched the bash to run and tried the command prompt start (like in Unix) and it actually doesn't even appear at all now. Beautiful! silent execute !start C:\\cygwin\\bin\\run.exe /usr/bin/chmod 0644 ' . substitute(expand(afile), ^\\(.\\):/, /cygdrive/\\1/, ) . ' -- View this message in context: http://old.nabble.com/Distributed-Git-not-compiled-under-Cygwin--tp33047124p33052477.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: SHELLOPTS=igncr and bash --posix
On 29/12/2011 21:40, Rafael Kitover wrote: Some of my bash scripts, particularly ones that are #!/bin/bash --posix trigger a nasty warning when I have SHELLOPTS=igncr set in my ~/.zshrc: rkitover@eeebox ~/src/scala % echo $SHELLOPTS igncr rkitover@eeebox ~/src/scala % bash --posix bash: SHELLOPTS: readonly variable this is rather unsightly so I have turned off SHELLOPTS for now. Is this a bug? Bug in your script I'm afraid. SHELLOPTS is indeed a readonly variable, it can only be set outside bash before starting it, definitely not from within a startup script. (Perhaps the reason it seems associated with --posix is because that selects different startup files? I'm guessing that you may have ENV=~/.zshrc because it's not normal behaviour for bash to read zsh's startup file!) If so, is a fix possible? Use set -o igncr instead. 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
