src/winsup/mingw ChangeLog mingwex/getopt.c
CVSROOT:/cvs/src Module name:src Changes by: keithmarsh...@sourceware.org2011-05-31 20:24:51 Modified files: winsup/mingw : ChangeLog winsup/mingw/mingwex: getopt.c Log message: Correct checking for short option matches in getopt_long_only(). Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/mingw/ChangeLog.diff?cvsroot=srcr1=1.477r2=1.478 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/mingw/mingwex/getopt.c.diff?cvsroot=srcr1=1.9r2=1.10
winsup/cygwin ChangeLog select.cc
CVSROOT:/cvs/uberbaum Module name:winsup Changes by: c...@sourceware.org 2011-06-01 00:57:49 Modified files: cygwin : ChangeLog select.cc Log message: * select.cc (pipe_data_available): New function - uses NtQueryInformationFile to return information about pipes. (peek_pipe): Rewrite to use pipe_data_available for both read and write tests. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/winsup/cygwin/ChangeLog.diff?cvsroot=uberbaumr1=1.5390r2=1.5391 http://sourceware.org/cgi-bin/cvsweb.cgi/winsup/cygwin/select.cc.diff?cvsroot=uberbaumr1=1.171r2=1.172
winsup/cygwin ChangeLog external.cc select.cc
CVSROOT:/cvs/uberbaum Module name:winsup Changes by: c...@sourceware.org 2011-06-01 01:20:28 Modified files: cygwin : ChangeLog external.cc select.cc Log message: * external.cc (fillout_pinfo): Don't truncate ctty if it's 0. * select.cc (pipe_data_available): Avoid printing debug info by default or suffer very large strace files. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/winsup/cygwin/ChangeLog.diff?cvsroot=uberbaumr1=1.5391r2=1.5392 http://sourceware.org/cgi-bin/cvsweb.cgi/winsup/cygwin/external.cc.diff?cvsroot=uberbaumr1=1.122r2=1.123 http://sourceware.org/cgi-bin/cvsweb.cgi/winsup/cygwin/select.cc.diff?cvsroot=uberbaumr1=1.172r2=1.173
winsup/cygwin ChangeLog exceptions.cc fhandler ...
CVSROOT:/cvs/uberbaum Module name:winsup Changes by: c...@sourceware.org 2011-06-01 01:47:51 Modified files: cygwin : ChangeLog exceptions.cc fhandler_console.cc Log message: * exceptions.cc (ctrl_c_handler): Simplify test for no parent tty. * fhandler_console.cc (fhandler_console::get_tty_stuff): Return NULL if ctty is not tty/console. Improve test for slave tty/pty device. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/winsup/cygwin/ChangeLog.diff?cvsroot=uberbaumr1=1.5392r2=1.5393 http://sourceware.org/cgi-bin/cvsweb.cgi/winsup/cygwin/exceptions.cc.diff?cvsroot=uberbaumr1=1.353r2=1.354 http://sourceware.org/cgi-bin/cvsweb.cgi/winsup/cygwin/fhandler_console.cc.diff?cvsroot=uberbaumr1=1.232r2=1.233
Re: Don't use snapshots until I send all-clear
On Mon, May 30, 2011 at 7:51 PM, Christopher Faylor wrote: Recent snapshots have pipe problems. Please don't use them. cgf I noticed, but I am glad to tell you that the plotting problem with octave doesn't not appear with : Changes by: cgf 2011-05-31 00:26:37 Modified files: cygwin : ChangeLog dtable.cc fhandler.cc fhandler.h pipe.cc Thanks very much Marco -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
iconv capability removed from rsync 3.0.8
Hello, I have noticed that the iconv capability is not activated anymore in rsync 3.0.8, while in rsync 3.0.7 it is. When cally rsync --version, in 3.0.7 iconv is listed in the capabilities section, while in 3.0.8 it appears as 'no iconv'. I use it, so I had to downgrade. Does anybody know why it's beed removed? Thank you. Regards, Fernando -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Missing dependency cmake = libidn
Dear CygWin community, After installing 2.8.4-1 I discovered that is depends on libidn, which was not automatically installed by setup (missing dependency?). When this library was manually installed, I was able to run cmake. $ cmake /usr/bin/cmake.exe: error while loading shared libraries: cygidn-11.dll: cannot open shared object file: No such file or directory -- With best regards, Dmitry -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Making gvim with Make_cyg.mak: /usr/bin/ld: cannot find crt2.o, -lmingw32, -lmoldname, etc.
Hi, I am trying to compile vim 7.3.206 from source on Cygwin, according to the advice on: http://users.skynet.be/antoine.mechelynck/vim/compile.htm but get the following linker failures: ~/vim/build/vim73/src # make -f Make_cyg.mak ARCH=i686 PERL_VER=512 DYNAMIC_PERL=no GUI=yes gcc -O3 -fomit-frame-pointer -freg-struct-return -fno-strength-reduce -DWIN32 -DHAVE_PATHDEF -DFEAT_BIG -DWINVER=0x0400 -D_WIN32_WINNT=0x0400 -DDYNAMIC_GETTEXT -DDYNAMIC_ICONV -DFEAT_MBYTE -DFEAT_MBYTE_IME -DDYNAMIC_IME -DFEAT_CSCOPE -DFEAT_NETBEANS_INTG -DFEAT_GUI_W32 -DFEAT_CLIPBOARD -march=i686 -Iproto -s -mno-cygwin -o gvim.exe gobj/blowfish.o gobj/buffer.o gobj/charset.o gobj/diff.o gobj/digraph.o gobj/edit.o gobj/eval.o gobj/ex_cmds.o gobj/ex_cmds2.o gobj/ex_docmd.o gobj/ex_eval.o gobj/ex_getln.o gobj/fileio.o gobj/fold.o gobj/getchar.o gobj/hardcopy.o gobj/hashtab.o gobj/main.o gobj/mark.o gobj/memfile.o gobj/memline.o gobj/menu.o gobj/message.o gobj/misc1.o gobj/misc2.o gobj/move.o gobj/mbyte.o gobj/normal.o gobj/ops.o gobj/option.o gobj/os_win32.o gobj/os_mswin.o gobj/pathdef.o gobj/popupmnu.o gobj/quickfix.o gobj/regexp.o gobj/screen.o gobj/search.o gobj/sha256.o gobj/spell.o gobj/syntax.o gobj/tag.o gobj/term.o gobj/ui.o gobj/undo.o gobj/version.o gobj/vimrc.o gobj/window.o gobj/if_cscope.o gobj/netbeans.o gobj/gui.o gobj/gui_w32.o gobj/gui_beval.o gobj/os_w32exe.o -luuid -lole32 -lwsock32 -mwindows -lcomctl32 -lversion /usr/bin/ld: cannot find crt2.o: No such file or directory /usr/bin/ld: cannot find -lmingw32 /usr/bin/ld: cannot find -lmoldname /usr/bin/ld: cannot find -lmingwex /usr/bin/ld: cannot find -lmsvcrt /usr/bin/ld: cannot find -lmingw32 /usr/bin/ld: cannot find -lmingw32 /usr/bin/ld: cannot find -lmoldname /usr/bin/ld: cannot find -lmingwex /usr/bin/ld: cannot find -lmsvcrt collect2: ld returned 1 exit status make: *** [gvim.exe] Error 1 These are the files in /usr/lib/mingw: ~/vim/build/vim73/src # ls /usr/lib/mingw CRT_fp10.odllcrt1.o libmingwex.alibmoldname80.a libmsvcr71d.a CRT_fp8.o dllcrt2.o libmingwthrd.a libmoldname80d.a libmsvcr80.a CRT_noglob.o gcrt0.olibmingwthrd_old.a libmoldname90.a libmsvcr80d.a binmode.o libcoldname.a libmoldname.a libmoldname90d.a libmsvcr90.a crt1.olibcrtdll.alibmoldname70.a libmoldnamed.alibmsvcr90d.a crt2.olibgmon.a libmoldname70d.alibmsvcr70.a libmsvcrt.a crtmt.o libm.a libmoldname71.a libmsvcr70d.a libmsvcrtd.a crtst.o libmingw32.a libmoldname71d.alibmsvcr71.a txtmode.o How should I change the make command line to so that these files libraries are found? I tried setting LD_LIBRARY_PATH: # LD_LIBRARY_PATH=/usr/lib/mingw make -f Make_cyg.mak ARCH=i686 PERL_VER=512 DYNAMIC_PERL=no GUI=yes No difference. The file Make_cyg.mak uses EXTRA_LIBS, so I tried setting that following the comment in the file: # USEDLLno or yes: set to yes to use the Runtime library DLL (no) # For USEDLL=yes the cygwin1.dll is required to run Vim. # no does not work with latest version of Cygwin, use # Make_ming.mak instead. Or set CC to gcc-3 and add # -L/lib/w32api to EXTRA_LIBS. # EXTRA_LIBS=-L/usr/lib/w32api make -f Make_cyg.mak ARCH=i686 PERL_VER=512 DYNAMIC_PERL=no GUI=yes USEDLL=yes But this fails with trace starting: gcc -O3 -fomit-frame-pointer -freg-struct-return -fno-strength-reduce -DWIN32 -DHAVE_PATHDEF -DFEAT_BIG -DWINVER=0x0400 -D_WIN32_WINNT=0x0400 -DDYNAMIC_GETTEXT -DDYNAMIC_ICONV -DFEAT_MBYTE -DFEAT_MBYTE_IME -DDYNAMIC_IME -D_MAX_PATH=256 -D__CYGWIN__ -DFEAT_CSCOPE -DFEAT_NETBEANS_INTG -DFEAT_GUI_W32 -DFEAT_CLIPBOARD -march=i686 -Iproto -s -o gvim.exe gobj/blowfish.o gobj/buffer.o gobj/charset.o gobj/diff.o gobj/digraph.o gobj/edit.o gobj/eval.o gobj/ex_cmds.o gobj/ex_cmds2.o gobj/ex_docmd.o gobj/ex_eval.o gobj/ex_getln.o gobj/fileio.o gobj/fold.o gobj/getchar.o gobj/hardcopy.o gobj/hashtab.o gobj/main.o gobj/mark.o gobj/memfile.o gobj/memline.o gobj/menu.o gobj/message.o gobj/misc1.o gobj/misc2.o gobj/move.o gobj/mbyte.o gobj/normal.o gobj/ops.o gobj/option.o gobj/os_win32.o gobj/os_mswin.o gobj/pathdef.o gobj/popupmnu.o gobj/quickfix.o gobj/regexp.o gobj/screen.o gobj/search.o gobj/sha256.o gobj/spell.o gobj/syntax.o gobj/tag.o gobj/term.o gobj/ui.o gobj/undo.o gobj/version.o gobj/vimrc.o gobj/window.o gobj/if_cscope.o gobj/netbeans.o gobj/gui.o gobj/gui_w32.o gobj/gui_beval.o gobj/os_w32exe.o -luuid -lole32 -L/usr/lib/w32api -lwsock32 -mwindows -lcomctl32 -lversion gobj/buffer.o:buffer.c:(.text+0x2d7d): undefined reference to `__isctype' gobj/buffer.o:buffer.c:(.text+0x2e7d): undefined reference to `__imp___pctype' gobj/buffer.o:buffer.c:(.text+0x335f): undefined reference to `__flsbuf' gobj/buffer.o:buffer.c:(.text+0x539d): undefined reference to `__isctype' and ending later with: gobj/gui_w32.o:gui_w32.c:(.text+0x67d7):
Re: Making gvim with Make_cyg.mak: /usr/bin/ld: cannot find crt2.o, -lmingw32, -lmoldname, etc.
On Tue, May 31, 2011 at 11:58 AM, Ingram, Clyde clyde.ing...@hp.com wrote: Hi, I am trying to compile vim 7.3.206 from source on Cygwin, according to the advice on: http://users.skynet.be/antoine.mechelynck/vim/compile.htm than you should ask him ;-) but get the following linker failures: ~/vim/build/vim73/src # make -f Make_cyg.mak ARCH=i686 PERL_VER=512 DYNAMIC_PERL=no GUI=yes gcc -O3 -fomit-frame-pointer -freg-struct-return -fno-strength-reduce -DWIN32 -DHAVE_PATHDEF -DFEAT_BIG -DWINVER=0x0400 -D_WIN32_WINNT=0x0400 -DDYNAMIC_GETTEXT -DDYNAMIC_ICONV -DFEAT_MBYTE -DFEAT_MBYTE_IME -DDYNAMIC_IME -DFEAT_CSCOPE -DFEAT_NETBEANS_INTG -DFEAT_GUI_W32 -DFEAT_CLIPBOARD -march=i686 -Iproto -s -mno-cygwin -o gvim.exe gobj/blowfish.o gobj/buffer.o gobj/charset.o gobj/diff.o gobj/digraph.o gobj/edit.o gobj/eval.o gobj/ex_cmds.o gobj/ex_cmds2.o gobj/ex_docmd.o gobj/ex_eval.o gobj/ex_getln.o gobj/fileio.o gobj/fold.o gobj/getchar.o gobj/hardcopy.o gobj/hashtab.o gobj/main.o gobj/mark.o gobj/memfile.o gobj/memline.o gobj/menu.o gobj/message.o gobj/misc1.o gobj/misc2.o gobj/move.o gobj/mbyte.o gobj/normal.o gobj/ops.o gobj/option.o gobj/os_win32.o gobj/os_mswin.o gobj/pathdef.o gobj/popupmnu.o gobj/quickfix.o gobj/regexp.o gobj/screen.o gobj/search.o gobj/sha256.o gobj/spell.o gobj/syntax.o gobj/tag.o gobj/term.o gobj/ui.o gobj/undo.o gobj/version.o gobj/vimrc.o gobj/window.o gobj/if_cscope.o gobj/netbeans.o gobj/gui.o gobj/gui_w32.o gobj/gui_beval.o gobj/os_w32exe.o -luuid -lole32 -lwsock32 -mwindows -lcomctl32 -lversion /usr/bin/ld: cannot find crt2.o: No such file or directory /usr/bin/ld: cannot find -lmingw32 /usr/bin/ld: cannot find -lmoldname /usr/bin/ld: cannot find -lmingwex /usr/bin/ld: cannot find -lmsvcrt /usr/bin/ld: cannot find -lmingw32 /usr/bin/ld: cannot find -lmingw32 /usr/bin/ld: cannot find -lmoldname /usr/bin/ld: cannot find -lmingwex /usr/bin/ld: cannot find -lmsvcrt collect2: ld returned 1 exit status make: *** [gvim.exe] Error 1 see http://cygwin.com/ml/cygwin/2011-05/msg00369.html I'd be grateful for advice on compiling gvim under cygwin to work as a Windows application. As you are building a standalone version of vim, you are a bit off topic here. Regards, Clyde Marco -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: User name in screen caption not displaying with snapshot from 28th
I have these two lines in my .screenr:
backtick 0 0 0 echo $LOGNAME
caption always %{= c}[%0`@%H:%n%f %{w}%t %{r}loadavg: %l %=%{g}%Y-%
m-%d %0c:%s]%{d}
Screen always displayed this until cygwin1-20110520.dll as
[thorsten@hombre:0$loadavg: 0.00 0.00 0.00 2011-05-30 17:20:46]
Starting with cygwin1-20110528.dll it displays as:
[@hombre:0$loadavg: 0.00 0.00 0.00 2011-05-30 17:20:46]
$LOGNAME is nonetheless set
Thorsten, can you confirm that the difference is only due to cygwin1.dll,
and not to a different version of screen?
The reason I ask is that I did just issue a minor update to screen, version
4.0.3-7. The build didn't change AFAIK - I just added some documentation -
but I'd like to be sure.
Thanks,
Andrew.
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: quote needed
' I had an extra one! ;-) -- Andrew DeFaria http://defaria.com If at first you DO succeed, try not to look astonished! -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Don't use snapshots until I send all-clear
On Tue, May 31, 2011 at 08:19:29AM +0200, marco atzeri wrote: On Mon, May 30, 2011 at 7:51 PM, Christopher Faylor wrote: Recent snapshots have pipe problems. Please don't use them. cgf I noticed, but I am glad to tell you that the plotting problem with octave doesn't not appear with : Changes by: cgf 2011-05-31 00:26:37 Modified files: cygwin : ChangeLog dtable.cc fhandler.cc fhandler.h pipe.cc Thanks very much That could be the result of my changes to pipe handling or to Ryan Johnson's rework of dll handling in fork. Either way, that's good news! Oh, and, btw: All clear! cgf -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Don't use snapshots until I send all-clear
On 31/05/2011 10:54 AM, Christopher Faylor wrote: Oh, and, btw: All clear! So cygwin1-20110531.dll.bz2 is good? -Edward -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: mintty font test
On 5/27/2011 1:29 AM, Andy Koppe wrote: On 27 May 2011 06:26, Andy Koppe wrote: On 26 May 2011 16:53, Warren Young wrote: It might be good if this xgraphics file you have were distributed with mintty in the doc directory, so others can repeat the test on their system with other fonts. It's not mintty-specific and it's not documentation, so no. Find it attached though. Forgot to say: the file was created by Thomas Wolff. I think this file, as well as the font-test stuff, would be most accessible if added to the mintty wiki somewhere. http://code.google.com/p/mintty/w/list Obviously, any direct download links in the wiki text (such as img src= / elements like the screenshots here: http://code.google.com/p/mintty/ would require that those files be added to svn under images/ or something. Andy, if you agree but don't want to do it yourself, I can do it if you give me (temporary) privileges...send me a private email for code.google account info. FWIW, the current version of those images (*) are (as of this email) explicitly placed under the CC-BY-SA 3.0 license, as is the web page that aggregates and displays them. (*) except for fonts-consolas-w7.png, which was created by Andy. -- Chuck -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Compiler for building Cygwin
It should probably noted on the website that building Cygwin requires the gcc4 package. For example, here: http://cygwin.com/faq.html#faq.programming.building-cygwin -Edward -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: mintty font test
Am 31.05.2011 17:17, schrieb Charles Wilson: On 5/27/2011 1:29 AM, Andy Koppe wrote: On 27 May 2011 06:26, Andy Koppe wrote: On 26 May 2011 16:53, Warren Young wrote: It might be good if this xgraphics file you have were distributed with mintty in the doc directory, so others can repeat the test on their system with other fonts. It's not mintty-specific and it's not documentation, so no. Find it attached though. Forgot to say: the file was created by Thomas Wolff. I think this file, as well as the font-test stuff, would be most accessible if added to the mintty wiki somewhere. The test file was kind of a hack. For the purpose of proliferation :) I cleaned it up a little bit and will provide the update tomorrow. Thomas -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: iconv capability removed from rsync 3.0.8
On Tue, May 31, 2011 at 11:03:06AM +0200, Fernando Molina Ortiz wrote: I have noticed that the iconv capability is not activated anymore in rsync 3.0.8, while in rsync 3.0.7 it is. When cally rsync --version, in 3.0.7 iconv is listed in the capabilities section, while in 3.0.8 it appears as 'no iconv'. I use it, so I had to downgrade. Does anybody know why it's beed removed? It could be a packaging issue, FWIW building from the sources enables iconv support. Rsync from the repo: $ rsync --help | head rsync version 3.0.8 protocol version 30 Copyright (C) 1996-2011 by Andrew Tridgell, Wayne Davison, and others. Web site: http://rsync.samba.org/ Capabilities: 64-bit files, 64-bit inums, 32-bit timestamps, 64-bit long ints, socketpairs, hardlinks, symlinks, IPv6, batchfiles, inplace, append, ACLs, xattrs, no iconv, symtimes Rsync rebuild from sources: $ ./rsync-3.0.8-1/inst/usr/bin/rsync.exe --help | head rsync version 3.0.8 protocol version 30 Copyright (C) 1996-2011 by Andrew Tridgell, Wayne Davison, and others. Web site: http://rsync.samba.org/ Capabilities: 64-bit files, 64-bit inums, 32-bit timestamps, 64-bit long ints, socketpairs, hardlinks, symlinks, IPv6, batchfiles, inplace, append, ACLs, xattrs, iconv, symtimes -- Huella de clave primaria: AD8F BDC0 5A2C FD5F A179 60E7 F79B AB04 5299 EC56 signature.asc Description: Digital signature
scp Counters seem to freeze
Hello, I'm using cygwin 1.7.7 on a Win2k3 R2 system. When I scp a file from a remote host running RHEL 4.7, e.g.: ... Administrator@sm-i222 /cygdrive/d/somedir scp root@linux_host:/someotherdir/some.file . ... The percentage, transfer amount, rate and transfer times all start out registering in the cygwin console window. The rate seems very low/slow. Then when the transfer reaches somewhere in the amount of 10%, all the counters seem to lock/freeze at their respective rates/amounts. When I open another terminal window on the cygwin system, I see the actual file size increasing in the target directory. Indeed, it looks as if more data had been transferring faster than the counters showed. The link between the two systems is via a 1GB copper switched fabric. That is 1GB NIC's in each system going through 1 GB ports on a Cisco Switch. The scp does appear to complete as the counters will suddenly go to 100% and when I ls -al the ../somedir/some.file on the cygwin host will show the same correct byte counts between the source file and the target file. Is this normal behavior? When I do a linux to linux scp, the counters work correctly. Should I expect this from the cygwin scp? Thanks! Blaine Miller -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Don't use snapshots until I send all-clear
* Edward Lam (Tue, 31 May 2011 10:58:51 -0400) On 31/05/2011 10:54 AM, Christopher Faylor wrote: Oh, and, btw: All clear! So cygwin1-20110531.dll.bz2 is good? It still has the screen issue I reported yesterday and that issue sounds to me suspiciously pipish. So I would say, no. Thorsten -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: User name in screen caption not displaying with snapshot from 28th
* Andrew Schulman (Tue, 31 May 2011 10:20:16 -0400)
I have these two lines in my .screenr:
backtick 0 0 0 echo $LOGNAME
caption always %{= c}[%0`@%H:%n%f %{w}%t %{r}loadavg: %l %=%{g}%Y-%
m-%d %0c:%s]%{d}
Screen always displayed this until cygwin1-20110520.dll as
[thorsten@hombre:0$loadavg: 0.00 0.00 0.00 2011-05-30 17:20:46]
Starting with cygwin1-20110528.dll it displays as:
[@hombre:0$loadavg: 0.00 0.00 0.00 2011-05-30 17:20:46]
$LOGNAME is nonetheless set
Thorsten, can you confirm that the difference is only due to cygwin1.dll,
and not to a different version of screen?
Yes, I can confirm that. It's sounds to me like it maybe connected to
the pipe issue. backtick = The output of such a command is used for
substitution of the %` string escape.
Thorsten
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Why does windows have such probs with dynamically loaded libs?
Christopher Faylor wrote: If you have an application which uses a lot of dlls then best practice for Windows DLLs is to build them with unique load addresses. Barring that you could rebase them with cygwin's rebase or rebaseall utilties. Setting unique base addresses will actually cause your application to load slightly faster whether you use Cygwin or not. Other than the stock answer of poor design, it seems loading a dynamically linked library at run-time shouldn't be a difficult task. 1) find out # of 'segments' and size. 2) allocate space somewhere 'unused' in the address space. (malloc seems to usually work for this) 3) load contents 4) get the symbol(s) needed and add them to the loaded address, and pass that back to the dlopen call for patching it's call tables so future calls can call the libs directly. 5) enjoy. ... So why all these problems with conflicting load addresses? When Cygwin forks, how different is it from linux (other than stock answer of 'alot'), i.e. Does it create a new process and load the same static libs in, then have problems with dynamically loaded libs because they aren't recorded in the static binary? Does cygwin actually copy, or attempt to setup COW pages that are not from static libs? If so, wouldn't that catch dynamically loaded libs? This may be complete insanity, but given the low level of support of MS's own Unix subsystem, I wonder if they might be persuaded (if it was desired) to lend more help or hooks for cygwin to do its magic reliably. It seems like it would be a win for MS -- since many Windows users (not just 'end', but corporate as well) often make use of Cygwin -- you'd think MS might think kindly toward efforts to help Cygwin work well with current versions of windows...but then my name is given as an example in some political dictionaries as an example under 'naïve' ;-/... -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Why does windows have such probs with dynamically loaded libs?
On 05/31/2011 05:18 PM, Linda Walsh wrote: Other than the stock answer of poor design, it seems loading a dynamically linked library at run-time shouldn't be a difficult task. Poor design of Windows, not of cygwin. When Cygwin forks, how different is it from linux (other than stock answer of 'alot'), i.e. Does it create a new process and load the same static libs in, then have problems with dynamically loaded libs because they aren't recorded in the static binary? Windows does _not_ have a native copy-on-write fork operation. Linux does. When Linux forks, it merely needs mark all pages as copy-on-write, then both the parent and the child share the same memory image until one or the other execs and gives up that memory. When cygwin forks, it must manually hand-copy every single page of memory from the parent into the child, including pages that can't normally be copied by user space apps but are instead allocated by Windows (such as dlls). How? By loading the same dlls in the child as in the parent, and _hoping_ that windows loads them at the same address as the parent. Does cygwin actually copy, or attempt to setup COW pages that are not from static libs? If so, wouldn't that catch dynamically loaded libs? Windows doesn't support COW pages between a parent process and its spawned child, at least not in the windows subsystem. And the documentation of the various subsystems lacking to the point that cygwin has no way of reproducing the subsystem setup utilized by Interix for its fork implementation (Interix doesn't have to care about interaction with the windows subsystem). So yes, cygwin really is stuck with copying data, and for the data not directly manageable by user space, cygwin has to go to great lengths to circumvent random behaviors introduced by newer windows versions to try to get dlls loaded into the same location. This may be complete insanity, but given the low level of support of MS's own Unix subsystem, I wonder if they might be persuaded (if it was desired) to lend more help or hooks for cygwin to do its magic reliably. Put yourself in Microsoft's shoes - why would you want to make it easier for free software to replace your proprietary software? Once you answer that question, then you can see why it is unlikely that Cygwin will ever have enough weight to convince MS to make our lives easier. -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: allowed Linux characters (and windows substitutes)...
sweinberger wrote: Since : and \ are not acceptable characters in a Linux path, I had to work around the problem. I don't know where you got this idea, but on linux, you can put : and \ in filenames just fine. Only / and \000 (ASCII NUL) can't be in a _file_name (/, obviously works fine in pathnames). /home uname --kernel-name --hardware-platform /home llg -d C* drwsrwsr-x 4 lw devel4096 May 29 10:38 CPAN-ishtar-build-cache/ drwxrwx--- 65 lw lwgrp4096 Mar 2 2010 C:\Windows/ Note in my C:\Windows dir, that's a real colon and backslash, Not the full-width or presentation forms one has to use to get a similar filename on Windows... Colon: ：U+FE13 (Presentation Form for Vertical Colon) Backslash: ＼U+FF3C (FullWidth Reverse Solidus) There also also 'small colon and small reverse solidus' but I've not used them but they would also appear to work to _display_ a colon and backslash in a windows filename. However, on Linux the 'ascii' versions work just fine. 0x3a(colon) 0x5c(backslash/reverse solidus). Note, : and \ have no special meaning on linux -- so they are not device or directory separators if that was something you needed. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Why does windows have such probs with dynamically loaded libs?
Eric Blake wrote: By loading the same dlls in the child as in the parent, and _hoping_ that windows loads them at the same address as the parent. --- Ah-hah!...that's the main rub. I could see that other pages would have to be copied 'manually', baring some kernel call (probably an undocumented NT call) that would allow for setting up COW pages, but guessed for copy given the thorough level of MS documentation available on such matters. Does cygwin actually copy, or attempt to setup COW pages that are not from static libs? If so, wouldn't that catch dynamically loaded libs? Windows doesn't support COW pages between a parent process and its spawned child, at least not in the windows subsystem. And the documentation of the various subsystems lacking to the point that cygwin has no way of reproducing the subsystem setup utilized by Interix for its fork implementation (Interix doesn't have to care about interaction with the windows subsystem). --- Hmmm...I wonder...do you know if Interix setups COW pages on fork? If so, why in the heck would it perform so much more slowly than cygwin when running the same tasks (shell scripts and such that do lots of little forks) its performance was pretty bad next to cygwin, though that was under XP, and several years back that I tested, so it may have changed). So yes, cygwin really is stuck with copying data, and for the data not directly manageable by user space, cygwin has to go to great lengths to circumvent random behaviors introduced by newer windows versions to try to get dlls loaded into the same location. --- Ahhh...the 'security enhancements!'famous for making everyone's life more difficult...(the major failing of security design -- if it was designed to be 'easier', everyone would use it!) This may be complete insanity, but given the low level of support of MS's own Unix subsystem, I wonder if they might be persuaded (if it was desired) to lend more help or hooks for cygwin to do its magic reliably. Put yourself in Microsoft's shoes - why would you want to make it easier for free software Um note, that may be 'free software', but it is running on top of MS's paid OS. With sufficiently well developed interoperability, I could see MS using cygwin's compat on Windows as a protective force against people switching to linux-desktops, since with good cygwin support, they can have the best of both worlds -- of course there's the possibility that 'Wine' will continue to make marked improvements which could swing things more in the linux direction. But even there, MS could still benefit, in that the often demanded apps run by Wine are MS apps. Once you answer that question, then you can see why it is unlikely that Cygwin will ever have enough weight to convince MS to make our lives easier. --- Maybe MS will try to compete with Google on 'don't be evil'? ;-) Hey, 'it' **could** freeze over The real problem is the 'false lure' of corrupt business models like that used by the record companies -- I'm sure SW companies would love to be able to keep selling the same SW and getting royalties for life+50 (or whatever it is these days)... Who knows -- as the government gets more corrupt and bought out by the corps, this may come to pass... -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: mintty font test
On 31 May 2011 16:17, Charles Wilson wrote: On 5/27/2011 1:29 AM, Andy Koppe wrote: On 27 May 2011 06:26, Andy Koppe wrote: On 26 May 2011 16:53, Warren Young wrote: It might be good if this xgraphics file you have were distributed with mintty in the doc directory, so others can repeat the test on their system with other fonts. It's not mintty-specific and it's not documentation, so no. Find it attached though. Forgot to say: the file was created by Thomas Wolff. I think this file, as well as the font-test stuff, would be most accessible if added to the mintty wiki somewhere. http://code.google.com/p/mintty/w/list Obviously, any direct download links in the wiki text (such as img src= / elements like the screenshots here: http://code.google.com/p/mintty/ would require that those files be added to svn under images/ or something. I'm not keen on doing that. The point remains that this is not mintty-specific, and it's bound to always be somewhat out-of-date and incomplete. I don't want to have to deal with requests to update it for new versions of a font, to add more fonts (for example CJK fonts), or to cover other aspects such as support for different languages or maths symbols. In other words, I think the Terminal Font Chronicler is a sizable project in its own right. I should add an entry about choosing a font to the Tips wiki page though, plugging DejaVu Sans and linking to your review, if you're planning on keeping it at its current location. GDI font linking could be mentioned there as well, which is a Windows font fallback scheme that can be configured in the registry at HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\FontLink\SystemLink. Also, the Character Map utility, which displays all the glyphs in a font. Andy -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
