[ITP] tftp-hpa 5.0
Hi there! As the inetutils' tftpd is too limited for our use cases, I tried packaging tftp-hpa. From tftp-hpa's README: -- This is tftp-hpa, a conglomerate of a number of versions of the BSD TFTP code, changed around to port to a whole collection of operating systems. The goal is to work on any reasonably modern Unix with sockets. The tftp-hpa series is maintained by H. Peter Anvin h...@zytor.com. The latest version of this collection can be found at: ftp://ftp.kernel.org/pub/software/network/tftp/ -- tftp-hpa is a rather common package, available for many Linux distributions, e.g. SUSE ([1]) and Debian ([2]). Please find my packages here: wget -r -np -nH -R index* \ http://h1629194.serverkompetenz.net/tftp-hpa/ This is setup.hint: --- category: Net requires: cygwin sdesc: extended version of the BSD TFTP client and server ldesc: tftp-hpa is an enhanced version of the BSD TFTP client and server. It possesses a number of bugfixes and enhancements over the original. It has been made portable and will work on pretty much any modern Unix variant. --- As this is my first Cygwin package, please let me know if anything could be improved, thx! [1] https://build.opensuse.org/package/files?package=tftpproject=openSUSE%3AFactory [2] http://packages.debian.org/lenny/tftpd-hpa -- Gernot Siemens AG, Corporate Technology, Program Open Source Platforms
Re: [ITP] tftp-hpa 5.0
On 9/30/2010 2:27 AM, Gernot Hillier wrote: As the inetutils' tftpd is too limited for our use cases I'll take a look at your packaging, and give the client/server a few tests -- but it will have to wait until the weekend. The first thing I noted, is that tftp-hpa still installs the server as /usr/sbin/in.tftpd (no .exe). For consistency with the inetutils server it is replacing -- and cygwin standards -- that should be renamed to /usr/sbin/tftpd.exe I'd always intended to retire inetutil's tftpd and tftp in favor of the hpa version, but I haven't had enough 'tuits. Thanks! We'll need to coordinate the release of tftp-hpa with an update to inetutils (removing its tftp*). If possible, it would be nice to split the server and client components into two separate packages (see rsh and rsh-server). I'd also like to move the relevant documentation from /usr/share/doc/Cygwin/inetutils.README to /usr/share/doc/Cygwin/tftp-hpa.README (and /usr/share/doc/Cygwin/tftp-hpa-server.README?) +1. (not that you need votes, since tftp-hpa is already in the distros) -- Chuck cygwin inetutils maintainer
Paste from clipboard can failed (XWin bug)
Hi, From X application, I select some text. I switch on Windows application and I try to paste the text. I do Ctrl-V = nothing happens I do a second Ctrl-V = the text is pasted This problem depends on the X application When a paste occurs, XWin receives a WM_RENDERFORMAT message : (cf. winClipboardWindowProc()) step 1/ XWin try to get the selection in COMPOUND_TEXT format (cf. winProcessXEventsTimeout() calls XConvertSelection(COMPOUND_TEXT )) step 2/ If the owner of the selection (the X app) can't handle COMPOUND_TEXT format, XWin try to get the selection in UTF8_STRING format (cf. winClipboardFlushXEvents(), on receive an SelectionNotify event with event.xselection.property == None, XWin calls XConvertSelection(UTF8_STRING)) step 3/ If the owner of the selection (the X app) can't handle UTF8_STRING format, XWin try to get the selection in XA_STRING format (cf. winClipboardFlushXEvents(), on receive an SelectionNotify event with event.xselection.property == None, XWin calls XConvertSelection(XA_STRING)) But there is a bug in XWin : XWin calls winProcessXEventsTimeout() only twice. If the X app handles only handles XA_STRING format, the step 3 is never invoked ! As the result, XWin can't get paste data and log the message: winClipboardWindowProc - timed out waiting for WIN_XEVENTS_NOTIFY XWin.log with my comment: ... (receive WM_RENDER_FORMAT message) winClipboardWindowProc - WM_RENDER*FORMAT - Hello. (call XConvertSelection(COMPOUND_TEXT )) (first call winProcessXEventsTimeout()) winClipboardFlushXEvents - SelectionNotify winClipboardFlushXEvents - SelectionNotify - ATOM: PRIMARY (receive event.xselection.target == atomCompoundText aka COMPOUND_TEXT) (the X app can't handle COMPOUND_TEXT format) winClipboardFlushXEvents - SelectionNotify - Requesting conversion of CompoundText target. (call XConvertSelection(UTF8_STRING) and return) (second call winProcessXEventsTimeout()) winClipboardFlushXEvents - SelectionNotify winClipboardFlushXEvents - SelectionNotify - ATOM: PRIMARY (receive event.xselection.target == atomUTF8String aka UTF8_STRING) (the X app can't handle UTF8_STRING format) winClipboardFlushXEvents - SelectionNotify - Requesting conversion of UTF8 target. (call XConvertSelection(XA_STRING) and return) (XWin can't get paste data, also it logs an error :) (and reset the clipboard = SetClipboardData (CF_UNICODETEXT, NULL);SetClipboardData (CF_TEXT, NULL);) winClipboardWindowProc - timed out waiting for WIN_XEVENTS_NOTIFY ... Solution 1 : Call a third time the function winProcessXEventsTimeout() (see paste_bug_solution1.patch file attached) but this is not a very elegant solution ... Solution 2 : call winProcessXEventsTimeout() only one time winProcessXEventsTimeout() must process all notification until * time out expired * getting the paste data * error occurred (see paste_bug_solution2.patch file attached) note: the actual timeout is set to 1 second. Greetings, paste_bug_solution1.patch Description: Binary data paste_bug_solution2.patch Description: Binary data -- 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/
[ANNOUNCEMENT] Updated: xorg-server-1.9.0-1 (TEST)
The following packages have been updated in the Cygwin distribution: *** xorg-server-1.9.0-1 *** xorg-server-dmx-1.9.0-1 This package contains XWin and the other X.Org X11 servers. This is the first official release of the xserver 1.9 series. It is currently available as a test release, and will be made stable in approximately one week if no major regressions are reported. In addition to the usual upstream fixes and improvements, this contains the following cygwin-specific changes: * fix a drawing crash, which could occur after moving a window in multiwindow mode, caused by incorrect initialization of composite position data * fix a clipboard-related crash which could occur during XDMCP session startup (thanks to Michel Hummel for the patch) * added Turkish keyboard layout detection * add -displayfd option (experimental), which may be useful in Terminal Server environments, see [1] for a discussion of how and why you might want to use this * various crash fixes for -resize. Also fix -resize from turning itself on in multiwindow mode even when not asked for. -resize will be enabled by default in multiwindow mode after more testing. * enable WGL AIGLX code and -wgl option which has been merged upstream, and various GLX fixes Server-side Hardware Accelerated OpenGL (AIGLX) === This release adds experimental support for hardware accelerated OpenGL rendering in the X server using the native WGL interface. * You need to provide the command line option '-wgl' to the X server to turn on the use of native Windows OpenGL to implement GLX. If you don't use this option, the server will carry on using software rendering. * The currently shipped cygwin mesa libGL is built in such a way that it does not support indirect rendering (rendering takes place on the server), only client-side rendering. ONLY REMOTE CLIENTS FROM UNIX SYSTEMS WILL WORK CURRENTLY. An updated libGL will be made available at some point in the future. * mesa's libGL prefers to use client-side rendering and transfer the image to the server using xlib. To force the use of GLX, so rendering is indirect (takes place on the server), and thus can be accelerated, you must export the environment variable LIBGL_ALWAYS_INDIRECT with a non-zero value before starting the client application. * If you have set things up successfully, 'glxinfo | grep OpenGL' should return something mentioning your graphics card vendor. If it mentions Mesa, you still have software rendering * As before, only multiwindow/mwextwm modes are supported. Software rendering is always used on screens which do not have 1 native window per X window. Removing this restriction requires a way to tell the native OpenGL to transform/clip to the portion of the native window occupied by the X window in the single native window modes. [1] http://cygwin.com/ml/cygwin-xfree/2010-09/msg00040.html -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- 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: [ANNOUNCEMENT] Updated: xorg-server-1.9.0-1 (TEST)
Hi jon, I was surprised to see in the Changelog of this test release : * fix a clipboard-related crash which could occur during XDMCP session startup (thanks to Michel Hummel for the patch) It would be very cool if this version included my patch about xdmcp and clipboard auto-restart but I don't think so, isn't it ? I think this version only includes the patch about : clipboard crash on server reset isn't it ? Thanks for your work, Michel Hummel Le 30/09/2010 17:26, Jon TURNEY a écrit : The following packages have been updated in the Cygwin distribution: *** xorg-server-1.9.0-1 *** xorg-server-dmx-1.9.0-1 This package contains XWin and the other X.Org X11 servers. This is the first official release of the xserver 1.9 series. It is currently available as a test release, and will be made stable in approximately one week if no major regressions are reported. In addition to the usual upstream fixes and improvements, this contains the following cygwin-specific changes: * fix a drawing crash, which could occur after moving a window in multiwindow mode, caused by incorrect initialization of composite position data * fix a clipboard-related crash which could occur during XDMCP session startup (thanks to Michel Hummel for the patch) * added Turkish keyboard layout detection * add -displayfd option (experimental), which may be useful in Terminal Server environments, see [1] for a discussion of how and why you might want to use this * various crash fixes for -resize. Also fix -resize from turning itself on in multiwindow mode even when not asked for. -resize will be enabled by default in multiwindow mode after more testing. * enable WGL AIGLX code and -wgl option which has been merged upstream, and various GLX fixes Server-side Hardware Accelerated OpenGL (AIGLX) === This release adds experimental support for hardware accelerated OpenGL rendering in the X server using the native WGL interface. * You need to provide the command line option '-wgl' to the X server to turn on the use of native Windows OpenGL to implement GLX. If you don't use this option, the server will carry on using software rendering. * The currently shipped cygwin mesa libGL is built in such a way that it does not support indirect rendering (rendering takes place on the server), only client-side rendering. ONLY REMOTE CLIENTS FROM UNIX SYSTEMS WILL WORK CURRENTLY. An updated libGL will be made available at some point in the future. * mesa's libGL prefers to use client-side rendering and transfer the image to the server using xlib. To force the use of GLX, so rendering is indirect (takes place on the server), and thus can be accelerated, you must export the environment variable LIBGL_ALWAYS_INDIRECT with a non-zero value before starting the client application. * If you have set things up successfully, 'glxinfo | grep OpenGL' should return something mentioning your graphics card vendor. If it mentions Mesa, you still have software rendering * As before, only multiwindow/mwextwm modes are supported. Software rendering is always used on screens which do not have 1 native window per X window. Removing this restriction requires a way to tell the native OpenGL to transform/clip to the portion of the native window occupied by the X window in the single native window modes. [1] http://cygwin.com/ml/cygwin-xfree/2010-09/msg00040.html -- 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 path.cc
CVSROOT:/cvs/src Module name:src Changes by: cori...@sourceware.org 2010-09-30 10:42:34 Modified files: winsup/cygwin : ChangeLog path.cc Log message: * path.cc (symlink_info::check): Remove erroneous assumption about required permissions when reading NFS symlinks. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/ChangeLog.diff?cvsroot=srcr1=1.5067r2=1.5068 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/path.cc.diff?cvsroot=srcr1=1.612r2=1.613
src/winsup/cygwin ChangeLog fhandler.cc fhandl ...
CVSROOT:/cvs/src Module name:src Changes by: cori...@sourceware.org 2010-09-30 13:52:35 Modified files: winsup/cygwin : ChangeLog fhandler.cc fhandler_disk_file.cc path.cc path.h Log message: * fhandler.cc: Drop including nfs.h. * fhandler_disk_file.cc: Ditto. (fhandler_base::fstat_by_nfs_ea): Use fattr3 from path_conv member, unless called from fstat. * path.cc: Drop including nfs.h. (symlink_info::check): Rearrange definition of file info buffers. Fetch fattr3 info for files on NFS and store in conv_hdl for later use in fhandler_base::fstat_by_nfs_ea. Use fattr3 file type to recognize symlink on NFS and try to fetch symlink target only for actual symlinks. * path.h: Include nfs.h. (class path_conv_handle): Change file info storage to union of FILE_NETWORK_OPEN_INFORMATION and fattr3 structures. (path_conv_handle::fnoi): Align to aforementioned change. (path_conv_handle::nfsattr): New method. (path_conv::nfsattr): New method. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/ChangeLog.diff?cvsroot=srcr1=1.5068r2=1.5069 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/fhandler.cc.diff?cvsroot=srcr1=1.371r2=1.372 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/fhandler_disk_file.cc.diff?cvsroot=srcr1=1.342r2=1.343 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/path.cc.diff?cvsroot=srcr1=1.613r2=1.614 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/path.h.diff?cvsroot=srcr1=1.149r2=1.150
Re: use the list of files stored in a text file and process it
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 You will also run into problems with xargs and filenames with spaces in. In my experience, the simplest thing that works reliably with xargs and all Windoz filenames is xargs -0, so what you want is tr -s '\012\015' '\000' test.txt | xargs -0 ls Note also that find has a -print0 flag, which goes well with -0 find . -name '[whatever]' ... -print0 | xargs -0 ... ht - -- Henry S. Thompson, School of Informatics, University of Edinburgh 10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440 Fax: (44) 131 651-1426, e-mail: h...@inf.ed.ac.uk URL: http://www.ltg.ed.ac.uk/~ht/ [mail from me _always_ has a .sig like this -- mail without it is forged spam] -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQFMpEHTkjnJixAXWBoRAvcjAJ4uo9c819hzVbbVovyTN8z4+/g2HQCfShCC pFsvAO0QacPuXcIQjsKqWVY= =9ZJi -END PGP SIGNATURE- -- 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
R: Cygwin 1.7.7 fork/exec performance MUCH slower than 1.5.25
--- Gio 30/9/10, SZABÓ Gergely ha scritto: Hello, we have a Cygwin-based build system for an embedded project. Build performance has deteriorated terribly since we upgraded to 1.7.x from 1.5.25. I've created 3 shell-scripts to benchmark 1.5.25 and 1.7.7 against each other. - null : read file inp line by line, write to /dev/null. - builtin : write each line to file out, only bash-builtins used (no fork) - fork : do some substitution for each line with sed (huge number of forks) Results: - null : 1.7.7 is about 5 times faster - builtin : 1.7.7 is slightly faster - fork : 1.7.7 is 5 times SLOWER !!! All measurements were made with the time command. The attached results.txt lists the real times. I've also attached the 3 shell-scripts (null, builtin, fork). Input file inp is also attached. Also see the cygcheck_xxx.out files for both Cygwin versions. Some notes: both cygwin versions use the same /home, mounted from D:\Documents and Settings, I bet is a network/acl issues. I suggest to create a real home on /home so all user-level config-files are shared between the Cygwin versions. Cygwin 1.7.7 is basically unusable at the moment. Any ideas why it's so much slower at spawning processes? Or is it the pipes? Am I doing something wrong? And more importantly: is there an easy way to fix this? Thanks in advance for any help! Best regards Gergely Szabó testing on /tmp/benchmark with XPS P2 cygwin 1.7.8s 20100924 $ time ./fork real1m12.856s user0m52.480s sys 1m6.423s cygwin 1.5.25-15 $ time ./fork real1m7.969s user0m52.992s sys 1m11.583s So no difference 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: R: Cygwin 1.7.7 fork/exec performance MUCH slower than 1.5.25
testing on /tmp/benchmark with XPS P2 cygwin 1.7.8s 20100924 You're testing on the latest snapshot against his cygwin 1.7.7 results. This gives me hope that Cygwin can become faster because Sagi Ben-Akiva was willing to track down the cause of the slowdown [1]. Last I read, it's not clear whether the latest CVS changes are faster though [2]. However, it's probably worth trying out the 20100926 snapshot. We haven't mentioned yet whether we are running under 32-bit or 64-bit Windows. It would be useful to know whether the problem only affects 64-bit Windows or not. Looking at the code changes, I would have thought it would equally affect 32-bit Windows. 1. http://cygwin.com/ml/cygwin/2010-08/msg00964.html 2. http://cygwin.com/ml/cygwin/2010-09/msg00796.html Regards, -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: use the list of files stored in a text file and process it
albert kao wrote: I store a list of files in a text file (test.txt) on Windows XP. I want to use the list of files and process it (e.g. ls). What is the command to do that? I tried the following commands but to no avail. $ cat test.txt test.txt $ cat test.txt | xargs ls : No such file or directory $ cat test.txt | xargs -delimiter=\n ls xargs: Invalid input delimiter specification elimiter=\n: the delimiter must be either a single char acter or an escape sequence starting with \. $ cat test.txt | xargs -delimiter='\n' ls xargs: Invalid input delimiter specification elimiter=\n: the delimiter must be either a single char acter or an escape sequence starting with \. $ cat test.txt | xargs -delimiter='\\n' ls xargs: Invalid input delimiter specification elimiter=\\n: the delimiter must be either a single cha racter or an escape sequence starting with \. $ cat test.txt | xargs -delimiter=\\n ls xargs: Invalid input delimiter specification elimiter=\n: the delimiter must be either a single char acter or an escape sequence starting with \. $ uname -srv CYGWIN_NT-5.1 1.7.5(0.225/5/3) 2010-04-12 19:07 -- 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 I would also suggest that you check your filenames in test.txt to make sure, if you included paths, that they are absolute and follow the Cygwin virtual-paths (cygpath) syntax, i.e.: /cygdrive/c/... or /etc/share/... and so on. Barring that, a path in Unix notation relative to your $PWD -- or the directory where test.txt is saved -- is a good starting point (npi): something along the lines of bin/deprecated or ../man1 . I know one of the trip-ups I often have if I spend any time away from a L/Unix environment has to do with the mv command: I often forget that it prefers absolute paths from root folders (or in the case of Cygwin, virtual ones taken as real) or dot-dot-slash relative path syntax to just /god-directory/ or what-have-you. Many other commands, particularly ls and ln -s, are likewise particular about their paths. Steve W. -- 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
gcc-4.5 + gdb dwarf problems
Hi
I think I've found an issue with the new gcc-4.5 with latest gdb.
I only experience these problems in the gdb debugger, when the
sourceline for the function is wrong,
but inspecting the dwarf output, esp the line info via objdump -Wl looks good.
objdump -Sgl also looks good.
objdump: The path of the source files resolves to something wrong in
objdump -Wl.
gdb: If linked with a library as dll (cygperl.dll in my case) the
arguments are not displayed in the debugger,
if linked to a static .a or .o, the arguments are displayed okay.
E.g. debugging perl linked to the static libperl.a like
gcc-4 -DPERL_USE_SAFE_PUTENV -U__STRICT_ANSI__ -march=pentium4
-mfpmath=sse -mieee-fp -mmmx -msse -msse2 -DDEBUGGING
-fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include
-I/usr/lib/perl5/5.13.5/i686-nothreads-debug-cygwin/CORE -g3
ccode27_o2.c -o ccode27_o2-Wl,--enable-auto-import
-Wl,--export-all-symbols -Wl,--stack,8388608
-Wl,--enable-auto-image-base -fstack-protector -L/usr/local/lib
/usr/lib/perl5/5.13.5/i686-nothreads-debug-cygwin/auto/Win32CORE/Win32CORE.a
/usr/lib/perl5/5.13.5/i686-nothreads-debug-cygwin/CORE/libperl.a
/usr/lib/perl5/5.13.5/i686-nothreads-debug-cygwin/CORE/DynaLoader.a
-ldl -lcrypt
=
objdump -WL -S -gl ccode27_o2.exe|less
CU: /usr/lib/perl5/5.13.5/i686-nothreads-debug-cygwin/CORE/ccode27_o2.c:
but the /ccode27_o2.c is in ./, the line info is correct here. I can
debug into it fine.
next obj is
CU: /usr/include/sys/gv.c:
File nameLine numberStarting address
gv.c 450x406f98
And this is in /usr/lib/perl5/5.13.5/i686-nothreads-debug-cygwin/CORE/
not in /usr/include/sys/
$ gdb ccode27_o2.exe
GNU gdb 6.8.0.20080328-cvs (cygwin-special)
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type show copying
and show warranty for details.
This GDB was configured as i686-pc-cygwin...
(gdb) run
Starting program: /cygdrive/d/data/urbanr/My
Documents/Perl/B-C-work/ccode27_o2.exe
[New thread 1988.0x116c]
[New thread 1988.0x1358]
ok
Program received signal SIGSEGV, Segmentation fault.
0x0068391b in Perl_pad_undef (cv=0x24a3d60) at pad.c:138
138 PERL_ARGS_ASSERT_PAD_PEG;
If linked to the dll the cv argument is missing.
And the correct src line is pad.c:256, not pad.c:138
objdump -S -gl ccode27_o2.exe|^egrep -7 ^Perl_pad_undef
00683785 _Perl_pad_undef:
Perl_pad_undef():
/usr/src/perl/blead/buildntdebug/pad.c:256
=cut
*/
void
Perl_pad_undef(pTHX_ CV* cv)
{
--
Reini Urban
http://phpwiki.org/ http://murbreak.at/
--
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: use the list of files stored in a text file and process it
On 9/30/2010 9:37 AM, SJ Wright wrote: I know one of the trip-ups I often have if I spend any time away from a L/Unix environment has to do with the mv command: I often forget that it prefers absolute paths from root folders (or in the case of Cygwin, virtual ones taken as real) or dot-dot-slash relative path syntax to just /god-directory/ or what-have-you. Many other commands, particularly ls and ln -s, are likewise particular about their paths. That's a sweeping statement without any supporting data. I guess all I can say is that my experience doesn't coincide with your statements. -- 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? -- 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: R: Cygwin 1.7.7 fork/exec performance MUCH slower than 1.5.25
On Thu, Sep 30, 2010 at 09:10:48AM -0400, Edward Lam wrote: testing on /tmp/benchmark with XPS P2 cygwin 1.7.8s 20100924 You're testing on the latest snapshot against his cygwin 1.7.7 results. This gives me hope that Cygwin can become faster because Sagi Ben-Akiva was willing to track down the cause of the slowdown [1]. Last I read, it's not clear whether the latest CVS changes are faster though [2]. However, it's probably worth trying out the 20100926 snapshot. We haven't mentioned yet whether we are running under 32-bit or 64-bit Windows. It would be useful to know whether the problem only affects 64-bit Windows or not. Looking at the code changes, I would have thought it would equally affect 32-bit Windows. 32-bit Windows is basically unchanged. -- 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: gcc-4.5 + gdb dwarf problems
2010/9/30 Reini Urban: I think I've found an issue with the new gcc-4.5 with latest gdb. Program received signal SIGSEGV, Segmentation fault. 0x0068391b in Perl_pad_undef (cv=0x24a3d60) at pad.c:138 138 PERL_ARGS_ASSERT_PAD_PEG; If linked to the dll the cv argument is missing. And the correct src line is pad.c:256, not pad.c:138 objdump -S -gl ccode27_o2.exe|^egrep -7 ^Perl_pad_undef I've crosschecked with mingw gdb-7.1 and the linenumber looks better there. Just the arguments for functions inside the dll are also not displayed: Program received signal SIGSEGV, Segmentation fault. 0x54a4d00b in Perl_pad_undef () from D:\cygwin\usr\local\bin\cygperl5_13_5d...@1fdb04e0.dll vs. Program received signal SIGSEGV, Segmentation fault. 0x00552f6b in Perl_pad_undef (cv=0x2323d60) at pad.c:290 290 *SvPVX_const(namesv) == '') -- Reini Urban http://phpwiki.org/ http://murbreak.at/ -- 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
does the `notexec' mount option influence file access performance on a server?
Hello, I have the following /etc/fstab entry //server/mirko/ /z dont_care binary,posix=0,user,noacl,notexec 0 0 for a server directory where I store my backups. I will not be using any of those files as executables. I have cygwin running on my desktop. The manual states that the `exec' option avoids the overhead of opening each file to determine whether it is an executable or not. Will the notexec option also improve reduce the overhead? Thanks, Mirko -- 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: error: unable to remap - despite repeated rebaseall
2010/9/29 Mike Slass: The system: Windows Server 2008 x86_64 perl, v5.10.1 (*) built for i686-cygwin-thread-multi-64int (with 12 registered patches, see perl -V for more detail) cygwin-1.7 The error: 5 [main] perl 19364 fork: child 19100 - died waiting for dll loading, errno 11 5071704 [main] perl 18988 C:\bin\perl.exe: *** fatal error - unable to remap \\?\C:\lib\perl5\site_perl\5.10\i686-cygwin\auto\P4\P4.dll to same address as parent: 0xA7 != 0x143 Stack trace: Frame Function Args 0088B458 610274AB (0088B458, , , ) 0088B748 610274AB (61177840, 8000, , 61178977) 0088C778 61004ADB (611A034C, 6123E3D4, 00A7, 0143) End of stack trace Additional background: P4.dll is part of a perl extension library for Perforce, p4perl. I built the perl library from source, but it links with some pre-compiled libraries that come from Perforce. Those libraries *were* built for cygwin. The P4.pm perl extension would not build with gcc 4, so when I built it I used g++-3 for the compiler and linker. I have tried running rebaseall several times, all successfully. I have provided an additional filelist to rebaseall (with -T) to make sure that the P4.dll was included in the rebaseing, since the P4.dll was not installed by cygwin, so is not listed as an installed file. Any suggestions? Sure, perlrebase (now also with man page) And if P4 depends on new dll's which are not under /usr/lib/perl/*/auto than you'll have to add your new dll's also to the intermediate rebase.lst which perlrebase creates for you in the current dir, and use rebase with -T rebase.lst rebaseall just rebases official cygwin package dll's, not any user dll's. -- Reini Urban -- 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: diff issue
Greetings, All! I have strange (to me) issue that I'm not entirely sure how to interpret. Let's say I have two versions of the same batch file: The old version from CVS: rem $Id: backup.bat,v 1.1 2007/07/17 01:53:30 Daemon Exp $ rar a -ag--MM-DD_HH-MM -- MinerTimer @MinerTimer.list The new version I've imported to Subversion: @echo off rem $Id: backup.bat 10 2010-09-30 01:22:14Z anrdaemon $ rar a -ag--MM-DD_HH-MM -- MinerTimer @MinerTimer.list When I'm comparing them with my usual macro diff -bdu -x CVS -x .svn -I \$Id.*\$ -I \$Revision.*\$ -I \$Date.*\$ -I \$Author.*\$ --strip-trailing-cr -- '1/backup.bat' 'backup.bat' It telling me that $Id$ lines are differ. But when I remove the @echo off from second file, it telling me that files are identical (the expected result). Having hard times dechiphering man diff, so if anyone can enlighten me in simple words on the matter, I'd appreciate help greatly. -- WBR, Andrey Repin 30.09.2010, 5:33 Sorry for my terrible english... Be sure the end of line characters are correct on the @echo line. You should be able to do this with a cat -vTE command. (sorry for my terrible Russian) #1059;#1073;#1077;#1076;#1080;#1090;#1077;#1089;#1100;, #1095;#1090;#1086; #1082;#1086;#1085;#1077;#1094; #1089;#1090;#1088;#1086;#1082;#1080; #1089;#1080;#1084;#1074;#1086;#1083;#1099; #1087;#1088;#1072;#1074;#1080;#1083;#1100;#1085;#1086; #1085;#1072; @echo #1083;#1080;#1085;#1080;#1080;. #1042;#1099; #1076;#1086;#1083;#1078;#1085;#1099; #1073;#1099;#1090;#1100; #1074; #1089;#1086;#1089;#1090;#1086;#1103;#1085;#1080;#1080; #1089;#1076;#1077;#1083;#1072;#1090;#1100; #1101;#1090;#1086; #1089; #1087;#1086;#1084;#1086;#1097;#1100;#1102; cat -vTE #1082;#1086;#1084;#1072;#1085;#1076;#1099;. (#1048;#1079;#1074;#1080;#1085;#1080;#1090;#1077; #1079;#1072; #1084;#1086;#1081; #1091;#1078;#1072;#1089;#1085;#1099;#1081; #1088;#1091;#1089;#1089;#1082;#1080;#1081;) Sincerely, Brian S. Wilson -- 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: use the list of files stored in a text file and process it
I store a list of files in a text file (test.txt) on Windows XP.
I want to use the list of files and process it (e.g. ls).
What is the command to do that?
I tried the following commands but to no avail.
$ cat test.txt
test.txt
$ cat test.txt | xargs ls
: No such file or directory
snip...
Try something like cat test.txt | xargs -i ls {} or cat test.txt | xargs -t
ls I suspect the first one will work for you and the second one will show you
the command line before running the command (to help you debug in future).
Sincerely,
Brian S. Wilson
--
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
CYGWIN=noglob remove double quotes from args.
As I understand docs if I set CYGWIN=noglob then command line arguments passed to Cygwin app WITHOUT changes. I use native Emacs build so worry about stop Cygwin damage passed arguments. And seems this is not true. With CYGWIN=noglob all double quotes removed from args! Originally I discaver this when I call Cygwin application from NT Emacs by: (call-process bash nil t nil -c echo \ab\ ) I get: a b (ONE space!) I wrote simple app that print its args quoted: (call-process printarg nil t nil -c echo \a b\) /cygdrive/d/home/usr/bin/printarg -c echo ab If compile printarg.c with MSVC all quotes printed: (call-process printarg nil t nil -c echo \a b\) /cygdrive/d/home/usr/bin/printarg -c echo ab Same happen with cmd.exe: cmd# printarg-msvc a \ b printarg-msvc.exe a b cmd# set CYGWIN=glob cmd# printarg-cygwin a \ b printarg a b cmd# set CYGWIN=noglob cmd# printarg-cygwin a \ b printarg a \ b -- 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
bash bug?: nested bash --login -i doesn't run /etc/profile (still runs ~/.bash_profile)
The behavior of bash --login -i seems to vary depending on whether it is a root invocation or a nested invocation of bash. This is inconsistent with the description man bash, and seems to be a bug. Details: When bash is started using the Cygwin shortcut (which runs cygwin.bat, which executes bash --login -i), bash reads files /etc/profile and ~/.bash_profile. (Running bash --login -i from an interactive cmd shell does the same.) However, when in that first bash process, another bash is started with that same bash --login -i command, bash does _not_ read /etc/profile. Interestingly, that nested bash shell _does_ still read ~/.bash_profile. According to the bash manual page, bash --login -i should read /etc/profile in either case. (There is no mention of anything, e.g., an environment variable from the context of the invocation, that changes the behavior of that command.) An additional symptom is that the nested bash does not listen to SHELLOPTS as expected: A root invocation notices igncr, verbose, and xtrace in the SHELLOPTS value from its invocation environment (the Windows/cmd environment variable) as specified--it ends up setting SHELLOPTS in itself to a value that includes those options. On the other hand, a nested invocation seems to ignore the SHELLOPTS from its invocation environment (the environment variable from the first bash shell/process)--it sets its SHELLOPTS to a value that does _not_ include those options.) Steps to reproduce (and easily see difference): 1. Set Windows environment variable SHELLOPTS to igncr:verbose:xtrace. 2. Start bash using the installer-created Cygwin shortcut. 3. Notice (from the output from the verbose and xtrace options) that bash runs /etc/profile and then ~/.bash_profile. 4. Notice (from set) that SHELLOPTS in bash includes igncr, verbose and xtrace (among other options). 5. Execute bash --login -i. 6. Notice (again, from the verbose/xtrace output) that bash does _not_ run /etc/profile, but still runs ~/.bash_profile. 7. Notice that SHELLOPTS in that invocation of bash does not include igncr, verbose or xtrace. It seems that something is going wrong between the points at which bash reads SHELLOPTS and runs /etc/profile and the point at which bash runs ~/.bash_profile. Daniel (user name - username) (Windows/DNS domain name - somedomain) Cygwin Configuration Diagnostics Current System Time: Thu Sep 30 13:21:26 2010 Windows XP Professional Ver 5.1 Build 2600 Service Pack 3 Path: C:\tools\cygwin\usr\local\bin C:\tools\cygwin\bin C:\tools\cygwin\bin C:\Username\bin C:\tools\jdk1.6.0_21\bin C:\tools\apache-ant-1.7.1\bin C:\tools\emacs-23.2\bin C:\WINDOWS\system32 C:\WINDOWS C:\WINDOWS\System32\Wbem C:\WINDOWS\system32\WindowsPowerShell\v1.0 C:\Program Files\Microsoft SQL Server\80\Tools\Binn\ C:\tools\cygwin\bin Output from C:\tools\cygwin\bin\id.exe UID: 12734(username) GID: 10513(Domain Users) 10513(Domain Users) 0(root) 544(Administrators) 545(Users) SysDir: C:\WINDOWS\system32 WinDir: C:\WINDOWS USER = 'username' PWD = '/c/Username' HOME = '/c/Username' HOMEPATH = '\Documents and Settings\username' MANPATH = '/usr/local/man:/usr/share/man:/usr/man:' APPDATA = 'C:\Documents and Settings\username\Application Data' HOSTNAME = 'november' TERM = 'cygwin' PROCESSOR_IDENTIFIER = 'x86 Family 15 Model 4 Stepping 1, GenuineIntel' HISTSIZE = '5000' WINDIR = 'C:\WINDOWS' IGNOREEOF = '10' OLDPWD = '/usr/bin' USERDOMAIN = 'SOMEDOMAIN_MAIN' OS = 'Windows_NT' ALLUSERSPROFILE = 'C:\Documents and Settings\All Users' ANT_HOME = 'C:\tools\apache-ant-1.7.1' HISTFILESIZE = '5000' TEMP = '/c/DOCUME~1/username/LOCALS~1/Temp' COMMONPROGRAMFILES = 'C:\Program Files\Common Files' CYGWIN_BIN = 'C:\tools\cygwin\bin' USERNAME = 'username' PROCESSOR_LEVEL = '15' PSModulePath = 'C:\WINDOWS\system32\WindowsPowerShell\v1.0\Modules\' SHELLOPTS = 'braceexpand:emacs:hashall:histexpand:history:ignoreeof:interactive-comments:monitor:verbose:xtrace' FP_NO_HOST_CHECK = 'NO' SYSTEMDRIVE = 'C:' JAVA_HOME = 'C:\tools\jdk1.6.0_21' LANG = 'C.UTF-8' USERPROFILE = 'C:\Documents and Settings\username' CLIENTNAME = 'Console' PS1 = '\[\e]0;\w\a\]\n\[\e[32m\...@\h \[\e[33m\]\w\[\e[0m\]\n\$ ' LOGONSERVER = '\\VA-DC01' PROCESSOR_ARCHITECTURE = 'x86' !C: = 'C:\tools\cygwin\bin' DSB_PROFILES_SOURCED = 't' SHLVL = '1' USERDNSDOMAIN = 'SOMEDOMAIN.COM' PATHEXT = '.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.PSC1' HOMEDRIVE = 'C:' ANT_ARGS = '-emacs -find build.xml' PROMPT = '$P$G' COMSPEC = 'C:\WINDOWS\system32\cmd.exe' TMP = '/c/DOCUME~1/username/LOCALS~1/Temp' SYSTEMROOT = 'C:\WINDOWS' USERNAME_BIN = 'C:\Username\bin' PRINTER = '\\VA-FS05\HP4200DTN' CVS_RSH = '/bin/ssh' PROCESSOR_REVISION = '0401' INFOPATH = '/usr/local/info:/usr/share/info:/usr/info:' PROGRAMFILES = 'C:\Program Files' NUMBER_OF_PROCESSORS = '2' SESSIONNAME = 'Console'
Need Cygwin maintainer for Icarus Verilog and GTKWave
I am one of the Icarus Verilog developers and I'm looking for someone to be the maintainer for both Icarus Verilog and GTKWave. I regularly compile both of these under cygwin so they should already compile out of the box. What I don't have time for is to monitor the main cygwin list looking for user problems. Icarus Verilog is a logic simulator that implement most of the hardware description language Verilog (IEEE std 1364-2005). GTKWave is a waveform viewer that supports many different waveform formats. The ideal maintainer would have some familiarity with Verilog, but I would not consider that a requirement. Both tools are available from various Linux distributions. There are currently MinGW compiled binaries available. For portability and speed reasons these are the projects preferred Windows solution, but having them available from setup would be useful to Cygwin user working on smaller projects where the speed difference is not a concern. The Cygwin version also produces results that exactly match what is produced under Linux.They probably belong with ngspice in the Science category. I'm willing to provide help as needed. Regards, Cary R. -- 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 window won't open
On 29 September 2010 09:49, Bengt-Arne Fjellner wrote: I think you can detect this situation (no access to the interactive desktop or whatever is it called), if you wished to issue a suitable error message, by checking that OpenInputDesktop() returns non-NULL... Good idea, and that does seem to do the job. Opening a window in that situation seems to work fine anyway though. I guess it goes to some hidden desktop. Can anyone think of a sensible use case for that, i.e. should I make this a warning rather than an error? I have a feeling it could be useful someway. Why not a command switch: --allow_null_desktop or something? Because there's a good chance that no-one would ever need it. ;) I'll make this a warning (or possibly just leave it). 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
complex.h for Cygwin?
After doing some web searches for complex.h and Cygwin, I found there doesn't seem to be any support unless I use: gcc -I/usr/include/mingw -lm tc.c But I still end up with: /cygdrive/c/DOCUME~1/JOHNC~1.ECS/LOCALS~1/Temp/ccAPGnIv.o:tc.c:(.text+0x3d): undefined reference to `_ccos' collect2: ld returned 1 exit status I'm really not interested in working with MinGW either. All the messages about complex.h and Cygwin are rather old (2007) so I was hoping that 1.7 would remedy the problem. Evidently not? ---John -- 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
R: complex.h for Cygwin?
--- Gio 30/9/10, Jan Chludzinski ha scritto: After doing some web searches for complex.h and Cygwin, I found there doesn't seem to be any support unless I use: gcc -I/usr/include/mingw -lm tc.c But I still end up with: /cygdrive/c/DOCUME~1/JOHNC~1.ECS/LOCALS~1/Temp/ccAPGnIv.o:tc.c:(.text+0x3d): undefined reference to `_ccos' collect2: ld returned 1 exit status I'm really not interested in working with MinGW either. All the messages about complex.h and Cygwin are rather old (2007) so I was hoping that 1.7 would remedy the problem. Evidently not? ---John John, newlib (cygwin libc-like library) has not the complex type, however on cygwin complex numbers are supported by the gcc/g++ compiler /usr/lib/gcc/i686-pc-cygwin/4.3.4/include/c++/complex.h what are exactly your needs ? 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
Cygwin uninstall: Problem with /dev/nul
Hello, I wanted to report a problem with the cygwin uninstallation: If I delete the folder cygwin on my PC (Windows 7, 32 bit), as described in the FAQ Cygwin uninstall, then there is remaining a special file C:\cygwin\dev\nul This file cannot be deleted afterwards from windows (at least, I didn't find any possibility.) So I wanted to post the following information: In my case (no warranty) the solution was as follows: For a clean uninstall of cygwin, FIRST delete this file cd /dev rm -f nul then exit cygwin, delete the cygwin folder (as described in the FAQ). Maybe this should be verified and then inserted into the Cygwin FAQ: How to uninstall Cygwin. -- 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: Cygwin uninstall: Problem with /dev/nul
On Thu, Sep 30, 2010 at 5:26 PM, Max Funk maxkhf...@gmx.net wrote: Hello, I wanted to report a problem with the cygwin uninstallation: If I delete the folder cygwin on my PC (Windows 7, 32 bit), as described in the FAQ Cygwin uninstall, then there is remaining a special file C:\cygwin\dev\nul This file cannot be deleted afterwards from windows (at least, I didn't find any possibility.) The last time I had to uninstall cygwin this was not a problem for me. -- 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
Slowdown after update on Win32 (XP Home)
I'm seeing a painfully noticeable slowdown on my system. I must have contracted this slowdown last week. My Cygwin is up to date as of now, October 1st, 01:00 CET Starting a MinTTY (or rxvt, for that matter) from the icon I've placed in the start menu does not take the usual two or three seconds, but may take as much as a whole minute. During this startup attempt phase, I can see various bash processes with different PIDs bubbling to the top in taskmgr. I've seen up to three of them at the same time when my MinTTY was trying to start as the first Cygwin process, so there should have been no other bash processes around. This is Win32, XP Home SP3. I hope this description is helpful in debugging this issue. -- Michael Ludwig -- 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: Slowdown after update on Win32 (XP Home)
Michael Ludwig schrieb am 01.10.2010 um 01:19 (+0200): I'm seeing a painfully noticeable slowdown on my system. I must have contracted this slowdown last week. My Cygwin is up to date as of now, October 1st, 01:00 CET For a bit more precision, here's an excerpt from $(cygcheck -s): Cygwin DLL version info: DLL version: 1.7.7 DLL epoch: 19 DLL old termios: 5 DLL malloc env: 28 Cygwin conv: 181 API major: 0 API minor: 230 Shared data: 5 DLL identifier: cygwin1 Mount registry: 3 Cygwin registry name: Cygwin Program options name: Program Options Installations name: Installations Cygdrive default prefix: Build date: Shared id: cygwin1S5 -- Michael Ludwig -- 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: diff issue
Greetings, Brian Wilson! I have strange (to me) issue that I'm not entirely sure how to interpret. Let's say I have two versions of the same batch file: The old version from CVS: rem $Id: backup.bat,v 1.1 2007/07/17 01:53:30 Daemon Exp $ rar a -ag--MM-DD_HH-MM -- MinerTimer @MinerTimer.list The new version I've imported to Subversion: @echo off rem $Id: backup.bat 10 2010-09-30 01:22:14Z anrdaemon $ rar a -ag--MM-DD_HH-MM -- MinerTimer @MinerTimer.list When I'm comparing them with my usual macro diff -bdu -x CVS -x .svn -I \$Id.*\$ -I \$Revision.*\$ -I \$Date.*\$ -I \$Author.*\$ --strip-trailing-cr -- '1/backup.bat' 'backup.bat' It telling me that $Id$ lines are differ. But when I remove the @echo off from second file, it telling me that files are identical (the expected result). Having hard times dechiphering man diff, so if anyone can enlighten me in simple words on the matter, I'd appreciate help greatly. Be sure the end of line characters are correct on the @echo line. You should be able to do this with a cat -vTE command. They are correct for windows batch fine (CRLF) and consistent for both files. However, changing line endings didn't changed the end result. I'm leaning towards diff specifics in treatment of ignored lines in scope of actually changed lines. (sorry for my terrible Russian) :) If my English was the same as your Russian, accept my deepest apology. -- WBR, Andrey Repin (anrdae...@freemail.ru) 01.10.2010, 4:17 Sorry for my terrible english... -- 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: Cygwin uninstall: Problem with /dev/nul
Greetings, Max Funk! If I delete the folder cygwin on my PC (Windows 7, 32 bit), as described in the FAQ Cygwin uninstall, then there is remaining a special file C:\cygwin\dev\nul This file cannot be deleted afterwards from windows (at least, I didn't find any possibility.) http://www.farmanager.com/ Get the 2.0 for your platform and forget your file access nightmares. It can create and delete any technically possible file names. -- WBR, Andrey Repin (anrdae...@freemail.ru) 01.10.2010, 4:25 Sorry for my terrible english... -- 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: Slowdown after update on Win32 (XP Home)
On 9/30/2010 7:19 PM, Michael Ludwig wrote: I'm seeing a painfully noticeable slowdown on my system. I must have contracted this slowdown last week. My Cygwin is up to date as of now, October 1st, 01:00 CET Starting a MinTTY (or rxvt, for that matter) from the icon I've placed in the start menu does not take the usual two or three seconds, but may take as much as a whole minute. During this startup attempt phase, I can see various bash processes with different PIDs bubbling to the top in taskmgr. I've seen up to three of them at the same time when my MinTTY was trying to start as the first Cygwin process, so there should have been no other bash processes around. This is Win32, XP Home SP3. I hope this description is helpful in debugging this issue. Could you provide the information requested by the problem reporting guidelines: http://cygwin.com/problems.html My WAG is you're suffering from changes in the new version of bash_completion. If you don't use this, uninstall it. -- 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? -- 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: Cygwin uninstall: Problem with /dev/nul
cd /dev rm -f nul I havn't seen that, but simliar. There remained setup.log and setup.log.ful on my Desktop and I couldn't delete them. From another Cygwin installation I was able to remove them with your receipe. rm -rf /cygdrive/c/Users/prefix/Desktop/setup.log rm -rf /cygdrive/c/Users/prefix/Desktop/setup.log.full Al -- 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: git stopped working with 1.7.1
that's really a patch :) but no choice.. I create a post on java.net Hope to get more feedback, to get this problem solve soon. Unix users are making fun of us :) Tomás Staig wrote: survivant wrote: Does anyone one have an answer for this problem ? (I saw lot of threads in different forums.. but never an answer.) I'm trying to clone a repository from my computer to my computer. I,m using cygwin 1.7. I,m able to clone all my others projects without problems. This project is 900k.. and the others are better than that. I have no idea what going on. I deleted the project and repush it.. always the same problems. $ GIT_TRACE=1 git clone g...@localhost:SmallProject.git trace: built-in: git 'clone' 'g...@localhost:SmallProject.git' Cloning into SmallProject... trace: run_command: 'ssh' 'g...@localhost' 'git-upload-pack '\''SmallProject.git'\''' DEBUG:gitosis.serve.main:Got command git-upload-pack 'SmallProject.git' DEBUG:gitosis.access.haveAccess:Access check for 'jerabi' as 'writable' on 'SmallProject.git'... DEBUG:gitosis.access.haveAccess:Stripping .git suffix from 'SmallProject.git', new value 'SmallProject' DEBUG:gitosis.group.getMembership:found 'jerabi' in 'gitosis-admin' DEBUG:gitosis.group.getMembership:found 'jerabi' in 'dev_jerabi' DEBUG:gitosis.access.haveAccess:Access ok for 'jerabi' as 'writable' on 'SmallProject' DEBUG:gitosis.access.haveAccess:Using prefix 'repositories' for 'SmallProject' DEBUG:gitosis.serve.main:Serving git-upload-pack 'repositories/SmallProject.git' trace: run_command: 'index-pack' '--stdin' '-v' '--fix-thin' '--keep=fetch-pack 6900 on jerabi-THINK' trace: exec: 'git' 'index-pack' '--stdin' '-v' '--fix-thin' '--keep=fetch-pack 6900 on jerabi-THINK' remote: Counting objects: 344, done. trace: built-in: git 'index-pack' '--stdin' '-v' '--fix-thin' '--keep=fetch-pack 6900 on jerabi-THINK' remote: Compressing objects: 58% (134/230) remote: Compressing objects: 100% (230/230), done. fatal: The remote end hung up unexpectedly fatal: early EOF fatal: index-pack failed jer...@jerabi-think ~/workspaces/test $ $ git --version git version 1.7.2.3 Don't have a clue of why this happens (some people say it is because of openssh, that if you change it for putty's implementation it works well) but when that happens to me (while pulling, never tried with clone) I just try a couple of times until it succeeds: for (( i=0 ; i 100 ; i++ )); do git pull; done works all the time for me... try something similar but with git clone ... of course. And well, I'm working with a 4+GB repository, so I'm really thankful that the clone worked right away. I know it's not the best solution, but if it works... it's good enough as a temporal workaround. Hope it works for you. Cheers, Tomas. -- 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 -- View this message in context: http://old.nabble.com/git-stopped-working-with-1.7.1-tp26905956p29853811.html Sent from the Cygwin list mailing list archive at Nabble.com. -- 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: diff issue
Let's say I have two versions of the same batch file: The old version from CVS: rem $Id: backup.bat,v 1.1 2007/07/17 01:53:30 Daemon Exp $ rar a -ag--MM-DD_HH-MM -- MinerTimer @MinerTimer.list The new version I've imported to Subversion: @echo off rem $Id: backup.bat 10 2010-09-30 01:22:14Z anrdaemon $ rar a -ag--MM-DD_HH-MM -- MinerTimer @MinerTimer.list When I'm comparing them with my usual macro diff -bdu -x CVS -x .svn -I \$Id.*\$ -I \$Revision.*\$ -I \$Date.*\$ -I \$Author.*\$ --strip-trailing-cr -- '1/backup.bat' 'backup.bat' It telling me that $Id$ lines are differ. But when I remove the @echo off from second file, it telling me that files are identical (the expected result). Having hard times dechiphering man diff, so if anyone can enlighten me in simple words on the matter, I'd appreciate help greatly. Be sure the end of line characters are correct on the @echo line. You should be able to do this with a cat -vTE command. They are correct for windows batch fine (CRLF) and consistent for both files. However, changing line endings didn't changed the end result. I'm leaning towards diff specifics in treatment of ignored lines in scope of actually changed lines. :) If my English was the same as your Russian, accept my deepest apology. Your English is fine. I used Google translate to try and make my response easier for you. I guess that didn't happen, so the fault is mine. Try changing the @echo line to something else and see if you still get the same results. Also try removing some of the -I cases and see if that makes a difference in the results. This could lead you to the answer if one of the patterns is causing the problem. Lastly do you need to use the -x PATtern exclusion options? You are already specifying the two files to diff so you shouldn't need these options. I'm not sure what the -- argument is used for (before the file names) though. I would also try naming the directory in the 1/backup.bat argument something other than 1. -- 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
