Re: guile: please update
On Mon, 2010-09-27 at 02:28 -0500, Yaakov (Cygwin/X) wrote: On Thu, 2010-06-24 at 22:37 -0500, Yaakov (Cygwin/X) wrote: Jan, Would you be able to update your guile package? Some software expect newer versions nowadays, and I found at least one additional variable that needs to be exported. Please feel free to use my work from Ports: http://cygwin-ports.svn.sourceforge.net/viewvc/cygwin-ports/ports/trunk/lang/guile/ Ping? Jan, are you still with us? Yaakov
Re: [ITP] enchant
On Wed, 2010-10-13 at 22:43 -0500, Yaakov (Cygwin/X) wrote: Enchant is a spell checking abstraction library supporting several backends. It is a requirement for several GNOME and KDE components and is already included in Fedora, Debian, and other major distros. ftp://ftp.cygwinports.org/pub/cygwinports/release-2/enchant/ Ping? Yaakov
Re: [ITP] enchant
On Mon, Oct 18, 2010 at 02:52:42PM -0500, Yaakov (Cygwin/X) wrote: On Wed, 2010-10-13 at 22:43 -0500, Yaakov (Cygwin/X) wrote: Enchant is a spell checking abstraction library supporting several backends. It is a requirement for several GNOME and KDE components and is already included in Fedora, Debian, and other major distros. ftp://ftp.cygwinports.org/pub/cygwinports/release-2/enchant/ Ping? It's ok with me. I assume you know how to create good packages so, in absence of any reviews, go ahead and do the appropriate bits. cgf
winsup/cygwin ChangeLog cygwin.din
CVSROOT:/cvs/uberbaum Module name:winsup Changes by: c...@sourceware.org 2010-10-18 15:14:17 Modified files: cygwin : ChangeLog cygwin.din Log message: * winsup/cygwin/cygwin.din: Add llround and llroundf. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/winsup/cygwin/ChangeLog.diff?cvsroot=uberbaumr1=1.5080r2=1.5081 http://sourceware.org/cgi-bin/cvsweb.cgi/winsup/cygwin/cygwin.din.diff?cvsroot=uberbaumr1=1.226r2=1.227
missing math functions
llround and llroundf are available in newlib but not exported in cygwin. http://www.cygwin.com/ml/cygwin/2010-10/msg00351.html simple path attached to solve the problem. changelog: * winsup/cygwin/cygwin.din : added llround and llroundf Regards Marco --- src/winsup/cygwin/cygwin.din 2010-10-08 20:25:00.87500 +0200 +++ src_new/winsup/cygwin/cygwin.din 2010-10-18 14:31:36.453125000 +0200 @@ -960,6 +960,8 @@ llrint = _f_llrint NOSIGFE llrintf = _f_llrintf NOSIGFE llrintl = _f_llrintl NOSIGFE +llround NOSIGFE +llroundf NOSIGFE __locale_mb_cur_max NOSIGFE localeconv NOSIGFE _localeconv = localeconv NOSIGFE
Re: missing math functions
On Mon, Oct 18, 2010 at 04:07:59PM +0100, Marco Atzeri wrote: llround and llroundf are available in newlib but not exported in cygwin. http://www.cygwin.com/ml/cygwin/2010-10/msg00351.html simple path attached to solve the problem. changelog: * winsup/cygwin/cygwin.din : added llround and llroundf --- src/winsup/cygwin/cygwin.din 2010-10-08 20:25:00.87500 +0200 +++ src_new/winsup/cygwin/cygwin.din 2010-10-18 14:31:36.453125000 +0200 @@ -960,6 +960,8 @@ llrint = _f_llrint NOSIGFE llrintf = _f_llrintf NOSIGFE llrintl = _f_llrintl NOSIGFE +llround NOSIGFE +llroundf NOSIGFE __locale_mb_cur_max NOSIGFE localeconv NOSIGFE _localeconv = localeconv NOSIGFE Applied with a tweaked ChangeLog. Thanks again for the patch. cgf
Re: Sending signals to a subprocess
On 16.10.2010 20:17, Ken Brown wrote: I could use some help fixing a longstanding bug in the Cygwin build of emacs, in which emacs is unable to send signals to subprocesses. This off top but I use native Emacs and have annoying bug: in C-x shell if I start cygwin app it can not be broken by C-c C-c (try run 'yes' utility). But while :; do echo +; sleep 1; done can be broken by C-c C-c. Also 'yes' can be broken by C-c C-\ (QUIT). -- 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: Sending signals to a subprocess
On 10/18/2010 4:46 AM, Oleksandr Gavenko wrote: On 16.10.2010 20:17, Ken Brown wrote: I could use some help fixing a longstanding bug in the Cygwin build of emacs, in which emacs is unable to send signals to subprocesses. This off top but I use native Emacs and have annoying bug: in C-x shell if I start cygwin app it can not be broken by C-c C-c (try run 'yes' utility). Yes, this is a known problem with native emacs and is documented in etc/PROBLEMS. But Cygwin emacs will no longer have this problem as of Emacs 23.3. Ken -- 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: -static not working with gcc 4.3.4
From: Samuel Thibault
Hello,
gcc -static doesn't seem to be working any more using gcc 4.3.4:
$ cat test.c
int main(void) {}
$ gcc test.c -o test -static
/usr/lib/gcc/i686-pc-cygwin/4.3.4/../../../../i686-pc-cygwin/bin/ld:
cannot find -lgcc_s
/usr/lib/gcc/i686-pc-cygwin/4.3.4/../../../../i686-pc-cygwin/bin/ld:
cannot find -lgcc_s
There indeed is libgcc_s.dll.a in /usr/lib/gcc/i686-pc-cygwin/, but for
some reason gcc doesn't seem to be happy with it. This is using gcc4
and
gcc4-core 4.3.4-3. gcc-3 works fine.
Samuel
Please, why such a large test case when the following would
have been perfectly adequate to demonstrate the problem?:
$ cat test.c
main() {}
$
--Ken Nellis
Re: -static not working with gcc 4.3.4
Nellis, Kenneth, le Mon 18 Oct 2010 07:45:15 -0500, a écrit :
From: Samuel Thibault
$ cat test.c
int main(void) {}
$ gcc test.c -o test -static
/usr/lib/gcc/i686-pc-cygwin/4.3.4/../../../../i686-pc-cygwin/bin/ld:
cannot find -lgcc_s
/usr/lib/gcc/i686-pc-cygwin/4.3.4/../../../../i686-pc-cygwin/bin/ld:
cannot find -lgcc_s
There indeed is libgcc_s.dll.a in /usr/lib/gcc/i686-pc-cygwin/, but for
some reason gcc doesn't seem to be happy with it. This is using gcc4
and
gcc4-core 4.3.4-3. gcc-3 works fine.
Please, why such a large test case when the following would
have been perfectly adequate to demonstrate the problem?:
$ cat test.c
main() {}
$
Because providing precise information is always better when reporting a
bug, whatever the circumstances.
That being said, I'd still like to see this bug fixed: the -static is
suppoed to be able to work alone.
Samuel
--
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: Sending signals to a subprocess
On 18.10.2010 15:36, Ken Brown wrote: On 10/18/2010 4:46 AM, Oleksandr Gavenko wrote: On 16.10.2010 20:17, Ken Brown wrote: I could use some help fixing a longstanding bug in the Cygwin build of emacs, in which emacs is unable to send signals to subprocesses. This off top but I use native Emacs and have annoying bug: in C-x shell if I start cygwin app it can not be broken by C-c C-c (try run 'yes' utility). Yes, this is a known problem with native emacs and is documented in etc/PROBLEMS. But Cygwin emacs will no longer have this problem as of Emacs 23.3. Did you mean ** Interrupting Cygwin port of Bash from Emacs doesn't work. Cygwin 1.x builds of the ported Bash cannot be interrupted from the MS-Windows version of Emacs. This is due to some change in the Bash port or in the Cygwin library which apparently make Bash ignore the keyboard interrupt event sent by Emacs to Bash. (Older Cygwin ports of Bash, up to b20.1, did receive SIGINT from Emacs.) -- 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: Sending signals to a subprocess
On 10/18/2010 9:12 AM, Oleksandr Gavenko wrote: On 18.10.2010 15:36, Ken Brown wrote: On 10/18/2010 4:46 AM, Oleksandr Gavenko wrote: On 16.10.2010 20:17, Ken Brown wrote: I could use some help fixing a longstanding bug in the Cygwin build of emacs, in which emacs is unable to send signals to subprocesses. This off top but I use native Emacs and have annoying bug: in C-x shell if I start cygwin app it can not be broken by C-c C-c (try run 'yes' utility). Yes, this is a known problem with native emacs and is documented in etc/PROBLEMS. But Cygwin emacs will no longer have this problem as of Emacs 23.3. Did you mean ** Interrupting Cygwin port of Bash from Emacs doesn't work. Cygwin 1.x builds of the ported Bash cannot be interrupted from the MS-Windows version of Emacs. This is due to some change in the Bash port or in the Cygwin library which apparently make Bash ignore the keyboard interrupt event sent by Emacs to Bash. (Older Cygwin ports of Bash, up to b20.1, did receive SIGINT from Emacs.) Yes. But let's not discuss native emacs further. It's off topic for the cygwin list and also for this thread. -- 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: -static not working with gcc 4.3.4
--- Lun 18/10/10, Samuel Thibault scritto:
From: Samuel Thibault
$ cat test.c
int main(void) {}
$ gcc test.c -o test -static
/usr/lib/gcc/i686-pc-cygwin/4.3.4/../../../../i686-pc-cygwin/bin/ld:
cannot find -lgcc_s
/usr/lib/gcc/i686-pc-cygwin/4.3.4/../../../../i686-pc-cygwin/bin/ld:
cannot find -lgcc_s
There indeed is libgcc_s.dll.a in
/usr/lib/gcc/i686-pc-cygwin/, but for
some reason gcc doesn't seem to be happy with it.
This is using gcc4
and
gcc4-core 4.3.4-3. gcc-3 works fine.
Please, why such a large test case when the following
would
have been perfectly adequate to demonstrate the
problem?:
$ cat test.c
main() {}
$
Because providing precise information is always better when
reporting a
bug, whatever the circumstances.
That being said, I'd still like to see this bug fixed: the
-static is
suppoed to be able to work alone.
Samuel
have you checked if 4.5 has the same problem ?
http://cygwin.com/ml/cygwin-announce/2010-08/msg00016.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
getting 'clear' to work in Emacs shell
GNU Emacs 21.3.1 (i386-msvc-nt5.1.2600) of 2003-03-27 on buffy GNU bash, version 3.2.51(24)-release (i686-pc-cygwin) CYGWIN_NT-5.1 1.7.7(0.230/5/3) 2010-08-31 09:58 Microsoft Windows XP Pro - Version 2002, SP3 The 'clear' work's in a Cygwin Bash session, c106...@usliny2r86krp8 ~ $ alias clear alias clear='cat ~/.cls' c106...@usliny2r86krp8 ~ $ less .cls ESC[2J .cls (END) But doesn't within Emacs: C-z runs the command shell which is an interactive compiled Lisp function in `shell'. (shell optional BUFFER) All I get within an Emacs shell session is the following, without clearing the screen. Is there some envionment variable I need to set here? bash-3.2$ clear [2J bash-3.2$ -- 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: can't compile opengl using w32api with gcc
chm devel dot chm dot 01 at gmail dot com wrote: Hi- Hi Chris, I've been trying to compile the Perl OpenGL module for cygwin using the w32api opengl32, glu32,.. for performance. I used to be able to add either -I/usr/X11R6/include or -I/usr/include/w32api to the gcc flags to get the compile to work. Going back with cygwin 1.7.1 now, I am unable to get the w32api compile to work. After some debugging, the problem is that /usr/include/w32api is in the gcc system headers list. As a result, duplicate -Idir flags are discarded and since both /usr/include and /usr/include/w32api are in the system search path (in that order), the compile *always* picks up the gl.h in /usr/include/GL which is the Mesa one. I was able to get the compile to work by using the -isystem flag instead of -I as the gcc option but now I have a compiler-specific flag that I have to track. Are there any other options here? Thanks much, Chris P.S. It turns out the previous use of flags had the same problem but since the X11/Mesa GL include files were in /usr/X11R6/include and not /usr/include, the duplicate use of -I/usr/include/w32api was ignored but that was the one being pulled in by the default search. Then when I put -I/usr/X11R6/include on the compile, it did get added to the header search path since it was not in the gcc system paths by default. Your problem is the consequence of the libGL-devel package (Mesa GL) taking over /usr/include/GL in 2008. If you want native GL, you need to install the opengl package, and compile with -I/usr/include/opengl , as stated in /usr/share/doc/opengl-1.1.0/README.txt . André Bleau, Cygwin's volunteer OpenGL package maintainer. Please send any question or comment about the opengl package to cygwin at cygwin dot com, not to directly to me. -- 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: getting 'clear' to work in Emacs shell
On 10/18/2010 9:53 AM, Jeff Rancier wrote: GNU Emacs 21.3.1 (i386-msvc-nt5.1.2600) of 2003-03-27 on buffy GNU bash, version 3.2.51(24)-release (i686-pc-cygwin) CYGWIN_NT-5.1 1.7.7(0.230/5/3) 2010-08-31 09:58 Microsoft Windows XP Pro - Version 2002, SP3 The 'clear' work's in a Cygwin Bash session, c106...@usliny2r86krp8 ~ $ alias clear alias clear='cat ~/.cls' c106...@usliny2r86krp8 ~ $ less .cls ESC[2J .cls (END) But doesn't within Emacs: C-z runs the command shell which is an interactive compiled Lisp function in `shell'. (shelloptional BUFFER) All I get within an Emacs shell session is the following, without clearing the screen. Is there some envionment variable I need to set here? bash-3.2$ clear [2J bash-3.2$ I'm not sure what you're expecting here. Do you want emacs to delete what's in the *shell* buffer? Or just scroll it so that nothing is visible but the prompt? FWIW, typing 'clear' in an emacs shell buffer under Linux doesn't have any visible effect either. (Here it runs /usr/bin/clear.) So I don't think this has anything to do with Cygwin. Ken Ken -- 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: Sending signals to a subprocess
On Sat, Oct 16, 2010 at 02:06:56PM -0400, Ken Brown wrote: On 10/16/2010 1:17 PM, Ken Brown wrote: I could use some help fixing a longstanding bug in the Cygwin build of emacs, in which emacs is unable to send signals to subprocesses. A symptom from the user's point of view is that one cannot interrupt a process in shell mode by typing C-c C-c. I've found a workaround that handles that case (SIGINT), as well as SIGQUIT and SIGTSTP. But as long as I'm fixing this, I'd like to do it right and figure out how to handle all signals. This boils down to finding the right process group ID to pass to 'kill'. On systems that have TIOCGPGRP, emacs uses the following code (in src/process.c) to get this ID: If it helps, I can implement TIOCGPGRP so it will be available in Cygwin 1.7.9. 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
R: gfortran 4.3.4: NINT() intrinsic triggers undefined references to '_llround' and '_llroundf'
--- Ven 15/10/10, Cornelis de Gier ha scritto: The NINT() intrinsic in current gfortran under current cygwin triggers undefined references to '_llround' and '_llroundf'. I found a somewhat related post here: http://sourceware.org/ml/cygwin/2010-06/msg00369.html , but I could not deduce a solution from this message. Below follows a small test program and the output of gfortran. The test program worked OK on a linux system.) program testnint integer, parameter :: kr64 = selected_real_kind(15,307) integer, parameter :: ki64 = selected_int_kind(18) real(kr64)::dp=1. real::r=2. write(*,*),nint(r,ki64) write(*,*),nint(dp,ki64) endprogram testnint $ gfortran -Wall testnint.f90 /tmp/ccqOJVB5.o:testnint.f90:(.text+0x5c): undefined reference to `_llroundf' /tmp/ccqOJVB5.o:testnint.f90:(.text+0xd1): undefined reference to `_llround' collect2: ld returned 1 exit status Cornelis next cygwin release/snapshot will solve it. http://cygwin.com/ml/cygwin-patches/2010-q4/msg5.html $ gfortran -Wall testninit.f90 -o testninit $ ./testninit 2 1 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: In what way is /cygdrive special WRT to permissions?
One final note on this: At Jeremy's suggestion, I tried changing the way /cygdrive is mounted. As Administrator I changed /etc/fstab to read //vega/repository /repos smbfs binary,noacl 0 0 none /cygdrive cygdrive binary,noacl,user 0 0 Mount now shows administra...@taurus ~ $ mount //vega/repository on /repos type smbfs (binary,noacl) C:/cygwin/bin on /usr/bin type ntfs (binary,auto) C:/cygwin/lib on /usr/lib type ntfs (binary,auto) C:/cygwin on / type ntfs (binary,auto) C: on /cygdrive/c type ntfs (binary,noacl,posix=0,user,noumount,auto) D: on /cygdrive/d type iso9660 (binary,noacl,posix=0,user,noumount,auto) F: on /cygdrive/f type smbfs (binary,noacl,posix=0,user,noumount,auto) H: on /cygdrive/h type smbfs (binary,noacl,posix=0,user,noumount,auto) Note that all drives now seem to inherit noacl from the mount of /cygdrive which for C: may not be what you want either. An ls -l of /cygrive/f now shows administra...@taurus ~ $ ls -l /cygdrive/f total 2048 drwxr-xr-x 36 Administrator None 0 2010-10-07 12:35 builds drwxr-xr-x 17 Administrator None 0 2010-10-04 18:23 releases and testing the ability to write you have administra...@taurus ~ $ test -w /cygdrive/f/builds echo you can write you can write This was always the case when you have Administrator privileges. But, when logged in as user build which does not have Administrator privileges, you now have: $ ls -l /cygdrive/f total 2048 drwxr-xr-x 36 build None 0 2010-10-07 12:35 builds drwxr-xr-x 17 build None 0 2010-10-04 18:23 releases and $ test -w /cygdrive/f/builds echo You can write You can write Which is the way cygwin 1.5 behaved! Perhaps the default mounting of file systems that are not NTFS should be with noacl, but that is a question best answered by more knowledgeable people. It would at least make the behavior of test consistent which what you can actually do with the filesystem. Corinna - Thanks for the reply and clarification. I have made the obvious change in my mounts to get around this problem. However, there has been a change in behavior between 1.5 and 1.7. I have 1.7.7 installed on Windows Server 2003 SP2. The mount table shows $ mount //vega/repository on /repos type smbfs (binary,noacl) C:/cygwin/bin on /usr/bin type ntfs (binary,auto) C:/cygwin/lib on /usr/lib type ntfs (binary,auto) C:/cygwin on / type ntfs (binary,auto) C: on /cygdrive/c type ntfs (binary,posix=0,user,noumount,auto) D: on /cygdrive/d type iso9660 (binary,posix=0,user,noumount,auto) F: on /cygdrive/f type smbfs (binary,posix=0,user,noumount,auto) H: on /cygdrive/h type smbfs (binary,posix=0,user,noumount,auto) F: also happens to be mapped to //vega/repository via the normal Windows mechanisms. When signed on to the Administrator account you have: administra...@taurus ~ $ ls -l /repos total 2048 drwxr-xr-x 36 Administrator None 0 2010-10-04 19:30 builds drwxr-xr-x 17 Administrator None 0 2010-10-04 18:23 releases administra...@taurus ~ $ test -w /repos/builds echo writeable writeable administra...@taurus ~ $ ls -l /cygdrive/f total 2048 drwxrwxr-x 36 0 2010-10-04 19:30 builds drwxrwxr-x 17 0 2010-10-04 18:23 releases administra...@taurus ~ $ test -w /repos/builds echo writeable writeable When logged on as the non-admistrative user build you have: bu...@taurus ~ $ ls -l /repos total 2048 drwxr-xr-x 36 build None 0 2010-10-04 19:30 builds drwxr-xr-x 17 build None 0 2010-10-04 18:23 releases bu...@taurus ~ $ test -w /repos/builds echo writeable writeable bu...@taurus ~ $ ls -l /cygdrive/f total 2048 drwxrwxr-x 36 0 2010-10-04 19:30 builds drwxrwxr-x 17 0 2010-10-04 18:23 releases bu...@taurus ~ $ test -w /cygdrive/f/builds echo writeable bu...@taurus ~ $ echo test /cygdrive/f/builds/zap bu...@taurus ~ $ ls -l /cygdrive/f/builds/zap -rwxrwxr-x 1 5 2010-10-06 16:11 /cygdrive/f/builds/zap Notice that the test -w /cygdrive/f/builds reports that /cygdrive/f/builds is not writeable, yet you can create and write files in /cygdrive/f/builds! THIS IS INCONSTENT BEHAVIOR. Cygwin 1.5 did not have this behavior. Regarding the mount of drive letters via /etc/fstab. I am not sure what the documentation should say about this. Overriding the default mount of a single drive letter in fstab actually seems to work, although it simply reproduces the same behavior as the default. Even if I understood the actual behavior, I regret that am not familiar with the ways of Cygwin source maintenance to make the documentation changes. I have to leave this to somebody else more qualified. Cheers, Andy On Oct 6 1:48 Corinna Vischen wrote: On Oct 5 15:40, Andy Hall wrote: If instead, I map F: to /cygdrive/c with the following entry in /etc/fstab F: /cygdrive/f smbfs binary,noacl 0 0 mount shows $ mount C:/cygwin/bin on /usr/bin
Re: Sending signals to a subprocess
On 10/18/2010 10:58 AM, Christopher Faylor wrote: On Sat, Oct 16, 2010 at 02:06:56PM -0400, Ken Brown wrote: On 10/16/2010 1:17 PM, Ken Brown wrote: I could use some help fixing a longstanding bug in the Cygwin build of emacs, in which emacs is unable to send signals to subprocesses. A symptom from the user's point of view is that one cannot interrupt a process in shell mode by typing C-c C-c. I've found a workaround that handles that case (SIGINT), as well as SIGQUIT and SIGTSTP. But as long as I'm fixing this, I'd like to do it right and figure out how to handle all signals. This boils down to finding the right process group ID to pass to 'kill'. On systems that have TIOCGPGRP, emacs uses the following code (in src/process.c) to get this ID: If it helps, I can implement TIOCGPGRP so it will be available in Cygwin 1.7.9. Yes, that would be great. Thanks. Ken -- 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: Sending signals to a subprocess
On 18 October 2010 18:27, Ken Brown wrote: On 10/18/2010 10:58 AM, Christopher Faylor wrote: On Sat, Oct 16, 2010 at 02:06:56PM -0400, Ken Brown wrote: On 10/16/2010 1:17 PM, Ken Brown wrote: I could use some help fixing a longstanding bug in the Cygwin build of emacs, in which emacs is unable to send signals to subprocesses. A symptom from the user's point of view is that one cannot interrupt a process in shell mode by typing C-c C-c. I've found a workaround that handles that case (SIGINT), as well as SIGQUIT and SIGTSTP. But as long as I'm fixing this, I'd like to do it right and figure out how to handle all signals. This boils down to finding the right process group ID to pass to 'kill'. On systems that have TIOCGPGRP, emacs uses the following code (in src/process.c) to get this ID: If it helps, I can implement TIOCGPGRP so it will be available in Cygwin 1.7.9. Yes, that would be great. Thanks. I'd put that to use in mintty too, to improve support for relative paths when opening a file with Ctrl+click or the 'Open' menu command. 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: Sending signals to a subprocess
On Mon, Oct 18, 2010 at 06:40:19PM +0100, Andy Koppe wrote: On 18 October 2010 18:27, Ken Brown wrote: On 10/18/2010 10:58 AM, Christopher Faylor wrote: On Sat, Oct 16, 2010 at 02:06:56PM -0400, Ken Brown wrote: On 10/16/2010 1:17 PM, Ken Brown wrote: I could use some help fixing a longstanding bug in the Cygwin build of emacs, in which emacs is unable to send signals to subprocesses. ??A symptom from the user's point of view is that one cannot interrupt a process in shell mode by typing C-c C-c. ??I've found a workaround that handles that case (SIGINT), as well as SIGQUIT and SIGTSTP. ??But as long as I'm fixing this, I'd like to do it right and figure out how to handle all signals. This boils down to finding the right process group ID to pass to 'kill'. On systems that have TIOCGPGRP, emacs uses the following code (in src/process.c) to get this ID: If it helps, I can implement TIOCGPGRP so it will be available in Cygwin 1.7.9. Yes, that would be great. ??Thanks. I'd put that to use in mintty too, to improve support for relative paths when opening a file with Ctrl+click or the 'Open' menu command. Ok, that's even more incentive for me to do this. It's been on my todo list for years. I'll try to get to it soon. (But now that I said this, I'll probably soon discover why it hasn't been implemented already) 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: Sending signals to a subprocess
On Sat, Oct 16, 2010 at 02:06:56PM -0400, Ken Brown wrote:
On 10/16/2010 1:17 PM, Ken Brown wrote:
I could use some help fixing a longstanding bug in the Cygwin build of
emacs, in which emacs is unable to send signals to subprocesses. A
symptom from the user's point of view is that one cannot interrupt a
process in shell mode by typing C-c C-c. I've found a workaround that
handles that case (SIGINT), as well as SIGQUIT and SIGTSTP. But as long
as I'm fixing this, I'd like to do it right and figure out how to handle
all signals.
This boils down to finding the right process group ID to pass to 'kill'.
On systems that have TIOCGPGRP, emacs uses the following code (in
src/process.c) to get this ID:
/* Return the foreground process group for the tty/pty that
the process P uses. */
static int
emacs_get_tty_pgrp (p)
struct Lisp_Process *p;
{
int gid = -1;
#ifdef TIOCGPGRP
if (ioctl (p-infd, TIOCGPGRP,gid) == -1 ! NILP (p-tty_name))
{
int fd;
/* Some OS:es (Solaris 8/9) does not allow TIOCGPGRP from the
master side. Try the slave side. */
fd = emacs_open (SDATA (p-tty_name), O_RDONLY, 0);
if (fd != -1)
{
ioctl (fd, TIOCGPGRP,gid);
emacs_close (fd);
}
}
#endif /* defined (TIOCGPGRP ) */
return gid;
}
What's the right way to do this in Cygwin?
I guess it's clear from the context, but I should have said that the
problem only arises when emacs has to communicate with the subprocess
through a tty that is not the controlling tty of emacs. So tcgetpgrp()
doesn't work.
I am a little confused as to the difference between tcgetpgrp and
TIOCGPGRP given this man page description from man 4 tty_ioctl on
linux:
TIOCGPGRP pid_t *argp
When successful, equivalent to *argp = tcgetpgrp(fd).
Get the process group ID of the foreground process group on this
terminal.
TIOCSPGRP const pid_t *argp
Equivalent to tcsetpgrp(fd, *argp).
Set the foreground process group ID of this terminal.
Do you have a simple test case which demonstrates the difference between
the calls? It seems odd that TIOCGPGRP would allow more access to a tty
than tcgetpgrp.
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: Sending signals to a subprocess
On 10/18/2010 2:34 PM, Christopher Faylor wrote:
On Sat, Oct 16, 2010 at 02:06:56PM -0400, Ken Brown wrote:
On 10/16/2010 1:17 PM, Ken Brown wrote:
I could use some help fixing a longstanding bug in the Cygwin build of
emacs, in which emacs is unable to send signals to subprocesses. A
symptom from the user's point of view is that one cannot interrupt a
process in shell mode by typing C-c C-c. I've found a workaround that
handles that case (SIGINT), as well as SIGQUIT and SIGTSTP. But as long
as I'm fixing this, I'd like to do it right and figure out how to handle
all signals.
This boils down to finding the right process group ID to pass to 'kill'.
On systems that have TIOCGPGRP, emacs uses the following code (in
src/process.c) to get this ID:
/* Return the foreground process group for the tty/pty that
the process P uses. */
static int
emacs_get_tty_pgrp (p)
struct Lisp_Process *p;
{
int gid = -1;
#ifdef TIOCGPGRP
if (ioctl (p-infd, TIOCGPGRP,gid) == -1 ! NILP (p-tty_name))
{
int fd;
/* Some OS:es (Solaris 8/9) does not allow TIOCGPGRP from the
master side. Try the slave side. */
fd = emacs_open (SDATA (p-tty_name), O_RDONLY, 0);
if (fd != -1)
{
ioctl (fd, TIOCGPGRP,gid);
emacs_close (fd);
}
}
#endif /* defined (TIOCGPGRP ) */
return gid;
}
What's the right way to do this in Cygwin?
I guess it's clear from the context, but I should have said that the
problem only arises when emacs has to communicate with the subprocess
through a tty that is not the controlling tty of emacs. So tcgetpgrp()
doesn't work.
I am a little confused as to the difference between tcgetpgrp and
TIOCGPGRP given this man page description from man 4 tty_ioctl on
linux:
TIOCGPGRP pid_t *argp
When successful, equivalent to *argp = tcgetpgrp(fd).
Get the process group ID of the foreground process group on this
terminal.
TIOCSPGRP const pid_t *argp
Equivalent to tcsetpgrp(fd, *argp).
Set the foreground process group ID of this terminal.
Do you have a simple test case which demonstrates the difference between
the calls? It seems odd that TIOCGPGRP would allow more access to a tty
than tcgetpgrp.
The difference is that, according to POSIX, tcgetpgrp is required to
fail unless fd references the controlling terminal of the calling
process. Ironically, Cygwin's tcgetpgrp used to succeed in this
situation until Corinna fixed it a year ago:
http://www.cygwin.com/ml/cygwin-patches/2009-q4/msg00045.html
Ken
--
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: Sending signals to a subprocess
On Mon, Oct 18, 2010 at 03:40:21PM -0400, Ken Brown wrote:
On 10/18/2010 2:34 PM, Christopher Faylor wrote:
On Sat, Oct 16, 2010 at 02:06:56PM -0400, Ken Brown wrote:
On 10/16/2010 1:17 PM, Ken Brown wrote:
I could use some help fixing a longstanding bug in the Cygwin build of
emacs, in which emacs is unable to send signals to subprocesses. A
symptom from the user's point of view is that one cannot interrupt a
process in shell mode by typing C-c C-c. I've found a workaround that
handles that case (SIGINT), as well as SIGQUIT and SIGTSTP. But as long
as I'm fixing this, I'd like to do it right and figure out how to handle
all signals.
This boils down to finding the right process group ID to pass to 'kill'.
On systems that have TIOCGPGRP, emacs uses the following code (in
src/process.c) to get this ID:
/* Return the foreground process group for the tty/pty that
the process P uses. */
static int
emacs_get_tty_pgrp (p)
struct Lisp_Process *p;
{
int gid = -1;
#ifdef TIOCGPGRP
if (ioctl (p-infd, TIOCGPGRP,gid) == -1 ! NILP (p-tty_name))
{
int fd;
/* Some OS:es (Solaris 8/9) does not allow TIOCGPGRP from the
master side. Try the slave side. */
fd = emacs_open (SDATA (p-tty_name), O_RDONLY, 0);
if (fd != -1)
{
ioctl (fd, TIOCGPGRP,gid);
emacs_close (fd);
}
}
#endif /* defined (TIOCGPGRP ) */
return gid;
}
What's the right way to do this in Cygwin?
I guess it's clear from the context, but I should have said that the
problem only arises when emacs has to communicate with the subprocess
through a tty that is not the controlling tty of emacs. So tcgetpgrp()
doesn't work.
I am a little confused as to the difference between tcgetpgrp and
TIOCGPGRP given this man page description from man 4 tty_ioctl on
linux:
TIOCGPGRP pid_t *argp
When successful, equivalent to *argp = tcgetpgrp(fd).
Get the process group ID of the foreground process group on
this terminal.
TIOCSPGRP const pid_t *argp
Equivalent to tcsetpgrp(fd, *argp).
Set the foreground process group ID of this terminal.
Do you have a simple test case which demonstrates the difference between
the calls? It seems odd that TIOCGPGRP would allow more access to a tty
than tcgetpgrp.
The difference is that, according to POSIX, tcgetpgrp is required to
fail unless fd references the controlling terminal of the calling
process. Ironically, Cygwin's tcgetpgrp used to succeed in this
situation until Corinna fixed it a year ago:
http://www.cygwin.com/ml/cygwin-patches/2009-q4/msg00045.html
Yes, I got that but TIOCGPGRP seems to have that same limitation on
Linux. That's why I quoted the above man page. A simple test case
(tm) seems to bear out the fact that the two are the same.
If you compile/link the below on linux and provide, e.g., /dev/tty0 as
an argument, then the command fails, even when run as root. If you give
it no argument or give it the fd of the current controlling tty then
both tcgetpgrp and TIOCGPGRP both succeed.
cgf
#include termios.h
#include sys/fcntl.h
#include stdio.h
#include string.h
#include errno.h
#include sys/ioctl.h
#include unistd.h
#include stdlib.h
int
main (int argc, char **argv)
{
int res;
pid_t pid;
const char tty[100];
int fd;
if (argc == 1)
{
int fds;
res = openpty (fd, fds, tty, NULL, NULL);
if (fd 0)
{
fprintf (stderr, openpty failed: %s\n, strerror (errno));
exit (1);
}
}
else
{
fd = open (argv[1], O_RDONLY);
if (fd 0)
{
fprintf (stderr, open failed: %s\n, strerror (errno));
exit (1);
}
}
printf (%d = tcgetpgrp(%d), res = tcgetpgrp (fd), fd);
if (res 0)
printf ( - %s, strerror (errno));
puts ();
printf (%d = ioctl(fd, TIOCGPGRP, pid), res = ioctl(fd, TIOCGPGRP, pid));
if (res 0)
printf ( - %s, strerror (errno));
else
printf (, pid = %d, pid);
puts ();
exit (0);
}
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: gcc: stable 4.5 soon?
On Thu, 2010-10-07 at 13:20 -0500, Yaakov (Cygwin/X) wrote: Dave, I have been using a gcc-4.5.1 built with your 4.5.0 patchset for some time. Besides the issues I noted back in August[1], I have been pleased with its performance. Any chance we can get a stable 4.5.1 soon with at least the easier issues noted therein fixed? Yaakov [1] http://cygwin.com/ml/cygwin/2010-08/msg00412.html Ping? Yaakov -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: OpenSP-1.5.2-2 missing package dependency in setup.hint
On Sat, 2010-10-16 at 14:11 +0200, Gerrit P. Haase wrote: the package OpenSP-1.5.2-2 is missing the sgml-common dependency in setup.hint. the package openjade is missing the sgml-common dependency in setup.hint. Confirmed and fixed. Thanks for the report. Yaakov -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
makewhatis bug (man-1.6f-1)
makewhatis from man-1.6f-1 produces incorrectly formated output. Here's
an example comparing the badly-formatted results to correctly formatted
results:
$ man -k ssh
git [] (1) - shell - Restricted login shell for GIT-only SSH
access
ssh [] (1) - add - adds RSA or DSA identities to the
authentication agent
ssh [] (1) - agent - authentication agent
ssh [] (1) - copy-id - install your public key in a remote
machine's authorized_keys
ssh [] (1) - keygen - authentication key generation, management
and conversion
ssh [] (1) - keyscan - gather ssh public keys
ssh [] (1) - OpenSSH SSH client (remote login program)
ssh [] (8) - keysign - ssh helper program for host - based
authentication
ssh [] (8) - pkcs11-helper - ssh - agent helper program for
PKCS#11 support
ssh_config [](5) - OpenSSH SSH client configuration files
sshd [] (8) - OpenSSH SSH daemon
sshd_config [] (5) - OpenSSH SSH daemon configuration file
XAllocClassHint [] (3) - allocate class hints structure and set or read a
window's WM_CLASS property
XClassHint [](3) - allocate class hints structure and set or read a
window's WM_CLASS property
XGetClassHint [] (3) - allocate class hints structure and set or read a
window's WM_CLASS property
XSetClassHint [] (3) - allocate class hints structure and set or read a
window's WM_CLASS property
Using previous version:
$ man -k ssh
git-shell(1) - Restricted login shell for GIT-only SSH access
ssh (1) - OpenSSH SSH client (remote login program)
ssh_config (5) - OpenSSH SSH client configuration files
ssh-add (1) - adds RSA or DSA identities to the authentication
agent
ssh-agent(1) - authentication agent
ssh-copy-id (1) - install your public key in a remote machine's
authorized_keys
sshd (8) - OpenSSH SSH daemon
sshd_config (5) - OpenSSH SSH daemon configuration file
ssh-keygen (1) - authentication key generation, management and
conversion
ssh-keyscan (1) - gather ssh public keys
ssh-keysign (8) - ssh helper program for host-based authentication
ssh-pkcs11-helper(8) - ssh-agent helper program for PKCS#11 support
XAllocClassHint (3) - allocate class hints structure and set or read a
window's WM_CLASS property
XClassHint [XAllocClassHint] (3) - allocate class hints structure and set or
read a window's WM_CLASS property
XGetClassHint [XAllocClassHint] (3) - allocate class hints structure and set
or read a window's WM_CLASS property
XSetClassHint [XAllocClassHint] (3) - allocate class hints structure and set
or read a window's WM_CLASS property
The problem is in the whatis database itself, and is caused by a bug in
makewhatis in the upstream distribution. From the function do_one in the
section of awk code:
use_zcat = match(filename,\\.Z$) ||
match(filename,\\.z$) || match(filename,\\.gz$);
if (!use_zcat)
use_bzcat = match(filename,\\.bz2);
if(!use_bzcat)
use_lzcat = match(filename,\\.lzma);
if (use_zcat || use_bzcat || use_lzcat ) {
filename_no_gz = substr(filename, 0, RSTART - 1);
} else {
filename_no_gz = filename;
}
When filname ends in .z, .Z, or .gz, use_zcat gets set, and match() sets
the variable RSTART. The check for a .bz2 file is careful not to call
match() if the file was already determined to be .gz (etc.), but the
newer .lzma-checking code fails to check for all earlier possibilities,
and invokes match() again. This trashes RSTART, causing the later
substr() call to give an unexpected result. How exactly this produces
the weird output above is left as an exercise to the reader, but fixing
the second 'if' fixes the problem.
A simple patch follows. It doesn't attempt to address the underlying
problem (that the decompression handling needs to be generalized), it's
just a quick fix. Interestingly there are other patches floating around
that add support for .xz files and repeat the .lzma mistake, making the
bug even worse.
-Kevin
--- makewhatis 2010-10-07 13:47:42.578125000 -0700
+++ makewhatis.fixed2010-10-09 10:06:44.234375000 -0700
@@ -268,7 +268,7 @@
match(filename,\\.z$) || match(filename,\\.gz$);
if (!use_zcat)
use_bzcat = match(filename,\\.bz2);
- if(!use_bzcat)
+ if(!use_zcat !use_bzcat)
use_lzcat = match(filename,\\.lzma);
if (use_zcat || use_bzcat || use_lzcat ) {
filename_no_gz = substr(filename, 0, RSTART - 1);
--
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: Sending signals to a subprocess
On 10/18/2010 4:18 PM, Christopher Faylor wrote:
On Mon, Oct 18, 2010 at 03:40:21PM -0400, Ken Brown wrote:
On 10/18/2010 2:34 PM, Christopher Faylor wrote:
On Sat, Oct 16, 2010 at 02:06:56PM -0400, Ken Brown wrote:
On 10/16/2010 1:17 PM, Ken Brown wrote:
I could use some help fixing a longstanding bug in the Cygwin build of
emacs, in which emacs is unable to send signals to subprocesses. A
symptom from the user's point of view is that one cannot interrupt a
process in shell mode by typing C-c C-c. I've found a workaround that
handles that case (SIGINT), as well as SIGQUIT and SIGTSTP. But as long
as I'm fixing this, I'd like to do it right and figure out how to handle
all signals.
This boils down to finding the right process group ID to pass to 'kill'.
On systems that have TIOCGPGRP, emacs uses the following code (in
src/process.c) to get this ID:
/* Return the foreground process group for the tty/pty that
the process P uses. */
static int
emacs_get_tty_pgrp (p)
struct Lisp_Process *p;
{
int gid = -1;
#ifdef TIOCGPGRP
if (ioctl (p-infd, TIOCGPGRP,gid) == -1! NILP (p-tty_name))
{
int fd;
/* Some OS:es (Solaris 8/9) does not allow TIOCGPGRP from the
master side. Try the slave side. */
fd = emacs_open (SDATA (p-tty_name), O_RDONLY, 0);
if (fd != -1)
{
ioctl (fd, TIOCGPGRP,gid);
emacs_close (fd);
}
}
#endif /* defined (TIOCGPGRP ) */
return gid;
}
What's the right way to do this in Cygwin?
I guess it's clear from the context, but I should have said that the
problem only arises when emacs has to communicate with the subprocess
through a tty that is not the controlling tty of emacs. So tcgetpgrp()
doesn't work.
I am a little confused as to the difference between tcgetpgrp and
TIOCGPGRP given this man page description from man 4 tty_ioctl on
linux:
TIOCGPGRP pid_t *argp
When successful, equivalent to *argp = tcgetpgrp(fd).
Get the process group ID of the foreground process group on
this terminal.
TIOCSPGRP const pid_t *argp
Equivalent to tcsetpgrp(fd, *argp).
Set the foreground process group ID of this terminal.
Do you have a simple test case which demonstrates the difference between
the calls? It seems odd that TIOCGPGRP would allow more access to a tty
than tcgetpgrp.
The difference is that, according to POSIX, tcgetpgrp is required to
fail unless fd references the controlling terminal of the calling
process. Ironically, Cygwin's tcgetpgrp used to succeed in this
situation until Corinna fixed it a year ago:
http://www.cygwin.com/ml/cygwin-patches/2009-q4/msg00045.html
Yes, I got that but TIOCGPGRP seems to have that same limitation on
Linux. That's why I quoted the above man page.
Sorry, I missed the point. In view of the use of TIOCGPGRP in emacs,
there must be some unix-like systems (BSD?) where TIOCGPGRP is not
subject to that limitation. Is it necessary to keep the limitation in
Cygwin? I guess it boils down to how important Linux compatibility is,
given that POSIX (as far as I know) is silent about TIOCGPGRP.
This is not a big deal from my point of view. As I said in my first
message, I have a workaround for the most important uses in emacs. I
think it might be more of an issue for mintty.
Ken
--
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: -static not working with gcc 4.3.4
Marco Atzeri, le Mon 18 Oct 2010 14:22:02 +0100, a écrit : have you checked if 4.5 has the same problem ? http://cygwin.com/ml/cygwin-announce/2010-08/msg00016.html It doesn't have the problem any more. Samuel -- 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
