[RFU] lftp-3.7.0-1
I've uploaded a new release of lftp. This is a new upstream release, with bug fixes, a few new features, and a new translation. Please upload. Thanks, Andrew. wget \ http://home.comcast.net/~andrex/cygwin/lftp/lftp-3.7.0-1.tar.bz2 \ http://home.comcast.net/~andrex/cygwin/lftp/lftp-3.7.0-1-src.tar.bz2
Re: [RFU] lftp-3.7.0-1
Andrew Schulman wrote: wget \ http://home.comcast.net/~andrex/cygwin/lftp/lftp-3.7.0-1.tar.bz2 \ http://home.comcast.net/~andrex/cygwin/lftp/lftp-3.7.0-1-src.tar.bz2 Uploaded. -- Chuck
Please upload: ImageMagick 6.4.0.6-1
Please upload the new and long overdue ImageMagick package. Actually this are four packages, find links below. Since upstream version 6.3.8-5 of ImageMagick the following changes were made by the ImageMagick team: Renames: /usr/include = /usr/include/ImageMagick libMagick = libMagickCore libWand = libMagickWand Magick-config (deprecated) = MagickCore-config Wand-config (deprecated) = MagickWand-config These were obviously ABI incompatible changes, but instead of increasing the library version number they reset it to one. In previous versions, we used to pack all the runtime libraries libMagick, libWand and libMagick++ in a libMagick10 package. To avoid confusion with a new runtime library package that has a smaller version number I decided to rename it to libImageMagick1. This means that all packages compiled against the libMagick-devel package need to include a dependency to the libImageMagick1 package. Please upload: http://www.scytek.de/cygwin/release/ImageMagick/setup.hint http://www.scytek.de/cygwin/release/ImageMagick/ImageMagick-6.4.0.6-1.tar.bz2 http://www.scytek.de/cygwin/release/ImageMagick/ImageMagick-6.4.0.6-1-src.tar.bz2 http://www.scytek.de/cygwin/release/ImageMagick/libImageMagick1/setup.hint http://www.scytek.de/cygwin/release/ImageMagick/libImageMagick1/libImageMagick1-6.4.0.6-1.tar.bz2 http://www.scytek.de/cygwin/release/ImageMagick/libMagick-devel/setup.hint http://www.scytek.de/cygwin/release/ImageMagick/libMagick-devel/libMagick-devel-6.4.0.6-1.tar.bz2 http://www.scytek.de/cygwin/release/ImageMagick/perl-Image-Magick/setup.hint http://www.scytek.de/cygwin/release/ImageMagick/perl-Image-Magick/perl-Image-Magick-6.4.0.6-1.tar.bz2 Please keep the 6.3.0.1-2 versions of the packages and delete all older versions, except the newest versions of the libMagick6 and libMagick10 runtime libraries. Volker -- PGP/GPG key (ID: 0x9F8A785D) available from wwwkeys.de.pgp.net key-fingerprint 550D F17E B082 A3E9 F913 9E53 3D35 C9BA 9F8A 785D signature.asc Description: OpenPGP digital signature
How to start up X directly, in a startx-like manner?
Hello people, I like to use cygwin in a self-contained, maximized window in which my window manager runs (fvwm). Currently I start this by first opening a bash shell and then typeng startx, which then reads my .xinitrc and does what I want. However, I'd like this to happen on a single click. I found startxwin.bat, but that just puts X-like windows on top of the normal Windows desktop. It doesn't create the cover-all Windows window with X inside. I played with the -fullscreen option inside startxwin.bat, but at any rate, startxwin.bat doesn't honor my .xinitrc How can I fix this? Thanks, robert -- 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: How to start up X directly, in a startx-like manner?
Robert Latest schrieb: I like to use cygwin in a self-contained, maximized window in which my window manager runs (fvwm). Currently I start this by first opening a bash shell and then typeng startx, which then reads my .xinitrc and does what I want. However, I'd like this to happen on a single click. I found startxwin.bat, but that just puts X-like windows on top of the normal Windows desktop. It doesn't create the cover-all Windows window with X inside. I played with the -fullscreen option inside startxwin.bat, but at any rate, startxwin.bat doesn't honor my .xinitrc Maybe putting: C:\cygwin\bin\bash.exe -c -l 'run bash -c -l Xwin.exe :0 export DISPLAY=:0.0; xterm; fvwm2 in an Icon does what you want. -- 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: How to start up X directly, in a startx-like manner?
Holger Krull schrieb: Robert Latest schrieb: I like to use cygwin in a self-contained, maximized window in which my window manager runs (fvwm). Currently I start this by first opening a bash shell and then typeng startx, which then reads my .xinitrc and does what I want. However, I'd like this to happen on a single click. I found startxwin.bat, but that just puts X-like windows on top of the normal Windows desktop. It doesn't create the cover-all Windows window with X inside. I played with the -fullscreen option inside startxwin.bat, but at any rate, startxwin.bat doesn't honor my .xinitrc Maybe putting: C:\cygwin\bin\bash.exe -c -l 'run bash -c -l Xwin.exe :0 export DISPLAY=:0.0; xterm; fvwm2 in an Icon does what you want. The closing ' missed the copy and paste, so the line should be C:\cygwin\bin\bash.exe -c -l 'run bash -c -l Xwin.exe :0 export DISPLAY=:0.0; xterm; fvwm2 ' -- 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: Help
Dharini, http://cygwin.com/acronyms/#PPIOSPE. Not only will you have the access to more expertise than any one person can provide, but your query and the answers to it will be in the archives for others to find later. I've redirected your query to the appropriate list, and set the Reply-To header accordingly -- please make sure your mailer honors it. On Thu, 17 Apr 2008, dharini sutharsan wrote: Hello Sir i want to use XV for my educational work and i couldn understand the installation procedure... kindly guide me in installing Xv... I hav cygwin and can in install XV in cygwin.. if so give me the procedures sir... Thanks in advance Regards Dharini What installation procedure are you referring to? The supported installation procedure for Cygwin is in the FAQ: http://cygwin.com/faq/faq-nochunks.html#faq.setup.setup. Was there a particular way that it didn't work? Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] | [EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_Igor Peshansky, Ph.D. (name changed!) |,4- ) )-,_. ,\ ( `'-' old name: Igor Pechtchanski '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! That which is hateful to you, do not do to your neighbor. That is the whole Torah; the rest is commentary. Go and study it. -- Rabbi Hillel -- 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: Help
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Igor Peshansky wrote: | On Thu, 17 Apr 2008, dharini sutharsan wrote: | | Hello Sir | i want to use XV for my educational work and i couldn understand the | installation procedure... kindly guide me in installing Xv... | | I hav cygwin and can in install XV in cygwin.. if so give me the | procedures sir... If you mean the shareware graphics program, you'll need to build it yourself due to its license. You can use the following with cygport(1): http://cygwin-ports.cvs.sourceforge.net/cygwin-ports/ports/graphics/xv/ OTOH, if you mean the X Video extension, it is not supported on Cygwin. Yaakov -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEAREIAAYFAkgH3vEACgkQpiWmPGlmQSO9dQCg55mvlptuvm/+9Ys8jdqOD332 UBYAoKrNk40pqxgnb2TTAiYmdAN4Pffz =cGjM -END PGP SIGNATURE- -- 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 dtable.cc
CVSROOT:/cvs/src Module name:src Branch: cr-0x5f1 Changes by: [EMAIL PROTECTED] 2008-04-17 09:29:51 Modified files: winsup/cygwin : ChangeLog dtable.cc Log message: * dtable.cc (dtable::init_std_file_from_handle): Fix pipe related test. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/ChangeLog.diff?cvsroot=srconly_with_tag=cr-0x5f1r1=1.3582.2.60r2=1.3582.2.61 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/dtable.cc.diff?cvsroot=srconly_with_tag=cr-0x5f1r1=1.169.4.6r2=1.169.4.7
Re: PATCH: login under privileged user != SYSTEM
On Apr 17 01:48, Charles Wilson wrote: I've been trying to get all the bugs in inetutils-1.5 squashed, and I ran into an issue with rlogin when rlogind was running under a privileged user (that is, not SYSTEM), as is required for Windows Server 2003, 2008, and Vista. The problem was, although rsh would honor my .rhosts and allow passwordless operation, rlogin would not. It always asked for my password. Internally, rlogind *knew* that the incoming connection was authenticated via .rhosts, so it invoked login thus: login -p -h incoming hostname -f -- username where the '-f' SHOULD mean this is already authenticated, don't ask for the password again. But it wasn't working, because login was hardcoded to compare the current uid to 18 (that is, SYSTEM), before allowing passwordless auth. But rlogind/login were not running under SYSTEM. I don't think you can simply replace the code in login, the way we did in many of the servers, tho: #ifdef __CYGWIN__ -#define ROOT_UID18 +#define ROOT_UIDgetuid() #else #define ROOT_UID 0 #endif because then you'd allow passwordless auth no matter what account login was running under. Now, it might fail later, assuming we added code to check whether some future setuid() succeeded or not, but I think that's too late in the process. So, for *login*, I changed the code from if (uid == ROOT_UID) to if (is_a_ROOT_UID(uid)) and implemented a function that, depending on the underlying windows version, either (1) compares to 18 (2) checks that the account with the specified uid has the following privileges: +SeAssignPrimaryTokenPrivilege +SeCreateTokenPrivilege +SeTcbPrivilege +SeIncreaseQuotaPrivilege +SeServiceLogonRight (On NT/2k/XP, uid = 18 is an automatic yes, but if uid != 18, then we fall back to the Vista check-privileges procedure) With these changes, I can now get passwordless rlogin when inetd is running under a privileged user, and not SYSTEM. Most of the code was adapted from editrights/main.c... Cool, thanks! Would you mind to take over login maintainance, too? It was always just the wagging tail of inetutils anyway... Other than that, I'd like to suggest a few minor changes to the patch: - The SeServiceLogonRight doesn't have to be tested, IMHO. It doesn't have anything to do with user account switching. - I don't understand why NT4 is handled specially by only checking for the uid while 2K and XP get the additional account check if necessary. None of the functions are new with 2K, they all exists since NT 3.51. - I wouldn't do the automatic yes for uid 18 anymore. Even for NT/2K/XP it would be more correct to check if the current account running the process is the one with SID S-1-5-18. Given that there's already so much code for Windows specific privilege checking, I don't think it hurts a lot to add something along the lines of AllocateAndInitializeSid (SECURITY_NT_AUTHORITY, 1, 18, ..., system_sid); token = OpenProcessToken (GetCurrentProcess ()); user_sid = GetTokenInformation(token, TOKEN_USER); if (EqualSid (user_sid, system_sid)) yes else check_privileges Thanks again, 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/
[ANNOUNCEMENT] Updated: cygwin-1.5.25-12
I've uploaded a new release Cygwin 1.5.25-12. This is a bug fix release. Changes since version 1.5.25-11: - Avoid potential data loss on Windows Vista/2008 when reading data from a input pipe created by a native Windows process. To update your installation, click on the Install Cygwin now link on the http://cygwin.com/ web page. This downloads setup.exe to your system. Save it and run setup, answer the questions, then look for 'cygwin' in the 'Base' category (it should already be selected). If you have questions or comments, please send them to the Cygwin mailing list. See http://cygwin.com/lists.html for details. *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO *** If you want to unsubscribe from the cygwin-announce mailing list, look at the List-Unsubscribe: tag in the email header of this message. Send email to the address specified there. It will be in the format: [EMAIL PROTECTED] 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. Corinna Vinschen 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: Directory existence prevents .exe execution
On Wed, 16 Apr 2008, Luke Kendall wrote: We have the Ici scripting language installed on Windows. Ici expects a directory called ici to exist alongside, where various libraries are installedd to provide extra functionality. Unfortunately, under Cygwin, if w try to run the command ici we get the error ici: command not found, because Cygwin chooses to try to execute the directory instead of the .exe: This behavior (preferring the unadorned file name to the .exe) has been in existence for a while (at least a year). We relied on the old behavior by having a script and a .exe with the same name (and expecting the .exe to be invoked on Windows/Cygwin). I remember we've had to work around this issue when the change happened, by prepending the following to our script: [ -x $0.exe ] exec $0.exe $@ $ /opt/bin/ici /cygdrive/x/bin/script/cfnhdr bash: /opt/bin/ici: is a directory $ ls -ld /opt/bin/ici drwxr-xr-x 1 luke Domain Users 0 Oct 17 2005 /opt/bin/ici $ ls -ld /opt/bin/ici.* -rwxr-xr-x 1 luke Domain Users 233503 Apr 18 2000 /opt/bin/ici.dll -rwxr-xr-x 1 luke Domain Users 24576 Jan 29 2003 /opt/bin/ici.exe I tried naming the ici directory Ici but it made no difference. Try also CYGWIN=$CYGWIN check_case:strict (while the code is still in the DLL) or managed mounts... The latter won't work unless ici.exe is a Cygwin program. The directory /opt/bin is mounted like so: $ mount \\samba\syncopt\microsoft.x86.win\bin on /opt/bin type system (textmode,exec) Using binmode doesn't help. Is this a bug, that bash tries to execute a directory even when there's an executable (with an implicit .exe suffix, naturally) of the same name in existence ? No, this is expected behavior (if you search through bash release announcements, you should be able to see the exact point at which the change happened). If not, can anyone suggest a workaround? Other than renaming the directory or using a wrapper script, no. I can't just append a .exe to the #!/opt/bin/ici shell wrapper since then the scripts wouldn't run from Unix. How do these scripts *ever* run from Unix? Unix would definitely not be aware of the .exe suffix, and would always attempt to execute /opt/bin/ici, which, as you say, is a directory. Do you have a /opt/bin/ici script as well? In any case, whatever solution you use to make it work from Unix should work on Cygwin as well. Is there a bash option that controls this, maybe (I couldn't see one)? There is no bash option to control this, AFAIK. Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] | [EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_Igor Peshansky, Ph.D. (name changed!) |,4- ) )-,_. ,\ ( `'-' old name: Igor Pechtchanski '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! That which is hateful to you, do not do to your neighbor. That is the whole Torah; the rest is commentary. Go and study it. -- Rabbi Hillel -- 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: Trouble installing DBD::Oracle on Cygwin
Hi I got the OCI Libraries installed and got the make file to get generated without any issues. Now I am encountering the below error trying to run the makefile $ make gcc -c -IC:/oracle/product/9.2.0/client_2/oci/include -IC:/oracle/product/9.2.0/client_2/rdbms/demo -I/usr/lib/perl5/site_perl/5.8/cygwin/auto/DBI -DPERL_USE_SAFE_PUTENV -fno-strict-aliasing -pipe -Wdeclaration-after-statement -DUSEIMPORTLIB -O3 -DVERSION=\1.21\ -DXS_VERSION=\1.21\ -I/usr/lib/perl5/5.8/cygwin/CORE -Wall -Wno-comment -DUTF8_SUPPORT -DNEW_OCI_INIT -DORA_OCI_VERSION=\9.2.0.1\ Oracle.c In file included from Oracle.xs:1: Oracle.h:114: error: conflicting types for 'OCIXMLTypeCreateFromSrc' Oracle.h:114: note: an argument type that has a default promotion can't match an empty parameter name list declaration C:/oracle/product/9.2.0/client_2/oci/include/ociap.h:10038: error: previous declaration of 'OCIXMLTypeCreateFromSrc' was here Oracle.h:114: error: conflicting types for 'OCIXMLTypeCreateFromSrc' Oracle.h:114: note: an argument type that has a default promotion can't match an empty parameter name list declaration C:/oracle/product/9.2.0/client_2/oci/include/ociap.h:10038: error: previous declaration of 'OCIXMLTypeCreateFromSrc' was here make: *** [Oracle.o] Error 1 Has anyone seen this error before? I scrubbed the system clean of any Oracle Client installation and reinstalled the 9i client in totality. Thanks Dunston - Original Message From: Reini Urban [EMAIL PROTECTED] To: cygwin@cygwin.com Sent: Wednesday, April 16, 2008 3:19:54 PM Subject: Re: Trouble installing DBD::Oracle on Cygwin 2008/4/16, Dunston Rocks: Hilling DBD::Oracle on Cygwin Steps followed : Download from CPAN tar –zxvf DBD-Oracle-1.20.tar.gz cd DBD-Oracle-1.20 make realclean perl Makefile.pl make : *** [ Oracle.o ] Error 1 ; output attached (make_results.txt) perl – V (attached : perl_V.out) make realclean perl Makefile.pl -g make (Same error as above in Step 6) ) ; output attached (make_results_debugmode.txt) Oracle 10g Client at C:\oracle\product\10.2.0\client_2 ORACLE_HOME set to above SQLPLUS set to C:\oracle\product\10.2.0\client_2\bin\sqllplus and am able to connect to all databases in C:\oracle\product\10.2.0\client_2\network\ADMIN\tnsnames.ora from cygwin bash shell Cygwin Installation : A complete installation from latest build from Cygwin.com on April 10th 2008 DBI is installed, but attempting to run code that uses DBD::Oracle throws below errorinstall_driver(Oracle) failed: Can't locate DBD/Oracle..pm in @INC (@INC contains: %PERL5LIB%;C \Documents and Settings\dunston\My Documents\scripts\parse;C \Program Files\Mozilla Firefox\tpsf;C \Documents and Settings\dunston\My Documents\scripts\parse;C \Program Files\Mozilla Firefox\tpsf /usr/lib/perl5/5.8/cygwin /usr/lib/perl5/5..8 /usr/lib/perl5/site_perl/5.8/cygwin /usr/lib/perl5/site_perl/5.8 /usr/lib/perl5/site_perl/5.8 /usr/lib/perl5/vendor_perl/5.8/cygwin /usr/lib/perl5/vendor_perl/5..8 /usr/lib/perl5/vendor_perl/5.8 .) at (eval 3) line 3. Change your PERL5LIB to a sane value. I know, Oracle 10 messes up the PERL5LIB environment variable, because they ship their own perl and apache. I just unset PERL5LIB and add the POSIX paths of the Oracle dirs to your perl Makefile.PL line. $ PERL5LIB= ORACLE_HOME=/cygdrive/oracle/product/10.2.0/client_2 perl Makefile.PL maybe add -h path to headers Also check out http://search.cpan.org/src/PYTHIAN/DBD-Oracle-1.21/README.wingcc.txt if the importlib was correctly created. Would appreciate your input on installing this library in Cygwin Thanks -- gcc -g -c -IC:/oracle/product/10.2.0/client_2/oci/include gcc cannot handle this path anymore! /cygdrive/c/oracle/product/10.2.0/client_2/oci/include is better. -IC:/oracle/product/10.2.0/client_2/rdbms/demo -I/usr/lib/perl5/site_perl/5.8/cygwin/auto/DBI -g -DPERL_USE_SAFE_PUTENV -fno-strict-aliasing -pipe -Wdeclaration-after-statement -DUSEIMPORTLIB-DVERSION=\1.20\ -DXS_VERSION=\1.20\ -I/usr/lib/perl5/5.8/cygwin/CORE -Wall -Wno-comment -DUTF8_SUPPORT -DNEW_OCI_INIT -DORA_OCI_VERSION=\9.2.0.1\ Oracle.c In file included from Oracle.xs:1: Oracle.h:37:17: oci.h: No such file or directory Oracle.h:39:20: ocidfn.h: No such file or directory Oracle.h:40:18: orid.h: No such file or directory Oracle.h:41:17: ori.h: No such file or directory -- Reini Urban http://phpwiki.org/ http://murbreak.at/ -- 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/ Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ --
How to access a cygwin folder mounted with 'managed' option?
Hi all, I want to use gnus to access maildir folders, which are cygwin folders mounted with 'managed' option. With 'managed' option, cygwin filesystem in a window machine can be case-sensitive and allow some special characters used in maildir files. I tried with the latest EmacsW32 but it does not seem to be able to access managed mounts as they are. Is there a way that EmacsW32 can access case-sensitive files on managed mounts as we can in cygwin? -- Jinhyok -- 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: How to access a cygwin folder mounted with 'managed' option?
Jinhyok Heo heo at stanford.edu writes: I tried with the latest EmacsW32 but it does not seem to be able to access managed mounts as they are. Of course it can't, since EmacsW32 isn't a cygwin app. Is there a way that EmacsW32 can access case-sensitive files on managed mounts as we can in cygwin? Use cygwin's emacs instead. -- Eric Blake -- 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: How to access a cygwin folder mounted with 'managed' option?
Eric Blake ebb9 at byu.net writes: Jinhyok Heo heo at stanford.edu writes: I tried with the latest EmacsW32 but it does not seem to be able to access managed mounts as they are. Of course it can't, since EmacsW32 isn't a cygwin app. Since it is known that how managed mounts treat special characters and uppercases, EmacsW32 may provide an interface with which users can use unix-type filenames in certain cygwin folders. Is there a way that EmacsW32 can access case-sensitive files on managed mounts as we can in cygwin? Use cygwin's emacs instead. Cygwin emacs needs X, which I do not want to run. -- Jinhyok -- 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: How to access a cygwin folder mounted with 'managed' option?
2008/4/17, Jinhyok Heo: Since it is known that how managed mounts treat special characters and uppercases, EmacsW32 may provide an interface with which users can use unix-type filenames in certain cygwin folders. I've written a cygpath wrapper for a slime interface to my w32 xemacs. But I forgot its name and where it is stored. On the emacs wiki most likely. Is there a way that EmacsW32 can access case-sensitive files on managed mounts as we can in cygwin? Use cygwin's emacs instead. Cygwin emacs needs X, which I do not want to run. xemacs or emacs -nox -- Reini Urban http://phpwiki.org/ http://murbreak.at/ -- 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: inetutils-1.5-2 test release
Dr. Volker Zell wrote:
Fixed the ftp problem. It was an '=' vs. '==' transcription bug.
If I try the old rsh against your new daemons it seems to work:
06:53 PM [637] /bin/rsh [EMAIL PROTECTED] pwd
/home/vzell
Fixed this. The new version of rsh added a check to ensure that rsh.exe
client had the setuid bit ON (that is, its getuid() is 'root'), and
exited otherwise. Obvious that's wrong on cygwin. The only reason
'/bin/rsh [EMAIL PROTECTED]' (with no command) worked is because that is
implmented as 'exec rlogin' BEFORE checking the setuid -- and the
rlogin.exe client does not check that getuid() is 'root').
and in /var/log/messages:
Mar 18 18:53:28 localhost rshd: PID 160: 2nd port not reserved 1022
This was a red herring. Just a cut-n-paste error; this log message
belonged elsewhere in the code.
Mar 18 18:53:51 localhost rshd: PID 2948: [EMAIL PROTECTED] as vzell: cmd='pwd'
Normal log message when a rcmd/rexec/rsh fails. The failure was due to
the setuid thing, above.
By the way, for every telnet session I see the following two entries in
/var/log/messages
Mar 18 18:02:11 localhost telnetd: PID 180: ttloop: retrying
Mar 18 18:02:39 localhost telnetd: PID 180: child process 1180 exited: 0
Is this expected behaviour ?
Well, kinda. If your server is faster than your client...
// function io_drain //
again:
ncc = read (net, netibuf, sizeof netibuf);
if (ncc 0)
{
if (errno == EAGAIN)
{
syslog (LOG_INFO, ttloop: retrying);
goto again;
}
It just means that you tried to read from an empty but non-blocking
socket. I don't really like the way this is coded; it's a 100% busy
loop. But, that's why it's called ttloop (which is the only caller of
io_drain):
#define ttloop(c) while (c) io_drain ()
But ttloop is used rather sparingly -- for instance, while doing the
handshaking to set up the login prompt. Most of the time telnetd sits in
a select() loop.
--
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/
[Avail for test] inetutils-1.5-3
I've uploaded a new test release for inetutils, based on the upstream 1.5 release. A short list of the changes appears below, but the documentation has been extensively revised. I urge you to read /usr/share/doc/Cygwin/inetutils-1.5.README. All clients and servers appear to work, even on Vista, with the possible exception of talkd (see inetutils-1.5.README). If there are no objections, I plan to make this current in about a week, even with the known issues below. I'd appreciate testing not just of these servers and clients, but also the iu-config and syslogd-config scripts (which might also smoke out any problems with csih-0.1.4) Known issues: * talkd (possibly just firewall issues) -- see README * password-less rsh/rcp operation on Vista will require an updated login.exe program, not yet available. * anonymous ftp not tested * rexec does not honor ~/.netrc (possible issue in cygwin's rcmd() implementation). Does honor $REXEC_USER/$REXEC_PASS. * uucpd not tested Building this package requires a patched cygport: http://cygwin.com/ml/cygwin-apps/2008-03/msg00139.html Major changes with respect to current 1.3.2-40 * servers are now called ftpd instead of in.ftpd. Update your inetd / xinetd configuration scripts. * inetd now supports both inetd.conf and inetd.d/ configuration directories. * inetd --install-as-service is deprecated. If you have installed inetd as a service under its own power -- that is, without using cygrunsrv -- please convert to using either cygrunsrv $ inetd --remove-as-service $ iu-config or run inetd as a slave of the sysvinit package's init service (see inetutils-1.5.README) Changes with respect to previous test release, 1.5-2 * fixed bug in ftpd server that prevented authentication * fixed bug in rsh client that prevented operation in any mode other than 'rlogin-like' * fixed WinServ2003/Vista bug in rlogind where ROOT id was hardcoded to LocalSystem (18). However, this also exposed a bug in the login package (not yet fixed). * removed erroneous warning message from rshd. * Added support for parsing DOS-style paths in tftpd, recieved from tftp clients. (The tftpd command-line arguments must be in unix form, as always). * silence warning in talkd when user has no ~/.talkrc file * Lots of documentation updates Changes with respect to previous test release, 1.5-1 * disabled all services in the default inetd.conf * updated default motd * imported fix for rshd (and rexecd) from 1.3.2-40 release * updated documentation * fixed packaging bug * inetd: + new macro CYGWIN_INETD_INSTALL_AS_SERVICE will eventually be used to disable --install-as-service option, but not yet. + check and use ...\\inetd\\Parameters\\ConfigFilePath registry key as a backup, if ConfigFilePaths is not found. Also, warn if both are present but differ. * use the new csih package to assist with service installation. Changes with regards to current release, 1.3.2-40: * inetd now accepts multiple configuration files (or directories) which will be searched. To accomodate this when running as a service under its own power, inetd --install-as-service creates a new registry key ConfigPaths instead of the old ConfigPath. By default, inetd uses /etc/inetd.conf /etc/inetd.d/ * The inetutils package no longer installs the server programs as `in.rlogind' and similar. Instead they are are installed as `rlogind'. If you have an existing /etc/inetd.conf file (or ./etc/xinetd.conf) you should manually update these references. * Added a new option to inetd: -T/--traditional-daemon, which does the regular fork/daemonize behavior. This is used with the (also provided) sysvinit-style startup script, so that inetd can be run under the control of the sysvinit package's init daemon. So now, there are THREE ways to run inetd as a service: a) install as a service using cygrunsrv (with the -D option) b) installed as a service under its own power [DEPRECATED] c) as a slave to the init service, using /etc/rc.d/init.d/inetd (which uses the -T option when invoking inetd) * There's also a little test program for the built-in services, provided as source code in /usr/share/doc/inetutils-*/. You can easily test TCP services using: telnet host port but there's no easy way to test UDP services. udp_client can be used to do this: udp_client host port or service name some data to send For instance, the UDP echo service can be tested using: $ udp_client localhost echo hello Received from localhost: 'hello'. $ -- Chuck -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports:
Re: info needed
unknown-1 wrote: Larry Hall (Cygwin reply-to-list-only-lh at cygwin.com writes: unknown-1 wrote: You have the latest versions available with Cygwin. You can either wait for the maintainer to update the packages to the version you want or pull the source from the GTK site and build it yourself. I saw several messages of updates packages but don't know where to find them in a usable way. If they were announced here by a Cygwin maintainer, then they will be available (eventually) on all Cygwin mirrors. You can access them through 'setup.exe', just the way you have in the past. I wonder if I could use the packages at ftp://sunsite.dk/projects/cygwinports/release These packages come from here http://cygwinports.dotsrc.org/. They are not part of the official distribution and aren't supported by this list. But they are packaged to be recognized by 'setup.exe' so they should install the same way. I am thinking of creating my own cygwin package mirror and include the ports from this site. Anybody an idea if that could work? Of course at my own risk as that would not be an official release. Any comments on this? With the caveats you mentioned, you're free to do so. But you don't have to if you just want to use these packages. If you add the path above to 'setup.exe', it will pull in any recognized packages from that site and any others you choose (or enter). -- 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? -- 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: How to access a cygwin folder mounted with 'managed' option?
Reini Urban rurban at x-ray.at writes: 2008/4/17, Jinhyok Heo: Since it is known that how managed mounts treat special characters and uppercases, EmacsW32 may provide an interface with which users can use unix-type filenames in certain cygwin folders. I've written a cygpath wrapper for a slime interface to my w32 xemacs. But I forgot its name and where it is stored. On the emacs wiki most likely. I searched 'cygpath' on the emacswiki, but I could not find something relevant. Your code treats special characters properly? Is there a way that EmacsW32 can access case-sensitive files on managed mounts as we can in cygwin? Use cygwin's emacs instead. Cygwin emacs needs X, which I do not want to run. xemacs or emacs -nox As I said, both need X, which I do not want. -- Jinhyok -- 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: [ANNOUNCEMENT] Updated: cygwin-1.5.25-12
Woohoo! Thanks very much Corinna, and the rest of the team. On Thu, Apr 17, 2008 at 5:54 AM, Corinna Vinschen [EMAIL PROTECTED] wrote: I've uploaded a new release Cygwin 1.5.25-12. This is a bug fix release. Changes since version 1.5.25-11: - Avoid potential data loss on Windows Vista/2008 when reading data from a input pipe created by a native Windows process. To update your installation, click on the Install Cygwin now link on the http://cygwin.com/ web page. This downloads setup.exe to your system. Save it and run setup, answer the questions, then look for 'cygwin' in the 'Base' category (it should already be selected). If you have questions or comments, please send them to the Cygwin mailing list. See http://cygwin.com/lists.html for details. *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO *** If you want to unsubscribe from the cygwin-announce mailing list, look at the List-Unsubscribe: tag in the email header of this message. Send email to the address specified there. It will be in the format: [EMAIL PROTECTED] 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. Corinna Vinschen 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/ -- 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/
environment variables and ssh logins
I have several environment variables defined in the Windows Control Panel - System - Advanced - Environment Variables - System Variables list on my Windows XP box. If I run a Cygwin bash login shell locally on this machine, I can find all those environment variables in the output of the env command. However, if I ssh to the same machine, several of those environment variables are missing from my environment. For example, PATH is in both environments and is the same except for the extra :/bin component in the ssh version, and CYGWIN=ntsec is in both. However, PYTHONPATH is in the local environment but not in the ssh environment. Why are some but not all the environment variables defined in the System dialog inherited by ssh logins? Thanks, Gary -- 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: environment variables and ssh logins
On 2008-04-17, Gary Johnson wrote: I have several environment variables defined in the Windows Control Panel - System - Advanced - Environment Variables - System Variables list on my Windows XP box. If I run a Cygwin bash login shell locally on this machine, I can find all those environment variables in the output of the env command. However, if I ssh to the same machine, several of those environment variables are missing from my environment. For example, PATH is in both environments and is the same except for the extra :/bin component in the ssh version, and CYGWIN=ntsec is in both. However, PYTHONPATH is in the local environment but not in the ssh environment. Why are some but not all the environment variables defined in the System dialog inherited by ssh logins? P.S. Yes, I have rebooted since setting PYTHONPATH. Gary -- 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: environment variables and ssh logins
Gary Johnson wrote: Why are some but not all the environment variables defined in the System dialog inherited by ssh logins? http://www.cygwin.com/ml/cygwin/2006-10/msg00729.html http://www.cygwin.com/ml/cygwin/2006-11/msg00397.html http://www.cygwin.com/ml/cygwin/2008-02/msg00386.html Brian -- 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: environment variables and ssh logins
On 2008-04-17, Brian Dessent wrote: Gary Johnson wrote: Why are some but not all the environment variables defined in the System dialog inherited by ssh logins? http://www.cygwin.com/ml/cygwin/2006-10/msg00729.html http://www.cygwin.com/ml/cygwin/2006-11/msg00397.html http://www.cygwin.com/ml/cygwin/2008-02/msg00386.html Thank you. That was very helpful. Regards, Gary -- 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.com not working. N360 the problem?
I had a problem with 'setup.exe' for the first time today. I finally seemed to have cleared it up. This is merely a heads up for other who may experience similar problems. I always use a copy of 'setup.exe on' my hard disk (since I use FireFox, and am generally paranoid about Net executables), which is the latest version (Setup+2.573.2.2+DL_2008-04-17). It made no difference which server I used (I tried over 15!), or what the protocol was (http vs ftp), they all failed. The error messages/conditions, however, varied by server and whether, the server had the latest updates (cygwin-1.5.25-12, tar-1.20-1). Also, some servers seemed to think that I have not installed about the last 10 updates, while other thought I have everything (and apparently have not yet updated to: cygwin-1.5.25-12, tar-1.20-1). I'm running Vista home premium (SP1 updates beyond), and Symantec Norton 360 (v2.1.0.5) which had not been a problem, up until today (and I do an update almost every day). I finally got it to work after I suspended both the auto-anti-virus protection, and the firewall. However, I'm not sure that that was the fix. (Every day, a Mac looks better to me. Sigh!) It's interesting to note that I can't even send email unless Cygwin is working, since I use an ssh tunnel to my mail server. Yet another kudo for Cygwin. Could this have been a temporal glitch in Comcast's net? (The problems were always during the download phase, not the install phase.) BTB, the new setup feature of warning you that key files are locked, and then let's you correct the problem during the setup session rocks! Kudos to the chef. The next update, I'll try again w/o messing with N360 to get a better idea of where the problem lies, and report if anybody's interested. Lee, JAVOTRH -- just another victim of the Redmond hordes -- 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: Directory existence prevents .exe execution
Corinna Vinschen wrote: On Apr 16 16:42, Luke Kendall wrote: Suppose that when it does a stat() on fred, before it decides that it's found the right file to exec, it should check that fred isn't a A stat() call can't know for what purpose it has been called. Calling stat on foo, it will return the information for foo first, if it exists. Only if it not exists it tries foo.exe or foo.lnk. Sure, that makes sense. The stat() call can't know, but the exec() certainly does know that it's trying to execute. So I meant that exec() could call stat(), and if the file exists but is a directory, reject it as a possible thing to execute, and continue with what I assume is the existing Windows-specific logic to look for foo.exe or foo.lnk. What do you think, does the idea make sense? Regards, luke Corinna -- 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: Directory existence prevents .exe execution
Mark J. Reed wrote: I still don't understand why you would put the ici dir in the same place as the ici script. You can't do that on Unix, so why do it on Cygwin? The creator did this because simply it seemed a convenient way to keep all the ici components together and easy to install and uninstall, and it also caused no problems for the Windows cmd.exe shell. cmd doesn't try to execute directories as if they were programs. ici has been around for about 25 years, so it wasn't designed with Cygwin in mind. luke On 4/16/08, Luke Kendall [EMAIL PROTECTED] wrote: On 15 Apr, Dyck, David wrote: how much control do you have on unix side? (you could create a symlink from ici.exe to ici on unix. True. And I suppose there are only rare programs that would suffer this problem. what about creating a new name for ici.exe and ici that could be found on both. Umm, I don't think I understand. Then we'd have to modify every script to change the #!/opt/bin/ici, wouldn't we? directories need to have 'x' attribute to be searchable (on unix) but I would also ask about your path why do you need an /opt/bin/ici directory on windows when if /opt/bin/ici was a directory on unix, where would the shell be finding ici executable? On Unix, it would be finding it under /opt/ici-3.0.1/lib/ici3. Since it should also work under Windows natively, we can't rely on using mount points under Cygwin, since they just wouldn't be visible. But maybe we could do something along those lines. It does seem like a corner case (in bash or in the exec call), that Cygwin would be better for handling. This corner case can't happen in Unix because Unix doesn't have implicit suffixes on commands: you can't have a directory and an executable in the same directory with the same name. (If you have a command called fred.sh, you type fred.sh to execute it, not fred.) I assume exec() stat()s a file, and then presumably does some special magic to change fred to fred.exe if it can't find fred. Suppose that when it does a stat() on fred, before it decides that it's found the right file to exec, it should check that fred isn't a directory. If it is a directory, it should consider that not found and the logic would flow through into the checking for .exe and whatever other arcane Windows executable-file suffixes make sense. But having not looked at the source, I confess I'm just guessing. Thanks, luke -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Luke Kendall Sent: Tuesday, April 15, 2008 9:44 PM To: cygwin@cygwin.com Subject: Directory existence prevents .exe execution We have the Ici scripting language installed on Windows. Ici expects a directory called ici to exist alongside, where various libraries are installedd to provide extra functionality. Unfortunately, under Cygwin, if w try to run the command ici we get the error ici: command not found, because Cygwin chooses to try to execute the directory instead of the .exe: $ /opt/bin/ici /cygdrive/x/bin/script/cfnhdr bash: /opt/bin/ici: is a directory $ ls -ld /opt/bin/ici drwxr-xr-x 1 luke Domain Users 0 Oct 17 2005 /opt/bin/ici $ ls -ld /opt/bin/ici.* -rwxr-xr-x 1 luke Domain Users 233503 Apr 18 2000 /opt/bin/ici.dll -rwxr-xr-x 1 luke Domain Users 24576 Jan 29 2003 /opt/bin/ici.exe I tried naming the ici directory Ici but it made no difference. The directory /opt/bin is mounted like so: $ mount \\samba\syncopt\microsoft.x86.win\bin on /opt/bin type system (textmode,exec) Using binmode doesn't help. Is this a bug, that bash tries to execute a directory even when there's an executable (with an implicit .exe suffix, naturally) of the same name in existence ? If not, can anyone suggest a workaround? I can't just append a .exe to the #!/opt/bin/ici shell wrapper since then the scripts wouldn't run from Unix. Is there a bash option that controls this, maybe (I couldn't see one)? Regards, luke -- 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/ This message (including any attachments) contains confidential and/or proprietary information intended only for the addressee. Any unauthorized disclosure, copying, distribution or reliance on the contents of this information is strictly prohibited and may constitute a violation of law. If you are not the intended recipient, please notify the sender immediately by responding to this e-mail, and delete the message from your system. If you have any questions about this e-mail please notify the sender immediately. -- 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: Directory existence prevents .exe execution
On 04/17/2008, Luke Kendall wrote: Mark J. Reed wrote: I still don't understand why you would put the ici dir in the same place as the ici script. You can't do that on Unix, so why do it on Cygwin? The creator did this because simply it seemed a convenient way to keep all the ici components together and easy to install and uninstall, and it also caused no problems for the Windows cmd.exe shell. cmd doesn't try to execute directories as if they were programs. ici has been around for about 25 years, so it wasn't designed with Cygwin in mind. Everything didn't have to be named ici though. But that's besides the point. Cygwin doesn't attempt to execute directories. It uses stat() to find out what type of thing foo is. Then it uses that information to decide how to handle foo. -- 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? -- 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: Directory existence prevents .exe execution
Igor Peshansky wrote: On Wed, 16 Apr 2008, Luke Kendall wrote: We have the Ici scripting language installed on Windows. Ici expects a directory called ici to exist alongside, where various libraries are installedd to provide extra functionality. Unfortunately, under Cygwin, if w try to run the command ici we get the error ici: command not found, because Cygwin chooses to try to execute the directory instead of the .exe: This behavior (preferring the unadorned file name to the .exe) has been in existence for a while (at least a year). Interesting. Do you mean that exec() prefers the unadorned file name to the .exe? Or do you mean bash or something else changed to prefer the unadorned name? From what you say below, I think you mean bash changed. We relied on the old behavior by having a script and a .exe with the same name (and expecting the .exe to be invoked on Windows/Cygwin). I remember we've had to work around this issue when the change happened, by prepending the following to our script: [ -x $0.exe ] exec $0.exe $@ Our olden approach, maybe 5-10 years ago, we wrote a script that examined the 1st line of some target script to generate a C program (that was compiled to a .exe of the same name) that invoked the named interpreter on the target script. This was needed for U/Win. Then we changed over to Cygwin and discovered we didn't need to do this: Cygwin supported #! magic. But some time ago it stopped working in this corner case and I finally got around to asking about it. To follow the approach you took for your case, we could convert all our ici scripts to shell scripts and um, what, set ICI to either /opt/bin/ici or /opt/bin/ici.exe depending on whether we detect the script is on Windows and then: exec $ICI -f - $@ 'some-eof-mark' But that wouldn't work, would it, since we'd still have to backslash escape any backtic character in the script? Shudder. $ /opt/bin/ici /cygdrive/x/bin/script/cfnhdr bash: /opt/bin/ici: is a directory $ ls -ld /opt/bin/ici drwxr-xr-x 1 luke Domain Users 0 Oct 17 2005 /opt/bin/ici $ ls -ld /opt/bin/ici.* -rwxr-xr-x 1 luke Domain Users 233503 Apr 18 2000 /opt/bin/ici.dll -rwxr-xr-x 1 luke Domain Users 24576 Jan 29 2003 /opt/bin/ici.exe I tried naming the ici directory Ici but it made no difference. Try also CYGWIN=$CYGWIN check_case:strict (while the code is still in the DLL) or managed mounts... The latter won't work unless ici.exe is a Cygwin program. Thanks for the suggestion, but it didn't help: $ echo $CYGWIN nobinmode $ CYGWIN=$CYGWIN check_case:strict $ ici -help bash: ici: command not found $ /opt/bin/ici -help bash: /opt/bin/ici: is a directory $ whiches ici /opt/bin/ici.exe /opt/bin/ici.dll /cygdrive/x/bin/ici.exe /cygdrive/x/bin/ici.dll $ type ici bash: type: ici: not found $ which ici ici: Command not found. $ CYGWIN=nobinmode $ ici -help bash: ici: command not found $ /opt/bin/ici -help bash: /opt/bin/ici: is a directory The directory /opt/bin is mounted like so: $ mount \\samba\syncopt\microsoft.x86.win\bin on /opt/bin type system (textmode,exec) Using binmode doesn't help. Is this a bug, that bash tries to execute a directory even when there's an executable (with an implicit .exe suffix, naturally) of the same name in existence ? No, this is expected behavior (if you search through bash release announcements, you should be able to see the exact point at which the change happened). I had a look, but couldn't find the release notes. Do you mean, the release notes for each of the bash updates announced on the mailing list? Or do you mean the full release notes - if so, any idea where I'd find them? I looked at the release notes for all the mailing list announcements for bash over the last few years, and searched for unadorned and exec. Sorry for asking. If not, can anyone suggest a workaround? Other than renaming the directory or using a wrapper script, no. I can't just append a .exe to the #!/opt/bin/ici shell wrapper since then the scripts wouldn't run from Unix. How do these scripts *ever* run from Unix? Unix would definitely not be aware of the .exe suffix, and would always attempt to execute /opt/bin/ici, which, as you say, is a directory. Do you have a /opt/bin/ici script as well? No, ici on Unix looks elsewhere for its libraries, since it can't use such a simple system as having the directory alongside the .exe with the same name but the suffix stripped, for obvious reasons. In any case, whatever solution you use to make it work from Unix should work on Cygwin as well. True. We can modify the ici source to also have a directory search path for the libraries, and move the ici directory somewhere else that's off the PATH search path, and that will solve this problem. I guess that's what we'll do. But we'll then have the problem that Windows native compiled ici won't be able to open any named scripts that aren't given with
Calling Cygwin from Dos - problem with sub program
Hi, I have a bash script (e.g. test.sh), and I have the following command inside the script: #!/usr/bin/bash export PROG_LIB=D:\batch\prod\prog\lib export PATH=$PROG_LIB:$PATH #include functions from functions.library file . functions.library #Using logmsg function: logmsg This is the beginning When I ran from cygwin, I got no error when executing the shell script (test.sh), all OK. However when I execute from dos, I got an error: functions.library: No such file or directory logmsg: command not found Here is my dos script, test.cmd: @echo off D: chdir D:\cygwin\bin bash --login -c '/cygdrive/d/Batch/prod/prog/scripts/test.sh' Any idea what's missing / went wrong? Thanks, Lian -- View this message in context: http://www.nabble.com/Calling-Cygwin-from-Dos---problem-with-sub-program-tp16760067p16760067.html Sent from the Cygwin list mailing list archive at Nabble.com. -- 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: Directory existence prevents .exe execution
Larry Hall (Cygwin) wrote: On 04/17/2008, Luke Kendall wrote: Mark J. Reed wrote: I still don't understand why you would put the ici dir in the same place as the ici script. You can't do that on Unix, so why do it on Cygwin? The creator did this because simply it seemed a convenient way to keep all the ici components together and easy to install and uninstall, and it also caused no problems for the Windows cmd.exe shell. cmd doesn't try to execute directories as if they were programs. ici has been around for about 25 years, so it wasn't designed with Cygwin in mind. Everything didn't have to be named ici though. But that's besides the point. And that will probably have to be the solution. Cygwin doesn't attempt to execute directories. What do you mean by Cygwin, in this case? Bash? Cygwin's implementation of exec()? It uses stat() to find out what type of thing foo is. Then it uses that information to decide how to handle foo. This is why I'm saying that something that handles the invocation of programs under Cygwin tries to execute directories: $ /opt/bin/ici -help bash: /opt/bin/ici: is a directory $ whiches ici /opt/bin/ici.exe /opt/bin/ici.dll /cygdrive/x/bin/ici.exe /cygdrive/x/bin/ici.dll $ ls -ld /opt/bin/Ici drwxr-xr-x 1 luke Domain Users 0 Oct 17 2005 /opt/bin/Ici It looks like something has stat()ed /opt/bin/ici and then decided it's been asked to execute that, and refusing (which makes a kind of sense), and bailing out with an error (*that* step seems wrong to me). I assumed that the logic which invokes foo.exe when you type foo should not be trying to execute a directory called foo. It's never right to try to execute a directory. I'm suggesting that instead of trying to do that and reporting an error and failing, the code should just skip past that as obviously wrong and fall through to the rest of its logic, which would in fact do the right thing - even if the foo.exe was in some other directory entirely, later on the PATH! Cheers, luke -- 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: Directory existence prevents .exe execution
On 04/18/2008, Luke Kendall wrote: Larry Hall (Cygwin) wrote: What do you mean by Cygwin, in this case? Bash? Cygwin's implementation of exec()? In this case, bash. Try it from, say, csh, and you'll see something a bit different. It uses stat() to find out what type of thing foo is. Then it uses that information to decide how to handle foo. This is why I'm saying that something that handles the invocation of programs under Cygwin tries to execute directories: $ /opt/bin/ici -help bash: /opt/bin/ici: is a directory $ whiches ici /opt/bin/ici.exe /opt/bin/ici.dll /cygdrive/x/bin/ici.exe /cygdrive/x/bin/ici.dll $ ls -ld /opt/bin/Ici drwxr-xr-x 1 luke Domain Users 0 Oct 17 2005 /opt/bin/Ici It looks like something has stat()ed /opt/bin/ici and then decided it's been asked to execute that, and refusing (which makes a kind of sense), and bailing out with an error (*that* step seems wrong to me). Well, didn't you ask to execute '/opt/bin/ici'? After all, that's what you typed. I don't see how it could be wrong to report back what you asked to execute is a directory. I assumed that the logic which invokes foo.exe when you type foo should not be trying to execute a directory called foo. It's never right to try to execute a directory. True enough. Hence the message. The directory isn't being executed here. I'm suggesting that instead of trying to do that and reporting an error and failing, the code should just skip past that as obviously wrong and fall through to the rest of its logic, which would in fact do the right thing - even if the foo.exe was in some other directory entirely, later on the PATH! If you ask for 'foo' or '/path/to/foo' and that's a directory, going beyond that looking for something else when you've found an exact match is a bit dangerous. You don't want to be taking too many liberties with the exe magic. Things could get ugly fast. That said, if you want an executable to be named foo and not foo.exe, you can do that on NT-based platforms. But again, here you're back to a situation where you won't be able to have a same-named directory right beside the executable. But that matches *nix. -- 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? -- 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: How to access a cygwin folder mounted with 'managed' option?
2008/4/17, Jinhyok Heo: Reini Urban writes: Cygwin emacs needs X, which I do not want to run. xemacs or emacs -nox As I said, both need X, which I do not want. What do you thing the -nox means? no X XEmacs also works fine without X, if you don't set the DISPLAY variable in your env. -- Reini Urban http://phpwiki.org/ http://murbreak.at/ -- 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: Directory existence prevents .exe execution
Larry Hall (Cygwin) wrote: On 04/18/2008, Luke Kendall wrote: Larry Hall (Cygwin) wrote: What do you mean by Cygwin, in this case? Bash? Cygwin's implementation of exec()? In this case, bash. Try it from, say, csh, and you'll see something a bit different. $ /opt/bin/ici -help CORRECT/opt/bin/Ici -help (y|n|e|a)? no /opt/bin/ici: Command not found. $ /opt/bin/ici -help CORRECT/opt/bin/Ici -help (y|n|e|a)? yes /opt/bin/Ici: Permission denied. Yep, it's no better. It even specifically offers me the optio to try to execute the directory. It uses stat() to find out what type of thing foo is. Then it uses that information to decide how to handle foo. This is why I'm saying that something that handles the invocation of programs under Cygwin tries to execute directories: $ /opt/bin/ici -help bash: /opt/bin/ici: is a directory $ whiches ici /opt/bin/ici.exe /opt/bin/ici.dll /cygdrive/x/bin/ici.exe /cygdrive/x/bin/ici.dll $ ls -ld /opt/bin/Ici drwxr-xr-x 1 luke Domain Users 0 Oct 17 2005 /opt/bin/Ici It looks like something has stat()ed /opt/bin/ici and then decided it's been asked to execute that, and refusing (which makes a kind of sense), and bailing out with an error (*that* step seems wrong to me). Well, didn't you ask to execute '/opt/bin/ici'? After all, that's what you typed. I don't see how it could be wrong to report back what you asked to execute is a directory. I thought that bash treated the first word on the line (after optional assignments to environment variables a la FRED=x run-some-command) as a command to execute, passing the remaining words on the line to the command as arguments? (Leaving aside things like backtic execution and variable expansion.) So I still think I asked for /opt/bin/ici to be executed by bash. I'd be interested to know if I've misunderstood. I also checked that bash doesn't work this way under Linux. I created a directory called ici (with execute permission, obviously), in the first directory in my PATH. I then ran ici from bash, and it did not tell me that ici was a directory and bail out - it executed the first ici executable it found later in my PATH. That's all I was hoping that Cygwin's bash would do, too. zsh under Cywgin is worse, though: $ /opt/bin/ici -help zsh: no such file or directory: /opt/bin/ici I assumed that the logic which invokes foo.exe when you type foo should not be trying to execute a directory called foo. It's never right to try to execute a directory. True enough. Hence the message. The directory isn't being executed here. I'm suggesting that instead of trying to do that and reporting an error and failing, the code should just skip past that as obviously wrong and fall through to the rest of its logic, which would in fact do the right thing - even if the foo.exe was in some other directory entirely, later on the PATH! If you ask for 'foo' or '/path/to/foo' and that's a directory, going beyond that looking for something else when you've found an exact match is a bit dangerous. You don't want to be taking too many liberties with the exe magic. Things could get ugly fast. That said, if you want an executable to be named foo and not foo.exe, you can do that on NT-based platforms. But again, here you're back to a situation where you won't be able to have a same-named directory right beside the executable. But that matches *nix. -- 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: Directory existence prevents .exe execution
Luke Kendall wrote: Larry Hall (Cygwin) wrote: On 04/18/2008, Luke Kendall wrote: It looks like something has stat()ed /opt/bin/ici and then decided it's been asked to execute that, and refusing (which makes a kind of sense), and bailing out with an error (*that* step seems wrong to me). Well, didn't you ask to execute '/opt/bin/ici'? After all, that's what you typed. I don't see how it could be wrong to report back what you asked to execute is a directory. I thought that bash treated the first word on the line (after optional assignments to environment variables a la FRED=x run-some-command) as a command to execute, passing the remaining words on the line to the command as arguments? (Leaving aside things like backtic execution and variable expansion.) So I still think I asked for /opt/bin/ici to be executed by bash. I'd be interested to know if I've misunderstood. I think you did as well. And so does bash. But it's not going to allow you to execute a directory, which is what your invocation matches exactly. So it tells you that you made a mistake by trying to execute a directory. I guess we're in violent agreement that you got what you asked for. I also checked that bash doesn't work this way under Linux. I created a directory called ici (with execute permission, obviously), in the first directory in my PATH. I then ran ici from bash, and it did not tell me that ici was a directory and bail out - it executed the first ici executable it found later in my PATH. Well here you're not comparing the same thing at all. You can't put a file/binary named ici in the same spot as a directory you have named ici. So you've already changed the rules. But try the exact same thing you just did under Linux on Cygwin and you'll see the same behavior as Linux. The point is that Windows allows you to do something you can't do in Linux. You can have the name of an executable match the name of a directory, if you ignore the extension. In addition you can run an executable by only providing part of its name (i.e. not the extension). You can't do this under Linux. And why would you want to. But if you try to put that same-named executable and directory under the one directory and then run the executable from there without providing the full name, you're being imprecise. Cygwin's bash lets you know this. You can't compare this behavior to Linux because you'd never get into that situation. Don't confuse any of this with an executable named ici.exe in one directory in your path and a directory named ici in another (also in your path). This isn't a general issue that will bite you every time you want to run ici.exe in this configuration. In this scenario, the only time running ici.exe as ici would cause you to get the complaint that ici is a directory is if you were trying to run it from the parent directory of ici-the-directory. And if you take that parent directory (and . if you have that) out of your path, you can run ici.exe as ici from anywhere. Better? -- 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? -- 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/
Updated: cygwin-1.5.25-12
I've uploaded a new release Cygwin 1.5.25-12. This is a bug fix release. Changes since version 1.5.25-11: - Avoid potential data loss on Windows Vista/2008 when reading data from a input pipe created by a native Windows process. To update your installation, click on the Install Cygwin now link on the http://cygwin.com/ web page. This downloads setup.exe to your system. Save it and run setup, answer the questions, then look for 'cygwin' in the 'Base' category (it should already be selected). If you have questions or comments, please send them to the Cygwin mailing list. See http://cygwin.com/lists.html for details. *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO *** If you want to unsubscribe from the cygwin-announce mailing list, look at the List-Unsubscribe: tag in the email header of this message. Send email to the address specified there. It will be in the format: [EMAIL PROTECTED] 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. Corinna Vinschen Red Hat
