Re: [RFU] mintty-0.4.1-1
On Jun 20 22:24, Andy Koppe wrote: For both 1.5 and 1.7: wget http://mintty.googlecode.com/files/mintty-0.4.1-1.tar.bz2 wget http://mintty.googlecode.com/files/mintty-0.4.1-1-src.tar.bz2 Uploaded. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: [ITP 1.7] lua
On Jun 21 19:12, Yaakov S wrote: Per popular request: ftp://ftp.cygwinports.org/pub/cygwinports/release-2/Lua/lua/lua-5.1.4-11-src.tar.bz2 ftp://ftp.cygwinports.org/pub/cygwinports/release-2/Lua/lua/lua-5.1.4-11.tar.bz2 ftp://ftp.cygwinports.org/pub/cygwinports/release-2/Lua/lua/setup.hint category: Interpreters requires: libgcc1 libreadline6 sdesc: Lua programming language interpreter ldesc: Lua is a powerful, light-weight programming language designed for extending applications. Lua is also frequently used as a general-purpose, stand-alone language. Looks good. Please upload. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: [ITP 1.7] dbus
On Jun 21 19:23, Yaakov S wrote: D-Bus is the fd.o IPC framework, which just about all desktop software is using nowadays. This, and its bindings (ITPs to follow), will be required for GNOME 2.26, KDE4, and Xfce4 libraries. D-Bus defines two separate buses, a system bus and a session bus. The system bus is installable as a Windows service via csih (thanks Chuck!), although most software that uses the system bus (e.g. HAL, DeviceKit, PolicyKit, etc.) is mostly Linux-specific. The session bus is started with dbus-launch, or it will be launched automatically by apps/xsessions which need it. ftp://ftp.cygwinports.org/pub/cygwinports/release-2/dbus/dbus-1.2.14-1-src.tar.bz2 ftp://ftp.cygwinports.org/pub/cygwinports/release-2/dbus/dbus-1.2.14-1.tar.bz2 ftp://ftp.cygwinports.org/pub/cygwinports/release-2/dbus/setup.hint ftp://ftp.cygwinports.org/pub/cygwinports/release-2/dbus/libdbus1-devel/libdbus1-devel-1.2.14-1.tar.bz2 ftp://ftp.cygwinports.org/pub/cygwinports/release-2/dbus/libdbus1-devel/setup.hint ftp://ftp.cygwinports.org/pub/cygwinports/release-2/dbus/libdbus1_3/libdbus1_3-1.2.14-1.tar.bz2 ftp://ftp.cygwinports.org/pub/cygwinports/release-2/dbus/libdbus1_3/setup.hint This looks good as well. Please upload. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: [RFU 1.7] nasm-2.05-1
On Jun 22 10:15, Dean Scarff wrote: Upstream release (actually I've missed a couple of minor upstream releases since the last cygwin package). Built for cygwin 1.7. wget \ 'http://scarff.id.au/file/cygwin/nasm/nasm-2.05-1-src.tar.bz2' \ 'http://scarff.id.au/file/cygwin/nasm/nasm-2.05-1.tar.bz2' rm -f nasm-2.01-1-src.tar.bz2 nasm-2.01-1.tar.bz2 Please upload :) Done. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: [ITP] task-1.7.1-1 (pinging for awaiting review)
Hi Dave (and Yaakov) THX for the feedback regarding the packaging of task. And sorry for me pinging (we had a couple of user who have been asking for task in cygwin though...) I have now fixed the 2 remarks you had: 1) setup.hint removed dependency to cygwin in requires (but http://cygwin.com/setup.html should be update regarding this as it still advises to require cygwin) 2) task-1.7.1-1.src.tar.bz2 OK. Now I understand. I miss-understood the instructions. Thought that only the ready build binary package should install and contain the README file. And not the manual user build. I have now switched to cyport as you recommended (THX for the patches). I have included 2 small changes in the patch file: above mentioned requirement for cygwin disappers and I have also changed the build instructions to use cygport (using ideas and templates for the text from other packages using cygport). I have now re-uploaded the packages (without bumping the version number as the package is not yet in cygwin). So I would appreciate if you could take a new look at the new files at http://taskwarrior.org/download/cygwin/setup.hint http://taskwarrior.org/download/cygwin/task-1.7.1-1-src.tar.bz2 http://taskwarrior.org/download/cygwin/task-1.7.1-1.tar.bz2 Let me know if there are any problems. And thx for your time. /Federico
HEADSUP maintainers: Packages install scripts without execute permissions
[Wrong list. Resent to cygwin-apps] Hi, Here's the problem: If you exec shell scripts, they should only be run if the user trying to run the script has execute permissions on the script. This requires to check for executability in Cygwin, but as of today, such a check isn't performed in Cygwin. I have the patch for this ready, but I found that it would potentially break a couple of packages which have not set execute permissions on some of their script files. As you should know by now, setup for Cygwin 1.7 will set POSIX file permissions for the files extracted from the tar archives. That means, all scripts which don't have execute permissions set, will also not have execute permissions set after the user installed them. That's bad. So I created a list of packages which install scripts into /etc/preremove, /etc/postinstall, and /usr/bin without setting execute permissions on them. Please guys, fix the permissions ASAP. Corinna Vinschen: robots: etc/postinstall/robots.sh Reini Urban: perl: usr/bin/cpan5.10.0 usr/bin/shasum5.10.0 Christian Franke: ddrescue: etc/postinstall/ddrescue.sh Jari Aalto: colorgcc: etc/postinstall/colorgcc.sh joe: etc/postinstall/joe-manifest.lst Frank Seelisch: singular-icons: etc/postinstall/singular-icons.sh Dave Korn: gcc-core: etc/postinstall/gcc.sh etc/preremove/gcc.sh gcc-gnat: etc/postinstall/gcc-gnat.sh etc/preremove/gcc-gnat.sh gcc-gdc: etc/postinstall/gcc-gdc.sh etc/preremove/gcc-gdc.sh gcc-gpc: etc/postinstall/gcc-gpc.sh etc/preremove/gcc-gpc.sh gcc-g++: etc/postinstall/gcc-g++.sh etc/preremove/gcc-g++.sh gcc-g77: etc/postinstall/gcc-g77.sh etc/preremove/gcc-g77.sh gcc-java: etc/postinstall/gcc-java.sh etc/preremove/gcc-java.sh Yaakov S: perl-extutils-pkgconfig: etc/postinstall/perl-ExtUtils-Pk libgnome2:etc/preremove/libgnome2.sh gnome-vfs:etc/preremove/gnome-vfs2.sh ilibIDL: etc/postinstall/libIDL.sh libIDL2: etc/postinstall/libIDL2.sh Btw., DLLs should also be executable, otherwise applications will fail to start. I found one of them: glib: usr/bin/cyggmodule-1-2-0.dll Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: HEADSUP maintainers: Packages install scripts without execute permissions
On 6/22/2009 9:12 AM, Corinna Vinschen wrote: Here's the problem: If you exec shell scripts, they should only be run if the user trying to run the script has execute permissions on the script. This requires to check for executability in Cygwin, but as of today, such a check isn't performed in Cygwin. I have the patch for this ready, but I found that it would potentially break a couple of packages which have not set execute permissions on some of their script files. As you should know by now, setup for Cygwin 1.7 will set POSIX file permissions for the files extracted from the tar archives. That means, all scripts which don't have execute permissions set, will also not have execute permissions set after the user installed them. That's bad. So I created a list of packages which install scripts into /etc/preremove, /etc/postinstall, and /usr/bin without setting execute permissions on them. Please guys, fix the permissions ASAP. Users who have existing preremove scripts without execute permissions will still have problems if you change setup.exe to check for this, won't they? Ken
Re: HEADSUP maintainers: Packages install scripts without execute permissions
On Jun 22 09:45, Ken Brown wrote: On 6/22/2009 9:12 AM, Corinna Vinschen wrote: Here's the problem: If you exec shell scripts, they should only be run if the user trying to run the script has execute permissions on the script. This requires to check for executability in Cygwin, but as of today, such a check isn't performed in Cygwin. I have the patch for this ready, but I found that it would potentially break a couple of packages which have not set execute permissions on some of their script files. As you should know by now, setup for Cygwin 1.7 will set POSIX file permissions for the files extracted from the tar archives. That means, all scripts which don't have execute permissions set, will also not have execute permissions set after the user installed them. That's bad. So I created a list of packages which install scripts into /etc/preremove, /etc/postinstall, and /usr/bin without setting execute permissions on them. Please guys, fix the permissions ASAP. Users who have existing preremove scripts without execute permissions will still have problems if you change setup.exe to check for this, won't they? If the affected packages are replaced before we install a new Cygwin DLL, which correctly checks for execute permissions, the preremove scripts would be replaced with the ones with correct permissions before the problem actually starts to become visible. I don't understand how you suggest to change setup.exe. In theory, it could change permissions of scripts in /etc/preremove and /etc/postinstall on the fly while installing them, as it already does for *.exe files. It could do the same also for .dll files, btw. Is that what you mean? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: HEADSUP maintainers: Packages install scripts without execute permissions
On Mon, Jun 22, 2009 at 09:45:12AM -0400, Ken Brown wrote: On 6/22/2009 9:12 AM, Corinna Vinschen wrote: Here's the problem: If you exec shell scripts, they should only be run if the user trying to run the script has execute permissions on the script. This requires to check for executability in Cygwin, but as of today, such a check isn't performed in Cygwin. I have the patch for this ready, but I found that it would potentially break a couple of packages which have not set execute permissions on some of their script files. As you should know by now, setup for Cygwin 1.7 will set POSIX file permissions for the files extracted from the tar archives. That means, all scripts which don't have execute permissions set, will also not have execute permissions set after the user installed them. That's bad. So I created a list of packages which install scripts into /etc/preremove, /etc/postinstall, and /usr/bin without setting execute permissions on them. Please guys, fix the permissions ASAP. Users who have existing preremove scripts without execute permissions will still have problems if you change setup.exe to check for this, won't they? Doesn't setup.exe invoke preremove/postinstall shell scripts via bash foo.sh? You don't need exec permissions for that. cgf
Re: HEADSUP maintainers: Packages install scripts without execute ?permissions
On Jun 22 16:09, Corinna Vinschen wrote: On Jun 22 13:58, Eric Blake wrote: For that matter, are there any postinstall scripts currently relying on a different interpreter? If not, then I'm in favor of the idea of changing setup.exe to be immune to the execute bit on postinstall scripts, at the expense of making postinstall scripts locked into bash (at least, as the initial interpreter). There can be only *.bat and *.sh files in /etc/postinstall and /etc/preremove. *.bat files are started via `cmd /c file' and *.sh files are started via `bash --norc --noprofile -c file'. So we sort of require a script to be a sh/bash script anyway right now. Admittedly, I did not actually *look* into all postinstall/preremove scripts in the distro. I just checked the entire 1.7 distro and here's the result: We have not a single package left which uses a .bat file in postinstall or in preremove. That's great, IMHO. And, AFAICS, all of the *.sh fiels are actually some variation of sh/ash/bash script. So I assume it's safe to remove the -c from setup's script starter method. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: HEADSUP maintainers: Packages install scripts without execute permissions
On 6/22/2009 10:04 AM, Corinna Vinschen wrote: If the affected packages are replaced before we install a new Cygwin DLL, which correctly checks for execute permissions, the preremove scripts would be replaced with the ones with correct permissions before the problem actually starts to become visible. Ah, that's the part I was missing. Sorry for the noise. Ken
Re: [ANNOUNCEMENT] [1.7] Updated: cygwin-1.7.0-50
On Jun 19 14:38, Mark Harig wrote: While running setup-1.7.exe (with no arguments) from a cygwin 1.5 bash shell prompt, the following (error?) messages were displayed: io_stream_cygfile: fopen(/etc/setup/installed.db) failed 2 No such file or directory io_stream_cygfile: fopen(/etc/setup/last-cache) failed 2 No such file or directory io_stream_cygfile: fopen(/etc/setup/timestamp) failed 2 No such file or directory io_stream_cygfile: fopen(/etc/setup/mirrors-lst) failed 2 No such file or directory Are these messages expected? Can they be safely ignored? Are they documented somewhere for cygwin users? I was not able to find a mention of them at http://cygwin.com/1.7/faq/faq.setup.html or http://cygwin.com/1.7/cygwin-ug-net/setup-net.html Also, during the installation of the (default set of) packages, the following error message was displayed: running: C:\cygwin-1.7\bin\bash.exe --norc --noprofile -c /etc/postinstall/base-files-profile.sh abnormal exit: exit code=-1073741819 I confirmed that all directories and files that /etc/postinstall/base-files-profiles.sh creates or installs exist. I re-ran setup-1.7.exe a second time (with no additional packages selected) and found that none of the above messages were displayed. They are harmless. Setup.exe tries to open these files the first time before it created them. So these messages are always expected on the first run of setup. 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] [ANNOUNCEMENT] Updated: mintty-0.4.1-1
MinTTY is a terminal emulator for Cygwin with a native Windows user
interface and minimalist design. Among its features are Unicode
support and a graphical options dialog. Its terminal emulation is
largely compatible with xterm, but it does not require an X server.
MinTTY is based on code from PuTTY 0.60 by Simon Tatham and team.
This is a maintenance release with a few small fixes and improvements.
CHANGES
===
- The window title can now include characters from the full Unicode
range rather than being limited to the system's ANSI codepage.
- When resizing the window, the sizetip moves with the upper left
corner of the window rather than being marooned at its original
position.
- Added one pixel of padding inside the window border to stop
characters from touching it. (PuTTY had that, but I'd unwisely removed
it.)
- Alt+Numpad codes work when NumLock is off as well. In UTF-8 mode, Alt
+1 to Alt+31 are interpreted as graphical OEM characters, e.g. Alt+3
is ♥ and Alt+1 is ☺.
- Alt works as the Meta modifier for AltGr combinations, e.g. Alt+AltGr
+7 on a German keyboard now sends ^[{ rather than just {.
- Added Xterm window focus reporting. (^[?1004h to enable, ^[?1004l
disable. ^[[I is sent for focus in and ^[[O for focus out.)
- Applications can ask to be notified when the width of the CJK
Ambiguous Width characters changes due to the user changing font. ^[?
7700h to enable, ^[?7700l to disable. ^[[1W is sent for cjknarrow
mode, and ^[[2W for cjkwide mode. Removed attempted SIGWINCH
notification for the same purpose, because it didn't work.
- Bell overload detection wasn't working, but I decided to remove it
instead of fixing it and to switch off the bell in the default config,
because I'm guessing most people don't want to be beeped or flashed at
by their terminal anyway.
More on these changes can be found at
http://code.google.com/p/mintty/issues/list?can=1q=Milestone%3A0.4.1
QUESTIONS
=
MinTTY's project page is located at http://mintty.googlecode.com.
Please use the issue tracker there to report bugs or suggest
enhancements. Questions or comments can be sent to the MinTTY
discussion group at http://groups.google.com/group/mintty-discuss or
the Cygwin mailing list at cygwin@cygwin.com .
To update your installation, click on the Install Cygwin now link
on the http://cygwin.com/ web page. This downloads setup.exe to
your system. Then, run setup and answer all of the questions.
*** 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
--
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: Possible file permission errors in 'base-files'
On Jun 20 12:59, Mark Harig wrote: The two files 'base-files-mketc.sh' and 'base-files-profiles.sh' included in the 'base-files' package have their permissions set to 644 while all other scripts in /etc/postinstall/ have their permissions set to 755. Is this a side-effect of 'base-files-profiles.sh' not completing without errors, or is this set in the packaging? (Technically, the files with the permission problems are /etc/postinstall/base-files-mketc.sh.done and /etc/postinstall/base-files-profiles.sh.done.) Technically it's a packaging bug. The scripts should have execute permissions like all the shell scripts in /etc/postinstall and /etc/preremove. John, I fixed that on Sourceware and created a 3.8-4 package with execute permissions for postinstall and preremove scripts. It shouldn't affect postinstall, though. When calling `bash -c script', then bash runs these scripts as long as the user has read permissions on Cygwin. Which is actually kind of a bug in Cygwin. I've put that on my TODO list. 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: Some files are missing from cygwin-doc version 1.5-1
On Jun 20 11:07, Mark Harig wrote: setup-1.7.exe installs the package 'cygwin-doc', version 1.5-1. This package includes /usr/share/info/cygwin.info. cygwin.info references two files, 'cygwin-ug-net.info' and 'cygwin-api.info', which are not included in 'cygwin-doc': $ cygcheck -c cygwin-doc Cygwin Package Information Package Version Status cygwin-doc1.5-1 OK $ cygcheck -l cygwin-doc | grep /usr/share/info/cygwin /usr/share/info/cygwin.info cygwin-doc has no official maintainer right now. Admittedly it needs a bit of revamping and, ideally, a new maintainer. 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: Cygwin 1.7: Possible file permission errors in 'base-files'
On Mon, June 22, 2009 10:43 am, Corinna Vinschen wrote: On Jun 20 12:59, Mark Harig wrote: The two files 'base-files-mketc.sh' and 'base-files-profiles.sh' included in the 'base-files' package have their permissions set to 644 while all other scripts in /etc/postinstall/ have their permissions set to 755. Is this a side-effect of 'base-files-profiles.sh' not completing without errors, or is this set in the packaging? (Technically, the files with the permission problems are /etc/postinstall/base-files-mketc.sh.done and /etc/postinstall/base-files-profiles.sh.done.) Technically it's a packaging bug. The scripts should have execute permissions like all the shell scripts in /etc/postinstall and /etc/preremove. John, I fixed that on Sourceware and created a 3.8-4 package with execute permissions for postinstall and preremove scripts. It shouldn't affect postinstall, though. When calling `bash -c script', then bash runs these scripts as long as the user has read permissions on Cygwin. Which is actually kind of a bug in Cygwin. I've put that on my TODO list. Thanks, I'll change my 'source' version. I probably changed the permissions higher up with recursion and, since setup never complained, never noticed. J. -- 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
gvim errors on launch, 1.7
from xterm I get 2 errors. They are inconsistent, but one or the other seems to happen within 1 or 2 starts of gvim. It continues to run after this one. $ /bin/gvim 2 [main] gvim 5804 child_copy: linked dll data write copy failed, 0x2B7000..0x2B76CC, done 0, windows pid 6048, Win32 error 487 xterm completely locks up on this one: $ /bin/gvim 2 [main] gvim 6108 F:\cygwin\bin\gvim.exe: *** fatal error - unable to remap \\?\F:\cygwin\lib\gtk-2.0\2.4.0\loaders\cygpixbufloader-xpm.dll to same address as parent(0x3D) != 0x3E - Ian Kelling Cygwin Configuration Diagnostics Current System Time: Mon Jun 22 03:10:51 2009 Windows Vista Ultimate Ver 6.0 Build 6002 Service Pack 2 Running under WOW64 on AMD64 Path: F:\cygwin\m\local\nzbget\bin F:\cygwin\m\local\bash\bin F:\cygwin\usr\local\bin F:\cygwin\bin F:\cygwin\bin F:\cygwin\usr\X11R6\bin C:\GTK\bin C:\Windows\system32 C:\Windows C:\Windows\System32\Wbem C:\Program Files (x86)\Microsoft SQL Server\90\Tools\binn\ C:\Windows\System32\WindowsPowerShell\v1.0\ F:\cygwin\usr\X11R6\bin F:\cygwin\usr\X11R6\bin F:\cygwin\usr\local\git\bin F:\cygwin\m\bin F:\cygwin\m\local\bin Output from F:\cygwin\bin\id.exe (nontsec) UID: 1000(ian) GID: 513(None) 0(root) 544(Administrators) 545(Users) 513(None) Output from F:\cygwin\bin\id.exe (ntsec) UID: 1000(ian) GID: 513(None) 0(root) 544(Administrators) 545(Users) 513(None) SysDir: C:\Windows\system32 WinDir: C:\Windows USER = 'ian' PWD = '/a' HOME = '/a' HOMEPATH = '\Users\ian' MANPATH = '/usr/local/man:/usr/share/man:/usr/man::/usr/ssl/man' APPDATA = 'C:\Users\ian\AppData\Roaming' ProgramW6432 = 'C:\Program Files' HOSTNAME = 'vd' TERM = 'xterm' PROCESSOR_IDENTIFIER = 'Intel64 Family 6 Model 15 Stepping 11, GenuineIntel' WINDIR = 'C:\Windows' WINDOWID = '2097183' PUBLIC = 'C:\Users\Public' OLDPWD = '/usr/bin' USERDOMAIN = 'vd' CommonProgramFiles(x86) = 'C:\Program Files (x86)\Common Files' OS = 'Windows_NT' ALLUSERSPROFILE = 'C:\ProgramData' XTERM_SHELL = '/bin/bash' LS_COLORS = 'no=00:fi=00:di=01;34:ln=01;36:pi=40;33:so=01;35:do=01;35:bd=40;33;01:cd=40;33;01:or=40;31;01:su=37;41:sg=30;43:tw=30;42:ow=34;42:st=37;44:ex=01;32:*.tar=01;31:*.tgz=01;31:*.svgz=01;31:*.arj=01;31:*.taz=01;31:*.lzh=01;31:*.lzma=01;31:*.zip=01;31:*.z=01;31:*.Z=01;31:*.dz=01;31:*.gz=01;31:*.bz2=01;31:*.bz=01;31:*.tbz2=01;31:*.tz=01;31:*.deb=01;31:*.rpm=01;31:*.jar=01;31:*.rar=01;31:*.ace=01;31:*.zoo=01;31:*.cpio=01;31:*.7z=01;31:*.rz=01;31:*.jpg=01;35:*.jpeg=01;35:*.gif=01;35:*.bmp=01;35:*.pbm=01;35:*.pgm=01;35:*.ppm=01;35:*.tga=01;35:*.xbm=01;35:*.xpm=01;35:*.tif=01;35:*.tiff=01;35:*.png=01;35:*.svg=01;35:*.mng=01;35:*.pcx=01;35:*.mov=01;35:*.mpg=01;35:*.mpeg=01;35:*.m2v=01;35:*.mkv=01;35:*.ogm=01;35:*.mp4=01;35:*.m4v=01;35:*.mp4v=01;35:*.vob=01;35:*.qt=01;35:*.nuv=01;35:*.wmv=01;35:*.asf=01;35:*.rm=01;35:*.rmvb=01;35:*.flc=01;35:*.avi=01;35:*.fli=01;35:*.gl=01;35:*.dl=01;35:*.xcf=01;35:*.xwd=01;35:*.yuv=01;35:*.aac=00;36:*.au=00;36:*.flac=00;36:*.mid=00;36:*.midi=00;36:*.mka=00;36:*.mp3=00;36:*.mpc=00;36:*.ogg=00;36:*.ra=00;36:*.wav=00;36:' VS90COMNTOOLS = 'C:\Program Files (x86)\Microsoft Visual Studio 9.0\Common7\Tools\' TEMP = '/c/Users/ian/AppData/Local/Temp' COMMONPROGRAMFILES = 'C:\Program Files (x86)\Common Files' GTK_BASEPATH = 'C:\GTK' TERMCAP = 'xterm-r6|xterm|xterm X11R6 version:am:km:mi:ms:xn:co#80:it#8:li#24:AL=\E[%dL:DC=\E[%dP:DL=\E[%dM:DO=\E[%dB:LE=\E[%dD:RI=\E[%dC:UP=\E[%dA:ae=^O:al=\E[L:as=^N:bl=^G:cd=\E[J:ce=\E[K:cl=\E[H\E[2J:cm=\E[%i%d;%dH:cr=^M:cs=\E[%i%d;%dr:ct=\E[3g:dc=\E[P:dl=\E[M:do=^J:ei=\E[4l:ho=\E[H:im=\E[4h:is=\E7\E[r\E[m\E[?7h\E[?1;3;4;6l\E[4l\E8\E:k1=\EOP:k2=\EOQ:k3=\EOR:k4=\EOS:k5=\E[15~:k6=\E[17~:k7=\E[18~:k8=\E[19~:k9=\E[20~:kD=\E[3~:kI=\E[2~:kN=\E[6~:kP=\E[5~:kd=\EOB:ke=\E[?1l\E:kh=\E[1~:kl=\EOD:kr=\EOC:ks=\E[?1h\E=:ku=\EOA:le=^H:md=\E[1m:me=\E[m:mr=\E[7m:nd=\E[C:rc=\E8:sc=\E7:se=\E[m:sf=^J:so=\E[7m:sr=\EM:ta=^I:te=\E[2J\E[?47l\E8:ti=\E7\E[?47h:ue=\E[m:up=\E[A:us=\E[4m:kb=\010:' USERNAME = 'ian' PROCESSOR_LEVEL = '6' ProgramFiles(x86) = 'C:\Program Files (x86)' FP_NO_HOST_CHECK = 'NO' SYSTEMDRIVE = 'C:' PROCESSOR_ARCHITEW6432 = 'AMD64' __COMPAT_LAYER = 'ElevateCreateProcess ' USERPROFILE = 'C:\Users\ian' PS1 = '\W \[[34m\]\$\[(B[m\] ' LOGONSERVER = '\\VD' CommonProgramW6432 = 'C:\Program Files\Common Files' PROCESSOR_ARCHITECTURE = 'x86' LOCALAPPDATA = 'C:\Users\ian\AppData\Local' XTERM_LOCALE = 'C' XTERM_VERSION = 'Cygwin 6.8.99.903(242)' ProgramData = 'C:\ProgramData' MANPAGER = 'vimmanpager' SHLVL = '1' PATHEXT = '.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.MSC' HOMEDRIVE = 'C:' ian = 'i...@68.7.135.174' COMSPEC = 'C:\Windows\system32\cmd.exe' LOGNAME = 'ian' TMP = '/c/Users/ian/AppData/Local/Temp' SYSTEMROOT = 'C:\Windows' PRINTER = 'HP LaserJet 6L' CVS_RSH = '/bin/ssh' PROCESSOR_REVISION =
Re: gvim errors on launch, 1.7
On Jun 22 03:12, Ian Kelling wrote: from xterm I get 2 errors. They are inconsistent, but one or the other seems to happen within 1 or 2 starts of gvim. It continues to run after this one. $ /bin/gvim 2 [main] gvim 5804 child_copy: linked dll data write copy failed, 0x2B7000..0x2B76CC, done 0, windows pid 6048, Win32 error 487 xterm completely locks up on this one: $ /bin/gvim 2 [main] gvim 6108 F:\cygwin\bin\gvim.exe: *** fatal error - unable to remap \\?\F:\cygwin\lib\gtk-2.0\2.4.0\loaders\cygpixbufloader-xpm.dll to same address as parent(0x3D) != 0x3E Try with the latest Cygwin DLL: http://cygwin.com/ml/cygwin-announce/2009-06/msg00028.html If that doesn't work, try rebasing: $ less /usr/share/doc/Cygwin/rebase-3.0.README 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: Possible Bug or limitation in Cygwin 1.7 and Rsync and file number limit
On Jun 19 15:55, Lists wrote: snip Can you upgrade to the latest Cygwin 1.7 package and try again. From your cygcheck output, it looks like things are not correct but this may be just a problem with an old cygcheck that doesn't know how to find the implicit mounts. If the issue is still the same, resending the output of the new cygcheck would be helpful. I just downloaded the newest version of cygwin 1.7 as of 6-19-09 at approximately 3:30 CST and had the exact same results. Please find the new cygcheck.out file attached. You mentioned above that their might be a problem with the mounts. Not sure if it helps to know this, but I can successfully use rsync to copy many gigabytes of files. It just hangs when there are thousands of files in a single directory (9,000 seems to always do it.). Also note that this cygcheck was done on a different computer than the first just to make sure this isn't computer specific. Again, I have tried it on several. Works fine for me under the latest Cygwin 1.7.0-50 using your perl script and your rsync options. I tend to agree to Larry's assumption that some 3PP is interferring. 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
HEADSUP maintainers: Packages install scripts without execute permissions
Hi, Here's the problem: If you exec shell scripts, they should only be run if the user trying to run the script has execute permissions on the script. This requires to check for executability in Cygwin, but as of today, such a check isn't performed in Cygwin. I have the patch for this ready, but I found that it would potentially break a couple of packages which have not set execute permissions on some of their script files. As you should know by now, setup for Cygwin 1.7 will set POSIX file permissions for the files extracted from the tar archives. That means, all scripts which don't have execute permissions set, will also not have execute permissions set after the user installed them. That's bad. So I created a list of packages which install scripts into /etc/preremove, /etc/postinstall, and /usr/bin without setting execute permissions on them. Please guys, fix the permissions ASAP. Corinna Vinschen: robots: etc/postinstall/robots.sh Reini Urban: perl: usr/bin/cpan5.10.0 usr/bin/shasum5.10.0 Christian Franke: ddrescue: etc/postinstall/ddrescue.sh Jari Aalto: colorgcc: etc/postinstall/colorgcc.sh joe: etc/postinstall/joe-manifest.lst Frank Seelisch: singular-icons: etc/postinstall/singular-icons.sh Dave Korn: gcc-core: etc/postinstall/gcc.sh etc/preremove/gcc.sh gcc-gnat: etc/postinstall/gcc-gnat.sh etc/preremove/gcc-gnat.sh gcc-gdc: etc/postinstall/gcc-gdc.sh etc/preremove/gcc-gdc.sh gcc-gpc: etc/postinstall/gcc-gpc.sh etc/preremove/gcc-gpc.sh gcc-g++: etc/postinstall/gcc-g++.sh etc/preremove/gcc-g++.sh gcc-g77: etc/postinstall/gcc-g77.sh etc/preremove/gcc-g77.sh gcc-java: etc/postinstall/gcc-java.sh etc/preremove/gcc-java.sh Yaakov S: perl-extutils-pkgconfig: etc/postinstall/perl-ExtUtils-Pk libgnome2:etc/preremove/libgnome2.sh gnome-vfs:etc/preremove/gnome-vfs2.sh ilibIDL: etc/postinstall/libIDL.sh libIDL2: etc/postinstall/libIDL2.sh Btw., DLLs should also be executable, otherwise applications will fail to start. I found one of them: glib: usr/bin/cyggmodule-1-2-0.dll Thanks, 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: HEADSUP maintainers: Packages install scripts without execute permissions
Corinna Vinschen wrote: Hi, Here's the problem: If you exec shell scripts, they should only be run if the user trying to run the script has execute permissions on the script. Shell scripts don't _have_ to be executable, only if you want to launch one as if it were a command, rather than sourcing it. Why don't we just remove the -c and get setup.exe to use the simple bash filename syntax meaning treat filename as a text file, open it and pipe it to stdin? [da...@ubique src]$ cat happy-script-file.txt echo I am a happy script file! [da...@ubique src]$ ls -la happy-script-file.txt -rw-rw-r-- 1 davek davek 33 2009-06-22 14:35 happy-script-file.txt [da...@ubique src]$ ./happy-script-file.txt bash: ./happy-script-file.txt: Permission denied [da...@ubique src]$ bash -c ./happy-script-file.txt bash: ./happy-script-file.txt: Permission denied [da...@ubique src]$ bash ./happy-script-file.txt I am a happy script file! [da...@ubique src]$ AFAIK this final syntax is equivalent to writing cat happy-script-file.txt | bash, where of course the execute bits couldn't make any difference. cheers, DaveK -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: HEADSUP maintainers: Packages install scripts without execute permissions
On Jun 22 14:38, Dave Korn wrote: Corinna Vinschen wrote: Hi, Here's the problem: If you exec shell scripts, they should only be run if the user trying to run the script has execute permissions on the script. Shell scripts don't _have_ to be executable, only if you want to launch one as if it were a command, rather than sourcing it. Oh well, I really thought that would go without saying. Yes, sure, you're right. That's at least the case for scripts in /bin or /usr/bin and that's not invalidated by your below objection. Why don't we just remove the -c and get setup.exe to use the simple bash filename syntax meaning treat filename as a text file, open it and pipe it to stdin? I already suggested this on the cygwin-developers ML back in May (*) but it was not discussed overly enthusiastic (**) (***). Corinna (*) http://cygwin.com/ml/cygwin-developers/2009-05/msg00045.html (**) http://cygwin.com/ml/cygwin-developers/2009-05/msg00047.html (***) http://cygwin.com/ml/cygwin-developers/2009-05/msg00050.html -- 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: HEADSUP maintainers: Packages install scripts without execute permissions
Corinna Vinschen corinna-cygwin at cygwin.com writes: Why don't we just remove the -c and get setup.exe to use the simple bash filename syntax meaning treat filename as a text file, open it and pipe it to stdin? I already suggested this on the cygwin-developers ML back in May (*) but it was not discussed overly enthusiastic (**) (***). Indeed - changing things to be 'bash script' instead of the current 'bash -c script' would make the use of alternative interpreters harder. But it does not make it impossible; you can always do: #!/bin/sh /bin/awk \EOF ... EOF instead of #!/bin/awk ... For that matter, are there any postinstall scripts currently relying on a different interpreter? If not, then I'm in favor of the idea of changing setup.exe to be immune to the execute bit on postinstall scripts, at the expense of making postinstall scripts locked into bash (at least, as the initial interpreter). -- Eric Blake -- 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: HEADSUP maintainers: Packages install scripts without execute ?permissions
On Jun 22 13:58, Eric Blake wrote: Corinna Vinschen corinna-cygwin at cygwin.com writes: Why don't we just remove the -c and get setup.exe to use the simple bash filename syntax meaning treat filename as a text file, open it and pipe it to stdin? I already suggested this on the cygwin-developers ML back in May (*) but it was not discussed overly enthusiastic (**) (***). Indeed - changing things to be 'bash script' instead of the current 'bash -c script' would make the use of alternative interpreters harder. But it does not make it impossible; you can always do: #!/bin/sh /bin/awk \EOF ... EOF instead of #!/bin/awk ... For that matter, are there any postinstall scripts currently relying on a different interpreter? If not, then I'm in favor of the idea of changing setup.exe to be immune to the execute bit on postinstall scripts, at the expense of making postinstall scripts locked into bash (at least, as the initial interpreter). There can be only *.bat and *.sh files in /etc/postinstall and /etc/preremove. *.bat files are started via `cmd /c file' and *.sh files are started via `bash --norc --noprofile -c file'. So we sort of require a script to be a sh/bash script anyway right now. Admittedly, I did not actually *look* into all postinstall/preremove scripts in the distro. 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: Some files are missing from cygwin-doc version 1.5-1
On Mon, Jun 22, 2009 at 11:44:49AM +0200, Corinna Vinschen wrote: On Jun 20 11:07, Mark Harig wrote: setup-1.7.exe installs the package 'cygwin-doc', version 1.5-1. This package includes /usr/share/info/cygwin.info. cygwin.info references two files, 'cygwin-ug-net.info' and 'cygwin-api.info', which are not included in 'cygwin-doc': $ cygcheck -c cygwin-doc Cygwin Package Information Package Version Status cygwin-doc1.5-1 OK $ cygcheck -l cygwin-doc | grep /usr/share/info/cygwin /usr/share/info/cygwin.info cygwin-doc has no official maintainer right now. Admittedly it needs a bit of revamping and, ideally, a new maintainer. I volunteered to maintain this a while ago. I have a newer, incomplete version sitting in a sandbox but it will be 1.7 only and no guarantees on when it will be available. 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: Possible file permission errors in 'base-files'
On Mon, Jun 22, 2009 at 11:43:10AM +0200, Corinna Vinschen wrote: On Jun 20 12:59, Mark Harig wrote: The two files 'base-files-mketc.sh' and 'base-files-profiles.sh' included in the 'base-files' package have their permissions set to 644 while all other scripts in /etc/postinstall/ have their permissions set to 755. Is this a side-effect of 'base-files-profiles.sh' not completing without errors, or is this set in the packaging? (Technically, the files with the permission problems are /etc/postinstall/base-files-mketc.sh.done and /etc/postinstall/base-files-profiles.sh.done.) Technically it's a packaging bug. The scripts should have execute permissions like all the shell scripts in /etc/postinstall and /etc/preremove. John, I fixed that on Sourceware and created a 3.8-4 package with execute permissions for postinstall and preremove scripts. It shouldn't affect postinstall, though. When calling `bash -c script', then bash runs these scripts as long as the user has read permissions on Cygwin. Which is actually kind of a bug in Cygwin. I've put that on my TODO list. Sounds like we should drop the -c. 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
default codepage
Since the latest locale-related changes, the default codepage after starting cygwin _without_ explicit setting (of a locale variable) seems to have changed from CP1252 (Windows ANSI) to ISO 8859-1 (Latin 1). Was this change on purpose? Maybe the previous default should be kept, to meet backwards compatibility expectations of 1.5 users. Thomas -- 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: Some files are missing from cygwin-doc version 1.5-1
On Jun 22 10:34, Christopher Faylor wrote: On Mon, Jun 22, 2009 at 11:44:49AM +0200, Corinna Vinschen wrote: On Jun 20 11:07, Mark Harig wrote: setup-1.7.exe installs the package 'cygwin-doc', version 1.5-1. This package includes /usr/share/info/cygwin.info. cygwin.info references two files, 'cygwin-ug-net.info' and 'cygwin-api.info', which are not included in 'cygwin-doc': $ cygcheck -c cygwin-doc Cygwin Package Information Package Version Status cygwin-doc1.5-1 OK $ cygcheck -l cygwin-doc | grep /usr/share/info/cygwin /usr/share/info/cygwin.info cygwin-doc has no official maintainer right now. Admittedly it needs a bit of revamping and, ideally, a new maintainer. I volunteered to maintain this a while ago. I have a newer, incomplete version sitting in a sandbox but it will be 1.7 only and no guarantees on when it will be available. Uh, good. I forgot about that. From my POV 1.7 is sufficient. 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 avoid having shell scripts which fail from killing Emacs shell?
I've often been annoyed by shell scripts which fail for particular reasons, at which point it causes my Emacs shell buffer to get killed, with Process shell2 finished. I think it's possible to code the scripts to use trap, which might avoid this problem, but sometimes (most times, really) I can't change the script. Is there some way to configure Bash/Cygwin, perhaps in the .emacs_bash script to mitigate this, without significant tradeoffs? -- 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: HEADSUP maintainers: Packages install scripts without execute ?permissions
On Jun 22 16:09, Corinna Vinschen wrote: On Jun 22 13:58, Eric Blake wrote: For that matter, are there any postinstall scripts currently relying on a different interpreter? If not, then I'm in favor of the idea of changing setup.exe to be immune to the execute bit on postinstall scripts, at the expense of making postinstall scripts locked into bash (at least, as the initial interpreter). There can be only *.bat and *.sh files in /etc/postinstall and /etc/preremove. *.bat files are started via `cmd /c file' and *.sh files are started via `bash --norc --noprofile -c file'. So we sort of require a script to be a sh/bash script anyway right now. Admittedly, I did not actually *look* into all postinstall/preremove scripts in the distro. I just checked the entire 1.7 distro and here's the result: We have not a single package left which uses a .bat file in postinstall or in preremove. That's great, IMHO. And, AFAICS, all of the *.sh fiels are actually some variation of sh/ash/bash script. So I assume it's safe to remove the -c from setup's script starter method. 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: default codepage
On Jun 22 16:48, Thomas Wolff wrote: Since the latest locale-related changes, the default codepage after starting cygwin _without_ explicit setting (of a locale variable) seems to have changed from CP1252 (Windows ANSI) to ISO 8859-1 (Latin 1). Was this change on purpose? There was no such change at all. The default codepage is still the default ANSI codepage on your system. The internal conversion from Windows functions to the POSIX multibyte environment and vice versa uses UTF-8, though, so that all existing filenames have a valid representation even when using characters not available in your current codepage. 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
Cygwin 1.7 Installation on Server 2008 with Terminal Services
The post install .sh scripts fail to run on Server 2008 with Terminal Services because bash crashes. Crash can be fixed using peflags and setting the Terminal Services aware bit on (solution found on the mailing list). Is there a recommended way to get the Terminal Services aware bit on before the post install happens? Or more generically, is there a recommended way of installing Cygwin on Server 2008 with Terminal Services? Thanks 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
[ANNOUNCEMENT] [1.7] Updated: mathomatic-14.4.5-1
Major bugfixes overall. See http://mathomatic.orgserve.de/changes.txt Cygwin build changes: * cygwin-1.7, gcc-4 About: Mathomatic is a highly portable, general purpose symbolic math program that can solve, simplify, combine, differentiate, integrate, and compare algebraic equations. It can do standard, complex number, and polynomial arithmetic. It is extremely easy to use and has pretty colored, easily readable display of equations. See http://www.mathomatic.org/ To update your installation, click on the Install Cygwin now link on the http://cygwin.com/ web page. This downloads setup.exe to your system. Then, run setup and answer all of the questions. *** 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://sources.redhat.com/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. -- Reini Urban mathomatic support under Cygwin at cygwin@cygwin.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
weird feature
Hi, I know that my question could be a bit astonishing but I am not afraid to ask it ;-) I am trying to compile a software for symbian platform and originally they have released a SDK on windows linked with mingw and where you use a DOS terminal to compile. They have designed some build system mixing mingw/perl/dos command (yuk!) but I don't want to follow their logic and I wouldn't like to install mingw (last time I tried I had so many issues I don't want to try again). So my question is would it be possible for cygwin to understand path like that : /myfolder/foo instead of /cygdrive/c/myfolder/foo What I mean is it seems that their toolchain is considering /... as DRIVELETTER_WHERE_ITS_INSTALLED/... Would it be possible I don't know by declaring a env var to allow that kind of behavior ? So we would be able to go to 'unix' folder (cd /usr) and to real windows folders (cd /Windows). -- 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 Installation on Server 2008 with Terminal Services
On Jun 22 10:07, Hortenstine, John wrote: The post install .sh scripts fail to run on Server 2008 with Terminal Services because bash crashes. Crash can be fixed using peflags and setting the Terminal Services aware bit on (solution found on the mailing list). Is there a recommended way to get the Terminal Services aware bit on before the post install happens? Or more generically, is there a recommended way of installing Cygwin on Server 2008 with Terminal Services? Quite inconvenient, but working: For the time being, until we have a gcc which sets the TS-aware flag by default and most of the executables have been rebuilt with it, switch DEP to Turn on DEP for essential Windows programs and services only and reboot the machine. Then install via setup.exe and use peflags to set the TS-aware flag in all executables. 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: weird feature
On Mon, 22 Jun 2009 17:15:18 +0200, Vincent R. foru...@smartmobili.com wrote: Hi, I know that my question could be a bit astonishing but I am not afraid to ask it ;-) I am trying to compile a software for symbian platform and originally they have released a SDK on windows linked with mingw and where you use a DOS terminal to compile. They have designed some build system mixing mingw/perl/dos command (yuk!) but I don't want to follow their logic and I wouldn't like to install mingw (last time I tried I had so many issues I don't want to try again). So my question is would it be possible for cygwin to understand path like that : /myfolder/foo instead of /cygdrive/c/myfolder/foo What I mean is it seems that their toolchain is considering /... as DRIVELETTER_WHERE_ITS_INSTALLED/... Would it be possible I don't know by declaring a env var to allow that kind of behavior ? So we would be able to go to 'unix' folder (cd /usr) and to real windows folders (cd /Windows). Hum think there are mount options where I could find some happiness. Need to read doc. -- 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: weird feature
On Mon, 22 Jun 2009 17:38:10 +0200, Vincent R. foru...@smartmobili.com wrote: On Mon, 22 Jun 2009 17:15:18 +0200, Vincent R. foru...@smartmobili.com wrote: Hi, I know that my question could be a bit astonishing but I am not afraid to ask it ;-) I am trying to compile a software for symbian platform and originally they have released a SDK on windows linked with mingw and where you use a DOS terminal to compile. They have designed some build system mixing mingw/perl/dos command (yuk!) but I don't want to follow their logic and I wouldn't like to install mingw (last time I tried I had so many issues I don't want to try again). So my question is would it be possible for cygwin to understand path like that : /myfolder/foo instead of /cygdrive/c/myfolder/foo What I mean is it seems that their toolchain is considering /... as DRIVELETTER_WHERE_ITS_INSTALLED/... Would it be possible I don't know by declaring a env var to allow that kind of behavior ? So we would be able to go to 'unix' folder (cd /usr) and to real windows folders (cd /Windows). Hum think there are mount options where I could find some happiness. Need to read doc. Actually my question is more about interoperability bewteen mingw and cygwin. For instance here is the working command line I am using : arm-none-symbianelf-gcc -o conftest ... c:/gynoid/sdks/symbian/Nokia_N97_SDK_v0.5/epoc32/release/armv5/urel/eexe.lib If I replace c:/gynoid by /c/gynoid or even by /cygdrive/c/gynoid it doesn't work because I suppose toolchain only understand windows path c:/... : arm-none-symbianelf-gcc -o conftest ... /c/gynoid/sdks/symbian/Nokia_N97_SDK_v0.5/epoc32/release/armv5/urel/eexe.lib arm-none-symbianelf-gcc.exe: /c/cygdrive/gynoid/sdks/symbian/Nokia_N97_SDK_v0.5/epoc32/release/armv5/urel/eexe.lib: No such file or directory arm-none-symbianelf-gcc -o conftest ... /cygdrive/c/gynoid/sdks/symbian/Nokia_N97_SDK_v0.5/epoc32/release/armv5/urel/eexe.lib arm-none-symbianelf-gcc.exe: /cygdrive/c/gynoid/sdks/symbian/Nokia_N97_SDK_v0.5/epoc32/release/armv5/urel/eexe.lib: No such file or directory Is it possible to make this toolchain works with cygwin path style ? -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
[1.7] sshd dc problem
Starting the laptop at home, without PDC connection works. I can properly login. But ssh to this box fails with -1 = initgroups (URBANR, 10513) This is without cyglsa $ /usr/sbin/sshd -d -D 25 592959 [main] sshd 5208 fhandler_tty_slave::write: (680): tty output_mutex: acquired debug1: temporarily_use_uid: 17966/10513 (e=18/544) 24 592983 [main] sshd 5208 fhandler_tty_slave::write: (723): tty output_mutex released 2243125 2836108 [main] sshd 5208 seterrno_from_win_error: /ext/build/netrel/src/cygwin-1.7.0-50/winsup/cygwin/sec_auth.cc:195 windows error 1355 45131 2881239 [main] sshd 5208 geterrno_from_win_error: unknown windows error 1355, setting errno to 13 25 2881264 [main] sshd 5208 __set_errno: void seterrno_from_win_error(const char*, int, DWORD):319 val 13 1785 2883049 [main] sshd 5208 seterrno_from_win_error: /ext/build/netrel/src/cygwin-1.7.0-50/winsup/cygwin/sec_auth.cc:256 windows error 2221 34 2883083 [main] sshd 5208 geterrno_from_win_error: unknown windows error 2221, setting errno to 13 23 2883106 [main] sshd 5208 __set_errno: void seterrno_from_win_error(const char*, int, DWORD):319 val 13 46 2883152 [main] sshd 5208 initgroups32: -1 = initgroups (URBANR, 10513) $ id URBANR uid=17966(URBANR) gid=10513(apache) groups=10513(apache) error 1355: DcGetDcName(PDC_REQUIRED) call failed error 2221: UserGetLocalGroups failed I should be able to login with pubkey to my box with sshd when windows lets me in also. sshd_config contains: StrictModes no UsePrivilegeSeparation no -- Reini Urban http://phpwiki.org/ http://murbreak.at/ -- 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: Re: fatal error - fork: can't reserve memory for stack
Thank you Marc for your help! It seems that your tools rebaseall peflagsall both run from a plain ash with no other Cygwin process running solve this problem for both, Cygwin 1.5 and Cygwin 1.7! Indeed I think the peflagsall might have been the magic one, as I am running through remote desktop connection on another machine! (And this sets the flag tsaware which seems to be related...) So after running the above two commands I do not get any such error any more. -- 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: weird feature
Vincent R. wrote: On Mon, 22 Jun 2009 17:38:10 +0200, Vincent R. foru...@smartmobili.com wrote: On Mon, 22 Jun 2009 17:15:18 +0200, Vincent R. foru...@smartmobili.com wrote: Hi, I know that my question could be a bit astonishing but I am not afraid to ask it ;-) I am trying to compile a software for symbian platform and originally they have released a SDK on windows linked with mingw and where you use a DOS terminal to compile. They have designed some build system mixing mingw/perl/dos command (yuk!) but I don't want to follow their logic and I wouldn't like to install mingw (last time I tried I had so many issues I don't want to try again). So my question is would it be possible for cygwin to understand path like that : /myfolder/foo instead of /cygdrive/c/myfolder/foo What I mean is it seems that their toolchain is considering /... as DRIVELETTER_WHERE_ITS_INSTALLED/... Would it be possible I don't know by declaring a env var to allow that kind of behavior ? So we would be able to go to 'unix' folder (cd /usr) and to real windows folders (cd /Windows). Hum think there are mount options where I could find some happiness. Need to read doc. Actually my question is more about interoperability bewteen mingw and cygwin. For instance here is the working command line I am using : arm-none-symbianelf-gcc -o conftest ... c:/gynoid/sdks/symbian/Nokia_N97_SDK_v0.5/epoc32/release/armv5/urel/eexe.lib If I replace c:/gynoid by /c/gynoid or even by /cygdrive/c/gynoid it doesn't work because I suppose toolchain only understand windows path c:/... : arm-none-symbianelf-gcc -o conftest ... /c/gynoid/sdks/symbian/Nokia_N97_SDK_v0.5/epoc32/release/armv5/urel/eexe.lib arm-none-symbianelf-gcc.exe: /c/cygdrive/gynoid/sdks/symbian/Nokia_N97_SDK_v0.5/epoc32/release/armv5/urel/eexe.lib: No such file or directory arm-none-symbianelf-gcc -o conftest ... /cygdrive/c/gynoid/sdks/symbian/Nokia_N97_SDK_v0.5/epoc32/release/armv5/urel/eexe.lib arm-none-symbianelf-gcc.exe: /cygdrive/c/gynoid/sdks/symbian/Nokia_N97_SDK_v0.5/epoc32/release/armv5/urel/eexe.lib: No such file or directory Is it possible to make this toolchain works with cygwin path style ? Not without compiling it with Cygwin, no. You do have alternatives: 1. Install Cygwin to your C: drive rather than C:\cygwin (or, if you know what you're doing, use 'mount' to manually achieve the same goal with your current installation). 2. Use 'cygpath' to convert from DOS to Cygwin path forms and back as needed. This can get tricky/cumbersome in some cases. 3. Use c:/ syntax. The last option is not guaranteed to work but may be the easiest to manage in the short-run. The first option (or some variant) is probably your best/most stable bet overall. -- Larry Hall http://www.rfk.com RFK Partners, Inc. (508) 893-9779 - RFK Office 216 Dalton Rd. (508) 893-9889 - FAX Holliston, MA 01746 _ A: Yes. Q: Are you sure? A: Because it reverses the logical flow of conversation. Q: Why is top posting annoying in email? -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Slow/sluggish response (system task at 50%)
Over time my cygwin responsiveness seems to have diminished. When compiling a project I can see that system task (not the system idle task) is running a lot at 50%. I don't know if this is normal or not. Possibly there is some corporate security s/w slowing it down now, I don't know. Or would possibly a reinstall of cygwin help? I have tried closing all other windows, rebooting etc but it is always slow. I don't notice a problem with other apps, just cygwin. Any other suggestions on what this could be? Thanks, -gene -- 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: Slow/sluggish response (system task at 50%)
Gene Smith wrote: Over time my cygwin responsiveness seems to have diminished. When compiling a project I can see that system task (not the system idle task) is running a lot at 50%. I don't know if this is normal or not. Possibly there is some corporate security s/w slowing it down now, I don't know. Or would possibly a reinstall of cygwin help? I have tried closing all other windows, rebooting etc but it is always slow. I don't notice a problem with other apps, just cygwin. Any other suggestions on what this could be? Typically? http://cygwin.com/acronyms/#BLODA is always a good guess. If that's not it, I recommend reviewing the problem reporting guidelines at the link below: Problem reports: http://cygwin.com/problems.html -- Larry Hall http://www.rfk.com RFK Partners, Inc. (508) 893-9779 - RFK Office 216 Dalton Rd. (508) 893-9889 - FAX Holliston, MA 01746 _ A: Yes. Q: Are you sure? A: Because it reverses the logical flow of conversation. Q: Why is top posting annoying in email? -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Slow/sluggish response (system task at 50%)
Larry Hall (Cygwin) wrote: Gene Smith wrote: Over time my cygwin responsiveness seems to have diminished. When compiling a project I can see that system task (not the system idle task) is running a lot at 50%. I don't know if this is normal or not. Possibly there is some corporate security s/w slowing it down now, I don't know. Or would possibly a reinstall of cygwin help? I have tried closing all other windows, rebooting etc but it is always slow. I don't notice a problem with other apps, just cygwin. Any other suggestions on what this could be? Typically? http://cygwin.com/acronyms/#BLODA is always a good guess. If that's not it, I recommend reviewing the problem reporting guidelines at the link below: I don't have any of the things specifically listed under BLODA. Problem reports: http://cygwin.com/problems.html I don't think it is a problem with cygwin itself. I was mainly curious if anyone sees the system task running 50% when doing a gcc build using Make (or similar intensive long term activity). I have weak XP based laptop with no corporate security that runs cygwin fine compared to my dual-core corporate desktop machine. I will check it on the laptop but it is not with me now. Thanks for the reply. -- 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: weird feature
Dave Korn wrote: Larry Hall (Cygwin) wrote: 2. Use 'cygpath' to convert from DOS to Cygwin path forms and back as needed. This can get tricky/cumbersome in some cases. It can be a lot easier if you have a Makefile-based build system, where you can do the conversion on things that you know need converting like $(SRC) and $(OBJS) and $(INCLUDEPATH) but not things like $(CFLAGS), rather than if you try and write shell scripts to wrap the compiler and parse the options. That can also be a good approach, but more work to get it completely right. In my experience, adding cygcheck does slow down a large build system *significantly* when adding cygpath's though. -Edward -- 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: HEADSUP maintainers: Packages install scripts without execute permissions
Eric Blake wrote: Indeed - changing things to be 'bash script' instead of the current 'bash -c script' would make the use of alternative interpreters harder. But it does not make it impossible; you can always do: #!/bin/sh /bin/awk \EOF ... EOF instead of #!/bin/awk Yes, but that does seem a bit awkward. cheers, DaveK -- *rimshot* -- 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: weird feature
Larry Hall (Cygwin) wrote: 2. Use 'cygpath' to convert from DOS to Cygwin path forms and back as needed. This can get tricky/cumbersome in some cases. It can be a lot easier if you have a Makefile-based build system, where you can do the conversion on things that you know need converting like $(SRC) and $(OBJS) and $(INCLUDEPATH) but not things like $(CFLAGS), rather than if you try and write shell scripts to wrap the compiler and parse the options. That can also be a good approach, but more work to get it completely right. cheers, DaveK -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: How to avoid having shell scripts which fail from killing Emacs shell?
On 6/22/2009 10:53 AM, David Karr wrote: I've often been annoyed by shell scripts which fail for particular reasons, at which point it causes my Emacs shell buffer to get killed, with Process shell2 finished. I don't recall ever seeing this happen, but maybe I just don't remember. Can you give me a simple test case? 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: Cygwin 1.7 Installation on Server 2008 with Terminal Services
Quite inconvenient, but working: For the time being, until we have a gcc which sets the TS-aware flag by default and most of the executables have been rebuilt with it, switch DEP to Turn on DEP for essential Windows programs and services only and reboot the machine. Then install via setup.exe and use peflags to set the TS-aware flag in all executables. Thank you. I tried your recommendation and it worked as far as I can tell. I just created a little batch wrapper to run setup and then turn on the TS-aware flag. Could you please add this to the 1.7 FAQ if you believe this might persist for a while? Thanks, 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
Some questions about mintty
My installed packages: $ cygcheck -c cygwin mintty Cygwin Package Information Package VersionStatus cygwin 1.7.0-50 OK mintty 0.4.1-1OK 1. There is no description of the '-e' switch in mintty's manual page. Is it an execute-this-command option? Or, should the user be aware that it is specific to execute this shell? 2. There is a '-p / --position' option described in the manual page. Is there a corresponding option for the ~/.minttyrc initialization file? (If so, I could not find a description of it in the manual page for mintty or /usr/share/doc/Cygwin/mintty-0.4.1.README.) 3. When the color of the cursor is changed to a block, the text can be read through the block, but it appears that the text is always white. Can the cursor's (reverse) text color be changed? If a light color is chosen for the cursor block, then the white text within the block is difficult to read. The behavior of xterm in X is that the cursor text is inverted, that is, it is dark if the cursor block is light, and light if the cursor block is dark. 4. Is is possible to view italic fonts (in italicized form) in mintty? I selected Italic and Bold Italic entries from the 'Font Style' list, but could not get mintty to accept/acknowledge those selections. Thanks to the author(s) of mintty for providing 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: How to avoid having shell scripts which fail from killing Emacs shell?
-Original Message- From: cygwin-ow...@cygwin.com [mailto:cygwin-ow...@cygwin.com] On Behalf Of Ken Brown Sent: Monday, June 22, 2009 12:26 PM To: cygwin@cygwin.com Subject: Re: How to avoid having shell scripts which fail from killing Emacs shell? On 6/22/2009 10:53 AM, David Karr wrote: I've often been annoyed by shell scripts which fail for particular reasons, at which point it causes my Emacs shell buffer to get killed, with Process shell2 finished. I don't recall ever seeing this happen, but maybe I just don't remember. Can you give me a simple test case? I'm not sure how complicated it needs to be. My test case gathers a couple of parameters and then calls a Java (JDK 1.6.0_14) class. The class throws an exception (file not found) in my test case (because I'm deliberately giving it parameters that will cause that). If I give it parameters that will avoid the exception, then it doesn't kill the shell. Is that enough information to build a test case with? -- 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 avoid having shell scripts which fail from killing Emacs shell?
On 6/22/2009 3:38 PM, David Karr wrote: -Original Message- From: cygwin-ow...@cygwin.com [mailto:cygwin-ow...@cygwin.com] On Behalf Of Ken Brown Sent: Monday, June 22, 2009 12:26 PM On 6/22/2009 10:53 AM, David Karr wrote: I've often been annoyed by shell scripts which fail for particular reasons, at which point it causes my Emacs shell buffer to get killed, with Process shell2 finished. I don't recall ever seeing this happen, but maybe I just don't remember. Can you give me a simple test case? I'm not sure how complicated it needs to be. My test case gathers a couple of parameters and then calls a Java (JDK 1.6.0_14) class. The class throws an exception (file not found) in my test case (because I'm deliberately giving it parameters that will cause that). If I give it parameters that will avoid the exception, then it doesn't kill the shell. Is that enough information to build a test case with? No. I don't have JDK installed, and I don't have any idea how it interacts with cygwin processes. If you can trigger the problem with a simple shell script that doesn't require JDK, I'll see if I can help. Or maybe someone on the list who does have JDK can suggest something for you to try. 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: gvim errors on launch, 1.7
Corinna Vinschen wrote: If that doesn't work, try rebasing: $ less /usr/share/doc/Cygwin/rebase-3.0.README Thank you. The latest cygwin dll did not help but rebasing fixed it. - Ian Kelling -- 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: weird feature
On Mon, Jun 22, 2009 at 03:10:19PM -0400, Edward Lam wrote: Dave Korn wrote: Larry Hall (Cygwin) wrote: 2. Use 'cygpath' to convert from DOS to Cygwin path forms and back as needed. This can get tricky/cumbersome in some cases. It can be a lot easier if you have a Makefile-based build system, where you can do the conversion on things that you know need converting like $(SRC) and $(OBJS) and $(INCLUDEPATH) but not things like $(CFLAGS), rather than if you try and write shell scripts to wrap the compiler and parse the options. That can also be a good approach, but more work to get it completely right. In my experience, adding cygcheck does slow down a large build system *significantly* when adding cygpath's though. I can't quite grok that sentence. Why would you add cygcheck to a build system? 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: HEADSUP maintainers: Packages install scripts without execute permissions
Corinna Vinschen wrote: So I created a list of packages which install scripts into /etc/preremove, /etc/postinstall, and /usr/bin without setting execute permissions on them. Please guys, fix the permissions ASAP. [...] Christian Franke: ddrescue: etc/postinstall/ddrescue.sh Hi Corinna, The postinstall script is only present in the [prev] release ddrescue-1.8-1 but not in ddrescue-1.9-1. If the script is considered a problem for Cygwin 1.7, I would suggest to simply remove 1.8-1 from release-2/ddrescue. Christian -- 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: weird feature
Christopher Faylor wrote: On Mon, Jun 22, 2009 at 03:10:19PM -0400, Edward Lam wrote: Dave Korn wrote: Larry Hall (Cygwin) wrote: 2. Use 'cygpath' to convert from DOS to Cygwin path forms and back as needed. This can get tricky/cumbersome in some cases. It can be a lot easier if you have a Makefile-based build system, where you can do the conversion on things that you know need converting like $(SRC) and $(OBJS) and $(INCLUDEPATH) but not things like $(CFLAGS), rather than if you try and write shell scripts to wrap the compiler and parse the options. That can also be a good approach, but more work to get it completely right. In my experience, adding cygcheck does slow down a large build system *significantly* when adding cygpath's though. ^^^ I can't quite grok that sentence. Why would you add cygcheck to a build system? Sorry, I meany cygpath. -Edward -- 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: weird feature
Edward Lam wrote: Dave Korn wrote: Larry Hall (Cygwin) wrote: 2. Use 'cygpath' to convert from DOS to Cygwin path forms and back as needed. This can get tricky/cumbersome in some cases. It can be a lot easier if you have a Makefile-based build system, where you can do the conversion on things that you know need converting like $(SRC) and $(OBJS) and $(INCLUDEPATH) but not things like $(CFLAGS), rather than if you try and write shell scripts to wrap the compiler and parse the options. That can also be a good approach, but more work to get it completely right. In my experience, adding cygcheck does slow down a large build system *significantly* when adding cygpath's though. Makefile variable caching can be done(*). And make very sure you use := not = when assigning a variable that might contain a $(shell)! There's still bound to be some overhead, but you can do a lot to optimise it away. cheers, DaveK -- (*) - http://www.cmcrossroads.com/content/view/7382/264/ -- 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: gvim errors on launch, 1.7
Corinna Vinschen wrote If that doesn't work, try rebasing: $ less /usr/share/doc/Cygwin/rebase-3.0.README Ugh. I followed the instructions and did rebaseall and peflagsall. It fixed gvim, but broke other things like this: perl 2084 F:\cygwin\bin\perl.exe: *** fatal error - unable to remap \\?\F:\cygwin\lib\perl5\5.10\i686-cygwin\auto\Fcntl\Fcntl.dll to same address as parent(0x91) != 0x15F I don't know what booleans and addresses things were set to previously, so now I'm looking at reinstalling cygwin :( I'm guessing to try again without the peflagsall. Any help would be appreciated. - Ian Kelling -- 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
HOWTO-Windows-Vista-Ultimate-32-bit-Cygwin-OpenSSH
cygwin: FYI -- I built another Vista machine and created a HOWTO for installing Cygwin and OpenSSH based on a prior thread: http://sourceware.org/ml/cygwin/2009-06/msg00454.html HTH, David -- 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
FW: HOWTO-Windows-Vista-Ultimate-32-bit-Cygwin-OpenSSH
cygwin: FYI -- I built another Vista machine and created a HOWTO for installing Cygwin and OpenSSH based on a prior thread: http://sourceware.org/ml/cygwin/2009-06/msg00454.html D'oh! Here's the HOWTO: http://www.holgerdanske.com/node/463 David -- 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: Slow/sluggish response (system task at 50%)
Gene Smith wrote: I don't think it is a problem with cygwin itself. I was mainly curious if anyone sees the system task running 50% when doing a gcc build using Make (or similar intensive long term activity). I have weak XP based laptop with no corporate security that runs cygwin fine compared to my dual-core corporate desktop machine. I will check it on the laptop but it is not with me now. Thanks for the reply. Attached is my cygcheck.out (some private info is redacted). I just did a compare by running the same make build using cygwin (rxvt), msys (also rxvt) and cmd. With msys and cmd I see system process running occasionally and for a short time at a maximum of 20% cpu. Usually I see the make process or just system idle and the build completes in about 22 seconds. With cygwin/rxvt, as described previously, I see system process at 40-50% (usually 50%) and nothing else using cpu comes to the top. The same build takes about 14 minutes on cygwin. Running in the standard cygwin shell (not rxvt) the time is the same, 14 minutes compared to 22 seconds under msys/rxvt and cmd shells. I removed the 2nd cygwin1.dll in the path that it warns about but it made no difference. Is there anything evident in the cygcheck that accounts for the extreme running of the windows system process with cygwin active? Cygwin Configuration Diagnostics Current System Time: Mon Jun 22 17:42:37 2009 Windows XP Professional Ver 5.1 Build 2600 Service Pack 2 Path: C:\cygwin\usr\local\bin C:\cygwin\bin C:\cygwin\bin C:\cygwin\usr\X11R6\bin c:\Program Files\Raisonance\Ride\arm-gcc\bin c:\WinAVR-20090313\bin c:\WinAVR-20090313\utils\bin C:\cygwin\bin C:\cygwin\usr\local\bin C:\cygwin\bin c:\Program Files\Common Files\REDACTED\Sqlany c:\Program Files\REDACTED\REDACTED\S7bin c:\WINDOWS\CatPC\CATSYS\BIN c:\Program Files\CatPC\Windows\System32 c:\WINDOWS\system32 c:\WINDOWS c:\WINDOWS\System32\Wbem c:\Program Files\Common Files\Autodesk Shared\ c:\PROGRA~1\NETMAN~1\System c:\Rational\ClearCase\bin c:\Rational\common c:\Program Files\PKWARE\pkzipc c:\WINDOWS\system32\WindowsPowerShell\v1.0 c:\Program Files\Vim\vim71 c:\Program Files\Raisonance\Ride\Bin Output from C:\cygwin\bin\id.exe (nontsec) UID: 51701(smited) GID: 10545(mkgroup-l-d) 0(root) 544(Administrators) 545(Users) 10545(mkgroup-l-d) Output from C:\cygwin\bin\id.exe (ntsec) UID: 51701(smited) GID: 10545(mkgroup-l-d) 0(root) 544(Administrators) 545(Users) 10545(mkgroup-l-d) SysDir: C:\WINDOWS\system32 WinDir: C:\WINDOWS USER = 'smited' PWD = '/cygdrive/c/Documents and Settings/smited/avr-play' HOME = '/cygdrive/c/Documents and Settings/smited' MAKE_MODE = 'unix' HOMEPATH = '\Documents and Settings\smited' MANPATH = '/usr/local/man:/usr/share/man:/usr/man::/usr/ssl/man' APPDATA = 'C:\Documents and Settings\smited\Application Data' SQLANY = 'C:\Program Files\Common Files\REDACTED\Sqlany' HOSTNAME = 'APHCZPLBD1DT' SHELL = '/bin/bash' TERM = 'cygwin' PROCESSOR_IDENTIFIER = 'x86 Family 6 Model 15 Stepping 6, GenuineIntel' WINDIR = 'C:\WINDOWS' SITESERVER = 'aph0e32a.us002.REDACTED.net' HOMELOC = 'US.APH' WINDOWID = '6881424' CLIENTVERSION = '2.12.93' OLDPWD = '/cygdrive/c/Documents and Settings/smited' USERDOMAIN = 'us002' OS = 'Windows_NT' ALLUSERSPROFILE = 'C:\Documents and Settings\All Users' http_proxy = 'http://aph0038a.us002.REDACTED.net:8080' VBSX = 'vbs' TEMP = '/cygdrive/c/DOCUME~1/smited/LOCALS~1/Temp' COMMONPROGRAMFILES = 'C:\Program Files\Common Files' USERNAME = 'smited' DEFPARDB = 'file:\\us002.REDACTED.net\rootdfs\ncip$\Config\Postsetup' INIX = 'ini' PROCESSOR_LEVEL = '6' DAS_HOME = 'C:\Program Files\DAS\' FP_NO_HOST_CHECK = 'NO' SYSTEMDRIVE = 'C:' DEPARTMENT = 'Corporate' USERPROFILE = 'C:\Documents and Settings\smited' PS1 = '\[\e]0;\w\a\]\n\[\e[32m\...@\h \[\e[33m\]\w\[\e[0m\]\n\$ ' LOGONSERVER = '\\JSCI002A' CLEARCASE_PRIMARY_GROUP = 'us002\jocy_clearcase_s7io' PROCESSOR_ARCHITECTURE = 'x86' !C: = 'C:\cygwin\bin' SHLVL = '1' COLORFGBG = '15;default;0' LSPROVID = 'SEA' USERDNSDOMAIN = 'US002.REDACTED.NET' PATHEXT = '.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.PSC1' HOMEDRIVE = 'C:' PROMPT = '$P$G' COMSPEC = 'C:\WINDOWS\system32\cmd.exe' TMP = '/cygdrive/c/DOCUME~1/smited/LOCALS~1/Temp' SYSTEMROOT = 'C:\WINDOWS' PRINTER = '\\jscip10a\JSCI004P' CVS_RSH = '/bin/ssh' VISUAL = 'gvim' PROCESSOR_REVISION = '0f06' S7TMP = 'C:\Program Files\REDACTED\REDACTED\S7Tmp' NETLINK = 'fso' CLEARCASE_GROUPS = 'us002\jocy_clearcase_docs;us002\jocy_clearcase_s7io;us002\jocy_clearcase_s7pt;us002\jocy_clearcase_dev;us002\jocy_clearcase_s7cpu' INFOPATH = '/usr/local/info:/usr/share/info:/usr/info:' PROGRAMFILES = 'C:\Program Files' CBEHOME = 'C:\WINDOWS\CatPC\CATSYS' DISPLAY = ':0' CSHX = 'csh'
RE: How to avoid having shell scripts which fail from killing Emacs shell?
-Original Message- From: cygwin-ow...@cygwin.com [mailto:cygwin-ow...@cygwin.com] On Behalf Of Ken Brown Sent: Monday, June 22, 2009 12:54 PM To: cygwin@cygwin.com Subject: Re: How to avoid having shell scripts which fail from killing Emacs shell? On 6/22/2009 3:38 PM, David Karr wrote: -Original Message- From: cygwin-ow...@cygwin.com [mailto:cygwin-ow...@cygwin.com] On Behalf Of Ken Brown Sent: Monday, June 22, 2009 12:26 PM On 6/22/2009 10:53 AM, David Karr wrote: I've often been annoyed by shell scripts which fail for particular reasons, at which point it causes my Emacs shell buffer to get killed, with Process shell2 finished. I don't recall ever seeing this happen, but maybe I just don't remember. Can you give me a simple test case? I'm not sure how complicated it needs to be. My test case gathers a couple of parameters and then calls a Java (JDK 1.6.0_14) class. The class throws an exception (file not found) in my test case (because I'm deliberately giving it parameters that will cause that). If I give it parameters that will avoid the exception, then it doesn't kill the shell. Is that enough information to build a test case with? No. I don't have JDK installed, and I don't have any idea how it interacts with cygwin processes. If you can trigger the problem with a simple shell script that doesn't require JDK, I'll see if I can help. Or maybe someone on the list who does have JDK can suggest something for you to try. I was able to produce an additional clue by writing a custom class for testing this. I found that the key is whether the Java class reads from stdin or not. I built a first version that takes a filepath on the command line, and whether I get the class to throw an exception or not, it exits the script without killing the shell. However, when I changed the class to also read a line of input from stdin, whether the filepath on the command line exists or not (i.e., whether the class throws an exception or not), it kills the shell at completion of the script. So, it has something to do with whether the sub-shell reads stdin or not. I have no idea what that indicates, but I'm sure that must be useful information. -- 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: Slow/sluggish response (system task at 50%)
Gene Smith wrote: Gene Smith wrote: I don't think it is a problem with cygwin itself. I was mainly curious if anyone sees the system task running 50% when doing a gcc build using Make (or similar intensive long term activity). I have weak XP based laptop with no corporate security that runs cygwin fine compared to my dual-core corporate desktop machine. I will check it on the laptop but it is not with me now. Thanks for the reply. Attached is my cygcheck.out (some private info is redacted). I just did a compare by running the same make build using cygwin (rxvt), msys (also rxvt) and cmd. With msys and cmd I see system process running occasionally and for a short time at a maximum of 20% cpu. Usually I see the make process or just system idle and the build completes in about 22 seconds. With cygwin/rxvt, as described previously, I see system process at 40-50% (usually 50%) and nothing else using cpu comes to the top. The same build takes about 14 minutes on cygwin. Running in the standard cygwin shell (not rxvt) the time is the same, 14 minutes compared to 22 seconds under msys/rxvt and cmd shells. I removed the 2nd cygwin1.dll in the path that it warns about but it made no difference. Is there anything evident in the cygcheck that accounts for the extreme running of the windows system process with cygwin active? The overridden utilities always makes me nervous, though there's no obvious reason to be, since the Cygwin versions are reported as overriding the WinAVR versions. But I think this is more of a cause for concern: Sonic Solutions burning software containing DLA component I'd try removing that and see if it helps. There's also 1.7 - http://cygwin.com/#beta-test -- Larry Hall http://www.rfk.com RFK Partners, Inc. (508) 893-9779 - RFK Office 216 Dalton Rd. (508) 893-9889 - FAX Holliston, MA 01746 _ A: Yes. Q: Are you sure? A: Because it reverses the logical flow of conversation. Q: Why is top posting annoying in email? -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
[ANNOUNCEMENT] [1.7] New package: lua-5.1.4-11
The following package has been added for Cygwin 1.7: + lua-5.1.4-11 Lua is a powerful, light-weight programming language designed for extending applications. Lua is also frequently used as a general-purpose, stand-alone language. Yaakov CYGWIN-ANNOUNCE UNSUBSCRIBE INFO If you want to unsubscribe from the cygwin-announce mailing list, please use the automated form at: http://cygwin.com/lists.html#subscribe-unsubscribe If this does not work, then 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. -- 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] [1.7] New package: dbus-1.2.14-1
The following packages have been added for Cygwin 1.7: + dbus-1.2.14-1 + libdbus1_3-1.2.14-1 + libdbus1-devel-1.2.14-1 D-Bus is an IPC system, a simple way for applications to talk to one another. D-Bus supplies both a system bus (for events such as 'new hardware device added' or 'printer queue changed') and a per-user-login-session bus (for general IPC needs among user applications). The system bus can be installed as a Windows service with the messagebus-config script. The session bus can be started with dbus-launch(1), or it will be started automatically by the application or xsession requiring it. Yaakov CYGWIN-ANNOUNCE UNSUBSCRIBE INFO If you want to unsubscribe from the cygwin-announce mailing list, please use the automated form at: http://cygwin.com/lists.html#subscribe-unsubscribe If this does not work, then 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. -- 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: [ANNOUNCEMENT] [1.7] Updated: {libtool/libltdl7}-2.2.7a-13
On 19/06/2009 22:55, Charles Wilson wrote:
* Include two new patches from Yaakov Selkowitz
- Ensure LT_PATH_LD works when called before LT_INIT
- [cygwin|mingw] Create UAC manifest files.
Thanks!
But regarding my previous export-all-symbols patch, I discovered today
that I only did half the job; I fixed things for CC but not for CXX.
Patch attached.
Yaakov
* libltdl/m4/libtool.m4 (_LT_LANG_CXX_CONFIG)
[cygwin*|mingw*|pw32*|cegcc*]:
Define export_dynamic_flag_spec as -Wl,--export-all-symbols here as well
(see commit 5f2bbb494a2753afb2878c399cfd8316b7403a5b).
--- origsrc/libtool-2.2.7a/libltdl/m4/libtool.m42009-06-18
11:51:29.937982900 -0500
+++ src/libtool-2.2.7a/libltdl/m4/libtool.m42009-06-22 21:14:07.585817500
-0500
@@ -5631,6 +5631,7 @@ if test $_lt_caught_CXX_error != yes;
# _LT_TAGVAR(hardcode_libdir_flag_spec, $1) is actually meaningless,
# as there is no search path for DLLs.
_LT_TAGVAR(hardcode_libdir_flag_spec, $1)='-L$libdir'
+_LT_TAGVAR(export_dynamic_flag_spec, $1)='${wl}--export-all-symbols'
_LT_TAGVAR(allow_undefined_flag, $1)=unsupported
_LT_TAGVAR(always_export_symbols, $1)=no
_LT_TAGVAR(enable_shared_with_static_runtimes, $1)=yes
--
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: Slow/sluggish response (system task at 50%)
Larry Hall (Cygwin) wrote, On 06/22/2009 08:08 PM: Gene Smith wrote: Gene Smith wrote: I don't think it is a problem with cygwin itself. I was mainly curious if anyone sees the system task running 50% when doing a gcc build using Make (or similar intensive long term activity). I have weak XP based laptop with no corporate security that runs cygwin fine compared to my dual-core corporate desktop machine. I will check it on the laptop but it is not with me now. Thanks for the reply. Attached is my cygcheck.out (some private info is redacted). I just did a compare by running the same make build using cygwin (rxvt), msys (also rxvt) and cmd. With msys and cmd I see system process running occasionally and for a short time at a maximum of 20% cpu. Usually I see the make process or just system idle and the build completes in about 22 seconds. With cygwin/rxvt, as described previously, I see system process at 40-50% (usually 50%) and nothing else using cpu comes to the top. The same build takes about 14 minutes on cygwin. Running in the standard cygwin shell (not rxvt) the time is the same, 14 minutes compared to 22 seconds under msys/rxvt and cmd shells. I removed the 2nd cygwin1.dll in the path that it warns about but it made no difference. Is there anything evident in the cygcheck that accounts for the extreme running of the windows system process with cygwin active? The overridden utilities always makes me nervous, though there's no obvious reason to be, since the Cygwin versions are reported as overriding the WinAVR versions. But I think this is more of a cause for concern: Sonic Solutions burning software containing DLA component I'd try removing that and see if it helps. And its the first thing on the BLODA list; I didn't notice. I didn't associate the name Sonic Solutions with anything on my computer. But I see it is really part of the Roxio package. I removed the DLA (Drive Letter Access) component of Roxio (remotely, at home now) but it says I need to reboot to complete the removal... After reboot, the DLA component warning is gone from cygcheck but it is still slow doing the build. :( Oh, well, I never used this DLA thing anyhow. Guess I can try to remove the overrides you mention above. But I agree, they do seem innocuous. There's also 1.7 - http://cygwin.com/#beta-test I will take a look at this. By the way, on the weak laptop I mentioned earlier, I get equal speed (and good speed) building a fairly big program on msys and cygwin. The system process barely registers any activity at all. One other note. Although the cygwin speed is slow, all programs seem to work OK. -- 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: Slow/sluggish response (system task at 50%)
Gene Smith wrote: Larry Hall (Cygwin) wrote, On 06/22/2009 08:08 PM: snip There's also 1.7 - http://cygwin.com/#beta-test I will take a look at this. By the way, on the weak laptop I mentioned earlier, I get equal speed (and good speed) building a fairly big program on msys and cygwin. The system process barely registers any activity at all. One other note. Although the cygwin speed is slow, all programs seem to work OK. Definitely a point understood. I'm not sure what's getting in the way on this problematic machine. In that context, the reference to 1.7 is a possible way to side-step the problem (or not ;-) ) but it certainly doesn't pinpoint the issue. -- Larry Hall http://www.rfk.com RFK Partners, Inc. (508) 893-9779 - RFK Office 216 Dalton Rd. (508) 893-9889 - FAX Holliston, MA 01746 _ A: Yes. Q: Are you sure? A: Because it reverses the logical flow of conversation. Q: Why is top posting annoying in email? -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Slow/sluggish response (system task at 50%)
Larry Hall (Cygwin) wrote, On 06/22/2009 08:08 PM: There's also 1.7 - http://cygwin.com/#beta-test 1.7 seems to fix it. It now takes 34 seconds as compared to 14 minutes with cygwin-1.5. (But I suspect that a fresh install of 1.5 might produce similar or better results.) At some point, 1.5 started getting slow for me. I don't know (yet) what caused it. I still have the conflict with winavr using 1.7 so I don't think that is it. Someone on a list mention about home directory affecting cygwin speed. I do notice that on 1.7-beta $HOME is /home/smited (under c:\cygwin-1.7\). While on my 1.5 $HOME is /cygdrive/c/Documents and Settings/smited. Somehow 1.5 points $HOME to the existing windows home while 1.7 points $HOME to a new and almost empty directory under c:\cygwin-1.7. Does this matter at all? -- 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: Slow/sluggish response (system task at 50%)
Gene Smith wrote: Larry Hall (Cygwin) wrote, On 06/22/2009 08:08 PM: There's also 1.7 - http://cygwin.com/#beta-test 1.7 seems to fix it. It now takes 34 seconds as compared to 14 minutes with cygwin-1.5. (But I suspect that a fresh install of 1.5 might produce similar or better results.) At some point, 1.5 started getting slow for me. I don't know (yet) what caused it. I still have the conflict with winavr using 1.7 so I don't think that is it. Someone on a list mention about home directory affecting cygwin speed. I do notice that on 1.7-beta $HOME is /home/smited (under c:\cygwin-1.7\). While on my 1.5 $HOME is /cygdrive/c/Documents and Settings/smited. Somehow 1.5 points $HOME to the existing windows home while 1.7 points $HOME to a new and almost empty directory under c:\cygwin-1.7. Does this matter at all? Depends on how much cruft has built up in your Windows home directory. While this does get pretty trashy IMO, I don't think the typical build-up of Windows junk there would seriously impact performance, unless this somehow became a network directory reference at some point. And I think if just pointing at the home directory Windows uses were a general issue, we'd hear allot more about it on this list. But I can't say for sure something in your case isn't causing the problem you were seeing. I suppose if you're real curious about it, you can try pointing your new 1.7 install to it and see if things revert to the nostalgic slow-boat that you've become accustomed to. ;-) -- Larry Hall http://www.rfk.com RFK Partners, Inc. (508) 893-9779 - RFK Office 216 Dalton Rd. (508) 893-9889 - FAX Holliston, MA 01746 _ A: Yes. Q: Are you sure? A: Because it reverses the logical flow of conversation. Q: Why is top posting annoying in email? -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
[ANNOUNCEMENT] Updated: mintty-0.4.1-1
MinTTY is a terminal emulator for Cygwin with a native Windows user
interface and minimalist design. Among its features are Unicode
support and a graphical options dialog. Its terminal emulation is
largely compatible with xterm, but it does not require an X server.
MinTTY is based on code from PuTTY 0.60 by Simon Tatham and team.
This is a maintenance release with a few small fixes and improvements.
CHANGES
===
- The window title can now include characters from the full Unicode
range rather than being limited to the system's ANSI codepage.
- When resizing the window, the sizetip moves with the upper left
corner of the window rather than being marooned at its original
position.
- Added one pixel of padding inside the window border to stop
characters from touching it. (PuTTY had that, but I'd unwisely removed
it.)
- Alt+Numpad codes work when NumLock is off as well. In UTF-8 mode, Alt
+1 to Alt+31 are interpreted as graphical OEM characters, e.g. Alt+3
is ♥ and Alt+1 is ☺.
- Alt works as the Meta modifier for AltGr combinations, e.g. Alt+AltGr
+7 on a German keyboard now sends ^[{ rather than just {.
- Added Xterm window focus reporting. (^[?1004h to enable, ^[?1004l
disable. ^[[I is sent for focus in and ^[[O for focus out.)
- Applications can ask to be notified when the width of the CJK
Ambiguous Width characters changes due to the user changing font. ^[?
7700h to enable, ^[?7700l to disable. ^[[1W is sent for cjknarrow
mode, and ^[[2W for cjkwide mode. Removed attempted SIGWINCH
notification for the same purpose, because it didn't work.
- Bell overload detection wasn't working, but I decided to remove it
instead of fixing it and to switch off the bell in the default config,
because I'm guessing most people don't want to be beeped or flashed at
by their terminal anyway.
More on these changes can be found at
http://code.google.com/p/mintty/issues/list?can=1q=Milestone%3A0.4.1
QUESTIONS
=
MinTTY's project page is located at http://mintty.googlecode.com.
Please use the issue tracker there to report bugs or suggest
enhancements. Questions or comments can be sent to the MinTTY
discussion group at http://groups.google.com/group/mintty-discuss or
the Cygwin mailing list at cyg...@cygwin.com .
To update your installation, click on the Install Cygwin now link
on the http://cygwin.com/ web page. This downloads setup.exe to
your system. Then, run setup and answer all of the questions.
*** 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
[1.7] Updated: mathomatic-14.4.5-1
Major bugfixes overall. See http://mathomatic.orgserve.de/changes.txt Cygwin build changes: * cygwin-1.7, gcc-4 About: Mathomatic is a highly portable, general purpose symbolic math program that can solve, simplify, combine, differentiate, integrate, and compare algebraic equations. It can do standard, complex number, and polynomial arithmetic. It is extremely easy to use and has pretty colored, easily readable display of equations. See http://www.mathomatic.org/ To update your installation, click on the Install Cygwin now link on the http://cygwin.com/ web page. This downloads setup.exe to your system. Then, run setup and answer all of the questions. *** 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://sources.redhat.com/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. -- Reini Urban mathomatic support under Cygwin at cyg...@cygwin.com
[1.7] New package: lua-5.1.4-11
The following package has been added for Cygwin 1.7: + lua-5.1.4-11 Lua is a powerful, light-weight programming language designed for extending applications. Lua is also frequently used as a general-purpose, stand-alone language. Yaakov CYGWIN-ANNOUNCE UNSUBSCRIBE INFO If you want to unsubscribe from the cygwin-announce mailing list, please use the automated form at: http://cygwin.com/lists.html#subscribe-unsubscribe If this does not work, then 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.
[1.7] New package: dbus-1.2.14-1
The following packages have been added for Cygwin 1.7: + dbus-1.2.14-1 + libdbus1_3-1.2.14-1 + libdbus1-devel-1.2.14-1 D-Bus is an IPC system, a simple way for applications to talk to one another. D-Bus supplies both a system bus (for events such as 'new hardware device added' or 'printer queue changed') and a per-user-login-session bus (for general IPC needs among user applications). The system bus can be installed as a Windows service with the messagebus-config script. The session bus can be started with dbus-launch(1), or it will be started automatically by the application or xsession requiring it. Yaakov CYGWIN-ANNOUNCE UNSUBSCRIBE INFO If you want to unsubscribe from the cygwin-announce mailing list, please use the automated form at: http://cygwin.com/lists.html#subscribe-unsubscribe If this does not work, then 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.
