Re: cygwin-1.5.16-1: FIFOs broken
cgf wrote: I thought that maybe something like: cat FIFO 42FIFO might work since that would cause cat to keep FIFO open for input and output but that just hangs on both cygwin and linux. Probably the right thing to do is: in one shell: $ cat fifo in the other shell: $ exec 6fff $ echo hello 6 $ echo more 6 $ exec 6- (or something similar). Or a more similar approach to your one also seems to work: $ cat fifo One thing that is different on cygwin to linux, is if there are multiple readers of a fifo. shell 1: $ cat fifo shell 2: $ cat fifo On linux, both keep waiting for someone to write to the fifo. On cygwin, when the second cat tries to listen on the fifo, they both exit. I don't know how fifos are supposed to work, but I'm guessing cygwin gets it wrong here. Lev -- 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/
Bash Process Substitution
Process substitution in bash is not working for me currently. I'm pretty certain it worked at some point in the past (maybe about 6 months ago). For example: $ cat ( echo hello) hangs, ignoring ^C, kill -9, and requiring kill -f on the cat process. Reading the bash manual, it seems bash can use either /dev/fd or named pipes as the underlying mechanism for process substitution. My understanding is that cygwin has recently gained some level of support for named pipes but that they aren't fully working (is this true?). Perhaps in the past, bash used the /dev/fd method but now it sees these named pipes and tries to use those, but chokes due to the incomplete implementation of the latter? Some evidence that this is the case: $ echo ( echo) /tmp/sh-np-197572444 $ ls -l /tmp/sh-np-197572444 prw--- 1 Lev None 102 Apr 14 03:42 /tmp/sh-np-197572444 So it looks to be using a fifo in /tmp I tried adding a symlink /dev/fd like on my linux box, but this didn't help: $ ls -l /dev/fd lrwxrwxrwx 1 Lev None 13 Apr 13 21:54 /dev/fd - /proc/self/fd So, if my guess is correct, maybe there is some way to convince bash to ignore the fifo possibility and just use /dev/fd, as it presumably did in the past? Results of the above commands on a linux box, for comparison purposes: $ cat ( echo hello) hello $ echo ( echo) /dev/fd/63 $ ls -l /dev/fd lrwxrwxrwx1 root root 15 Oct 5 2001 /dev/fd - ../proc/self/fd So it appears that on the linux box it is not using a fifo. Thanks for any insight, Lev cygcheck -s -v -r output attached Cygwin Configuration Diagnostics Current System Time: Thu Apr 14 03:52:07 2005 Windows XP Home Edition Ver 5.1 Build 2600 Service Pack 2 Path: C:\cygwin\usr\local\bin C:\cygwin\bin C:\cygwin\bin .\ C:\cygwin\bin C:\cygwin\usr\X11R6\bin c:\WINDOWS\system32 c:\WINDOWS c:\WINDOWS\System32\Wbem c:\Program Files\ProENGINEER Student Edition\bin c:\Program Files\ATI Technologies\ATI Control Panel c:\Program Files\Common Files\GTK\2.0\bin c:\MATLABR11\bin c:\Program Files\SSH Communications Security\SSH Secure Shell c:\WINDOWS\System32\ C:\cygwin\bin C:\cygwin\usr\X11R6\bin\ Output from C:\cygwin\bin\id.exe (nontsec) UID: 1007(Lev) GID: 513(None) 513(None) Output from C:\cygwin\bin\id.exe (ntsec) UID: 1007(Lev) GID: 513(None) 0(root) 513(None) 544(Administrators) 545(Users) SysDir: C:\WINDOWS\system32 WinDir: C:\WINDOWS CYGWIN = `server' HOME = `C:\cygwin\home\Lev' MAKE_MODE = `unix' PWD = `/home/Lev' USER = `Lev' !EXITCODE = `' ALLUSERSPROFILE = `C:\Documents and Settings\All Users' APPDATA = `C:\Documents and Settings\Lev\Application Data' CLASSPATH = `C:\Program Files\Java\j2re1.4.2_03\lib\ext\QTJava.zip' COLLECTIONID = `COL8143' COMMONPROGRAMFILES = `C:\Program Files\Common Files' COMPUTERNAME = `RAAJSGDH' COMSPEC = `C:\WINDOWS\system32\cmd.exe' CVS_RSH = `/bin/ssh' CYGWIN_ROOT = `\cygwin' DISPLAY = `127.0.0.1:0.0' FP_NO_HOST_CHECK = `NO' HMSERVER = `https://wwss1pro.cce.hp.com/wuss/servlet/WUSSServlet' HOMEDRIVE = `C:' HOMEPATH = `\Documents and Settings\Lev' HOSTNAME = `raajsgdh' ITEMID = `dj-22741-10' LANG = `2057' LOGNAME = `Lev' LOGONSERVER = `\\RAAJSGDH' LS_COLORS = `no=00:fi=00:di=01;34:ln=01;36:pi=40;33:so=01;35:bd=40;33;01:cd=40;33;01:ex=01;33:*~=05;31:*.mtxt=05;31:*.ndx=05;31:*.cmd=01;32:*.exe=01;32:*.com=01;32:*.btm=01;32:*.bat=01;32:*.c=01;36:*.h=01;36:*.pl=01;36:*.pm=01;36:*.cgi=01;36:*.java=01;36:*.html=01;36:*.tar=01;31:*.tgz=01;31:*.gz=01;31:*.tgz=01;31:*.bz2=01;31:*.arj=01;31:*.taz=01;31:*.lzh=01;31:*.zip=01;31:*.z=01;31:*.Z=01;31:*.gz=01;31:*.jpg=01;35:*.jpeg=01;35:*.JPG=01;35:*.gif=01;35:*.GIF=01;35:*.bmp=01;35:*.BMP=01;35:*.xbm=01;35:*.ppm=01;35:*.xpm=01;35:*.tif=01;35:' MANPATH = `:/usr/ssl/man:/usr/X11R6/man' NUMBER_OF_PROCESSORS = `1' OS = `Windows_NT' OSVER = `winXPH' PATHEXT = `.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.tcl' PKG_CONFIG_PATH = `/usr/X11R6/lib/pkgconfig' PROCESSOR_ARCHITECTURE = `x86' PROCESSOR_IDENTIFIER = `x86 Family 6 Model 11 Stepping 1, GenuineIntel' PROCESSOR_LEVEL = `6' PROCESSOR_REVISION = `0b01' PROGRAMFILES = `C:\Program Files' PROMPT = `$P$G' PS1 = `\[\033]0;\w\007 [EMAIL PROTECTED] \[\033[33m\w\033[0m\] $ ' QTJAVA = `C:\Program Files\Java\j2re1.4.2_03\lib\ext\QTJava.zip' SESSIONID = `1102556474045htx694c2ea0b:101105131c0:-23bf' SESSIONNAME = `Console' SHLVL = `3' SSH_AGENT_PID = `3304' SSH_AUTH_SOCK = `/tmp/ssh-GAHQJz3256/agent.3256' SWUTVER = `1.0.18.30716' SYSTEMDRIVE = `C:' SYSTEMROOT = `C:\WINDOWS' TEMP = `c:\DOCUME~1\Lev\LOCALS~1\Temp' TERM = `xterm' TERMCAP = `xterm-r6|xterm|xterm X11R6
cd /proc/garbage
I looked and this doesn't seem to have been mentioned in the archives. You can cd to any random subdirectory of a directory in the /proc filesystem, irrespective of whether it exists. Examples: $ cd /proc/banana $ ls ls: .: Not a directory $ cd /proc/self/banana $ ls ls: .: Not a directory $ cd /proc/self/fd/banana $ ls ls: .: Not a directory However it only works one level deep: $ cd /proc/banana/banana bash: cd: /proc/banana/banana: No such file or directory Lev Cygwin Configuration Diagnostics Current System Time: Thu Apr 14 03:52:07 2005 Windows XP Home Edition Ver 5.1 Build 2600 Service Pack 2 Path: C:\cygwin\usr\local\bin C:\cygwin\bin C:\cygwin\bin .\ C:\cygwin\bin C:\cygwin\usr\X11R6\bin c:\WINDOWS\system32 c:\WINDOWS c:\WINDOWS\System32\Wbem c:\Program Files\ProENGINEER Student Edition\bin c:\Program Files\ATI Technologies\ATI Control Panel c:\Program Files\Common Files\GTK\2.0\bin c:\MATLABR11\bin c:\Program Files\SSH Communications Security\SSH Secure Shell c:\WINDOWS\System32\ C:\cygwin\bin C:\cygwin\usr\X11R6\bin\ Output from C:\cygwin\bin\id.exe (nontsec) UID: 1007(Lev) GID: 513(None) 513(None) Output from C:\cygwin\bin\id.exe (ntsec) UID: 1007(Lev) GID: 513(None) 0(root) 513(None) 544(Administrators) 545(Users) SysDir: C:\WINDOWS\system32 WinDir: C:\WINDOWS CYGWIN = `server' HOME = `C:\cygwin\home\Lev' MAKE_MODE = `unix' PWD = `/home/Lev' USER = `Lev' !EXITCODE = `' ALLUSERSPROFILE = `C:\Documents and Settings\All Users' APPDATA = `C:\Documents and Settings\Lev\Application Data' CLASSPATH = `C:\Program Files\Java\j2re1.4.2_03\lib\ext\QTJava.zip' COLLECTIONID = `COL8143' COMMONPROGRAMFILES = `C:\Program Files\Common Files' COMPUTERNAME = `RAAJSGDH' COMSPEC = `C:\WINDOWS\system32\cmd.exe' CVS_RSH = `/bin/ssh' CYGWIN_ROOT = `\cygwin' DISPLAY = `127.0.0.1:0.0' FP_NO_HOST_CHECK = `NO' HMSERVER = `https://wwss1pro.cce.hp.com/wuss/servlet/WUSSServlet' HOMEDRIVE = `C:' HOMEPATH = `\Documents and Settings\Lev' HOSTNAME = `raajsgdh' ITEMID = `dj-22741-10' LANG = `2057' LOGNAME = `Lev' LOGONSERVER = `\\RAAJSGDH' LS_COLORS = `no=00:fi=00:di=01;34:ln=01;36:pi=40;33:so=01;35:bd=40;33;01:cd=40;33;01:ex=01;33:*~=05;31:*.mtxt=05;31:*.ndx=05;31:*.cmd=01;32:*.exe=01;32:*.com=01;32:*.btm=01;32:*.bat=01;32:*.c=01;36:*.h=01;36:*.pl=01;36:*.pm=01;36:*.cgi=01;36:*.java=01;36:*.html=01;36:*.tar=01;31:*.tgz=01;31:*.gz=01;31:*.tgz=01;31:*.bz2=01;31:*.arj=01;31:*.taz=01;31:*.lzh=01;31:*.zip=01;31:*.z=01;31:*.Z=01;31:*.gz=01;31:*.jpg=01;35:*.jpeg=01;35:*.JPG=01;35:*.gif=01;35:*.GIF=01;35:*.bmp=01;35:*.BMP=01;35:*.xbm=01;35:*.ppm=01;35:*.xpm=01;35:*.tif=01;35:' MANPATH = `:/usr/ssl/man:/usr/X11R6/man' NUMBER_OF_PROCESSORS = `1' OS = `Windows_NT' OSVER = `winXPH' PATHEXT = `.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.tcl' PKG_CONFIG_PATH = `/usr/X11R6/lib/pkgconfig' PROCESSOR_ARCHITECTURE = `x86' PROCESSOR_IDENTIFIER = `x86 Family 6 Model 11 Stepping 1, GenuineIntel' PROCESSOR_LEVEL = `6' PROCESSOR_REVISION = `0b01' PROGRAMFILES = `C:\Program Files' PROMPT = `$P$G' PS1 = `\[\033]0;\w\007 [EMAIL PROTECTED] \[\033[33m\w\033[0m\] $ ' QTJAVA = `C:\Program Files\Java\j2re1.4.2_03\lib\ext\QTJava.zip' SESSIONID = `1102556474045htx694c2ea0b:101105131c0:-23bf' SESSIONNAME = `Console' SHLVL = `3' SSH_AGENT_PID = `3304' SSH_AUTH_SOCK = `/tmp/ssh-GAHQJz3256/agent.3256' SWUTVER = `1.0.18.30716' SYSTEMDRIVE = `C:' SYSTEMROOT = `C:\WINDOWS' TEMP = `c:\DOCUME~1\Lev\LOCALS~1\Temp' TERM = `xterm' TERMCAP = `xterm-r6|xterm|xterm X11R6 version:am:km:mi:ms:xn:co#80:it#8:li#24:AL=\E[%dL:DC=\E[%dP:DL=\E[%dM:DO=\E[%dB:LE=\E[%dD:RI=\E[%dC:UP=\E[%dA:ae=^O:al=\E[L:as=^N:bl=^G:cd=\E[J:ce=\E[K:cl=\E[H\E[2J:cm=\E[%i%d;%dH:cr=^M:cs=\E[%i%d;%dr:ct=\E[3g:dc=\E[P:dl=\E[M:do=^J:ei=\E[4l:ho=\E[H:im=\E[4h:is=\E7\E[r\E[m\E[?7h\E[?1;3;4;6l\E[4l\E8\E:k1=\EOP:k2=\EOQ:k3=\EOR:k4=\EOS:k5=\E[15~:k6=\E[17~:k7=\E[18~:k8=\E[19~:k9=\E[20~:kD=\E[3~:kI=\E[2~:kN=\E[6~:kP=\E[5~:kd=\EOB:ke=\E[?1l\E:kh=\E[1~:kl=\EOD:kr=\EOC:ks=\E[?1h\E=:ku=\EOA:le=^H:md=\E[1m:me=\E[m:mr=\E[7m:nd=\E[C:rc=\E8:sc=\E7:se=\E[m:sf=^J:so=\E[7m:sr=\EM:ta=^I:te=\E[2J\E[?47l\E8:ti=\E7\E[?47h:ue=\E[m:up=\E[A:us=\E[4m:kb=\010:' TEXDOCVIEW_dvi = `cygstart %s' TEXDOCVIEW_html = `cygstart %s' TEXDOCVIEW_pdf = `cygstart %s' TEXDOCVIEW_ps = `cygstart %s' TEXDOCVIEW_txt = `cygstart %s' TIMEOUT = `0' TMP = `c:\DOCUME~1\Lev\LOCALS~1\Temp' TOOLPATH = `/C:\Program%20Files\Hewlett-Packard\HP%20Software%20Update\install.htm' UPDATEDIR = `C:\DOCUME~1\Lev\LOCALS~1\Temp\radE4343.tmp' USERDOMAIN = `RAAJSGDH' USERNAME = `Lev' USERPROFILE = `C:\Documents and Settings\Lev' VERSION = `3.0.2.993' WINDIR = `C:\WINDOWS' WINDOWID = `2097166' XAPPLRESDIR = `/usr/X11R6/lib/X11/app-defaults' XCMSDB = `/usr/X11R6/lib/X11/Xcms.txt' XKEYSYMDB
RE: cd /proc/garbage
There's an interesting interaction with the recent changes to coreutils here, too: $ ln -s /proc/banana ooo $ rm ooo rm: cannot lstat `ooo.exe': No such file or directory Who said anything about ooo.exe, just delete ooo :-) Lev -- 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: Bash Process Substitution
I tried building bash from the source package, and then it uses either /dev/fd (if I have that as a symlink) or /proc/self/fd (if I don't), rather than the fifo that the binary package uses. So perhaps whoever built the binary package didn't have /proc/self/fd for whatever reason? With my built bash.exe, process substitution seems to work for input: $ echo (ls) /proc/self/fd/63 $ cat (echo hi) hi But not for output: $ tar -cf (cat) syntax.c tar: /proc/self/fd/63: Cannot open: Permission denied tar: Error is not recoverable: exiting now I'm not sure how there can be a permissions problem or what to do about it if there really is one, given that as I understand it the /proc/self/fd/63 is effectively a symlink to one end of something returned from pipe(2). Lev -- 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: Bash Process Substitution
Brian Dessent wrote: If I'm not mistaken /proc/pid/fd capabilty was added 2005-02-01. The current bash package (2.05b-16) was released 2003-10-23. (the test version -17 was released 2004-11-22.) So it was quite impossible for the person who built bash to have that feature. Thanks for this piece of info, Brian. It saved me from barking up completely the wrong tree. Things are becoming clearer. I guess what happened is that the binary build of bash used fifos, which have only ever been partially implemented in cygwin, and although at one point in the past they worked well enough for process substitution's needs, in the meantime the implementation has changed sufficiently to break that. The version of bash that I built uses /proc/self/fd, which is a brand spanking new feature that also doesn't quite work in terms of process substitution on output. (Is this all plausible?) Its either that, or process substituion never worked at all on cygwin, my memory is completely flawed, and these nifty scripts I have here were copied from a non-cygwin box. (This is certainly plausible.) Lev -- 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: Bash Process Substitution
Corina wrote: In the Linux kernel there's some magic going on which we can't reproduce in Cygwin so far. Trying to open an existing pipe for writing or reading opens apparently exactly the right end of the pipe under Linux. On Windows, you only get the exact end of the pipe which is already available to the current process. That's the read side of the pipe, AFAICS, and that doesn't allow writing. This explains the Permission denied. Interesting. Looking in function process_substitute in subst.c, I can see that bash tries to swap ends of the pipe depending on whether its a (cmd) or a (cmd) substitution. Lev -- 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: Bash Process Substitution
On Thu, 14 Apr 2005, Lev S Bishop wrote: Corina wrote: ^^ Sorry, 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/
slow xterm startup
This is not a new issue, but at some point in the past year or so, my xterm startup time got much much longer. I never really thought about it until now because I thought I just needed to defrag my hard drive or something, but I've just done a whole bunch of spring cleaning and it's still slow. I'm talking about starting a *local* xterm -- starting one forwarded from a remote machine takes under 2 seconds, even over a slow cablemodem connection. Starting a local xterm takes about 50seconds, if its the first one, during which time it's accessing the HDD continuously. If I start another xterm immediately afterwards then I guess all the files are in the memory cache so it doesn't touch the HDD but still takes about 20seconds. Other X progs don't take anything like so long (xev, xeyes, emacs). It's a 866MHz pentium III, and everything else about Cygwin/X has good performance. I'm not sure whether it happened when I upgraded from cygwin setup, or made some other change to my system. I have, however, tried disabling the windows firewall, and unchecked the enable filesystem realtime protection in norton antivirus (corporate edition, version 7.60.926) and neither of these actions made any difference. As far as I can tell, there are no references to network shares in my path or elsewhere. I think these exhaust the FAQ reasons for poor performance. During the delay while xterm is starting up, windows task manager lists the process xterm.exe as using 97% of the processor time. One thing that may (or may not) be related to the problem is that xterm seems to be linked a lot of times to cygXt-6.dll: $ cygcheck -v /bin/xterm.exe | grep cygXt-6.dll | wc -l 2141 Full cygcheck -v /bin/xterm.exe output is attached to this message. Is it possible that this is the reason? I assume this output of cygcheck -v is similar to what I get from ldd -v on a linux box, which does not have the same level of duplication. Any other ideas of things I might look into? Thanks, Lev Cygwin Configuration Diagnostics Current System Time: Wed Oct 27 21:27:38 2004 Windows XP Home Edition Ver 5.1 Build 2600 Service Pack 2 Path: C:\cygwin\usr\local\bin C:\cygwin\bin C:\cygwin\bin .\ C:\cygwin\bin C:\cygwin\usr\X11R6\bin c:\WINDOWS\system32 c:\WINDOWS c:\WINDOWS\System32\Wbem c:\Program Files\ProENGINEER Student Edition\bin c:\Program Files\ATI Technologies\ATI Control Panel c:\Tcl\bin c:\MATLABR11\bin c:\Program Files\SSH Communications Security\SSH Secure Shell c:\WINDOWS\System32\ C:\cygwin\bin C:\cygwin\usr\X11R6\bin\ Output from C:\cygwin\bin\id.exe (nontsec) UID: 1007(Lev) GID: 513(None) 513(None) Output from C:\cygwin\bin\id.exe (ntsec) UID: 1007(Lev) GID: 513(None) 0(root) 513(None) 544(Administrators) 545(Users) SysDir: C:\WINDOWS\system32 WinDir: C:\WINDOWS HOME = `C:\cygwin\home\Lev' MAKE_MODE = `unix' PWD = `/home/Lev' USER = `Lev' !EXITCODE = `' ALLUSERSPROFILE = `C:\Documents and Settings\All Users' APPDATA = `C:\Documents and Settings\Lev\Application Data' CLASSPATH = `C:\Program Files\Java\j2re1.4.2_03\lib\ext\QTJava.zip' COMMONPROGRAMFILES = `C:\Program Files\Common Files' COMPUTERNAME = `RAAJSGDH' COMSPEC = `C:\WINDOWS\system32\cmd.exe' CVS_RSH = `/bin/ssh' CYGWIN_ROOT = `\cygwin' DISPLAY = `127.0.0.1:0.0' FP_NO_HOST_CHECK = `NO' HOMEDRIVE = `C:' HOMEPATH = `\Documents and Settings\Lev' HOSTNAME = `raajsgdh' LOGNAME = `Lev' LOGONSERVER = `\\RAAJSGDH' LS_COLORS = `no=00:fi=00:di=01;34:ln=01;36:pi=40;33:so=01;35:bd=40;33;01:cd=40;33;01:ex=01;33:*~=05;31:*.mtxt=05;31:*.ndx=05;31:*.cmd=01;32:*.exe=01;32:*.com=01;32:*.btm=01;32:*.bat=01;32:*.c=01;36:*.h=01;36:*.pl=01;36:*.pm=01;36:*.cgi=01;36:*.java=01;36:*.html=01;36:*.tar=01;31:*.tgz=01;31:*.gz=01;31:*.tgz=01;31:*.bz2=01;31:*.arj=01;31:*.taz=01;31:*.lzh=01;31:*.zip=01;31:*.z=01;31:*.Z=01;31:*.gz=01;31:*.jpg=01;35:*.jpeg=01;35:*.JPG=01;35:*.gif=01;35:*.GIF=01;35:*.bmp=01;35:*.BMP=01;35:*.xbm=01;35:*.ppm=01;35:*.xpm=01;35:*.tif=01;35:' MANPATH = `:/usr/ssl/man:/usr/X11R6/man' NUMBER_OF_PROCESSORS = `1' OS = `Windows_NT' PATHEXT = `.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.tcl' PKG_CONFIG_PATH = `/usr/X11R6/lib/pkgconfig' PROCESSOR_ARCHITECTURE = `x86' PROCESSOR_IDENTIFIER = `x86 Family 6 Model 11 Stepping 1, GenuineIntel' PROCESSOR_LEVEL = `6' PROCESSOR_REVISION = `0b01' PROGRAMFILES = `C:\Program Files' PROMPT = `$P$G' PS1 = `\[\033]0;\w\007 [EMAIL PROTECTED] \[\033[33m\w\033[0m\] $ ' PVX_INSTALL_DIR = `C:\Program Files\ProductViewExpress\' QTJAVA = `C:\Program Files\Java\j2re1.4.2_03\lib\ext\QTJava.zip' SESSIONNAME = `Console' SHLVL = `2' SSH_AGENT_PID = `3292' SSH_AUTH_SOCK = `/tmp/ssh-FdwmAe3228/agent.3228' SYSTEMDRIVE = `C:' SYSTEMROOT = `C:\WINDOWS' TEMP = `c:\DOCUME~1\Lev\LOCALS~1\Temp' TERM
Re: slow xterm startup (Problem solved)
Solved my own problem. I ran fc-cache and now xterm kicks off in under a second... I have: dir/cygdrive/c/windows/fonts//dir In my /etc/fonts/local.conf so there's quite a few fonts to scan, which I guess explains the delay. Question: the man page for fontconfig (man fonts-conf) states that ~/.fonts-cache-* is automatically maintained by fontconfig. Does this mean that I don't have to remember to rerun fc-cache when I install new fonts? I still wonder whether its right that xterm is linked over 2000 times to cygXt-6.dll Lev
Icons in 6.7-6
The recent changes from LoadIcon to LoadImage, while technically The Right Thing, have made the default X icon less pretty in the small size (ie in window titles, on the taskbar). I can explain in detail the cause of this if anyone cares. Last night I was toying in my head with a few ideas for extensions to the current icon handling system that would cover this and a few other nitpicky icon prettiness issues in a more general/complete way -- I'll probably have a go at coding those ideas up next weekend if I don't get a chance before. Lev
Re: Icons in 6.7-6
Earle wrote: Sure, I'd like to hear the cause! When you use LoadIcon(), windows keeps track of the original source of the icon, so that if a different sized icon is required, it can go back to that resource/file and load up the appropriate sized icon from there. If you use loadimage, then it keeps no record of the original source, and if a different sized (ie small) icon is required, all it can do is attempt to rescale the loaded version, which generally doesn't work out to be as pretty as an icon specifically designed at that size. Were you planning on sidestepping the issue by making a wrapper around the ICON/IMAGE to keep track of whether you LoadIcon()'d or LoadImaged()'d them, so you know how to get rid of them? No, I was planning on explicitly LoadImage()ing both small and large icons, so that _all_ icons are loaded nicely at large and small sizes, not just the default X. I was also going to extend the xwinrc language to allow explicitly setting the large and small icons should you desire them to be different. I was going to use the system metrics to set WM_ICON_SIZE on the root window properly, just in case any clients actually pay attention to that. And I was going to look at _NET_WM_ICON for clients that adhere to that extended ICCCM standard (gnome and kde stuff). I also stumbled upon the cygwin calls for converting from cygwin paths to Win32 paths, it may make sense to support both path types when specifying from where to load ICONs. PNG icon support would be neat and easy too, but it doesn't look like libpng is standard in the X tree and I wouldn't want to add dependencies... Yeah, I was also toying with adding support for other graphics formats, filtering, porterduff operations, etc, by adding some way to hook into ImageMagick or GraphicsMagick (whichever it is that's supported on cygwin), but I'd have to do it in such a way that *Magick wasn't required if you didn't use those features. Haven't thought that aspect through yet. Maybe I could just program the few features that would actually be relevant to icon processing -- I haven't done any image processing for a while so it might be fun. Extending the xwinrc language should be easy since it's parsed with a yacc grammar. The hardest part of all this will probably be writing the manual Lev
Re: Color support added to HW accelerated cursor
Earle wrote: Anyone who knows any apps that compile under cygwin that use the render cursors, I'd be interested in hearing about them so I can do some coding and testing... Well, emacs compiles under cygwin, but the version distributed with cygwin doesn't use render. But I know for a fact that the version I'm using right now (on a remote machine) does use ARGB cursors so there must be compile-time options to tell emacs to use them. L
Re: Problem with truetype fonts caused by not building FreeType module?
Harold wrote: Now you are getting somewhere... the implication of BuildFreeType NO is that you are going to use the installed version since we set HasFreeType YES, but this does not appear to be the case. We'll either have to fix the build rules or just set BuildFreeType to YES but not actually include it in our distribution, just as we do for Xft. I think you have the wrong idea about FreeType backend. My understanding is that this is one of the modules which implement server-side truetype (the other being X-TrueType, the xtt module - only one of the two is allowed, and X-TrueType is scheduled for demolition in the next release). It's built *around* the FreeType library (which is what we say we have by asserting HasFreeType YES...) but it's not the same thing as having the library. I think all we need to do is set BuildFreeType to yes - the resulting module gets statically linked into libXfont.a (rather than being a loadable module, as it would be in many other X servers, since we don't do loadable modules on cygwin/x), and from there gets linked into XWin.exe and xfs.exe (I understand xfs.exe is currently non-functional, though), and perhaps some other places? I could be wrong about all this but the release notes seem to back me up: http://freedesktop.org/~xorg/X11R6.7.0/doc/RELNOTES6.html#41 Lev
Re: Problem with truetype fonts caused by not building FreeType module?
Harold wrote: Lev S Bishop wrote: - the resulting module gets statically linked into libXfont.a (rather than being a loadable module, as it would be in many other X servers, since we don't do loadable modules on cygwin/x), and from there gets linked into XWin.exe and xfs.exe (I understand xfs.exe is currently non-functional, though), and perhaps some other places? Regarding the static linking, that is not correct. I had noticed recently that XWin.exe was no longer linked to cygfreetype-6.dll (do a 'cygcheck XWin.exe' to find out what DLLs are being linked to) and was wondering what happened. No, I am sure that I am correct about the static linking, but I was not very clear what I was saying. There are *two* things called freetype under discussion. There is the freetype library (the thing that is available from www.freetype.org, is independent of X, and is contained in cygfreetype-6.dll from the package libfreetype26-2.1.5-1) and there is the freetype module (aka FreeType backend, formerly known as xfsft, this is the thing that's part of the x server). From now on I'll call the former freetype the freetype2 library and the latter the freetype backend. The freetype backend deals with making truetype fonts look and feel to the rest of the x server like all other x core fonts, XLFDs, fonts.dir, fonts.alias, etc) but to do the actual rendering it calls upon the freetype2 library. You can think of it as a wrapper for the freetype2 library. There is a version of the freetype2 library in the xc source tree, but we don't want to use it because we prefer to use a seperately installed (more up to date) version, so we set HasFreeType2 YES (typo in my earlier email, missed off the 2 on HasFreeType2). The freetype2 library can be dynamically linked (its cygfreetype6.dll). Following me so far? Now, here's what I was really getting at: the server architecture is such that certain parts of the X server are loadable modules -- whether or not they get loaded into the server is configured *at runtime* by looking in the Module section of the config file (xorg.conf), for lines like 'Load type1' to load the type 1 font rasterizer, etc (this is as opposed to load time dynamic linking, which is what cygcheck tells you about). See: http://freedesktop.org/~xorg/X11R6.7.0/doc/xorg.conf.5.html#sect5 However, cygwin/x doesn't support loadable modules like that (we don't set DoLoadableServer YES, and we don't have a config file to read even if we did) so the freetype backend gets built statically into libXfont.a, and libXfont.a is linked into XWin.exe. So the path is like this for cygwin/x: XWin.exe is linked to libXfont.a, which includes the freetype backend, which depends on the freetype2 library. So the ultimate situation is that XWin.exe is statically linked to the freetype backend but dynamically linked to the freetype2 library. (With recent builds, the situation was: XWin.exe is linked to libXfont.a, which doesn't include the freetype backend, so nothing in XWin.exe depends on the freetype2 library, so cygcheck on XWin.exe doesn't report cygfreetype6.dll). Whether or not we use the freetype backend is controlled by the build switch: BuildFreeType (note capitalization). The freetype2 library is controlled by the switch HasFreetype2. We already have HasFreetype2 YES, but we need to add BuildFreeType YES. The switches control the building of completely orthogonal branches of the source tree. I hope that was clear? Harold: you mentioned something about BuildFontconfig. There is no such switch. There is only a switch BuildFontconfigLibrary. This gets its default (correctly) due to our setting HasFontconfig YES. You don't need to change anything here. Anyway, we're talking about server-side fonts here, which don't use fontconfig. The client-side font mechanism does use fontconfig, and that side of things is working perfectly right now -- no need to mess about with that. Lev
Re: Problem with truetype fonts caused by not building FreeType module?
Harold wrote: What more do you want? You must not have read the end of my last message very clearly. I just didn't want you to do a complete rebuild with the wrong flags and break something that worked before or waste your time any more than needed. Just trying to spell everything out as precisely and clearly as I can, because I find it very confusing and I have to be really careful what I say or I end up tripping over myself with multiple meanings for freetype. I find build systems confusing at the best of times, and whoever decided to change the name from xfsft to freetype has a twisted sense of humour :-) Sorry if it came accross as pedantic or patronizing. I can tell you if I tried to discuss this in real time on IRC I'd be utterly incomprehensible. Lev
