[RFU] subversion-1.6.9-1
New upstream release. Please leave version 1.6.6-3 and remove all prior versions. wget -x -nH --cut-dirs=2 \ http://mysite.verizon.net/res00a7j/cygwin/subversion/setup.hint \ http://mysite.verizon.net/res00a7j/cygwin/subversion/subversion-1.6.9-1-src.tar.bz2 \ http://mysite.verizon.net/res00a7j/cygwin/subversion/subversion-1.6.9-1.tar.bz2 \ http://mysite.verizon.net/res00a7j/cygwin/subversion/subversion-apache2/setup.hint \ http://mysite.verizon.net/res00a7j/cygwin/subversion/subversion-apache2/subversion-apache2-1.6.9-1.tar.bz2 \ http://mysite.verizon.net/res00a7j/cygwin/subversion/subversion-devel/setup.hint \ http://mysite.verizon.net/res00a7j/cygwin/subversion/subversion-devel/subversion-devel-1.6.9-1.tar.bz2 \ http://mysite.verizon.net/res00a7j/cygwin/subversion/subversion-perl/setup.hint \ http://mysite.verizon.net/res00a7j/cygwin/subversion/subversion-perl/subversion-perl-1.6.9-1.tar.bz2 \ http://mysite.verizon.net/res00a7j/cygwin/subversion/subversion-python/setup.hint \ http://mysite.verizon.net/res00a7j/cygwin/subversion/subversion-python/subversion-python-1.6.9-1.tar.bz2 \ http://mysite.verizon.net/res00a7j/cygwin/subversion/subversion-ruby/setup.hint \ http://mysite.verizon.net/res00a7j/cygwin/subversion/subversion-ruby/subversion-ruby-1.6.9-1.tar.bz2 \ http://mysite.verizon.net/res00a7j/cygwin/subversion/subversion-tools/setup.hint \ http://mysite.verizon.net/res00a7j/cygwin/subversion/subversion-tools/subversion-tools-1.6.9-1.tar.bz2 -- David Rothenberger daver...@acm.org Help Mr. Wizard! -- Tennessee Tuxedo
Re: [RFU] subversion-1.6.9-1
On 22/01/2010 13:02, David Rothenberger wrote: New upstream release. Please leave version 1.6.6-3 and remove all prior versions. Done and done. Yaakov
[ITA] plotutils
Hi, as Corinna said, we are starting a PACman action. The packages are cygwinport ones, courtesy of Yaakov. Just a version bump. plotutils-devel and plotutils-doc are obsoleted the development packages are 3 libplot-devel libplotter-devel libxmi-devel one for each of the dll's libxmi0usr/bin/cygxmi-0.dll libplot2 usr/bin/cygplot-2.dll libplotter2usr/bin/cygplotter-2.dll to download: wget -r -np -nH --cut-dirs=2 http://matzeri.altervista.org/cygwin-1.7/plotutils font-tektronix-misc/font-tektronix-misc-2.6-2.tar..bz2 font-tektronix-misc/setup.hint libplot-devel/libplot-devel-2.6-2.tar.bz2 libplot-devel/setup.hint libplot2/libplot2-2.6-2.tar.bz2 libplot2/setup.hint libplotter-devel/libplotter-devel-2.6-2.tar.bz2 libplotter-devel/setup.hint libplotter2/libplotter2-2.6-2.tar.bz2 libplotter2/setup.hint libxmi-devel/libxmi-devel-2.6-2.tar.bz2 libxmi-devel/setup.hint libxmi0/libxmi0-2.6-2.tar.bz2 libxmi0/setup.hint plotutils-2.6-2-src.tar.bz2 plotutils-2.6-2.tar.bz2 plotutils-devel/plotutils-devel-2.6-2.tar.bz2 plotutils-devel/setup.hint plotutils-doc/plotutils-doc-2.6-2.tar.bz2 plotutils-doc/setup.hint setup.hint Regards Marco
Re: [ITA] plotutils
Marco Atzeri wrote: as Corinna said, we are starting a PACman action. The packages are cygwinport ones, courtesy of Yaakov. Just a version bump. plotutils-devel and plotutils-doc are obsoleted the development packages are 3 libplot-devel libplotter-devel libxmi-devel one for each of the dll's libxmi0usr/bin/cygxmi-0.dll libplot2 usr/bin/cygplot-2.dll libplotter2usr/bin/cygplotter-2.dll to download: Rebuilds fine from src. GTG. -- Chuck
RFU] octave-3.2.4-1
new upstream version, just bugfix to download: wget -r -np -nH --cut-dirs=2 http://matzeri.altervista.org/cygwin-1.7/octave octave-3.2.4-1-src.tar.bz2 octave-3.2.4-1.tar.bz2 octave-devel/octave-devel-3.2.4-1.tar.bz2 octave-devel/setup.hint octave-doc/octave-doc-3.2.4-1.tar.bz2 octave-doc/setup.hint setup.hint Regards Marco
[RFU] qrupdate-1.1.0-1
new upstream version, functionality extension to download: wget -r -np -nH --cut-dirs=2 http://matzeri.altervista.org/cygwin-1.7/qrupdate file list libqrupdate-devel/libqrupdate-devel-1.1.0-1.tar.bz2 libqrupdate-devel/setup.hint libqrupdate0/libqrupdate0-1.1.0-1.tar.bz2 libqrupdate0/setup.hint qrupdate-1.1.0-1-src.tar.bz2 qrupdate-1.1.0-1.tar.bz2 setup.hint Regards Marco
Re: 1.7.1: no xdmcp login prompt after upgrade
Am 15.01.2010 21:32, schrieb Paxton, Michael: After upgrading to Cygwin/X 1.7.1, XDMCP query to any remote host no longer produces a login prompt. All XDMCP connections functioned correctly prior to upgrade. Examination of an iptrace report (ipreport10.out) on the remote host shows that Cygwin/X is not continuing the connection sequence after the remote host replies to the initial port 177 communication. Did you try to do use numeric ip addresses and the -from switch to see if it produces a different result? Like: XWin -query xdmcp.numeric.host.address -from your.own.numeric.address -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
RE: 1.7.1: no xdmcp login prompt after upgrade
That is a good suggestion; I will try that this weekend. Should that prove to work, would that then suggest something in Cygwin/X's name resolution is broken? This worked as-is under 1.5.25; it is broken under 1.7.1 - what changed? Respectfully, D. Michael Paxton, Esq., MBA FBI/CJIS Systems Agency Information Security Officer Indiana State Police (317) 232-5686 -Original Message- From: cygwin-xfree-ow...@cygwin.com [mailto:cygwin-xfree-ow...@cygwin.com] On Behalf Of Holger Krull Sent: Friday, 22 January 2010 08:47 To: cygwin-xfree@cygwin.com Subject: Re: 1.7.1: no xdmcp login prompt after upgrade Am 15.01.2010 21:32, schrieb Paxton, Michael: After upgrading to Cygwin/X 1.7.1, XDMCP query to any remote host no longer produces a login prompt. All XDMCP connections functioned correctly prior to upgrade. Examination of an iptrace report (ipreport10.out) on the remote host shows that Cygwin/X is not continuing the connection sequence after the remote host replies to the initial port 177 communication. Did you try to do use numeric ip addresses and the -from switch to see if it produces a different result? Like: XWin -query xdmcp.numeric.host.address -from your.own.numeric.address -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Mouse right-click doesn't work when working with exported windows
Hello all, I'm facing a strange problem here, hope that someone could help. When I start Cygwin/X and open a graphical application such as nedit, I can right-click and get the proper context menus, regardless of the Num-lock state. But when I log on to any of our servers via ssh -X or rlogin from within xterm and I start any graphical app (exporting the window to my desktop), the behaviour is as follows: - With Num-lock on, right-clicking does nothing. No context menu appears; - With Num-lock off, the cursor flips (it points to the right instead of the left), and then both the mouse and the keyboard stops responding, even on xterm. I'm forced to shut down the Cygwin/X server. As I said, this error only occurs when working with exported windows of any application, regardless of the server (tried with both Red Hat EL5 and HP-UX 11.* ones). My desktop is Windows XP Pro SP3, and I'm using the latest version of Cygwin. Attached is the output of cygcheck and from the XWin log. I used the xev utility to check if there are differences on the output when clicking on a local window and a remote one: no difference perceived. Curiously, I can work properly when using Cygwin 1.5.x, as it's already installed on some machines, but I couldn't get it to work using the setup-legacy.exe. It installs but no command is recognized (maybe something related to path setting, but I'll research more and post on the proper list if necessary). Any clues on how to solve it? Regards, Daniel cygcheck.out Description: Binary data XWin.0.log Description: Binary data -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: bug report/suggested temp. patch: handling bursts of sent keys
Larry Hall wrote: On 01/19/2010 01:17 PM, Mark Lillibridge wrote: Hi. I don't appear to have gotten any response to my message sent to this list January 12 (copied below). Do I have the right list? Am I supposed to use a different mechanism to report bugs with the Cygwin X server? Please help. Thanks for the information you've provided. This is the correct list for Cygwin X issues. I can't engage you on this topic because I'm not knowledgeable about the area you investigated. However, a couple of questions come to my mind about what you've found: 1. Is this Cygwin-specific? The Xming server, which I understand shares source code, also has this bug. The commercial X server, Reflection, does not have this bug. This bug is specific to Windows implementations so I presume it does not belong in the generic Xorg source. 2. If not, what's the upstream solution? This information might help you decide if your issue is better reported upstream. It may also help developers here decide how to solve the problem. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
src/winsup/cygwin ChangeLog Makefile.in autolo ...
CVSROOT:/cvs/src Module name:src Changes by: cori...@sourceware.org 2010-01-22 22:31:31 Modified files: winsup/cygwin : ChangeLog Makefile.in autoload.cc cygwin.din strfuncs.cc wchar.h wincap.cc wincap.h winsup/cygwin/include/cygwin: version.h winsup/cygwin/libc: strptime.cc Added files: winsup/cygwin : nlsfuncs.cc winsup/cygwin/include: monetary.h winsup/cygwin/libc: strfmon.c Log message: * Makefile.in (DLL_OFILES): Add nlsfunc.o and strfmon.o. * autoload.cc (LocaleNameToLCID): Define. * cygwin.din (strfmon): Export. * nlsfuncs.cc: New file. Define a lot of internal functions called from setlocale. (wcscoll): Implement locale-aware here, using CompareStringW function. (strcoll): Ditto. (wcsxfrm): Implement locale-aware here, usingLCMapStringW function. (strxfrm): Ditto. (__set_charset_from_locale): Replace __set_charset_from_codepage. Return Linux-compatible charset. * strfuncs.cc (__set_charset_from_codepage): Remove. * wchar.h (__set_charset_from_codepage): Drop definition. * wincap.h (wincaps::has_localenames): New element. * wincap.cc: Implement above element throughout. * libc/strfmon.c: New file. * libc/strptime.cc: Remove locale constant strings in favor of access to locale-specifc data. (strptime): Point _CurrentTimeLocale to locale-specific data. Throughout use correct locale-specific format fields for all locale-specific formats. * include/monetary.h: New file. * include/cygwin/version.h (CYGWIN_VERSION_API_MINOR): Bump. Patches: http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/winsup/cygwin/nlsfuncs.cc.diff?cvsroot=srcr1=NONEr2=1.1 http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/winsup/cygwin/ChangeLog.diff?cvsroot=srcr1=1.4775r2=1.4776 http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/winsup/cygwin/Makefile.in.diff?cvsroot=srcr1=1.230r2=1.231 http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/winsup/cygwin/autoload.cc.diff?cvsroot=srcr1=1.166r2=1.167 http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/winsup/cygwin/cygwin.din.diff?cvsroot=srcr1=1.219r2=1.220 http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/winsup/cygwin/strfuncs.cc.diff?cvsroot=srcr1=1.40r2=1.41 http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/winsup/cygwin/wchar.h.diff?cvsroot=srcr1=1.10r2=1.11 http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/winsup/cygwin/wincap.cc.diff?cvsroot=srcr1=1.98r2=1.99 http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/winsup/cygwin/wincap.h.diff?cvsroot=srcr1=1.80r2=1.81 http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/winsup/cygwin/include/monetary.h.diff?cvsroot=srcr1=NONEr2=1.1 http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/winsup/cygwin/include/cygwin/version.h.diff?cvsroot=srcr1=1.307r2=1.308 http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/winsup/cygwin/libc/strfmon.c.diff?cvsroot=srcr1=NONEr2=1.1 http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/winsup/cygwin/libc/strptime.cc.diff?cvsroot=srcr1=1.5r2=1.6
src/winsup/doc ChangeLog new-features.sgml set ...
CVSROOT:/cvs/src Module name:src Changes by: cori...@sourceware.org 2010-01-22 22:32:42 Modified files: winsup/doc : ChangeLog new-features.sgml setup2.sgml Log message: * new-features.sgml (ov-new1.7.2): Add chapter for news in 1.7.2. * setup2.sgml (setup-locale-ov): Describe how valid locales are determined by Windows locale support. Change description for modifiers in locale environment variables. (setup-locale-how): Describe new charset behaviour. Mention new getlocale tool to fetch valid locale information from Windows. (setup-locale-missing): Drop now implemented LC_foo options. Explain missing LC_MESSAGES in more detail. Patches: http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/winsup/doc/ChangeLog.diff?cvsroot=srcr1=1.257r2=1.258 http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/winsup/doc/new-features.sgml.diff?cvsroot=srcr1=1.23r2=1.24 http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/winsup/doc/setup2.sgml.diff?cvsroot=srcr1=1.32r2=1.33
src/winsup/cygwin ChangeLog posix.sgml
CVSROOT:/cvs/src Module name:src Changes by: cori...@sourceware.org 2010-01-22 22:33:22 Modified files: winsup/cygwin : ChangeLog posix.sgml Log message: * posix.sgml (strfmon): Move to implemented SUSv4 API. Patches: http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/winsup/cygwin/ChangeLog.diff?cvsroot=srcr1=1.4776r2=1.4777 http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/winsup/cygwin/posix.sgml.diff?cvsroot=srcr1=1.42r2=1.43
Re: Best way to backup 1.5 to go to 1.7
2010/1/21 Brian Keener: I want to upgrade to 1.7 but would like to get a backup of the full 1.5 install before hand. I know in the past just doing copies some files didn't or couldn't get copied. Also in the unix world seems as though I recall tar and cpio have difference in terms of what they will and won't backup. What the best way to get a good copy of my 1.5 in case I need/want to get it back. I have made a backup of 1.5 by 7-Zipping the entire directory and also backup the mount v2 tree of Cygnus Solutions in the registry. I have had problems upgrading to 1.7 on one pc and could successfully restore my 1.5 installation. Regards, Frank -- 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
Differentiate workgroup system from domain member under Cygwin
Dear Colleagues, I need being able to differentiate a workgroup system from a domain member in a shellscript under Cygwin - does anybody have an approach for me? Mit freundlichen Grüßen / with kind regards Christoph Herdeg Christoph HerdegContact IBM Deutschland Research Windows Infrastructure Support Information Development GmbH Information Management Vorsitzender des Aufsichtsrats: Development Martin Jetter IBM Software Group Geschäftsführung: Erich Baier Sitz der Gesellschaft: Böblingen Registergericht: Amtsgericht Stuttgart, HRB 243294 mail: christoph.her...@de.ibm.com fon:49-7031-16-1039 (tie line fax:*120-1039) address:49-7031-16-4891 Schönaicher Str. 220 71032-03 Böblingen visit IBM Deutschland Research Development GmbH -- 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: flex package requires m4
On Jan 21 16:49, Jeff Jones wrote: Christopher Faylor cgf-use-the-mailinglist-please at cygwin.com writes: On Sun, Aug 23, 2009 at 06:36:12PM -0700, Karl M wrote: My point was that flex needs a dependency on m4 for setup so that m4 is installed automatically. Unless, of course, there is some reason not to make the dependancy explicit. The dependency has been added. Thanks for the heads up. cgf The dependency is not yet there as of Setup Version 2.677 for Cygwin 1.7.1-1. I just performed a virgin-install and selecting flex did not also select m4. Be aware that flex fatal-errors without m4 installed. Cgf definitely changed it on sourceware. If you didn't get it, then the mirror you're using didn't catch up, yet. 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: units: update, FHS compliance
On Jan 21 12:40, Yaakov S wrote: On 21/01/2010 05:11, Corinna Vinschen wrote: Interesting. Especially the part about cmake. Did you try to convince Bill that WIN32 is not a good idea for the Cygwin distro package? Yes, among other things: http://www.cmake.org/Bug/view.php?id=10122 I didn't manage to read all of it but, boy, sounds like a lot of work. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Differentiate workgroup system from domain member under Cygwin
On Jan 22 09:31, Christoph Herdeg wrote: Dear Colleagues, I need being able to differentiate a workgroup system from a domain member in a shellscript under Cygwin - does anybody have an approach for me? Look for the mkpasswd uppercase options -C, -L, -D, -S. They allow to generate usernames with machine/domain prefix. Same for mkgroup. 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
Problem with svn and users over multiple machines
I don't know if this is a Cygwin related problem or if I am just being stupid. Probably the latter, but maybe in that case some kind soul will take pity on me. I added a new user svn and a new group subversion-user, basically following http://www.cygwin.com/ml/cygwin/2005-07/msg00933.html with the addition of also doing mkgroup -l -g subversion-user /etc/group. I then created a subversion repository in the usual way, on an NDAS drive, and then changed the file permissions so that they are owned by user svn and can be modified by members of the group subversion-user. I could then add and commit files to my repository. So far so good. I also want to be able to work on another machine in a similar manner, so did the same things on that machine regarding user and group as I did on the first. My suspicion is that I shouldn't have, I should have done something else instead, because I see g...@mimosa ~ $ ls -l /svn/db total 14 -rw-r--r--+ 1 garyKein 2 2010-01-22 09:34 current -r--r--r-- 1 svn subversion-user 22 2010-01-22 08:22 format -rw-r--r-- 1 svn subversion-user5 2010-01-22 08:22 fs-type -rw-r--r-- 1 svn subversion-user 1920 2010-01-22 08:22 fsfs.conf (etc.) from the first machine... ...but see g...@sunflower ~ $ ls -l /svn/db total 14 -rw-r--r--+ 1 2 2010-01-22 09:34 current -r--r--r-- 1 22 2010-01-22 08:22 format -rw-r--r-- 1 5 2010-01-22 08:22 fs-type -rw-r--r-- 1 1920 2010-01-22 08:22 fsfs.conf (etc.) from the second. Furthermore, attempting to commit a file (directory, actually) from the second machine results in an error, like so - g...@sunflower ~/src/myproject $ svn ci src svn: Commit failed (details follow): svn: Can't open file '/svn/db/txn-current': No such file or directory but I don't know if that is related to this or some other problem. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: 1.7.1-1 - forward slash UNC names to use 'noacl'
On Jan 21 11:25, na na wrote: Listing the contents of a directory on our file server (a Samba share) by t= he following command: =A0=A0 $ ls -l or explicitly =A0=A0 $ ls -l ./ the output is =A0=A0 --+ 1 group 600 2009-09-09 11:12 README.txt =A0=A0 d-+ 1 group=A0=A0 0 2009-09-09 11:03 conf whereas the following command: =A0=A0 $ ls -l .\\ outputs =A0=A0 -rw-r--r-- 1 user group 600 2009-09-09 11:12 README.txt =A0=A0 drwxr-xr-x 1 user group=A0=A0 0 2009-09-09 11:03 conf I presume this behaviour has something to do with this point: http://cygwin.com/cygwin-ug-net/ov-new1.7.html: - Incoming DOS paths are always handled case-insensitive and get no = POSIX permission=2C as if they are mounted with noacl=2Cposix=3D0 mo= unt flags. My goal is to specify 'noacl' for forward slash UNC paths in order to displ= ay file permissions in the same way as they are displayed with backslash UN= C paths. Is there any way to do this without mounting all file servers in question (= we have many) with the 'noacl' option? No, there's no way to do that. I played a bit with this and it might be more feasible to treat all UNC paths as noacl,posix=0. I added this problem to 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: Differentiate workgroup system from domain member under Cygwin
On Jan 22 09:31, Christoph Herdeg wrote: Dear Colleagues, I need being able to differentiate a workgroup system from a domain member in a shellscript under Cygwin - does anybody have an approach for me? Look for the mkpasswd uppercase options -C, -L, -D, -S. They allow to generate usernames with machine/domain prefix. Same for mkgroup. Corinna Hi Corinna, thanks for the fast reply. But I probably didn't express myself clearly enough. In need to distinguish a workgroup/single system from a domain member to know if I have to create a local user (net user bla /add) or not. This needs to happen before calling mkpasswd/~group and without knowledge of the current workgroup-/domain-name. Background is that I would like to start sshd with a domain user, but only if the current machine is member of a domain. Depending on that difference I need to use mkpasswd/~group with other parameters (-l vs. -d). So question is more if there is any place on a windows system, a file or a directory or an entry in a file that exists only if that machine is a domain member? Best Regards, Christoph Herdeg Windows Infrastructure Support Information Management Development IBM Software Group -- 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: Differentiate workgroup system from domain member under Cygwin
On Jan 22 10:34, Christoph Herdeg wrote: So question is more if there is any place on a windows system, a file or a directory or an entry in a file that exists only if that machine is a domain member? There are certainly multiple methods to fetch this information. One of them is, for instance: bash$ net config workstation | grep -q 'Domain DNS' \ echo domain-member || echo standalone-machine 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: Differentiate workgroup system from domain member under Cygwin
On Jan 22 10:34, Christoph Herdeg wrote: So question is more if there is any place on a windows system, a file or a directory or an entry in a file that exists only if that machine is a domain member? There are certainly multiple methods to fetch this information. One of them is, for instance: bash$ net config workstation | grep -q 'Domain DNS' \ echo domain-member || echo standalone-machine Corinna Great! Works just perfect. Thank you very much!!! -- 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 -- 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 and gtk+ compiling problems still
Hi I am still not able to compile gtk+ or gtkmm programs in cygwin on my Vista machine I would appreciate some advice on how to do this. I have already posted recently about this and I had a reply but as yet no further help to my follow up (http://cygwin.com/ml/cygwin/2010-01/msg00850.html). I have been trying to get this sorted for many days now and this is becoming frustrating. My latest attempt was this (again unsuccessful as shown): d...@dad-pc /cygdrive/c/RPD_Programming/RPD_Gtk_Gimp_toolkit/helloworld/www_gtk_o rg_hw_tutorial $ cc `pkg-config --cflags --libs gtk+-2.0` helloworld.c -o helloworld : No such file or directory cygwin warning: MS-DOS style path detected: C:/gtkmm/include/gtk-2.0 Preferred POSIX equivalent is: /cygdrive/c/gtkmm/include/gtk-2.0 CYGWIN environment variable option nodosfilewarning turns off this warning. Consult the user's guide for more details about POSIX paths: http://cygwin.com/cygwin-ug-net/using.html#using-pathnames d...@dad-pc /cygdrive/c/RPD_Programming/RPD_Gtk_Gimp_toolkit/helloworld/www_gtk_o rg_hw_tutorial $ gcc `pkg-config --cflags --libs gtk+-2.0` helloworld.c -o helloworld : Invalid argument This compile line is from: Compiling GTK+ Applications Compiling GTK+ Applications How to compile your GTK+ application http://library.gnome.org/devel/gtk/unstable/gtk-compiling.html I will also add that I would eventually like to set up my Vista cmd prompt so I can compile gtk+ and gtkmm directly from cmd prompt but my first step is to get this cygwin bash shell compiling to work. I am grateful for and look forward to some helpful replies, many thanks Richard -- 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: Differentiate workgroup system from domain member under Cygwin
Corinna Vinschen wrote: On Jan 22 10:34, Christoph Herdeg wrote: So question is more if there is any place on a windows system, a file or a directory or an entry in a file that exists only if that machine is a domain member? There are certainly multiple methods to fetch this information. One of them is, for instance: bash$ net config workstation | grep -q 'Domain DNS' \ echo domain-member || echo standalone-machine Corinna Of course you should be aware that localization kicks in. On a French Win Server 2k3 machine I get Nom DNS du domaine de la station de travail Good luck, -- Sylvain RICHARD -- 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: Differentiate workgroup system from domain member under Cygwin
Corinna Vinschen wrote: On Jan 22 10:34, Christoph Herdeg wrote: So question is more if there is any place on a windows system, a file or a directory or an entry in a file that exists only if that machine is a domain member? There are certainly multiple methods to fetch this information. One of them is, for instance: bash$ net config workstation | grep -q 'Domain DNS' \ echo domain-member || echo standalone-machine Corinna Of course you should be aware that localization kicks in. On a French Win Server 2k3 machine I get Nom DNS du domaine de la station de travail And for me, it is necessary to use Workstation (capital W) rather than workstation. -- 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: Design issue with new MS-DOS style path warning?
It may be good advice not to do it. However, there's the case of environment variables, or parameter files containing Windows-style paths used in build.xml, for example. It appears that those variables are not converted sometimes, resulting in failures. One of my build files refers to such a property. I get the DOS file warning at the start of the script, and further down, an error states that C:/cygdrive/c/Users/... couldn't be found. I wonder how Cygwin would come to creating such a hybrid path. Did anyone else run into this? The same script worked perfectly fine before I upgraded to 1.7. -e On Thu, Jan 21, 2010 at 5:59 AM, Dave Korn dave.korn.cyg...@googlemail.com wrote: On 21/01/2010 01:11, Batson, Chuck wrote: That is, how to avoid the warning in a clean way without resorting to the 'nodosfilewarning' option? Say, for example, you create a Windows batch file containing the line: touch C:\foo.txt Well, don't do that then. 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: help with error?
From: Afflictedd2
Sent: Thursday, January 21, 2010 20:57
To: cygwin@cygwin.com
Subject: help with error?
Hi everyone,
I am having the following errors when compiling with cygwin.
It complains on this line of code:
while ( context-holder != '' ) {
/usr/bin/g++ -c-g -o Debug/prodcon.o prodcon.c
prodcon.c:129:32: error: empty character constant
prodcon.c: In function ‘void* producer(void*)’:
prodcon.c:103: error: expected `;' before ‘sizeof’
prodcon.c:103: error: expected `)' before ‘;’ token
prodcon.c:103: error: expected `;' before ‘)’ token
prodcon.c:147: error: expected `}' at end of input
make: *** [Debug/prodcon.o] Error 1
How do I fix this?
--
View this message in context: http://old.nabble.com/help-with-error--
tp27266461p27266461.html
Sent from the Cygwin list mailing list archive at Nabble.com.
'' is not a valid character constant. Did you mean ?
--Ken Nellis
Re: Why require ps -W and kill -f
Don Beusee wrote: ps -e on Unix displays “every process running on the system”. This command doesn't do that under cygwin. Why should it be necessary to supply -W to see all processes running on the system? This makes it incompatible with Linux/Unix, and such scripts that rely on -e doing this will not work the same on Cygwin. What is the point to not showing all other processes on the system like Linux/Unix does? This is a silly design and causes headaches and frustration for people trying to write scripts that work on cygwin and Linux/Unix. Can this be changed please? FWIW I just alias: ps='ps -W' works fine roger wells -Don -- 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 -- Roger Wells, P.E. SAIC 221 Third St Newport, RI 02840 401-847-4210 (voice) 401-849-1585 (fax) roger.k.we...@saic.com -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
RE: help with error?
I got the code from the web so I'm not sure what the author might
have truly meant, a fix was to change it to 0, but I'm not sure if the
program
works as it is meant.
Nellis, Kenneth-2 wrote:
From: Afflictedd2
Sent: Thursday, January 21, 2010 20:57
To: cygwin@cygwin.com
Subject: help with error?
Hi everyone,
I am having the following errors when compiling with cygwin.
It complains on this line of code:
while ( context-holder != '' ) {
/usr/bin/g++ -c-g -o Debug/prodcon.o prodcon.c
prodcon.c:129:32: error: empty character constant
prodcon.c: In function ‘void* producer(void*)’:
prodcon.c:103: error: expected `;' before ‘sizeof’
prodcon.c:103: error: expected `)' before ‘;’ token
prodcon.c:103: error: expected `;' before ‘)’ token
prodcon.c:147: error: expected `}' at end of input
make: *** [Debug/prodcon.o] Error 1
How do I fix this?
--
View this message in context: http://old.nabble.com/help-with-error--
tp27266461p27266461.html
Sent from the Cygwin list mailing list archive at Nabble.com.
'' is not a valid character constant. Did you mean ?
--Ken Nellis
--
View this message in context:
http://old.nabble.com/help-with-error--tp27266461p27273392.html
Sent from the Cygwin list mailing list archive at Nabble.com.
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
RE: Design issue with new MS-DOS style path warning?
Batson, Chuck sent the following at Wednesday, January 20, 2010 8:11 PM I am aware it is possible to disable the MS-DOS style path detected warning with the 'nodosfilewarning' option. But this message raises the question of, What is the Cygwin ideal? That is, how to avoid the warning in a clean way without resorting to the 'nodosfilewarning' option? (1) It seems to me that 'nodosfilewarning' is clean and is the Cygwin ideal. What is the problem using it? (2) Have people set the CYGWIN environmental variable? I would think that anyone who can handle the command line could handle that. (3) Note to the CYGWIN DEVELOPERS: Now that the mount table is has moved from the Registry to a text file, perhaps it would make sense for cygwin1.dll to look at a text file, e.g., /etc/cygwin.env, if the CYGWIN environmental variable is unset. This might also allow one to duplicate a cygwin installation by just copying a directory tree and the appropriate Windows batch files and shortcuts without having to run setup and without having set CYGWIN via the Control Panel | System | Advanced | Environmental Variables. Just a suggestion, not a request. (I don't need it.) There is a situation in which it is not conceptually clean to avoid the warning: at the interface between the host OS and Cygwin tools. Say, for example, you create a Windows batch file containing the line: touch C:\foo.txt (4) Does the following work if you put it at the beginning of the batch file? set CYGWIN=%CYGWIN% nodosfilewarning (Sorry I haven't tested - too much trouble.) (5) Tell people to always run from the current directory? cd C:\ touch foo.txt (6) Don't use cygwin. Compile the utilities of interest under MinGW. http://www.mingw.org/ (While you are there, look into MSYS and mingwPORTs.) Find native utilities. Here are the 2 I know about. http://sourceforge.net/projects/pw32/ http://unxutils.sourceforge.net/ Note that they haven't been updated in a while. (7) Go back to 1.5. - Barry Disclaimer: Statements made herein are not made on behalf of NIAID. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Cygwin and gtk+ compiling problems still
On 1/22/2010 5:28 AM, Richard Dickinson wrote: Hi I am still not able to compile gtk+ or gtkmm programs in cygwin on my Vista machine I would appreciate some advice on how to do this. I have already posted recently about this and I had a reply but as yet no further help to my follow up (http://cygwin.com/ml/cygwin/2010-01/msg00850.html). I have been trying to get this sorted for many days now and this is becoming frustrating. My latest attempt was this (again unsuccessful as shown): d...@dad-pc /cygdrive/c/RPD_Programming/RPD_Gtk_Gimp_toolkit/helloworld/www_gtk_o rg_hw_tutorial $ cc `pkg-config --cflags --libs gtk+-2.0` helloworld.c -o helloworld : No such file or directory cygwin warning: MS-DOS style path detected: C:/gtkmm/include/gtk-2.0 Preferred POSIX equivalent is: /cygdrive/c/gtkmm/include/gtk-2.0 CYGWIN environment variable option nodosfilewarning turns off this warning. Consult the user's guide for more details about POSIX paths: http://cygwin.com/cygwin-ug-net/using.html#using-pathnames I'm no expert at compiling GTK+ applications, but the cygwin warning you see there tells me that you have a program in your PATH being used by your command which is returning Windows-style paths. Cygwin programs won't do this, so you must have a mixed environment. You should scrub your PATH so that you only have Cygwin programs available, most especially cc and pkg-config. Resolving that issue may resolve the other issue I see: : No such file or directory This sort of output is usually caused by passing in a line of text with DOS (CRLF) line endings rather than Unix (LF) line endings to a Cygwin program. What happens in this case is that the line is a path and the Cygwin program tries to use it including the CR. This is obviously not going to work since the path doesn't really include the CR, so the Cygwin program will complain that the path does not exist. When it does that the line is printed, but the carriage return character (CR) backs up the cursor to the beginning of the line at which point the error message, everything past and including the colon you see, is printed which overwrites the first part of the line. You can get a better idea of what's really being printed by running your command as follows: cc `pkg-config --cflags --libs gtk+-2.0` \ helloworld.c -o helloworld compile.out 21 Be sure to include the trailing backslash on the first line. This command will cause all of the output to be sent to compile.out which you may then open with a text editor to see the exact text, including the text which is being overwritten when sent to the terminal. I will also add that I would eventually like to set up my Vista cmd prompt so I can compile gtk+ and gtkmm directly from cmd prompt but my first step is to get this cygwin bash shell compiling to work. You can get this to work, but you may end up spending more effort than it's worth to be honest. You're probably more comfortable with the cmd shell than bash at the moment, but believe me that once you learn to use bash, you'll wonder how Microsoft ever got away with shipping cmd as their only shell for all these years. :-) There are many bash resources including howtos, FAQs, and even the full bash manual (http://www.gnu.org/software/bash/manual/) just a quick google away. Good luck. -Jeremy -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Problems starting sshd as a service on cygwin 1.7.1
Yes I looked for the logs - the /var/logs/sshd.log file is 0 length. Is there another log somewhere ? I'll explore if this is something the Symantec Client Firewall is causing. imaging away / flick -- 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
Insall libsdl1.2 and libsdl1.2-dev packages
Hi, I installed cygwin 1.5, but when when I used it to install another programm, I've got this error: $ ./bootstrap configure.ac:562: warning: macro `AM_PATH_SDL' not found in library which means that I need to install these packages to my system: libsdl1.2 and libsdl1.2-dev , my problem is that I don't find these packages in cygwin setup.exe, and I don't know how to get them, and install them via cygwin! any help would be appreciated Thanks -- 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: units: update, FHS compliance
On Fri, Jan 22, 2010 at 10:19:10AM +0100, Corinna Vinschen wrote: On Jan 21 12:40, Yaakov S wrote: On 21/01/2010 05:11, Corinna Vinschen wrote: Interesting. Especially the part about cmake. Did you try to convince Bill that WIN32 is not a good idea for the Cygwin distro package? Yes, among other things: http://www.cmake.org/Bug/view.php?id=10122 I didn't manage to read all of it but, boy, sounds like a lot of work. Yeah, I'm in awe of the perseverence shown in that report. We're certainly lucky to have someone like Yaakov in this project. 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: Design issue with new MS-DOS style path warning?
On Fri, Jan 22, 2010 at 02:17:56PM +0100, Eric Vautier wrote: It may be good advice not to do it. However, there's the case of environment variables, or parameter files containing Windows-style paths used in build.xml, for example. It appears that those variables are not converted sometimes, resulting in failures. Cygwin doesn't complain about MS-DOS paths in random environment variables unless your program decides to use them to open/stat/access/etc. a file. If you are getting warnings then Cygwin is working as designed. It is telling you that you're doing something that is not guaranteed to work. If you want to turn this off then use the CYGWIN environment variable. One of my build files refers to such a property. And the property is? I get the DOS file warning at the start of the script, and further down, an error states that C:/cygdrive/c/Users/... couldn't be found. I wonder how Cygwin would come to creating such a hybrid path. Did anyone else run into this? The same script worked perfectly fine before I upgraded to 1.7. It is likely that Cygwin didn't. It's much more likely that it is something local to your installation. If it wasn't then the mailing list would be full of complaints. 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
1.7: Problem with Novell volumes
Hello, I recently upgraded to Cygwin 1.7. Since the upgrade, I started having issues with accessing Novell volumes. These issues are possibly similar to those seen by Avi Shwartz in his other threads. I'm too dumb to figure out how I can reply to those other threads so my apologies for creating another one. But I figured having another person with the same issue might be useful for getting to the bottom of the problem. All of the Novell volumes are having the same issues, but I'll use the H: drive to show the problem. I can perform an ls with no problems, but ls -l and cd fail as shown below: 34...@tcom-nfo-16 ~ $ ls /cygdrive/h Citrix_docs Favorites My Wallpapers Workspace workbench Default.rdp My Documents Notes notes.ini 34...@tcom-nfo-16 ~ $ ls -l /cygdrive/h ls: cannot access /cygdrive/h: Input/Output error 34...@tcom-nfo-16 ~ $ cd /cygdrive/h -bash: cd: /cygdrive/h: Not a directory Here is a comparison of a local NTFS volume versus the Novell drive mentioned above: 34...@tcom-nfo-16 ~ $ /usr/lib/csih/getVolInfo /cygdrive/c Device Type: 7 Characteristics: 20 Volume Name: Serial Number : 2289774672 Max Filenamelength : 255 Filesystemname : NTFS Flags : 700ff FILE_CASE_SENSITIVE_SEARCH : TRUE FILE_CASE_PRESERVED_NAMES : TRUE FILE_UNICODE_ON_DISK: TRUE FILE_PERSISTENT_ACLS: TRUE FILE_FILE_COMPRESSION : TRUE FILE_VOLUME_QUOTAS : TRUE FILE_SUPPORTS_SPARSE_FILES : TRUE FILE_SUPPORTS_REPARSE_POINTS: TRUE FILE_SUPPORTS_REMOTE_STORAGE: FALSE FILE_VOLUME_IS_COMPRESSED : FALSE FILE_SUPPORTS_OBJECT_IDS: TRUE FILE_SUPPORTS_ENCRYPTION: TRUE FILE_NAMED_STREAMS : TRUE FILE_READ_ONLY_VOLUME : FALSE FILE_SEQUENTIAL_WRITE_ONCE : FALSE FILE_SUPPORTS_TRANSACTIONS : FALSE 34...@tcom-nfo-16 ~ $ /usr/lib/csih/getVolInfo /cygdrive/h Device Type: 7 Characteristics: 30 Volume Name: USER42 Serial Number : 167843373 Max Filenamelength : 255 Filesystemname : NWFS Flags : 2 FILE_CASE_SENSITIVE_SEARCH : FALSE FILE_CASE_PRESERVED_NAMES : TRUE FILE_UNICODE_ON_DISK: FALSE FILE_PERSISTENT_ACLS: FALSE FILE_FILE_COMPRESSION : FALSE FILE_VOLUME_QUOTAS : FALSE FILE_SUPPORTS_SPARSE_FILES : FALSE FILE_SUPPORTS_REPARSE_POINTS: FALSE FILE_SUPPORTS_REMOTE_STORAGE: FALSE FILE_VOLUME_IS_COMPRESSED : FALSE FILE_SUPPORTS_OBJECT_IDS: FALSE FILE_SUPPORTS_ENCRYPTION: FALSE FILE_NAMED_STREAMS : FALSE FILE_READ_ONLY_VOLUME : FALSE FILE_SEQUENTIAL_WRITE_ONCE : FALSE FILE_SUPPORTS_TRANSACTIONS : FALSE Output from mount if it is helpful: $ mount C:/cygwin/bin on /usr/bin type ntfs (binary,auto) C:/cygwin/lib on /usr/lib type ntfs (binary,auto) C:/cygwin on / type ntfs (binary,auto) C: on /cygdrive/c type ntfs (binary,posix=0,user,noumount,auto) F: on /cygdrive/f type nwfs (binary,posix=0,user,noumount,auto) G: on /cygdrive/g type nwfs (binary,posix=0,user,noumount,auto) H: on /cygdrive/h type nwfs (binary,posix=0,user,noumount,auto) Q: on /cygdrive/q type nwfs (binary,posix=0,user,noumount,auto) Y: on /cygdrive/y type nwfs (binary,posix=0,user,noumount,auto) Cygwin Version information: $ uname -a CYGWIN_NT-5.1 TCOM-NFO-16 1.7.1(0.218/5/3) 2009-12-07 11:48 i686 Cygwin I did not include a trace here but I can do so if it is helpful. Thanks in advance for any help you can provide, Sean -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
R: Insall libsdl1.2 and libsdl1.2-dev packages
--- Ven 22/1/10, ghada zaibi ha scritto: Hi, I installed cygwin 1.5, but when when I used it to install another programm, I've got this error: $ ./bootstrap configure.ac:562: warning: macro `AM_PATH_SDL' not found in library which means that I need to install these packages to my system: libsdl1.2 and libsdl1.2-dev , my problem is that I don't find these packages in cygwin setup.exe, and I don't know how to get them, and install them via cygwin! any help would be appreciated Thanks http://sourceware.org/cygwinports/ Regards Marco -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: ls command crashed
On 01/22/2010 01:43 AM, Huang Bambo wrote: [ba...@bambo-pc /cygdrive/c/Sandbox/Bambo/DefaultBox] $ ls 6 [main] -bash 1104 fork: child -1 - died waiting for longjmp before initialization, retry 0, exit code 0xC10A, errno 11 snip $ cygcheck.exe -s We ask that you *attach* rather than append/inline this information. This removes false-positive hits on terms that show up in the cygcheck output. The version of cygrunsrv installed is too old to dump service info. So you've apparently somewhat unsuccessfully installed 1.7.1 over 1.5.25. Use the current 'setup.exe' at http://cygwin.com/setup.exe to reinstall your environment. *Don't* use a cached version of 'setup.exe'. You need version 2.677. -- 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: Design issue with new MS-DOS style path warning?
On Fri, Jan 22, 2010 at 4:45 PM, Christopher Faylor cgf-use-the-mailinglist-ple...@cygwin.com wrote: On Fri, Jan 22, 2010 at 02:17:56PM +0100, Eric Vautier wrote: If you are getting warnings then Cygwin is working as designed. It is telling you that you're doing something that is not guaranteed to work. If you want to turn this off then use the CYGWIN environment variable. I understand that. One of my build files refers to such a property. And the property is? I'll try and investigate the issue further. I get the DOS file warning at the start of the script, and further down, an error states that C:/cygdrive/c/Users/... couldn't be found. I wonder how Cygwin would come to creating such a hybrid path. Did anyone else run into this? The same script worked perfectly fine before I upgraded to 1.7. It is likely that Cygwin didn't. It's much more likely that it is something local to your installation. If it wasn't then the mailing list would be full of complaints. Let me confirm that the script has not changed at all, and used to work fine under the previous version. You'll agree that arriving at a C:/cygdrive/c/... path is a little odd, regardless of setup. Perhaps a string is set that way some place, but I doubt it. -e -- 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: Problem with svn and users over multiple machines
On 01/22/2010 04:21 AM, Gary . wrote: I don't know if this is a Cygwin related problem or if I am just being stupid. Probably the latter, but maybe in that case some kind soul will take pity on me. I added a new user svn and a new group subversion-user, basically following http://www.cygwin.com/ml/cygwin/2005-07/msg00933.html with the addition of also doing mkgroup -l -g subversion-user /etc/group. I then created a subversion repository in the usual way, on an NDAS drive, and then changed the file permissions so that they are owned by user svn and can be modified by members of the group subversion-user. I could then add and commit files to my repository. So far so good. I also want to be able to work on another machine in a similar manner, so did the same things on that machine regarding user and group as I did on the first. My suspicion is that I shouldn't have, I should have done something else instead, because I see g...@mimosa ~ $ ls -l /svn/db total 14 -rw-r--r--+ 1 garyKein 2 2010-01-22 09:34 current -r--r--r-- 1 svn subversion-user 22 2010-01-22 08:22 format -rw-r--r-- 1 svn subversion-user5 2010-01-22 08:22 fs-type -rw-r--r-- 1 svn subversion-user 1920 2010-01-22 08:22 fsfs.conf (etc.) from the first machine... ...but see g...@sunflower ~ $ ls -l /svn/db total 14 -rw-r--r--+ 1 2 2010-01-22 09:34 current -r--r--r-- 1 22 2010-01-22 08:22 format -rw-r--r-- 1 5 2010-01-22 08:22 fs-type -rw-r--r-- 1 1920 2010-01-22 08:22 fsfs.conf (etc.) from the second. The means that Cygwin on the second machine doesn't know the owner of these files. This means the user and group IDs are missing from the '/etc/passwd' and '/etc/group' files. Add them and this problem should go away. See the discussion of security in the Cygwin Users Guide for more details. -- 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: Design issue with new MS-DOS style path warning?
On 22/01/2010 16:23, Eric Vautier wrote: Let me confirm that the script has not changed at all, and used to work fine under the previous version. You'll agree that arriving at a C:/cygdrive/c/... path is a little odd, regardless of setup. Nope, it's actually entirely sensible! Because : is not a drive-letter separator in Linux; it's a separator between path-list components, like ; is under DOS. So if you say C:\foo\bar in a path-list context, you are specifying a list of two paths: C and \foo\bar. Cygwin (or whatever utility is doing the work) translates each one separately and then reconcatenates them. C in DOS is a relative path to any subdirectory called C in the current dir; that stays the same in unix syntax. \foo\bar in DOS is an absolute path relative to the root of the current drive, which, being your C drive, translates into /cygdrive/c/foo/bar. These two are then reconcatenated into a path list separted by colons. The older version was buggy in this regard, it handled dos paths correctly at the expense of making a mess of colon-separated posix-style path lists sometimes. That's why the behaviour has changed, because posix compatibility wins out over windows compatibility as a design goal of cygwin, and that's why there's now a warning, to let you know that what you are doing is not going to work how you want it to. 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: Best way to backup 1.5 to go to 1.7
If you have both 1.5 1.7, they can sorta co-exist. Leave your 1.5 system alone. Now crate download 1.7 into a new node. (e.g./cygwinII). Just make sure everything is separate, include your update nodes and create a new start icon for 1.7 only. You might want to enforce separate executions of 1.5 1.7 I did this for the several months before switch-over and it worked perfectly. If your machine is shared amoung users, them you will have to work that out. My was a single-user system. Frank Fesevur wrote: 2010/1/21 Brian Keener: I want to upgrade to 1.7 but would like to get a backup of the full 1.5 install before hand. I know in the past just doing copies some files didn't or couldn't get copied. Also in the unix world seems as though I recall tar and cpio have difference in terms of what they will and won't backup. What the best way to get a good copy of my 1.5 in case I need/want to get it back. I have made a backup of 1.5 by 7-Zipping the entire directory and also backup the mount v2 tree of Cygnus Solutions in the registry. I have had problems upgrading to 1.7 on one pc and could successfully restore my 1.5 installation. Regards, Frank -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
futimes?
I noticed this change when reviewing libarchive development: Windows resets atime at file close, so we can't use futimes() on Cygwin. http://code.google.com/p/libarchive/source/detail?r=1832 Is that the expected behavior? I thought cygwin-(1.7?) took special care to go back and fix up this problem during close()... -- Chuck -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: futimes?
According to Charles Wilson on 1/22/2010 9:48 AM: I noticed this change when reviewing libarchive development: Windows resets atime at file close, so we can't use futimes() on Cygwin. http://code.google.com/p/libarchive/source/detail?r=1832 Is that the expected behavior? I thought cygwin-(1.7?) took special care to go back and fix up this problem during close()... In fact, cygwin goes to great lengths to work around this bug in the MVFS file system (that is, duplicate the handle, set atime on the duplicate, close it to force a flush to disk, then set atime on the original). Which file system was the libarchive bug reported on? Maybe we need to reuse the MVFS hack on other file systems. But my experience has been that futimes works correctly on NTFS. -- Don't work too hard, make some time for fun as well! Eric Blake e...@byu.net signature.asc Description: OpenPGP digital signature
1.7.1 gcc doesn't produce an output file
I've been using Cygwin and gcc for years with no problems. Recently I had to rebuild my Windows machine, and I installed the previous version of Cygwin (1.5.?). After a few days, I noticed 1.7 was out so I upgraded. Yesterday I tried using gcc for the first time. I'm now having a problem where gcc fails to produce an output file in my normal working directory. When I attempt to compile a simple hello world program, gcc just returns without showing an error, but does not produce an object or executable. Turning verbose mode on, I get the following information: -~ gcc -v hw.c Reading specs from /usr/lib/gcc/i686-pc-cygwin/3.4.4/specs Configured with: /managed/gcc-build/final-v3-bootstrap/gcc-3.4.4-999/configure --verbose --program-suffix=-3 --prefix=/usr --exec-prefix=/usr --sysconfdir=/etc --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info --enable-languages=c,ada,c++,d,f77,pascal,java,objc --enable-nls --without-included-gettext --enable-version-specific-runtime-libs --without-x --enable-libgcj --disable-java-awt --with-system-zlib --enable-interpreter --disable-libgcj-debug --enable-threads=posix --enable-java-gc=boehm --disable-win32-registry --enable-sjlj-exceptions --enable-hash-synchronization --enable-libstdcxx-debug Thread model: posix gcc version 3.4.4 (cygming special, gdc 0.12, using dmd 0.125) /usr/lib/gcc/i686-pc-cygwin/3.4.4/cc1.exe -quiet -v -D__CYGWIN32__ -D__CYGWIN__ -Dunix -D__unix__ -D__unix -idirafter /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api -idirafter /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../i686-pc-cygwin/lib/../../include/w32api hw.c -quiet -dumpbase hw.c -mtune=pentiumpro -auxbase hw -version -o /cygdrive/c/Documents and Settings/121756/Local Settings/Temp/ccxai7o3.s I CAN, however, compile the same program if I copy it over to /usr/bin. It shows the following in verbose mode: gcc -v hw.c Reading specs from /usr/lib/gcc/i686-pc-cygwin/3.4.4/specs Configured with: /managed/gcc-build/final-v3-bootstrap/gcc-3.4.4-999/configure --verbose --program-suffix=-3 --prefix=/usr --exec-prefix=/usr --sysconfdir=/etc --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info --enable-languages=c,ada,c++,d,f77,pascal,java,objc --enable-nls --without-included-gettext --enable-version-specific-runtime-libs --without-x --enable-libgcj --disable-java-awt --with-system-zlib --enable-interpreter --disable-libgcj-debug --enable-threads=posix --enable-java-gc=boehm --disable-win32-registry --enable-sjlj-exceptions --enable-hash-synchronization --enable-libstdcxx-debug Thread model: posix gcc version 3.4.4 (cygming special, gdc 0.12, using dmd 0.125) /usr/lib/gcc/i686-pc-cygwin/3.4.4/cc1.exe -quiet -v -D__CYGWIN32__ -D__CYGWIN__ -Dunix -D__unix__ -D__unix -idirafter /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api -idirafter /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../i686-pc-cygwin/lib/../../include/w32api hw.c -quiet -dumpbase hw.c -mtune=pentiumpro -auxbase hw -version -o /cygdrive/c/Documents and Settings/121756/Local Settings/Temp/cc1H9n5q.s ignoring nonexistent directory /usr/local/include ignoring nonexistent directory /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../i686-pc-cygwin/include ignoring duplicate directory /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../i686-pc-cygwin/lib/../../include/w32api #include ... search starts here: #include ... search starts here: /usr/lib/gcc/i686-pc-cygwin/3.4.4/include /usr/include /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api End of search list. GNU C version 3.4.4 (cygming special, gdc 0.12, using dmd 0.125) (i686-pc-cygwin) compiled by GNU C version 3.4.4 (cygming special, gdc 0.12, using dmd 0.125). GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 hw.c: In function `main': hw.c:4: warning: return type of 'main' is not `int' /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../i686-pc-cygwin/bin/as.exe -o /cygdrive/c/Documents and Settings/121756/Local Settings/Temp/ccUOmYcs.o /cygdrive/c/Documents and Settings/121756/Local Settings/Temp/cc1H9n5q.s /usr/lib/gcc/i686-pc-cygwin/3.4.4/collect2.exe -Bdynamic --dll-search-prefix=cyg /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../crt0.o -L/usr/lib/gcc/i686-pc-cygwin/3.4.4 -L/usr/lib/gcc/i686-pc-cygwin/3.4.4 -L/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../.. /cygdrive/c/Documents and Settings/121756/Local Settings/Temp/ccUOmYcs.o -lgcc -lcygwin -luser32 -lkernel32 -ladvapi32 -lshell32 -lgcc The difference is that the nonworking compile stops before it starts showing the ignoring nonexistent directory messages. I thought perhaps this was a permissions issue, so I matched the user/group and file permissions between the directories, yet still no luck. Any ideas for me to try would be much appreciated. Thanks, Tony -- Problem reports: http://cygwin.com/problems.html FAQ:
Re: 1.7.1 gcc doesn't produce an output file
On 22/01/2010 17:05, Tony Nelson wrote: I CAN, however, compile the same program if I copy it over to /usr/bin. Where was it in the first place? Please run cygcheck /usr/lib/gcc/i686-pc-cygwin/3.4.4/cc1.exe from within both there and the original directory. And tell us what your $PATH is set to. 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: Design issue with new MS-DOS style path warning?
On Fri, Jan 22, 2010 at 6:01 PM, Dave Korn
dave.korn.cyg...@googlemail.com wrote:
On 22/01/2010 16:23, Eric Vautier wrote:
Let me confirm that the script has not changed at all, and used to
work fine under the previous version. You'll agree that arriving at a
C:/cygdrive/c/... path is a little odd, regardless of setup.
Nope, it's actually entirely sensible! Because : is not a drive-letter
separator in Linux; it's a separator between path-list components, like ; is
under DOS.
So if you say C:\foo\bar in a path-list context, you are specifying a list
of two paths: C and \foo\bar. Cygwin (or whatever utility is doing the
work) translates each one separately and then reconcatenates them. C in DOS
is a relative path to any subdirectory called C in the current dir; that
stays the same in unix syntax. \foo\bar in DOS is an absolute path relative
to the root of the current drive, which, being your C drive, translates into
/cygdrive/c/foo/bar. These two are then reconcatenated into a path list
separted by colons.
The older version was buggy in this regard, it handled dos paths correctly
at the expense of making a mess of colon-separated posix-style path lists
sometimes. That's why the behaviour has changed, because posix compatibility
wins out over windows compatibility as a design goal of cygwin, and that's why
there's now a warning, to let you know that what you are doing is not going to
work how you want it to.
Right :)
So essentially, I have a broken script now, that used to work fine.
Remains the challenge: how to fix it for non-buggy 1.7.
FYI, the faulty but perfectly logical path in one of the two
failures (I'll try to trace the other one as well) was arrived at
from:
0. Invocation from sh build.sh (mid-script):
ant clean get-common debug
1. Output of build script:
AndroidApp
BUILD FAILED
C:\dev\prj\app4\AndroidApp\build.xml:343: Warning: Could not find file
C:\cygdrive\c\dev\prj\app4\Common\target\Common.jar to copy.
2. Build target (lines 342-344):
target name=get-common
copy file=${common-jar} todir=libs /
/target
3. Properties:
property name=common location=${env.APP4_COMMON_ROOT} /
property name=common-jar value=${common}/target/Common.jar /
4. Environment variable:
APP4_COMMON_ROOT = C:\dev\prj\app4\Common
Typing ant clean get-common debug works fine from the command line.
-e
--
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: Design issue with new MS-DOS style path warning?
On 22/01/2010 17:23, Eric Vautier wrote:
FYI, the faulty but perfectly logical path in one of the two
failures (I'll try to trace the other one as well) was arrived at
from:
0. Invocation from sh build.sh (mid-script):
ant clean get-common debug
1. Output of build script:
AndroidApp
BUILD FAILED
C:\dev\prj\app4\AndroidApp\build.xml:343: Warning: Could not find file
C:\cygdrive\c\dev\prj\app4\Common\target\Common.jar to copy.
2. Build target (lines 342-344):
target name=get-common
copy file=${common-jar} todir=libs /
/target
3. Properties:
property name=common location=${env.APP4_COMMON_ROOT} /
property name=common-jar value=${common}/target/Common.jar /
4. Environment variable:
APP4_COMMON_ROOT = C:\dev\prj\app4\Common
Typing ant clean get-common debug works fine from the command line.
So, you are lumbered with some massive mish-mash of complex build scripts,
ANT, java, mixture of cygwin and native executables and god knows what else,
and somewhere down in the middle of it something's invoking what it probably
expects to be a win32 program and getting the cygwin version, or vice-versa.
Ouch. You're going to have to figure out what's going on way down in the
internals and try and extract a simple testcase.
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: units: update, FHS compliance
On 01/22/2010 10:40 AM, Christopher Faylor wrote: On Fri, Jan 22, 2010 at 10:19:10AM +0100, Corinna Vinschen wrote: On Jan 21 12:40, Yaakov S wrote: On 21/01/2010 05:11, Corinna Vinschen wrote: Interesting. Especially the part about cmake. Did you try to convince Bill that WIN32 is not a good idea for the Cygwin distro package? Yes, among other things: http://www.cmake.org/Bug/view.php?id=10122 I didn't manage to read all of it but, boy, sounds like a lot of work. Yeah, I'm in awe of the perseverence shown in that report. We're certainly lucky to have someone like Yaakov in this project. What's all this talk about Yaakov? I mean sure, he maintains thousands of packages between what's in the distribution and what's on Cygwin Ports. And he's very active and all. But really, how much time can this take? A couple of hours a month and an occasional email? I mean, come on, anyone could do that. It's not that hard. Especially in this world full of unicorns and rainbows. -- 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: 1.7.1 gcc doesn't produce an output file
I ran cygcheck and saw that there was a stray Cygwin DLL file in my path. It was installed as part of Mentor Graphics Expedition. After removing the Expedition directory from my $PATH, the problem was resolved. Thanks, Tony -- 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: Design issue with new MS-DOS style path warning?
So, you are lumbered with some massive mish-mash of complex build scripts, ANT, java, mixture of cygwin and native executables and god knows what else, and somewhere down in the middle of it something's invoking what it probably expects to be a win32 program and getting the cygwin version, or vice-versa. Ouch. You're going to have to figure out what's going on way down in the internals and try and extract a simple testcase. Yes, it's a slightly complicated build script, but it does the job properly when invoked manually. It only fails if it is invoked from inside a wrapping shell script. To sum up: all 5 builds (three maven, two ant) work fine when invoked manually from the command-line. The two ant builds fail in the overall build invocator (build.sh, but I should probably call it build-all.sh), whose sole task is to launch the 5 builds from inside their own directories; the three maven builds are fine. I see no reason why calling that ant build from inside a shell script should mess up the paths with C:\cygdrive\c\dev\ prefixes. build.sh does have #!/bin/sh at the top. Will investigate a little more. -e -- 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: Design issue with new MS-DOS style path warning?
On 22/01/2010 17:55, Eric Vautier wrote:
So, you are lumbered with some massive mish-mash of complex build scripts,
ANT, java, mixture of cygwin and native executables and god knows what else,
and somewhere down in the middle of it something's invoking what it probably
expects to be a win32 program and getting the cygwin version, or vice-versa.
Ouch. You're going to have to figure out what's going on way down in the
internals and try and extract a simple testcase.
Yes, it's a slightly complicated build script, but it does the job
properly when invoked manually. It only fails if it is invoked from
inside a wrapping shell script.
That shell script presumably does some stuff first before invoking it; maybe
that's where the problem originates. Also, you're running it from sh in
that situation, instead of bash as you do from the command-line; that might
be relevant or might not. (sh is an alias for bash that invokes it with
slightly-altered behaviour.)
To sum up: all 5 builds (three maven, two ant) work fine when invoked
manually from the command-line. The two ant builds fail in the overall
build invocator (build.sh, but I should probably call it
build-all.sh), whose sole task is to launch the 5 builds from inside
their own directories; the three maven builds are fine.
I see no reason why calling that ant build from inside a shell script
should mess up the paths with C:\cygdrive\c\dev\ prefixes. build.sh
does have #!/bin/sh at the top. Will investigate a little more.
Adding -x flag to the shebang might help.
property name=common location=${env.APP4_COMMON_ROOT} /
property name=common-jar value=${common}/target/Common.jar /
APP4_COMMON_ROOT = C:\dev\prj\app4\Common
Try not using mixed slashes. Both Cygwin and DOS should be fairly happy with
APP4_COMMON_ROOT = C:/dev/prj/app4/Common
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: 1.7.1 Bad Address when running cmd.exe on 64 bit windows server 2008
Hi - I found that this error occurs on a 32 bit windows system, so its not 64 bit related as I initially thought. The problem is only occurring in Cygwin 1.7.1, not 1.5.24 so I will use the older version of cygwin until there is a fix for this. Thanks jennifer...@nc.rr.com wrote: Hi - I am trying to run various windows commands from an ssh session to my Windows 2008 64 bit server running Cygwin 1.7.1. Everything I run with 'cmd.exe' fails with bad address as shown below, note that I can run the command natively without cmd.exe in the last example so in general things work, its just this cmd.exe that is causing my program to fail; administra...@nc042046 ~ $ cmd.exe /c 'mkdir C:\WINDOWS\temp' -bash: /cygdrive/c/Windows/system32/cmd.exe: Bad address administra...@nc042046 ~ $ cmd.exe /c hostname -bash: /cygdrive/c/Windows/system32/cmd.exe: Bad address administra...@nc042046 ~ $ hostname nc042046 I've looked in all the forums, and I cannot find anything. I do see the support statement for 64 bit states as well as the WOW64 32 bit environment on released 64 bit versions of Windows (XP/2003/Vista/2008/7/2008 R2). As far as we know no one is working on a native 64 bit version of Cygwin. but I am not sure exactly how to run or check that I am using the WOW64 32 bit environment. I do suspect the problem is related to 64 bit as others have told me this is working fine on their 32 bit systems. Any thoughts would be appreciated. Thank You Jennifer -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: 1.7.1 Bad Address when running cmd.exe on 64 bit windows server 2008
Hi - I found that this error occurs on a 32 bit windows system, so its not 64 bit related as I initially thought. The problem is only occurring in Cygwin 1.7.1, not 1.5.24 so I will use the older version of cygwin until there is a fix for this. Thanks jennifer...@nc.rr.com wrote: Hi - I am trying to run various windows commands from an ssh session to my Windows 2008 64 bit server running Cygwin 1.7.1. Everything I run with 'cmd.exe' fails with bad address as shown below, note that I can run the command natively without cmd.exe in the last example so in general things work, its just this cmd.exe that is causing my program to fail; administra...@nc042046 ~ $ cmd.exe /c 'mkdir C:\WINDOWS\temp' -bash: /cygdrive/c/Windows/system32/cmd.exe: Bad address administra...@nc042046 ~ $ cmd.exe /c hostname -bash: /cygdrive/c/Windows/system32/cmd.exe: Bad address administra...@nc042046 ~ $ hostname nc042046 I've looked in all the forums, and I cannot find anything. I do see the support statement for 64 bit states as well as the WOW64 32 bit environment on released 64 bit versions of Windows (XP/2003/Vista/2008/7/2008 R2). As far as we know no one is working on a native 64 bit version of Cygwin. but I am not sure exactly how to run or check that I am using the WOW64 32 bit environment. I do suspect the problem is related to 64 bit as others have told me this is working fine on their 32 bit systems. Any thoughts would be appreciated. Thank You Jennifer -- 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
Bash process substitution
Is process substitution expected to work in 1.7.1? Here's what I tried: kilr...@minime ~ $ uname -a CYGWIN_NT-5.1 MINIME 1.7.1(0.218/5/3) 2009-12-07 11:48 i686 Cygwin kilr...@minime ~ $ echo LOG:bananas | tee file.txt LOG:bananas kilr...@minime ~ $ cat file.txt LOG:bananas kilr...@minime ~ $ echo LOG:bananas | tee (grep ^LOG: file.txt) LOG:bananas tee: /dev/fd/63: Bad file descriptor kilr...@minime ~ $ cat file.txt --- I'm actually trying to do something like: socat - /dev/ttyS0,raw,echo=0 | tee \ (grep ^LOG: --line-buffered | socat - UDP:localhost:1234) but am getting the same error as the simpler example. And if anyone knows whether STDIN would make it out of /dev/ttyS0, (or how to get that) I'd appreciate the hint. Thanks, Dave. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
RE: 1.7.1 Bad Address when running cmd.exe on 64 bit windows server 2008
Hi - I found that this error occurs on a 32 bit windows system, so its not 64 bit related as I initially thought. The problem is only occurring in Cygwin 1.7.1, not 1.5.24 so I will use the older version of cygwin until there is a fix for this. Thanks jennifer...@nc.rr.com wrote: Hi - I am trying to run various windows commands from an ssh session to my Windows 2008 64 bit server running Cygwin 1.7.1. Everything I run with 'cmd.exe' fails with bad address as shown below, note that I can run the command natively without cmd.exe in the last example so in general things work, its just this cmd.exe that is causing my program to fail; administra...@nc042046 ~ $ cmd.exe /c 'mkdir C:\WINDOWS\temp' -bash: /cygdrive/c/Windows/system32/cmd.exe: Bad address I get the same result you do when I use /c (lower case c), but the command is processed as expected when I use /C (upper case C). -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: help with error?
On 22/01/2010 01:57, Afflictedd2 wrote: Hi everyone, I am having the following errors when compiling with cygwin. Didn't like the answer you got first time, when you were compiling it on your mac, eh? http://cboard.cprogramming.com/cplusplus-programming/123331-help-error.html When you get the same error in two different systems like this, you should assume that the code is at fault, rather than the systems. 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: 1.7.1 Bad Address when running cmd.exe on 64 bit windows server 2008
On 22/01/2010 19:10, Cooper, Karl (US SSA) wrote: jenniferlee@ wrote: administra...@nc042046 ~ $ cmd.exe /c 'mkdir C:\WINDOWS\temp' -bash: /cygdrive/c/Windows/system32/cmd.exe: Bad address I get the same result you do when I use /c (lower case c), but the command is processed as expected when I use /C (upper case C). I get the same, and found a different workaround: it works by using cmd instead of cmd.exe. 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
Missing xdvi
Hello friends, I've installed all tetex-* packages, howver, I can't find xdvi. Should I compile it from source myself? Thank you in advance for any hint! Wen -- 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] Very odd reverse proxy problem . [nginx - win32 zope]
The things: * I have a nginx handmade compiled under the hood * I have an official zope+plone installation on native windows * I have a django based application inside the cygwin * I have a tomcat+cas installation on native windows All of that seem to be configured correctly. What i want to do is to make my nginx a reverse proxy of the 3 others applications. Because of some other application needs (wsgi served with flup/socket) i need that nginx to live inside the cygwin installation. That's not my concern afterall :). The nginx works well for static contents and as the the django and tomcat installations reverse proxy. Here come problems with zope+plone. If i hit my http://url/plone (nginx mapped point to the plone install as http reverse proxy), the first request (get /) pass, but the other stall as 206 partial content and are very long to be satisfied. The browser seems to be blocked on some read() call. I tried a bunch of things nginx side (use epoll, use select, tweak proxy parameters, stop proxy buffering, set timeouts, set retrys and so on) but i have not found the right configuration if it is there. But where it is very strange is that if i make an ssh tunnel from localhost:80 to prod_machine:localhost:80, then make some entry into my /etc/hosts to fake the dns name. Then browse to http://myurl/plone, no problem, i have the content, and all http request are satisfied (js co.). I really don't know how to debug that, can it be because the request enter from cygwin, go out to windows re enter cygwin and go for the client? The fact that throught the ssh tunnel, when i hit the nginx server on my plone install (like as normal, i dont hit plone but nginx) work perfectly lives me without words. Other strange thing is that the CAS application, also http reverse proxified work like a charm. Other thing is that if i use the windows nginx binary from nginx website, with equal configuration, it works. The only thing is nginx running out of cygwin stack and compiled for win32. If someone has some suggestions -- Cordialement, KiOrKY GPG Key FingerPrint: 0x1A1194B7681112AF signature.asc Description: OpenPGP digital signature
RE: Why require ps -W and kill -f
People don't care about implementation details. They care about what is running on the system (the WHOLE system). They want kill and ps to show what's running on the system, not what cygwin thinks is running. Since exec() creates a new process on windows, that's more relevant for these tools. You have to admit, ps -ef showing only a few processes out of a houndred is a serious handicap for these tools and any scripts trying to maintain compatibility across windows and unix/linux. Also, the man page for -e (on unix/linux) says that -e means every process on the system. It will be more useful to show all windows processes, or if you want to be smart about it, all windows processes minus all the ones cygwin knows are the result of exec(). However, I think the exec() distinction doesn't really matter (certainly not to most people), since, how often will you really see it and how often will it really matter? I don't see what's the big deal to allow ps and kill to see all windows processes by default. How about let the user control how this works without having to change scripts or typing habits? Can you add a new option via the CYGWIN environment variable, something like [no]allprocs which kill and ps can look at instead of -f and -W options (although you can keep those for compatibility with existing cygwin releases)? Of course, I think the default behavior should be allprocs, since I believe almost all users will prefer this behavior. -Don -Original Message- From: Andy Koppe [mailto:andy.ko...@gmail.com] Sent: Thursday, January 21, 2010 9:02 PM To: d...@beusee.com; cygwin@cygwin.com Subject: Re: Why require ps -W and kill -f 2010/1/22 Don Beusee: ps -e on Unix displays �every process running on the system�.� This command doesn't do that under cygwin.� Why should it be necessary to supply -W to see all processes running on the system? Because those processes are not Cygwin/Unix processes. In particular, they do not have Cygwin process IDs. Cygwin PIDs and Windows PIDs are different concepts (even though they often coincide), and that's because multiple windows processes can be needed to emulate one Cygwin process. For example, when calling exec(), the new program is conceptually executed in the same Cygwin process, but actually a new Windows process has to be created since Windows doesn't allow a process to change executable. Andy -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Missing xdvi
On 01/22/2010 04:22 PM, Xianwen Chen wrote: Hello friends, I've installed all tetex-* packages, howver, I can't find xdvi. Should I compile it from source myself? Thank you in advance for any hint! Cygwin X questions are best asked on the Cygwin X list. However: http://cygwin.com/cgi-bin2/package-grep.cgi?grep=xdvi -- 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: Missing xdvi
On 2010-01-22, Xianwen Chen wrote: Hello friends, I've installed all tetex-* packages, howver, I can't find xdvi. Should I compile it from source myself? Thank you in advance for any hint! Searching the Cygwin Package List (http://cygwin.com/packages/) for xdvi results in a number of hits including tetex-x11/tetex-x11-3.0.0-3 The TeX text formatting system (X11 binaries). which contains Thu May 5 14:46:09 2005 1697 usr/X11R6/bin/xdvi HTH, Gary -- 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: subversion-1.6.9-1
A new subversion package is available for the new upstream 1.6.9 release. (Versions 1.6.7 and 1.6.8 were never publicly released.) CYGWIN NEWS: There was one test failure. * All tests hang using the serf HTTP library. This package still includes support for serf, but if you encounter problems, please switch to the neon library. NEWS: = See CHANGES (URL below) for more information about the differences between 1.6.9 and previous Subversion releases. IMPORTANT: This release will silently upgrade your Subversion working copies to the 1.6 format, rendering them unusable with previous major versions of Subversion. Please see the release notes http://subversion.tigris.org/svn_1.6_releasenotes.html for more details about the changes in Subversion. See http://svn.collab.net/viewvc/svn/tags/1.6.9/CHANGES for more details about the changes in 1.6.9. DESCRIPTION: Subversion is a version control system designed to be a compelling successor to CVS. Please see http://svnbook.red-bean.com/en/1.5/index.html for the latest official release of the Subversion Book, covering 1.5 or http://svnbook.red-bean.com/en/nightly/index.html for the WIP version of the book covering 1.6. DOWNLOAD: = Note that downloads from sourceware.org (aka cygwin.com) aren't allowed due to bandwidth limitations. This means that you will need to find a mirror which has this update, please choose the one nearest to you: http://cygwin.com/mirrors.html QUESTIONS: == If you want to make a point or ask a question the Cygwin mailing list is the appropriate place. CYGWIN-ANNOUNCE UNSUBSCRIBE INFO: = To unsubscribe to the cygwin-announce mailing list, look at the List-Unsubscribe: tag in the email header of this message. Send email to the address specified there. It will be in the format: cygwin-announce-unsubscribe-you=yourdomain@cygwin.com If you need more information on unsubscribing, start reading here: http://sourceware.org/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. -- David Rothenberger daver...@acm.org -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
R: Missing xdvi
--- Ven 22/1/10, Xianwen Chen ha scritto: Hello friends, I've installed all tetex-* packages, howver, I can't find xdvi. Should I compile it from source myself? Thank you in advance for any hint! Wen /usr/X11R6/bin/xdvi /usr/X11R6/bin/ is likely not anymore in the PATH Marco -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: 1.7: Problem with Novell volumes
On Jan 22 07:53, Sean Stidman wrote: Hello, I recently upgraded to Cygwin 1.7. Since the upgrade, I started having issues with accessing Novell volumes. Should be fixed in CVS. Try the latest developer snapshot at http://cygwin.com/snapshots/ 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: Design issue with new MS-DOS style path warning?
On 1/22/2010 10:23 AM, Eric Vautier wrote: AndroidApp BUILD FAILED C:\dev\prj\app4\AndroidApp\build.xml:343: Warning: Could not find file C:\cygdrive\c\dev\prj\app4\Common\target\Common.jar to copy. My first thought when I see things like this isn't oh, bad idea, DOS style paths in Cygwin. I think oh, bad idea, absolute paths hard-coded into a build system. That makes it hard to build on any other system, because it ranges from difficult to impossible to demand that everyone install outside dependencies in the same locations. There must be a tool you can use to generate the Ant files from something higher-level, which discovers the correct paths to use. That tool could also abstract away the difference in path styles. Something like Automake, Bakefile or CMake, but which knows how to create Ant files. That's where I'd put my effort, anyway. -- 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: Why require ps -W and kill -f
On 01/22/2010 04:28 PM, Don Beusee wrote: People don't care about implementation details. They care about what is running on the system (the WHOLE system). They want kill and ps to show what's running on the system, not what cygwin thinks is running. Since exec() creates a new process on windows, that's more relevant for these tools. You have to admit, ps -ef showing only a few processes out of a houndred is a serious handicap for these tools and any scripts trying to maintain compatibility across windows and unix/linux. Also, the man page for -e (on unix/linux) says that -e means every process on the system. It will be more useful to show all windows processes, or if you want to be smart about it, all windows processes minus all the ones cygwin knows are the result of exec(). However, I think the exec() distinction doesn't really matter (certainly not to most people), since, how often will you really see it and how often will it really matter? I don't see what's the big deal to allow ps and kill to see all windows processes by default. How about let the user control how this works without having to change scripts or typing habits? Can you add a new option via the CYGWIN environment variable, something like [no]allprocs which kill and ps can look at instead of -f and -W options (although you can keep those for compatibility with existing cygwin releases)? Of course, I think the default behavior should be allprocs, since I believe almost all users will prefer this behavior. You've been given allot of good reasons for why Cygwin's 'ps' works as it does. While there may be some minimal benefit to users to not have to type the extra flag to get Windows processes listed, if that's what they want, adding a system-wide flag to the CYGWIN environment variable is a 10 ton sledge hammer for the pin you're trying to drive home. I don't see the point to arguing for this change to Cygwin if you're not going to get consistency everywhere though. Perhaps you should consider that aspect and redirect your efforts upstream if you feel this issue warrants more discussion (and hasn't already been hashed and rehashed there). In any case, as others have pointed out already, in the meantime, you're stuck with the current options - either alias or script your way out of this problem or create a patched version for yourself. -- 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: Why require ps -W and kill -f
--- Ven 22/1/10, Don Beusee ha scritto: People don't care about implementation details. They care about what is running on the system (the WHOLE system). They want kill and ps to show what's running on the system, not what cygwin thinks is running. then you are in the wrong place try here http://technet.microsoft.com/en-us/sysinternals/bb795533.aspx pslist and pskill are for any windows program -Don Marco -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Why require ps -W and kill -f
Larry Hall (Cygwin) wrote: adding a system-wide flag to the CYGWIN environment variable is a 10 ton sledge hammer for the pin you're trying to drive home. Yep. Especially as adding this: alias ps='ps -W' to ~/.bashrc will DTRT. -- Chuck -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Why require ps -W and kill -f
On Fri, Jan 22, 2010 at 01:28:05PM -0800, Don Beusee wrote: People don't care about implementation details. They care about what is running on the system (the WHOLE system). They want kill and ps to show what's running on the system, not what cygwin thinks is running. Since exec() creates a new process on windows, that's more relevant for these tools. You're missing the point. kill DOESN'T WORK with windows process unless you want to summarily terminate a process. The built-in kill in the shells that are in the distribution won't work with pure Windows process at all. How about let the user control how this works without having to change scripts or typing habits? Can you add a new option via the CYGWIN environment variable, something like [no]allprocs which kill and ps can look at instead of -f and -W options (although you can keep those for compatibility with existing cygwin releases)? Of course, I think the default behavior should be allprocs, since I believe almost all users will prefer this behavior. Sorry but it doesn't work this way. You don't go to a mailing list, argue for a feature and then, when people disagree and try to explain, suggest that those people should implement something for you. It's a free software project. If you think this is a good idea then show us the code. If you don't have the skills to make the necessary modifications then you'll just have to live with the current implementation because, I can assure you, that I don't agree with your point of view and I, as the author of most of the process code, will not be making any changes to it to accommodate your wishes. 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: missing setup command line arguments in the FAQ.
I found this message in my hosted Gmail (Google Apps) account’s Spam folder. I wonder why Gmail thought it was spam? Because it contained the URL of a(n) (Windows) executable file? Dave Korn wrote: G.W. Haywood wrote: BTW, if you run setup.exe --help, it will (depending on OS version) either display the usage instructions to the screen, I assume you mean it will print the usage instructions to stdout or stderr, which are not necessarily connected to a terminal? or dump them to a setup.log file in the directory where you run it. That's not correct (*): laptop:~$ ./setup.exe -bash: ./setup.exe: cannot execute binary file Well strictly it is, since I said what would happen if you ran it, and not what would happen if you _didn't_ run it (for whatever reason that might happen to be)! Because G.W. Haywood is not running it on Windows (nor ReactOS) nor with Wine? Yes, one could just *try it*, if he had a Windows machine on which to try it. Not all Cygwin users are male. Please use “he or she” or, if you agree with singular usage of traditionally plural pronouns, “they” instead of “he”. *koff* Don’t you mean *COFF* (as opposed to ELF)? ;) Prepare to be shocked, amazed, awed and astounded! [da...@ubique ~]$ uname -a bash? Shouldn’t you use *ksh? ;) Linux ubique.localdomain 2.6.27.21-170.2.56.fc10.i686 #1 SMP Mon Mar 23 23:37:54 EDT 2009 i686 athlon i386 GNU/Linux [da...@ubique ~]$ wget http://cygwin.com/setup.exe --2010-01-18 13:20:58-- http://cygwin.com/setup.exe Resolving cygwin.com... 209.132.180.131 Connecting to cygwin.com|209.132.180.131|:80... connected. HTTP request sent, awaiting response... 200 OK Length: 624128 (610K) [application/octet-stream] Is that a (bit)stream of eighth notes in the key of C? ;) Saving to: `setup.exe' 100%[] 624,128 28.6K/s in 16s 2010-01-18 13:21:15 (37.3 KB/s) - `setup.exe' saved [624128/624128] [da...@ubique ~]$ chmod a+x setup.exe [da...@ubique ~]$ wine ./setup.exe --help Are you using Wine with the builtin xor native libraries? Note: the xor operator is to prevent a “Yes” answer since this question requires a string, not a boolean, as an answer. :) fixme:msvcrt:MSVCRT_setlocale :Codepage only locale not implemented Starting cygwin install, version 2.677 io_stream_cygfile: fopen(/etc/setup/setup.rc) 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/last-action) failed 2 No such file or directory io_stream_cygfile: fopen(/etc/setup/net-method) failed 2 No such file or directory io_stream_cygfile: fopen(/etc/setup/net-proxy-host) failed 2 No such file or directory io_stream_cygfile: fopen(/etc/setup/net-proxy-port) failed 2 No such file or directory io_stream_cygfile: fopen(/etc/setup/last-mirror) failed 2 No such file or directory io_stream_cygfile: fopen(/etc/setup/extrakeys) failed 2 No such file or directory io_stream_cygfile: fopen(/etc/setup/chooser_window_settings) failed 2 No such file or directory Current Directory: Z:\home\davek Command Line Options: snip Ending cygwin install AddAccessAllowedAce(, owner) failed: 1337 AddAccessAllowedAce(, group) failed: 1337 AddAccessAllowedAce(, everyone) failed: 1337 AddAccessAllowedAce(, owner) failed: 1337 AddAccessAllowedAce(, group) failed: 1337 AddAccessAllowedAce(, everyone) failed: 1337 Does this mean you are too 1337 to be allowed access? ;) [da...@ubique ~]$ :-) cheers, DaveK Did you know old Apple keyboards, such as the Apple Extended Keyboard II from 1989, have the bumps on D and K instead of F and J? :) I used to have one of those keyboards in my 68k Mac collection. I wish I had kept the keyboard because it would be cool if I could use it on a PC with an ADB→USB converter. I liked that keyboard’s feel: it had mechanical key switches instead of rubber membrane/dome switches. The Caps Lock key stayed down when Caps Lock was on, like Shift Lock on a typewriter (and a C64?). I forgot if it had the Lock LEDs on the keys themselves or in a group elsewhere on the keyboard. -- Sometimes I forget how to do small talk: http://xkcd.com/222/ “If you have to ask why, you’re not a member of the intended audience.” — Bob Zimbinski, http://webpages.mr.net/bobz/ttyquake/ -- 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: Why require ps -W and kill -f
I am a unix user that has moved to windows. I want unix commands on windows that function like their unix counterparts. That is supposed to be one of cygwin's missions, is it not? Isn't that one of the main reasons people get cygwin? What's the point of providing these commands otherwise? Why the apparent objection to offering the options to the CYGWIN (or some other) environment variable where users can control the behavior of these commands globally on their system? If you won't change the default behavior because of your religious beliefs, fine, but can you at least allow us to change the default behavior on our systems that does not involve changing scripts or typing habits? Please? -Don -Original Message- From: Marco Atzeri [mailto:marco_atz...@yahoo.it] Sent: Friday, January 22, 2010 2:03 PM To: cygwin@cygwin.com; d...@beusee.com Subject: RE: Why require ps -W and kill -f --- Ven 22/1/10, Don Beusee ha scritto: People don't care about implementation details. They care about what is running on the system (the WHOLE system). They want kill and ps to show what's running on the system, not what cygwin thinks is running. then you are in the wrong place try here http://technet.microsoft.com/en-us/sysinternals/bb795533.aspx pslist and pskill are for any windows program -Don Marco -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Why require ps -W and kill -f
On 22/01/2010 21:28, Don Beusee wrote: People don't care about implementation details. They care about what is running on the system (the WHOLE system). You are speaking for yourself. Not everyone in the world. Try not to forget that. 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: Design issue with new MS-DOS style path warning?
Just to clear things up, none of the paths are hard-coded. They are all obtained from environment variables or paths relative to project root. Only in the output from ant do they look absolute (the build has to figure out an absolute path sooner or later...). Again, the build script works perfectly fine, as long as it's not called from within a shell script. ant clean get-common debug works fine from the command line, but the same line fails with the error mentioned when run from INSIDE a shell script. And it's starting to look like an old Ant/Cygwin interaction issue, slightly off-topic with regards to the original discussion. http://www.eyt.ca/blog/item/136/ (dated) http://ant.apache.org/manual/platform.html (mid-page: Cygwin is trouble!) Seems this issue crops up again every now and then when cygwin or ant comes out with an update. -e On Fri, Jan 22, 2010 at 10:53 PM, Warren Young war...@etr-usa.com wrote: On 1/22/2010 10:23 AM, Eric Vautier wrote: AndroidApp BUILD FAILED C:\dev\prj\app4\AndroidApp\build.xml:343: Warning: Could not find file C:\cygdrive\c\dev\prj\app4\Common\target\Common.jar to copy. My first thought when I see things like this isn't oh, bad idea, DOS style paths in Cygwin. I think oh, bad idea, absolute paths hard-coded into a build system. That makes it hard to build on any other system, because it ranges from difficult to impossible to demand that everyone install outside dependencies in the same locations. There must be a tool you can use to generate the Ant files from something higher-level, which discovers the correct paths to use. That tool could also abstract away the difference in path styles. Something like Automake, Bakefile or CMake, but which knows how to create Ant files. That's where I'd put my effort, anyway. -- 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: Design issue with new MS-DOS style path warning?
Tried bash, -x, bash build.sh, bash -x build.sh, forward
slashes in Windows environment variables, to no avail. But thank you
for your time and patience, Dave!
-e
On Fri, Jan 22, 2010 at 7:25 PM, Dave Korn
dave.korn.cyg...@googlemail.com wrote:
On 22/01/2010 17:55, Eric Vautier wrote:
Yes, it's a slightly complicated build script, but it does the job
properly when invoked manually. It only fails if it is invoked from
inside a wrapping shell script.
That shell script presumably does some stuff first before invoking it; maybe
that's where the problem originates. Also, you're running it from sh in
that situation, instead of bash as you do from the command-line; that might
be relevant or might not. (sh is an alias for bash that invokes it with
slightly-altered behaviour.)
To sum up: all 5 builds (three maven, two ant) work fine when invoked
manually from the command-line. The two ant builds fail in the overall
build invocator (build.sh, but I should probably call it
build-all.sh), whose sole task is to launch the 5 builds from inside
their own directories; the three maven builds are fine.
I see no reason why calling that ant build from inside a shell script
should mess up the paths with C:\cygdrive\c\dev\ prefixes. build.sh
does have #!/bin/sh at the top. Will investigate a little more.
Adding -x flag to the shebang might help.
property name=common location=${env.APP4_COMMON_ROOT} /
property name=common-jar value=${common}/target/Common.jar /
APP4_COMMON_ROOT = C:\dev\prj\app4\Common
Try not using mixed slashes. Both Cygwin and DOS should be fairly happy with
APP4_COMMON_ROOT = C:/dev/prj/app4/Common
--
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
X11 + remote desktop + clipboard = hang
Hi all, I noticed today that trying to cut and paste between an xterm and a remote desktop session causes the remote desktop to hang with a CPU pegged. I have vague memories of this sort of thing happening before (but with a VNC client causing the problem instead of rdtsc.exe). The fix then was to install Jon Turney's hacked version of xwin.exe [1], but that binary targeted v1.5 and I'm running v1.7 now... Thoughts? Ryan [1] http://www.cygwin.com/ml/cygwin-xfree/2009-02/msg00276.html -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem with Installation: No option to select DOS lines endings, defaults to UNIX.
I am having a problem with an installation of Cygwin. When I run setup.exe, I do not get an option for choosing line endings. So, I want to select DOS ine endings but that option is never available during setup, so it ends up being UNIX line endings. How do I force that option during installation? Please help. -- 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: Why require ps -W and kill -f
On 1/22/2010 4:15 PM, Don Beusee wrote: I am a unix user that has moved to windows. I want unix commands on windows that function like their unix counterparts. That is supposed to be one of cygwin's missions, is it not? Sorry, but you're not exactly on the side of the angels when you argue that ps should work like on Unix. ps is one of the few programs that still works quite differently on every *ix. You can say you want it to work like the ps some particular *ix, but then you have to explain how you want it to work around the problems that cause it to work the way it does now. (One being, Windows PIDs are not Cygwin PIDs.) A raw demand to make it work the way I think it should work isn't going to get you very far. It works the way it does for a reason, and if you want it to work another way, you have to propose a way to get from here to there. -- 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: missing setup command line arguments in the FAQ.
On Fri, Jan 22, 2010 at 03:07:10PM -0800, Brolin Empey wrote: [deleted] Please. There was little in this message that was on-topic for the cygwin mailing list. Please use the cygwin-talk mailing list if you really want to pursue this further. -- 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
Please support CP932. (I have problem using subversion with SJIS)
Hi all, Please support CP932. Because CP932 is not equal to SJIS, I have problem using subversion when LANG=ja_JP.SJIS . With the attached patch and LANG=ja_JP.CP932, I can use subversion as expected. The problem is as follows: I have the following line in my ~/.subversion/config: global-ignores = *~ When LANG=ja_JP.UTF-8, subversion ignores a file 'foo~'. But when LANG=ja_JP.SJIS, it doesn't. I looked into subverson, then I found a workaround. I added *[U+203E] to the line: global-ignores = *~ *[U+203E] ([U+203E] is one character) and saved it in UTF-8. This works fine. In short, '~' (U+007E TILDE) turns into U+203E (OVERLINE) when LANG=ja_JP.SJIS. Then I looked into cygwin and subversion again. (1) cygwin1.dll converts Lfoo~ (UCS-2) to foo~ (CP932). (2) Because subversion's internally uses UTF-8, foo~ (CP932) should be converted to foo~ (UTF-8). (3) It uses iconv to convert from *SJIS* to UTF-8, because nl_langinfo(CODESET) returns SJIS when LANG=ja_JP.SJIS. (4) The final string is foo\xe2\x80\xbe. (e2 80 be is UTF-8 representation of U+203E) With my patch I can use LANG=ja_JP.CP932, nl_langinfo(CODESET) returns CP932. So the final string is foo~. supplement: $ echo -n foo~ | iconv -f CP932 -t UTF-8 | od -t x1 -t a 00066 6f 6f 7e f o o ~ 004 $ echo -n foo~ | iconv -f SJIS -t UTF-8 | od -t x1 -t a 00066 6f 6f e2 80 be f o o ? 80 ? 006 -- TAGA Nayuta ganaw...@gmail.com -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Please support CP932. (I have problem using subversion with SJIS)
Pardon me. I forgot to attach my patch. 2010/1/23 Nayuta Taga ganaw...@gmail.com: Please support CP932. Because CP932 is not equal to SJIS, I have problem using subversion when LANG=ja_JP.SJIS . With the attached patch and LANG=ja_JP.CP932, I can use subversion as expected. Index: newlib/libc/locale/locale.c === RCS file: /cvs/src/src/newlib/libc/locale/locale.c,v retrieving revision 1.33 diff -u -p -r1.33 locale.c --- newlib/libc/locale/locale.c 22 Jan 2010 13:03:42 - 1.33 +++ newlib/libc/locale/locale.c 23 Jan 2010 03:59:48 - @@ -659,6 +659,13 @@ loadlocale(struct _reent *p, int categor #endif /* _MB_EXTENDED_CHARSETS_WINDOWS */ #endif break; + case 932: + mbc_max = 2; +#ifdef _MB_CAPABLE + l_wctomb = __sjis_wctomb; + l_mbtowc = __sjis_mbtowc; +#endif + break; default: return NULL; } -- 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
bash script error
Hi, I am trying to run a script in cygwin,and keep getting this error.Both of these files exist (bash.exe) and user has 777 permissions. $ bin/run.sh : /bin/bash: /usr/local/x-daemon.sh: No such file or directory Any help appreciated. Brian -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Updated: subversion-1.6.9-1
A new subversion package is available for the new upstream 1.6.9 release. (Versions 1.6.7 and 1.6.8 were never publicly released.) CYGWIN NEWS: There was one test failure. * All tests hang using the serf HTTP library. This package still includes support for serf, but if you encounter problems, please switch to the neon library. NEWS: = See CHANGES (URL below) for more information about the differences between 1.6.9 and previous Subversion releases. IMPORTANT: This release will silently upgrade your Subversion working copies to the 1.6 format, rendering them unusable with previous major versions of Subversion. Please see the release notes http://subversion.tigris.org/svn_1.6_releasenotes.html for more details about the changes in Subversion. See http://svn.collab.net/viewvc/svn/tags/1.6.9/CHANGES for more details about the changes in 1.6.9. DESCRIPTION: Subversion is a version control system designed to be a compelling successor to CVS. Please see http://svnbook.red-bean.com/en/1.5/index.html for the latest official release of the Subversion Book, covering 1.5 or http://svnbook.red-bean.com/en/nightly/index.html for the WIP version of the book covering 1.6. DOWNLOAD: = Note that downloads from sourceware.org (aka cygwin.com) aren't allowed due to bandwidth limitations. This means that you will need to find a mirror which has this update, please choose the one nearest to you: http://cygwin.com/mirrors.html QUESTIONS: == If you want to make a point or ask a question the Cygwin mailing list is the appropriate place. CYGWIN-ANNOUNCE UNSUBSCRIBE INFO: = To unsubscribe to the cygwin-announce mailing list, look at the List-Unsubscribe: tag in the email header of this message. Send email to the address specified there. It will be in the format: cygwin-announce-unsubscribe-you=yourdomain@cygwin.com If you need more information on unsubscribing, start reading here: http://sourceware.org/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. -- David Rothenberger daver...@acm.org
