Re: Zsh filename completion sluggishness?
Peter A. Castro [EMAIL PROTECTED] writes: I've edited your output to show just the interesting things :) CDPATH='' FIGNORE='' FPATH=/usr/share/zsh/site-functions:/usr/share/zsh/4.0.6/functions PATH='.:/usr/bin:/c/WINNT/system32:/c/WINNT:/c/WINNT/System32/Wbem:/i/VCI/RTX SDK/bin:/i/Common Files/Adaptec Shared/System:/i/Rational/ClearCase/bin:/i/Rational/common:/i/Rational/ClearQuest:/c/BC5/BIN:/c/emacs-21.2/bin:/c/util:/c/emtprog:/c/j2sdk1.4.0_02/bin:/f/vc98/bin:/f/Common/MSDev98/Bin:/f/Common/Tools/WinNT:/f/Common/Tools' path=(. /usr/bin /c/WINNT/system32 /c/WINNT /c/WINNT/System32/Wbem '/i/VCI/RTX SDK/bin' '/i/Common Files/Adaptec Shared/System' /i/Rational/ClearCase/bin /i/Rational/common /i/Rational/ClearQuest /c/BC5/BIN /c/emacs-21.2/bin /c/util /c/emtprog /c/j2sdk1.4.0_02/bin /f/vc98/bin /f/Common/MSDev98/Bin /f/Common/Tools/WinNT /f/Common/Tools) Well, your path doesn't look quite right. Remove the quotes from the directory paths. This is arguably a bug in cygwin and or both zsh and bash. In the Win32 world, quotes around path elements are valid. If I have: PATH=c:\foo bar cmd.exe will find executables in that dir. When I run bash or zsh, things in c:\foo bar aren't found. Zsh doesn't like quotes embedded in the actual directory names and it won't strip them off before using them. Maybe cygwin should do this in the PATH environment variable it exposes to cygwin apps. Bash seems confused by this as well, unlike Win32 programs. -- matt -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Zsh filename completion sluggishness?
Christopher Faylor [EMAIL PROTECTED] writes: On Fri, Feb 14, 2003 at 10:12:54AM -0700, Matt Armstrong wrote: In the Win32 world, quotes around path elements are valid. If I have: PATH=c:\foo bar cmd.exe will find executables in that dir. When I run bash or zsh, things in c:\foo bar aren't found. This is a UNIX emulation environment. c:\foo bar doesn't mean the c drive in a PATH variable. It means the 'c' directory followed by the '\foo bar' directory. Colon is the separator for PATH. The correct syntax for the above is PATH=/cygdrive/c/foo bar . I understand completely -- as I said somewhat ambiguously I was setting the path to c:\foo bar in cmd.exe, then running bash. When Cygwin initializes its PATH from the Win32 one, it doesn't handle quoted elements properly. E.g. cygwin converts the Win32 path like this: c:\foo;c:\bar - /cygdrive/c/foo:c:\bar But it should do this: c:\foo;c:\bar - /cygdrive/c/foo:/cygdrive/c/bar The latter is the semantic equivalent to the Win32 path. The session below describes exactly what I'm talking about. Microsoft Windows 2000 [Version 5.00.2195] (C) Copyright 1985-2000 Microsoft Corp. C:\cd foo bar C:\foo bardir Volume in drive C is MYDISK Volume Serial Number is 7C67-4A84 Directory of C:\foo bar 02/14/2003 10:01a DIR . 02/14/2003 10:01a DIR .. 02/14/2003 10:01a 19 foobar.cmd 1 File(s) 19 bytes 2 Dir(s) 1,021,567,488 bytes free C:\foo barcd .. C:\foobar 'foobar' is not recognized as an internal or external command, operable program or batch file. C:\set PATH=c:\foo bar;%PATH% C:\foobar C:\echo I ran foobar! I ran foobar! C:\cd cygwin C:\cygwincygwin maarmstr@MAARMSTR ~ $ which foobar.cmd foobar.cmd: Command not found. maarmstr@MAARMSTR ~ $ echo $PATH /usr/local/bin:/usr/bin:/bin:c:/foo bar:/cygdrive/c/WINNT/system32:/cygdrive/c/WINNT:/cygdrive/c/WINNT/System32/Wbem:/bin:/usr/bin:/usr/X11R6/bin maarmstr@MAARMSTR ~ $ export PATH='/cygdrive/c/foo bar':$PATH maarmstr@MAARMSTR ~ $ which foobar.cmd /cygdrive/c/foo bar/foobar.cmd maarmstr@MAARMSTR ~ $ -- matt -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
running programs using cygwin1.dll
Is there a windows or cygwin way of telling when cygwin1.dll is no longer used by any running processes? -- matt -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: running programs using cygwin1.dll
Christopher Faylor [EMAIL PROTECTED] writes: On Tue, Feb 11, 2003 at 10:07:35AM -0700, Matt Armstrong wrote: Is there a windows or cygwin way of telling when cygwin1.dll is no longer used by any running processes? ps? Duh, I never realized ps only showed cygwin processes. Andrew DeFaria [EMAIL PROTECTED] writes: Matt Armstrong wrote: Is there a windows or cygwin way of telling when cygwin1.dll is no longer used by any running processes? Get Process Explorer from sysinternals.com then use it to search for cygwin1.dll. Neat tool. -- matt -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: [ANN] Re: cyg-wrapper.sh
Luc Hermitte [EMAIL PROTECTED] writes: Hello Matt, * On Tue, Dec 10, 2002 at 09:38:02AM -0700, Matt Armstrong * [EMAIL PROTECTED] wrote: Luc, you might consider adding an option to unset the PWD environment variable (or convert it to a Windows path). That's done. I haven't done any test with perforce, so, let me know. The two new options are: --cyg-PWD-clear : to unset PWD --cyg-PWD-convert : to convert PWD to its DOS (short) form. I was considering to handle other environment variables, but I didn't see any good candidate -- ie. environment variables specific to bash or cygwin that win32 native applications may also use. SHELL. Today I discovered the NT port of emacs uses SHELL if set, so it ends up getting its shell set to /usr/bin/zsh. Emacs looks for c:\usr\bin\zsh.exe, but it is really c:\cygwin\usr\bin\zsh.exe. The solution was to clear the SHELL env var, since I didn't want emacs using my cygwin shell. HOME is also probably a good idea to convert into DOS form. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: [ANN] cyg-wrapper.sh
Luc Hermitte [EMAIL PROTECTED] writes: cyg-wrapper v2.2 has been uploaded on my web site: http://hermitte.free.fr/cygwin/#Win32 http://hermitte.free.fr/cygwin/cyg-wrapper.sh cyg-wrapper is a shell script that helps to run, from cygwin, command-line applications that have been compiled for windows only ; ie: applications un-aware and independant of the cygwin layer.[1] cyg-wrapper converts pathname arguments, passed to win32 programs, from the written form (unix/dos/windows ; relative or absolute) to the DOS (short [2] ; and absolute) form that win32 command-line programs understand. Luc, you might consider adding an option to unset the PWD environment variable (or convert it to a Windows path). The Perforce (http://www.perforce.com/) p4.exe will barf if PWD is still set to a cygwin path. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Problems with gcc 3.2.
Christopher Faylor [EMAIL PROTECTED] writes: On Tue, Nov 05, 2002 at 10:11:18AM -0700, Matt Armstrong wrote: Christopher Faylor [EMAIL PROTECTED] writes: You can't send mail with attachments to this list, since some filter strips them all. Not true. For instance, see: http://cygwin.com/ml/cygwin/2002-11/msg00100.html cgf Interesting. There must be a bug in the mailing list software, since it bounced a valid MIME multipart email I sent the list last week: http://www.lickey.com/~matt/bounce.txt I'm no Mime expert but that message looks improperly formatted to me. There is no Content-Type after the message separators. The RFCs say an implicit text/plain content type is assumed when Content-Type is not present. My mailer has been doing it this way for years with no problems (except perhaps this one). Oh well, whoever wrote the patch to ezmlm that does MIME filtering has a bug. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Problems with gcc 3.2.
Harig, Mark A. [EMAIL PROTECTED] writes: As requested at http://cygwin.com/bugs.html: o In your description, show how to reproduce the problem, including a test case, if possible. o At least include the cygwin release number you are using, and give the operating system and its version number, e.g., cygwin v1.3.13 under NT 4.0. o Run cygcheck -s -v -r cygcheck.out and include that *AS AN ATTACHMENT* in your report. You can't send mail with attachments to this list, since some filter strips them all. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
cvs can't parse its arguments -- known issue?
I'm seeing some very odd behavior from cvs and I wonder if others are seeing it too. No matter what args I pass it, cvs tells me it is an invalid option -- even the --help-options arg. All other cygwin stuff seems to be functioning well. -- % cvs -d :pserver:[EMAIL PROTECTED]:/usr/local/cvsroot login cvs: invalid option -- Usage: cvs [cvs-options] command [command-options-and-arguments] where cvs-options are -q, -n, etc. (specify --help-options for a list of options) where command is add, admin, etc. (specify --help-commands for a list of commands or --help-synonyms for a list of command synonyms) where command-options-and-arguments depend on the specific command (specify -H followed by a command name for command-specific help) Specify --help to receive this message The Concurrent Versions System (CVS) is a tool for version control. For CVS updates and additional information, see the CVS home page at http://www.cvshome.org/ or Pascal Molli's CVS site at http://www.loria.fr/~molli/cvs-index.html -- I just installed CVS via the cygwin setup utility and have a recently upgraded installation (cygcheck below). --=-=-= Cygwin Win95/NT Configuration Diagnostics Current System Time: Fri Nov 01 10:45:22 2002 Windows 2000 Professional Ver 5.0 Build 2195 Service Pack 3 Path: C:\cygwin\bin c:\WINNT\system32 c:\WINNT c:\WINNT\System32\Wbem SysDir: C:\WINNT\System32 WinDir: C:\WINNT HOME = `c:\home' PWD = `/cygdrive/c/home' USER = `maarmstr' ALLUSERSPROFILE = `C:\Documents and Settings\All Users' APPDATA = `C:\Documents and Settings\maarmstr\Application Data' CHECK_LEAK_LESS_OFTEN = `100' COMMONPROGRAMFILES = `C:\Program Files\Common Files' COMPUTERNAME = `MAARMSTR' COMSPEC = `C:\WINNT\system32\cmd.exe' EDITOR = `vim' EMAIL = `[EMAIL PROTECTED]' FTP_PASSIVE = `yes' GCC_FILTER = `yes' HOMEDRIVE = `U:' HOMEPATH = `\maarmstr' HOMESHARE = `\\netapp\home' HOSTNAME = `MAARMSTR' INCLUDE = `C:\Program Files\Microsoft Visual Studio\VC98\atl\include;C:\Program Files\Microsoft Visual Studio\VC98\mfc\include;C:\Program Files\Microsoft Visual Studio\VC98\include' LESS = `-Q' LIB = `C:\Program Files\Microsoft Visual Studio\VC98\mfc\lib;C:\Program Files\Microsoft Visual Studio\VC98\lib' LOGNAME = `maarmstr' LOGONSERVER = `\\MAARMSTR' MANPATH = `/usr/man' MSDEVDIR = `C:\Program Files\Microsoft Visual Studio\Common\MSDev98' MUTT_COLORS = `/cygdrive/c/home/env/mutt/color.cygwin' NUMBER_OF_PROCESSORS = `1' OLDPWD = `/cygdrive/c/home/dp/6.2.0-br1/debug-full-wap-mms.vc98/lib' OS2LIBPATH = `C:\WINNT\system32\os2\dll;' OS = `Windows_NT' P4MERGE = `p4merge' PAGER = `less' PATHEXT = `.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH' PERL5 = `c:\perl\bin\perl.exe' PERL5LIB = `/cygdrive/c/home/env/perlib' PROCESSOR_ARCHITECTURE = `x86' PROCESSOR_IDENTIFIER = `x86 Family 6 Model 8 Stepping 10, GenuineIntel' PROCESSOR_LEVEL = `6' PROCESSOR_REVISION = `080a' PROGRAMFILES = `C:\Program Files' PROMPT = `%B%m%#%b ' PURIFYOPTIONS = `-check-debug-timestamps=no -cache-dir=/cygdrive/c/home/purify/cache -always-use-cache-dir=yes -windows=yes -max-threads=500 -chain-length=12' QUANTIFYOPTIONS = `-cache-dir=/home/matt/quantify/cache -always-use-cache-dir=yes' RSYNC_RSH = `ssh' RUBYLIB = `/cygdrive/c/home/env/rubylib:/cygdrive/c/home/lib/ruby' SGML_CATALOG_FILES = `catalog:/etc/sgml/catalog:/usr/lib/sgml/catalog:/usr/local/lib/sgml/catalog:/cygdrive/c/home/dtd/catalog' SGML_SEARCH_PATH = `/cygdrive/c/home/dtd:/usr/share/sgml:/usr/local/share/sgml:/usr/local/lib/sgml:/usr/lib/sgml' SHELL = `/usr/bin/zsh' SHLVL = `1' SSH_AGENT_PID = `1484' SSH_AUTH_SOCK = `/tmp/ssh-QTuY1480/agent.1480' SYSTEMDRIVE = `C:' SYSTEMROOT = `C:\WINNT' TEMP = `c:\DOCUME~1\maarmstr\LOCALS~1\Temp' TERM = `cygwin' TERMINFO = `/cygdrive/c/home/.terminfo' TMP = `c:\DOCUME~1\maarmstr\LOCALS~1\Temp' TZ = `MST7MDT6,M4.1.0/2,M10.5.0/2' USERDNSDOMAIN = `myopwv.com' USERDOMAIN = `MYOPWV' USERNAME = `maarmstr' USERPROFILE = `C:\Documents and Settings\maarmstr' WINDIR = `C:\WINNT' _ = `/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 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 (default) = `/cygdrive' cygdrive flags = 0x0022 HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/ (default) = `C:\cygwin' flags = 0x000a HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/usr/bin (default) = `C:\cygwin/bin' flags = 0x000a HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/usr/lib (default) = `C:\cygwin/lib' flags = 0x000a
Re: cvs can't parse its arguments -- known issue?
John Morrison [EMAIL PROTECTED] writes: I've had this - a while ago I think. Try calling cvs with it's full path... $ /bin/cvs ... Unfortunately, no luck. :-( Randall R Schulz [EMAIL PROTECTED] writes: I cannot replicate that failure (I get a password prompt). Are you invoking it from a Cygwin shell, or from CMD.exe (or COMMAND.COM?). Win2k's CMD.EXE and Cygwin's bash give the same result. You might want to escape the @ sign, since under certain circumstances it's special (i.e., it's a extended shell argument processing syntax meant to allow arguments contained in files to be incorporated into the command line). Simply running cvs a gives the same error message. I suppose it is time to compile from source and debug the problem. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: cvs can't parse its arguments -- known issue?
George William Smith [EMAIL PROTECTED] writes: Check your .cvsrc, you may have some flags there that CVS doesn't support. Thanks, that was it. My .cvsrc was using DOS style end of line terminators. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
