Re: [ITA][1.7] GraphicsMagick-1.3.5-2
Marco Atzeri wrote: Should they stay in libGraphicsMagick3 or in libGraphicsMagick-devel ? To avoid having all GM users pull in a dependency on perl, I'd put these files into a new package, GraphicsMagick-perl (or perl-GraphicsMagick? nah...) -- Chuck
Re: [ITA][1.7] GraphicsMagick-1.3.5-2
--- Dom 22/3/09, Charles Wilson ha scritto: Da: Charles Wilson Oggetto: Re: [ITA][1.7] GraphicsMagick-1.3.5-2 A: CygWin-Apps Data: Domenica 22 marzo 2009, 07:46 Marco Atzeri wrote: Should they stay in libGraphicsMagick3 or in libGraphicsMagick-devel ? To avoid having all GM users pull in a dependency on perl, I'd put these files into a new package, GraphicsMagick-perl (or perl-GraphicsMagick? nah...) -- Chuck like this ? Creating binary package(s) GraphicsMagick-1.3.5-3.tar.bz2 usr/bin/gm.exe usr/share/doc/ usr/share/doc/Cygwin/ usr/share/doc/Cygwin/GraphicsMagick.README usr/share/doc/GraphicsMagick/ usr/share/doc/GraphicsMagick/ChangeLog usr/share/doc/GraphicsMagick/ChangeLog.2001 usr/share/doc/GraphicsMagick/ChangeLog.2002 usr/share/doc/GraphicsMagick/ChangeLog.2003 usr/share/doc/GraphicsMagick/ChangeLog.2004 usr/share/doc/GraphicsMagick/ChangeLog.2005 usr/share/doc/GraphicsMagick/ChangeLog.2006 usr/share/doc/GraphicsMagick/ChangeLog.2007 usr/share/doc/GraphicsMagick/Copyright.txt usr/share/doc/GraphicsMagick/NEWS.txt usr/share/doc/GraphicsMagick/TODO.txt usr/share/doc/GraphicsMagick/www/ usr/share/doc/GraphicsMagick/www/animate.html usr/share/doc/GraphicsMagick/www/api/ usr/share/doc/GraphicsMagick/www/api/animate.html usr/share/doc/GraphicsMagick/www/api/annotate.html usr/share/doc/GraphicsMagick/www/api/api.html usr/share/doc/GraphicsMagick/www/api/api.rst usr/share/doc/GraphicsMagick/www/api/api_hyperlinks.rst usr/share/doc/GraphicsMagick/www/api/attribute.html usr/share/doc/GraphicsMagick/www/api/blob.html usr/share/doc/GraphicsMagick/www/api/channel.html usr/share/doc/GraphicsMagick/www/api/color.html usr/share/doc/GraphicsMagick/www/api/compare.html usr/share/doc/GraphicsMagick/www/api/composite.html usr/share/doc/GraphicsMagick/www/api/constitute.html usr/share/doc/GraphicsMagick/www/api/decorate.html usr/share/doc/GraphicsMagick/www/api/deprecate.html usr/share/doc/GraphicsMagick/www/api/display.html usr/share/doc/GraphicsMagick/www/api/draw.html usr/share/doc/GraphicsMagick/www/api/effect.html usr/share/doc/GraphicsMagick/www/api/enhance.html usr/share/doc/GraphicsMagick/www/api/error.html usr/share/doc/GraphicsMagick/www/api/fx.html usr/share/doc/GraphicsMagick/www/api/image.html usr/share/doc/GraphicsMagick/www/api/list.html usr/share/doc/GraphicsMagick/www/api/magick.html usr/share/doc/GraphicsMagick/www/api/Makefile.am usr/share/doc/GraphicsMagick/www/api/memory.html usr/share/doc/GraphicsMagick/www/api/monitor.html usr/share/doc/GraphicsMagick/www/api/montage.html usr/share/doc/GraphicsMagick/www/api/operator.html usr/share/doc/GraphicsMagick/www/api/paint.html usr/share/doc/GraphicsMagick/www/api/pixel_cache.html usr/share/doc/GraphicsMagick/www/api/pixel_iterator.html usr/share/doc/GraphicsMagick/www/api/profile.html usr/share/doc/GraphicsMagick/www/api/quantize.html usr/share/doc/GraphicsMagick/www/api/registry.html usr/share/doc/GraphicsMagick/www/api/render.html usr/share/doc/GraphicsMagick/www/api/resize.html usr/share/doc/GraphicsMagick/www/api/resource.html usr/share/doc/GraphicsMagick/www/api/segment.html usr/share/doc/GraphicsMagick/www/api/shear.html usr/share/doc/GraphicsMagick/www/api/signature.html usr/share/doc/GraphicsMagick/www/api/transform.html usr/share/doc/GraphicsMagick/www/api/types.html usr/share/doc/GraphicsMagick/www/api/types.rst usr/share/doc/GraphicsMagick/www/api/widget.html usr/share/doc/GraphicsMagick/www/authors.html usr/share/doc/GraphicsMagick/www/authors.rst usr/share/doc/GraphicsMagick/www/benchmarks-1.2.html usr/share/doc/GraphicsMagick/www/benchmarks-1.2.rst usr/share/doc/GraphicsMagick/www/benchmarks.html usr/share/doc/GraphicsMagick/www/benchmarks.rst usr/share/doc/GraphicsMagick/www/bugs.html usr/share/doc/GraphicsMagick/www/bugs.rst usr/share/doc/GraphicsMagick/www/Changelog.html usr/share/doc/GraphicsMagick/www/color.html usr/share/doc/GraphicsMagick/www/compare.html usr/share/doc/GraphicsMagick/www/composite.html usr/share/doc/GraphicsMagick/www/conjure.html usr/share/doc/GraphicsMagick/www/contribute.html usr/share/doc/GraphicsMagick/www/contribute.rst usr/share/doc/GraphicsMagick/www/convert.html usr/share/doc/GraphicsMagick/www/Copyright.html usr/share/doc/GraphicsMagick/www/CVS.html usr/share/doc/GraphicsMagick/www/CVS.rst usr/share/doc/GraphicsMagick/www/display.html usr/share/doc/GraphicsMagick/www/docutils-api.css usr/share/doc/GraphicsMagick/www/docutils-articles.css usr/share/doc/GraphicsMagick/www/download.html usr/share/doc/GraphicsMagick/www/download.rst usr/share/doc/GraphicsMagick/www/FAQ.html usr/share/doc/GraphicsMagick/www/FAQ.rst usr/share/doc/GraphicsMagick/www/formats.html usr/share/doc/GraphicsMagick/www/formats.rst usr/share/doc/GraphicsMagick/www/gm.html usr/share/doc/GraphicsMagick/www/GraphicsMagick.html usr/share/doc/GraphicsMagick/www/identify.html usr/share/doc/GraphicsMagick/www/ImageMagickObject.html usr/share/doc/GraphicsMagick/www/ImageMagickObject.rst
Re: [ITA][1.7] GraphicsMagick-1.3.5-2
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Charles Wilson wrote: To avoid having all GM users pull in a dependency on perl, I'd put these files into a new package, GraphicsMagick-perl (or perl-GraphicsMagick? nah...) I've been using perl-Graphics-Magick in Ports. Yaakov -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEAREIAAYFAknGB5EACgkQpiWmPGlmQSMt2ACgrBpmFzlU3i2LcPW03vL0WVR5 ImMAnR6le9M7xO10YcRGrTE+wKGj12e/ =lhze -END PGP SIGNATURE-
Re: [ITA][1.7] GraphicsMagick-1.3.5-2
--- Dom 22/3/09, Yaakov (Cygwin/X) yselkow...@users.sourceforge.net ha scritto: Da: Yaakov (Cygwin/X) yselkow...@users.sourceforge.net Oggetto: Re: [ITA][1.7] GraphicsMagick-1.3.5-2 A: cygwin-apps@cygwin.com Data: Domenica 22 marzo 2009, 10:40 -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Charles Wilson wrote: To avoid having all GM users pull in a dependency on perl, I'd put these files into a new package, GraphicsMagick-perl (or perl-GraphicsMagick? nah...) I've been using perl-Graphics-Magick in Ports. Yaakov Hi Yaakov, re-uploaded to download wget -r -np http://matzeri.altervista.org/cygwin-1.7/GraphicsMagick/ ./GraphicsMagick-1.3.5-2-src.tar.bz2 ./GraphicsMagick-1.3.5-2.tar.bz2 ./index.html ./libGraphicsMagick-devel ./libGraphicsMagick-devel/index.html ./libGraphicsMagick-devel/libGraphicsMagick-devel-1.3.5-2.tar.bz2 ./libGraphicsMagick-devel/setup.hint ./libGraphicsMagick3 ./libGraphicsMagick3/index.html ./libGraphicsMagick3/libGraphicsMagick3-1.3.5-2.tar.bz2 ./libGraphicsMagick3/setup.hint ./perl-Graphics-Magick ./perl-Graphics-Magick/index.html ./perl-Graphics-Magick/perl-Graphics-Magick-1.3.5-2.tar.bz2 ./perl-Graphics-Magick/setup.hint ./setup.hint Regards Marco
Re: [ITA][1.7] GraphicsMagick-1.3.5-2
Marco Atzeri wrote: GraphicsMagick-perl-1.3.5-3.tar.bz2 usr/lib/perl5/ usr/lib/perl5/5.10/ usr/lib/perl5/5.10/i686-cygwin/ usr/lib/perl5/5.10/i686-cygwin/perllocal.pod usr/lib/perl5/site_perl/ usr/lib/perl5/site_perl/5.10/ usr/lib/perl5/site_perl/5.10/i686-cygwin/ usr/lib/perl5/site_perl/5.10/i686-cygwin/auto/ usr/lib/perl5/site_perl/5.10/i686-cygwin/auto/Graphics/ usr/lib/perl5/site_perl/5.10/i686-cygwin/auto/Graphics/Magick/ usr/lib/perl5/site_perl/5.10/i686-cygwin/auto/Graphics/Magick/.packlist usr/lib/perl5/site_perl/5.10/i686-cygwin/auto/Graphics/Magick/autosplit.ix usr/lib/perl5/site_perl/5.10/i686-cygwin/auto/Graphics/Magick/Magick.dll usr/lib/perl5/site_perl/5.10/i686-cygwin/Graphics/ usr/lib/perl5/site_perl/5.10/i686-cygwin/Graphics/Magick.pm Almost. You can't install perllocal.pod because it will clobber the existing one -- and .packlist is probably wrong. Take a look at /usr/share/cygport/perl.class (perl_postinst) to see how you should manage perllocal.pod and .packlist. I'm not sure if you can just 'inherit perl' in your cygport file -- Yaakov will have better advice. -- Chuck
Re: [ITA][1.7] GraphicsMagick-1.3.5-2
--- Dom 22/3/09, Charles Wilson ha scritto: Da: Charles Wilson Oggetto: Re: [ITA][1.7] GraphicsMagick-1.3.5-2 A: Marco Atzeri Cc: CygWin-Apps Data: Domenica 22 marzo 2009, 15:05 Marco Atzeri wrote: GraphicsMagick-perl-1.3.5-3.tar.bz2 usr/lib/perl5/ usr/lib/perl5/5.10/ usr/lib/perl5/5.10/i686-cygwin/ usr/lib/perl5/5.10/i686-cygwin/perllocal.pod usr/lib/perl5/site_perl/ usr/lib/perl5/site_perl/5.10/ usr/lib/perl5/site_perl/5.10/i686-cygwin/ usr/lib/perl5/site_perl/5.10/i686-cygwin/auto/ usr/lib/perl5/site_perl/5.10/i686-cygwin/auto/Graphics/ usr/lib/perl5/site_perl/5.10/i686-cygwin/auto/Graphics/Magick/ usr/lib/perl5/site_perl/5.10/i686-cygwin/auto/Graphics/Magick/.packlist usr/lib/perl5/site_perl/5.10/i686-cygwin/auto/Graphics/Magick/autosplit.ix usr/lib/perl5/site_perl/5.10/i686-cygwin/auto/Graphics/Magick/Magick.dll usr/lib/perl5/site_perl/5.10/i686-cygwin/Graphics/ usr/lib/perl5/site_perl/5.10/i686-cygwin/Graphics/Magick.pm Almost. You can't install perllocal.pod because it will clobber the existing one -- and .packlist is probably wrong. Take a look at /usr/share/cygport/perl.class (perl_postinst) to see how you should manage perllocal.pod and .packlist. I'm not sure if you can just 'inherit perl' in your cygport file -- Yaakov will have better advice. -- Chuck Hi Chuck I am checking cygwin ports to see Yaakov's way :-) I forget to see if GraphichMagick was already there. Regards Marco
Re: [ITA][1.7] GraphicsMagick-1.3.5-2
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Charles Wilson wrote: Almost. You can't install perllocal.pod because it will clobber the existing one -- and .packlist is probably wrong. Take a look at /usr/share/cygport/perl.class (perl_postinst) to see how you should manage perllocal.pod and .packlist. I'm not sure if you can just 'inherit perl' in your cygport file -- Yaakov will have better advice. You need to call perl_postinst in src_install to remove the perllocal.pod and fix the .packlist. Here are the files I've been using for Ports so far: http://cygwin-ports.svn.sourceforge.net/viewvc/cygwin-ports/ports/trunk/graphics/graphicsmagick/ Yaakov -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEAREIAAYFAknGgLYACgkQpiWmPGlmQSMN4wCeIzO3s5fJhRRKK3kbF6qDnYa7 Pw8AoOX0wRLuGIDF5NvD/zepQPR2zdNu =xySi -END PGP SIGNATURE-
src/winsup/utils ChangeLog ldd.cc passwd.c
CVSROOT:/cvs/src Module name:src Changes by: cori...@sourceware.org 2009-03-22 10:09:01 Modified files: winsup/utils : ChangeLog ldd.cc passwd.c Log message: * ldd.cc: Fix compiler warning. * passwd.c: Use mbstowcs instead of MultiByteToWideChar throughout. (main): Call setlocale. Fix a bug in fetching the logon server from the environment. Patches: http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/winsup/utils/ChangeLog.diff?cvsroot=srcr1=1.458r2=1.459 http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/winsup/utils/ldd.cc.diff?cvsroot=srcr1=1.4r2=1.5 http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/winsup/utils/passwd.c.diff?cvsroot=srcr1=1.15r2=1.16
src/winsup/utils ChangeLog passwd.c
CVSROOT:/cvs/src Module name:src Changes by: cori...@sourceware.org 2009-03-22 19:18:26 Modified files: winsup/utils : ChangeLog passwd.c Log message: * passwd.c (main): Always get logonserver from environment and use when fetching user info for caller. Patches: http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/winsup/utils/ChangeLog.diff?cvsroot=srcr1=1.459r2=1.460 http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/winsup/utils/passwd.c.diff?cvsroot=srcr1=1.16r2=1.17
Re: to developers: please post signature for setup-1.7.exe
On Mar 21 19:23, Vass Dude wrote: Thanks for the signature for setup.exe; please post one for 1.7 so I can try it out. You don't need the sig to use it. If you're just interested to know that it hasn't been tampered with, the SHA1 sum is SHA1(setup-1.7.exe)= 5f97ae3e2f32176ef8ecc8df3ca91a99966e5401 Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: [1.7] passwd: useless if used with a logged on domain user
On Mar 21 11:10, Corinna Vinschen wrote: On Mar 20 18:43, Julio Emanuel wrote: Hi, I've been tracing some problems related to the installation scripts of ssh (more info on another mail later), and the root cause for one of the problems is the passwd misbehaving. The test case is very simple. Log on with a domain user on a cygwin shell. My particular case, it's an local Administrator, but not Domain Admin (as 99% of users in a corporate network out there, I suppose). ~ $ id uid=18606(security) gid=10513(Domain Users) groups=0(root),544(Administrators),545(Users),10513(Domain Users) Now, just try to do pretty much anything with passwd: ~ $ passwd -v passwd (cygwin) 1.5 Password Utility Copyright 1999, 2000, 2001, 2002, 2003 Red Hat, Inc. Compiled on Mar 11 2009 ~ $ passwd passwd: unknown user security ~ $ passwd SYSTEM passwd: unknown user security ~ $ passwd Administrator passwd: unknown user security Am I missing something here? How can I make it work with local users, when I'm logged on with a Domain user? That doesn't look too well, but I can't reproduce the effect. I could today. The bug is fixed in CVS. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: chere doesn't work anymore with MinTTY
Andy Koppe wrote: Corinna Vinschen: I just think the -e option is along the lines of the -c option for shells. Every Unix shell has a -c option and it always means the same, even for csh and, FWIW, cmd.exe. Agreed, and implemented in 0.3.8. Thanks all for sorting this out (only just got back from holiday). I noticed the absence of -e in the options list, but assumed the list was wrong since there were no complaints about it. regards, Dave. chere maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
1.5.24-2: Interfere with Cygwin
Hi. I have found a new software which interfere with Cygwin. It is the Logitech SetPoint, at least a version 4.7.213. When I kill SetPoint's process the Cygwin work normally. I use Cygwin which is included to Altera Quartus II 9.0. -- С уважением, Владимир Ромашкин. E-mail: energ...@list.ru vladimir.romash...@gmail.com ICQ: 329-237-935 Cygwin Configuration Diagnostics Current System Time: Sun Mar 22 19:33:17 2009 Windows Vista Ver 6.0 Build 6001 Service Pack 1 Path: c:\altera\90\quartus\bin\cygwin\usr\local\bin c:\altera\90\quartus\bin\cygwin\bin c:\altera\90\quartus\bin\cygwin\bin c:\Windows\system32 c:\Windows c:\Windows\System32\Wbem c:\Program Files\Microsoft SQL Server\90\Tools\binn\ c:\Program Files\MATLAB\R2008a\bin c:\Program Files\MATLAB\R2008a\bin\win32 c:\Program Files\TortoiseSVN\bin c:\altera\90\quartus\bin Output from c:\altera\90\quartus\bin\cygwin\bin\id.exe (nontsec) UID: 400(caxapok) GID: 401(mkpasswd) 401(mkpasswd) Output from c:\altera\90\quartus\bin\cygwin\bin\id.exe (ntsec) UID: 400(caxapok) GID: 401(mkpasswd) 401(mkpasswd) SysDir: C:\Windows\system32 WinDir: C:\Windows USER = 'caxapok' PWD = '/' CYGWIN = 'nontsec nodosfilewarning' HOME = '/cygdrive/c/Users/caxapok' MAKE_MODE = 'unix' HOMEPATH = '\Users\caxapok' APPDATA = 'C:\Users\caxapok\AppData\Roaming' HOSTNAME = 'caxapok-mobile' COMMANDER_INI = 'C:\Users\caxapok\AppData\Roaming\GHISLER\wincmd.ini' TERM = 'cygwin' PROCESSOR_IDENTIFIER = 'x86 Family 6 Model 14 Stepping 8, GenuineIntel' WINDIR = 'C:\Windows' VS80COMNTOOLS = 'C:\Program Files\Microsoft Visual Studio 8\Common7\Tools\' PUBLIC = 'C:\Users\Public' OLDPWD = '/' SOPC_KIT_NIOS2 = 'C:\altera\90\nios2eds' PROGRAMDATA = 'C:\ProgramData' USERDOMAIN = 'caxapok-mobile' OS = 'Windows_NT' ALLUSERSPROFILE = 'C:\ProgramData' COMMANDER_PATH = 'C:\Program Files\totalcmd' VS90COMNTOOLS = 'C:\Program Files\Microsoft Visual Studio 9.0\Common7\Tools\' TEMP = '/cygdrive/d/tmp_usr' COMMONPROGRAMFILES = 'C:\Program Files\Common Files' USERNAME = 'caxapok' PROCESSOR_LEVEL = '6' QUARTUS_ROOTDIR = 'c:\altera\90\quartus' COMMANDER_DRIVE = 'C:' FP_NO_HOST_CHECK = 'NO' SYSTEMDRIVE = 'C:' USERPROFILE = 'C:\Users\caxapok' PS1 = '\[\033]0;Altera Cygwin Shell\a\007 \033[32m\...@\h \[\033[33m\w\033[0m\] $ ' LOGONSERVER = '\\CAXAPOK-MOBILE' PROCESSOR_ARCHITECTURE = 'x86' LOCALAPPDATA = 'C:\Users\caxapok\AppData\Local' !C: = 'C:\altera\90\quartus\bin\cygwin' SHLVL = '1' PATHEXT = '.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.MSC' HOMEDRIVE = 'C:' PROMPT = '$P$G' COMSPEC = 'C:\Windows\system32\cmd.exe' TMP = '/cygdrive/d/tmp_usr' SYSTEMROOT = 'C:\Windows' CVS_RSH = '/bin/ssh' PROCESSOR_REVISION = '0e08' PROGRAMFILES = 'C:\Program Files' NUMBER_OF_PROCESSORS = '2' SESSIONNAME = 'Console' COMPUTERNAME = 'CAXAPOK-MOBILE' _ = '/usr/bin/cygcheck' HKEY_CURRENT_USER\Software\Cygnus Solutions HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\mounts v2 c__altera_90_quartus_bin_cygwin_bin_cygwin1_dll HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\Program Options HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2 c__altera_90_quartus_bin_cygwin_bin_cygwin1_dll HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2 c__altera_90_quartus_bin_cygwin_bin_cygwin1_dll\/ (default) = 'c:\altera\90\quartus\bin\cygwin' flags = 0x0008 HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2 c__altera_90_quartus_bin_cygwin_bin_cygwin1_dll\/usr/bin (default) = 'c:\altera\90\quartus\bin\cygwin\bin' flags = 0x0008 HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2 c__altera_90_quartus_bin_cygwin_bin_cygwin1_dll\/usr/lib (default) = 'c:\altera\90\quartus\bin\cygwin\lib' flags = 0x0008 HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\Program Options c: hd NTFS 61443Mb 57% CP CS UN PA FC system d: hd NTFS 5122Mb 27% CP CS UN PA FC swap e: hd NTFS171906Mb 83% CP CS UN PA FC trash f: cd N/AN/A g: cd N/AN/A c:\altera\90\quartus\bin\cygwin / system textmode c:\altera\90\quartus\bin\cygwin\bin /usr/bin system textmode c:\altera\90\quartus\bin\cygwin\lib /usr/lib system textmode Found: c:\altera\90\quartus\bin\cygwin\bin\awk.exe Found: c:\altera\90\quartus\bin\cygwin\bin\awk.exe Found: c:\altera\90\quartus\bin\cygwin\bin\bash.exe Found: c:\altera\90\quartus\bin\cygwin\bin\bash.exe Found: c:\altera\90\quartus\bin\cygwin\bin\cat.exe Found: c:\altera\90\quartus\bin\cygwin\bin\cat.exe Found: c:\altera\90\quartus\bin\cygwin\bin\cp.exe Found: c:\altera\90\quartus\bin\cygwin\bin\cp.exe Found: c:\altera\90\quartus\bin\cygwin\bin\cpp.exe Found:
Re: [1.7] passwd: useless if used with a logged on domain user
Hi Corinna, On Sun, Mar 22, 2009 at 10:09, Corinna Vinschen wrote: On Mar 21 11:10, Corinna Vinschen wrote: On Mar 20 18:43, Julio Emanuel wrote: Hi, I've been tracing some problems related to the installation scripts of ssh (more info on another mail later), and the root cause for one of the problems is the passwd misbehaving. The test case is very simple. Log on with a domain user on a cygwin shell. My particular case, it's an local Administrator, but not Domain Admin (as 99% of users in a corporate network out there, I suppose). ~ $ id uid=18606(security) gid=10513(Domain Users) groups=0(root),544(Administrators),545(Users),10513(Domain Users) Now, just try to do pretty much anything with passwd: ~ $ passwd -v passwd (cygwin) 1.5 Password Utility Copyright 1999, 2000, 2001, 2002, 2003 Red Hat, Inc. Compiled on Mar 11 2009 ~ $ passwd passwd: unknown user security ~ $ passwd SYSTEM passwd: unknown user security ~ $ passwd Administrator passwd: unknown user security Am I missing something here? How can I make it work with local users, when I'm logged on with a Domain user? That doesn't look too well, but I can't reproduce the effect. I could today. The bug is fixed in CVS. WOW! That was fast! Thanks! Although it does not produce that error message constantly, I'm still unable to use consistently this tool. I think some program logic has to change, although I'm not certain of what/where. I'll try to explain with samples plus comments: ~ $ # Who are you? ~ $ ./my_passwd.exe -v my_passwd (cygwin) 1.5 Password Utility Copyright 1999, 2000, 2001, 2002, 2003 Red Hat, Inc. Compiled on Mar 22 2009 ~ $ # Ok. Now the no-brainer: ~ $ ./my_passwd.exe Enter the new password (minimum of 5, maximum of 8 characters). Please use a combination of upper and lower case letters and numbers. Old password: ~ $ # Just typed Ctrl-C. Not in the mood right now :) ~ $ # And now for the interesting part: ~ $ ./my_passwd.exe -S SYSTEM my_passwd: unknown user SYSTEM ~ $ # Ooops. And what about ~ $ ./my_passwd.exe -S Administrator You have no maintenance privileges. ~ $ # Ouch. If I may insist: ~ $ ./my_passwd.exe -d $HOSTNAME -S Administrator my_passwd: unknown user security ~ $ # Ouch Ouch. Now we're back to the start.. :( Sooo... What I think is that there is a lack of distinction between the current user's domain AND the target's domain. Where the latter should always assumed as the local machine, if not instructed otherwise, and not derived from the current user's domain. What do you think, Corinna? I am missing some trick to have passwd give me '--status' on local users? Or is really needed this program logic change? Thanks for your help! ___ Julio Costa Robert Benchley - I have tried to know absolutely nothing about a great many things, and I have succeeded fair... -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: R: Problem [1.7]: link /bin/lzma - xz
On 3/18/2009 8:28 AM, Charles Wilson wrote: But lzma-4.32.7-3 -- the *current* version of lzma -- IS empty. 4.43-2 is...WAY old. 4.32.7-2 is the most recent one, prior to the latest update. I know it looks like it, but 4.43 is NOT actually newer. lzma-4.43 was derived from a patched version of the LZMA SDK. lzma-4.32.7-X were derived from LZMA Utils, which follow a different numbering scheme. Hmmm...I think I know what happened...because of the screwy version numbers, I need to re-establish the prev: and curr: settings in the setup.hints. I'll go do that now. Has this been taken care of? I'm seeing 4.32.7-2 as the current version of lzma when I run setup-1.7.exe rather than 4.32.7-3. Ken -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: [1.7] passwd: useless if used with a logged on domain user
On Mar 22 17:34, J?lio Costa wrote: ~ $ # Just typed Ctrl-C. Not in the mood right now :) ~ $ # And now for the interesting part: ~ $ ./my_passwd.exe -S SYSTEM my_passwd: unknown user SYSTEM The SYSTEM user is not in the user database. So that's an expected result. ~ $ # Ooops. And what about ~ $ ./my_passwd.exe -S Administrator You have no maintenance privileges. I can't reproduce this one, but maybe that's just a different case of the same as this one: ~ $ # Ouch. If I may insist: ~ $ ./my_passwd.exe -d $HOSTNAME -S Administrator my_passwd: unknown user security I applied another fix to passwd to decouple the logonserver for fetching the user info for the running user account from the user info for the user account which is going to be manipulated by passwd. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: 1.5.24-2: Interfere with Cygwin
On Sun, Mar 22, 2009 at 07:42:23PM +0300, Vladimir Romashkin wrote: I have found a new software which interfere with Cygwin. It is the Logitech SetPoint, at least a version 4.7.213. When I kill SetPoint's process the Cygwin work normally. I use Cygwin which is included to Altera Quartus II 9.0. I use the latest SetPoint software, and latest Cygwin on two different peecees. I do not find a problem. Would you please describe the specific nature of your problem. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Bug in upset? [Was: Re: R: Problem [1.7]: link /bin/lzma - xz]
Ken Brown said: Has this been taken care of? I'm seeing 4.32.7-2 as the current version of lzma when I run setup-1.7.exe rather than 4.32.7-3. Interesting. I just looked at the setup.hint on sourceware (release-2 area): category: _obsolete requires: xz sdesc: removed package ldesc: Compatibility package to force installation of replacement curr: 4.32.7-3 prev: 4.32.7-2 Which seems right, Then, in setup-2.ini: @ lzma sdesc: Removed package ldesc: Compatibility package to force installation of replacement category: _obsolete requires: xz cygwin [prev] version: 4.32.7-2 install: release-2/lzma/lzma-4.32.7-2.tar.bz2 162142 ffe2c623c69e07251ad8ed5560425fee source: release-2/lzma/lzma-4.32.7-2-src.tar.bz2 486990 2945e37b4f6b76f3fc3895f90d2c4737 So, I'm not sure if there's a bug in upset (the setup*.ini generator), or if it's working as it is supposed to (logically, if a package is _obsolete, then there is no current version). If the latter, then I need to figure out how to get the right thing into setup*.ini. However, an argument for the former (e.g. a bug in upset): the setup.ini for cygwin-1.5 has: @ lzma sdesc: Removed package ldesc: Compatibility package to force installation of replacement category: _obsolete requires: xz version: 4.32.7-3 install: release/lzma/lzma-4.32.7-3.tar.bz2 14 4059d198768f9f8dc9372dc1c54bc3c3 source: release/lzma/lzma-4.32.7-3-src.tar.bz2 14 4059d198768f9f8dc9372dc1c54bc3c3 [prev] version: 4.32.7-2 install: release/lzma/lzma-4.32.7-2.tar.bz2 162142 ffe2c623c69e07251ad8ed5560425fee source: release/lzma/lzma-4.32.7-2-src.tar.bz2 486990 2945e37b4f6b76f3fc3895f90d2c4737 And the two lzma/setup.hints are identical. Chris, any suggestions? -- Chuck -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Bug in upset? [Was: Re: R: Problem [1.7]: link /bin/lzma - xz]
On Sun, Mar 22, 2009 at 03:25:31PM -0400, Charles Wilson wrote: Ken Brown said: Has this been taken care of? I'm seeing 4.32.7-2 as the current version of lzma when I run setup-1.7.exe rather than 4.32.7-3. Interesting. I just looked at the setup.hint on sourceware (release-2 area): category: _obsolete requires: xz sdesc: removed package ldesc: Compatibility package to force installation of replacement curr: 4.32.7-3 prev: 4.32.7-2 Which seems right, Then, in setup-2.ini: @ lzma sdesc: Removed package ldesc: Compatibility package to force installation of replacement category: _obsolete requires: xz cygwin [prev] version: 4.32.7-2 install: release-2/lzma/lzma-4.32.7-2.tar.bz2 162142 ffe2c623c69e07251ad8ed5560425fee source: release-2/lzma/lzma-4.32.7-2-src.tar.bz2 486990 2945e37b4f6b76f3fc3895f90d2c4737 So, I'm not sure if there's a bug in upset (the setup*.ini generator), or if it's working as it is supposed to (logically, if a package is _obsolete, then there is no current version). If the latter, then I need to figure out how to get the right thing into setup*.ini. However, an argument for the former (e.g. a bug in upset): the setup.ini for cygwin-1.5 has: @ lzma sdesc: Removed package ldesc: Compatibility package to force installation of replacement category: _obsolete requires: xz version: 4.32.7-3 install: release/lzma/lzma-4.32.7-3.tar.bz2 14 4059d198768f9f8dc9372dc1c54bc3c3 source: release/lzma/lzma-4.32.7-3-src.tar.bz2 14 4059d198768f9f8dc9372dc1c54bc3c3 [prev] version: 4.32.7-2 install: release/lzma/lzma-4.32.7-2.tar.bz2 162142 ffe2c623c69e07251ad8ed5560425fee source: release/lzma/lzma-4.32.7-2-src.tar.bz2 486990 2945e37b4f6b76f3fc3895f90d2c4737 And the two lzma/setup.hints are identical. Chris, any suggestions? I don't understand how you'd posit this as an upset bug if upset is working correctly for the release directory. That implies a difference between the two directories, not an upset bug. And, in fact, there was no lzma-4.32.7-3*tar.bz2 files in the lzma directory. Apparently they were deleted on March 16. I ressurrected them. Since release-2 isn't supposed to have obsolete stuff in it can't we just remove this directory entirely? cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Bug in upset? [Was: Re: R: Problem [1.7]: link /bin/lzma - xz]
On Sun, Mar 22, 2009 at 05:03:41PM -0400, Christopher Faylor wrote: And, in fact, there was no lzma-4.32.7-3*tar.bz2 files in the lzma ^ release-2 directory. Apparently they were deleted on March 16. I ressurrected them. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Bug in upset? [Was: Re: R: Problem [1.7]: link /bin/lzma - xz]
Christopher Faylor wrote: I don't understand how you'd posit this as an upset bug if upset is working correctly for the release directory. That implies a difference between the two directories, not an upset bug. I didn't notice the missing -3 version, because I didn't expect it to be there. The correct obsolete version number for lzma in release-2 is -10 -- and it was there. I also wasn't sure if upset runs in a different mode for release-2, other than look in this directory instead of that one, and put the output in this file instead of that. (I wouldn't expect that it does, but...) And, in fact, there was no lzma-4.32.7-3*tar.bz2 files in the lzma directory. Apparently they were deleted on March 16. I ressurrected them. Urk. Now I remember. Normally, when I'm forking a package for 1.7, I do the following: 1) install lower number in release/ 2) delete the copies in release/ 3) install higher number in release-2/ (it's a little odd when the forked package is ALSO simultaneously being made obsolete...why fork it at all? Eh...) That's ok. However...THIS was the problem: And the two lzma/setup.hints are identical. That's usually correct -- unless you're trying to explicitly specify prev: and curr: versions. When installed like I have been, the numbers are different, and the setup.hints *ought* to have been different, as well. The release-2 version should have said: prev: 4.32.7-2 curr: 4.32.7-10 (not -3). Since release-2 isn't supposed to have obsolete stuff in it can't we just remove this directory entirely? No. How do you propose to accomodate people -- esp. testers who have accepted Corinna's plea to please begin testing cygwin-1.7 -- that have an existing lzma package into their cygwin-1.7 installation? They need to (automatically?) get that existing one removed and the new version from xz installed in its place (ignoring the fact that I screwed up the setup.hints -- TWICE -- this time). Is the policy about obsolete files so hard-and-fast that we want to require current 1.7 users to manually perform these actions, uninstall lzma and then install xz...? Ditto for the reorganization of the libpng packages. It wasn't enough, in that case, to just update libpng12-*. Because I was ripping out the alternatives support, I needed to force an update of both package sets, even though libpng10-devel was moved obsolete. If I had just deleted the libpng10-devel directory, then folks would have been left with half of the alternatives system installed. This would have broken badly: only the obsolete version would have had an alternatives entry, so alternatives would have tried to make it current by setting the symlinks in /usr/lib/. But, the new alternatives-less libpng12-devel installed its actual files where alternatives wants to put the symlinks. It might work (maybe alternatives is shy about deleting real files) -- but it would have been wrong, confusing, and very ugly. (Note: at least THAT time, I didn't bork up the setup.hints). -- Chuck -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: 1.5.24-2: Interfere with Cygwin
David Arnstein wrote: On Sun, Mar 22, 2009 at 07:42:23PM +0300, Vladimir Romashkin wrote: I have found a new software which interfere with Cygwin. It is the Logitech SetPoint, at least a version 4.7.213. When I kill SetPoint's process the Cygwin work normally. I use Cygwin which is included to Altera Quartus II 9.0. I use the latest SetPoint software, and latest Cygwin on two different peecees. I do not find a problem. Would you please describe the specific nature of your problem. The Logitech Process Monitor software which is bundled with many Logitech products is known to interfere with Cygwin processes (it's listed on BLODA). Do either and/or both of you have that process installed and configured to run (in your services control panel?) cheers, DaveK -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: 1.7.0: Chronic Re-install Problem
Lee D.Rothstein wrote: * Until a recent update. During that update, lots of things went haywire, including scads of messages about not being able to read from 'null'. Can't tell you anything about it, but I just saw this myself yesterday. It happened using 1.5, when I was doing a fresh install that stalled part way through and wasn't able to download all the packages I had selected. * Each time I do a Cygwin 1.7 'setup' update, 'setup' shows the following 3 packages (binaries) as requiring update (even if I do an update and immediately follow it with another update): gcc tetex startup-notification After starting the install, setup reports nothing needed installing and quits. At least part of this (the gcc part) is a known-and-harmless bug in setup. I'm not sure whether the others are the same. cheers, DaveK -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
1.7.0: Getting a Windows app to run synchronously to a script from which it is invoked
This is in all probability, not a bug. I suspect it falls into CGF's category of works but isn't (wasn't) guaranteed. All of my scripts (developed under Cygwin 1.5 or earlier) that involve a Windows native app use: winapp $(cygpath -w $something) have stopped working properly since I installed Cygwin 1.7. Here's the script I use, FOR EXAMPLE, for invoking Windows Explorer to the current directory or a specified Cygwin directory path, AND that stops further use of the invoked from terminal window, until this Explorer window terminates: #!/usr/bin/bash if [[ -n $1 ]] ; then cd $1 ; fi explorer $(cygpath -w .) Explorer opens okay, but always to the Computer folder, rather than the current working or specified directory. (Yes, I know that there is a special option for Explorer in 'cygstart'. Please read on.) I found that I can make the above work by replacing the invocation using 'cygpath' with a 'cygstart' initiated invocation without 'cygpath', at all. The problem with this latter fix, however, is that 'cygstart' invokes the Windows app asynchronously to the script in which it is contained. Sometimes I want the script continuance to be tethered to the Windows app, and the only way to do this (that I can see), is to put an otherwise superfluous 'read' statement right after the Windows app invocation. Ugly, and not as obvious, to the user, as the old method. Is there no straight-forward way to invoke a windows app from a script synchronously with Cygwin 1.7? -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
PING: Deprecation of -mno-cygwin.
Ho there gang. Over on gcc-patches, Kai has posted a patch to add some documentation for the i386 cygming subtarget options. See the thread at: http://gcc.gnu.org/ml/gcc-patches/2009-03/threads.html#00994 I asked him if he would add a note mentioning that -mno-cygwin is deprecated, and anyone who wants to review the patch or suggest wording for the deprecation warning is invited to pitch in to that thread. (In particular, should we describe -mcygwin as being deprecated too, or should we say that it will become the always-on default setting, but not actually removed, since we might want to retain the positive form as a permitted no-op flag to aid backward compatibility with old makefiles that use it?) cheers, DaveK -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
[1.7] wordexp()/wordfree() missing?
Hi, Using Cygwin 1.7.0(0.193/5/3), there is /usr/include/wordexp.h but the functions defined there are not in a library (they belong to libc). Do I need a ?-development package? The comment at the end of the wordexp.h file is strange, it says you need bash... what has that to do with a library? Thanks for any help. -- R.Berber -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
setup.exe crash
In case someone else has this problem ... after many years of working w/o a problem, setup.exe failed half way through an install leaving me with a busted WIN XP cygwin. I removed several Windows updates that i thought might have caused the problem but that didn't help. I tried my previous version of setup.exe and that crashed in the same manner. I then tried an even older version (from 2005 w/ size of 298 KB) and that worked! Here is the diagnostic: ?xml version=1.0 encoding=UTF-16? DATABASE EXE NAME=setup.exe FILTER=GRABMI_FILTER_PRIVACY MATCHING_FILE NAME=setup.exe SIZE=585728 CHECKSUM=0x35ED28A0 MODULE_TYPE=WIN32 PE_CHECKSUM=0x0 LINKER_VERSION=0x1 LINK_DATE=06/19/2008 08:22:31 UPTO_LINK_DATE=06/19/2008 08:22:31 / MATCHING_FILE NAME=setup.exe.04.exe SIZE=415232 CHECKSUM=0x2F33FB67 MODULE_TYPE=WIN32 PE_CHECKSUM=0x0 LINKER_VERSION=0x1 LINK_DATE=06/27/2007 08:21:53 UPTO_LINK_DATE=06/27/2007 08:21:53 / /EXE EXE NAME=kernel32.dll FILTER=GRABMI_FILTER_THISFILEONLY MATCHING_FILE NAME=kernel32.dll SIZE=984576 CHECKSUM=0xF0B331F6 BIN_FILE_VERSION=5.1.2600.3119 BIN_PRODUCT_VERSION=5.1.2600.3119 PRODUCT_VERSION=5.1.2600.3119 FILE_DESCRIPTION=Windows NT BASE API Client DLL COMPANY_NAME=Microsoft Corporation PRODUCT_NAME=Microsoft® Windows® Operating System FILE_VERSION=5.1.2600.3119 (xpsp_sp2_gdr.070416-1301) ORIGINAL_FILENAME=kernel32 INTERNAL_NAME=kernel32 LEGAL_COPYRIGHT=© Microsoft Corporation. All rights reserved. VERFILEDATEHI=0x0 VERFILEDATELO=0x0 VERFILEOS=0x40004 VERFILETYPE=0x2 MODULE_TYPE=WIN32 PE_CHECKSUM=0xF9293 LINKER_VERSION=0x50001 UPTO_BIN_FILE_VERSION=5.1.2600.3119 UPTO_BIN_PRODUCT_VERSION=5.1.2600.3119 LINK_DATE=04/16/2007 15:52:53 UPTO_LINK_DATE=04/16/2007 15:52:53 VER_LANGUAGE=English (United States) [0x409] / /EXE /DATABASE -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
'cygstart' option? was Re: 1.7.0: Getting a Windows app to run synchronously to a script from which it is invoked
I figured out a solution, but it still has limitations. The solution: It just requires doing a cd into the path (complete directory path) of the argument, and cd'ing into that path. If the command operates on a directory as Explorer does, then you submit '.' as the argument. If the command requires a file name, you just submit the 'basename' as the argument. I used to do this years ago (starting with the MKS toolkit, and then the Thompson toolkit), but stopped once I became conversant with 'cygpath'. Brain damage is my excuse for forgetting. However, this will only work with Windows programs that themselves are synchronous, OTB (out of the box). This won't work, for example, with OpenOffice (OO) after about version 1.5, or WinWord after version 10, or thereabouts. OO really bummed me out, when they made the change, invalidating all my blogging scripts. That's when I started using the 'read' nonsense. Actually, more recently, they both require 'cygstart' or they flat out blow up. However, you don't have to specifiy the command name at all, just the file name argument. But you still end up with the asynch start. In brief, it would be very nice if there was a cygstart option that did not exit until the command which it starts exits. Is this possible? Lee Lee D.Rothstein wrote: This is in all probability, not a bug. I suspect it falls into CGF's category of works but isn't (wasn't) guaranteed. All of my scripts (developed under Cygwin 1.5 or earlier) that involve a Windows native app use: winapp $(cygpath -w $something) have stopped working properly since I installed Cygwin 1.7. Here's the script I use, FOR EXAMPLE, for invoking Windows Explorer to the current directory or a specified Cygwin directory path, AND that stops further use of the invoked from terminal window, until this Explorer window terminates: #!/usr/bin/bash if [[ -n $1 ]] ; then cd $1 ; fi explorer $(cygpath -w .) Explorer opens okay, but always to the Computer folder, rather than the current working or specified directory. (Yes, I know that there is a special option for Explorer in 'cygstart'. Please read on.) I found that I can make the above work by replacing the invocation using 'cygpath' with a 'cygstart' initiated invocation without 'cygpath', at all. The problem with this latter fix, however, is that 'cygstart' invokes the Windows app asynchronously to the script in which it is contained. Sometimes I want the script continuance to be tethered to the Windows app, and the only way to do this (that I can see), is to put an otherwise superfluous 'read' statement right after the Windows app invocation. Ugly, and not as obvious, to the user, as the old method. Is there no straight-forward way to invoke a windows app from a script synchronously with Cygwin 1.7? -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
