Re: 1.7: Problem with Vista64b ACLs and sockets
Corinna Vinschen wrote: On Apr 17 10:46, Charles Wilson wrote: Corinna Vinschen wrote: Yes, sure, but in that case, why not use the native ping? AFAIK the ICMP API doesn't provide all the data you need to emulate the usual UNIX ping output anyway. AFAIK, the native (e.g. the shipped-with-windows) ping doesn't use the ICMP dll either. That's why I installed FPing. However, FPing (or even shipped-with-windows ping) are native, not cygwin progs. I don't like using native progs at all, ever, if I can help it. They always lead to surprises: pty issues in terminals, issues with pathnames, difficulties in complex commands (pipes |), etc. But it was just an idle thought. No, it's not idle, it's a valid argument. The problem is, ping isn't useful as is for non-Admin users, and the package is orphaned. That's why I think we should drop it from the distro. If somebody takes over maintainance and comes up with a patch which makes ping work for non-Admin users again, there's nothing to say against a Cygwin ping. In the current state it just leads to confusion, though. Corinna First, Corrina, thanks for the info. Because of my other ACL problems I was totally confused as to what was going on. I have, I think fixed these with a combination of tools. Second, my user ID is part of the Administrator group, but you must specifically 'run as' Cygwin to gain true Administrator privilege even from an Administrators group ID in order for /bin/ping to work in my tests. I'm sure you knew this Corinna, but others may not have. Third, I've changed the ping in my profile to use MS ping, and it works fine. The parameters are specified differently, but the exit codes work fine. I tried 'fping', but its too noisy about having to use the ICMP.dll, and the -i option (use the ICMP.dll as a first choice rather than raw sockets) seems not to work. Now, I understand why 'ping' was missing for so long from Cygwin, and why 'traceroute' has never been a part of it. (Yes, I know about MS 'tracert'.) Thank you, again, Corinna. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: WTF/database still needs updating
YSHFRTT is not in the 'wtf' database which means, 'wtf'' needs to be 're-rolled'? --On Wednesday, April 15, 2009, Owen Rees noted: --On Wednesday, April 15, 2009 09:03:57 -0400 Lee D. Rothstein wrote: ISHFRTT not in WTF database. It is the first-person form of YSHFRTT (which is in OLOCA). -- 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: edit Aux.pm under GNU emacs hangs
Corinna Vinschen wrote: On Apr 6 15:14, Lee D. Rothstein wrote: Corinna Vinschen wrote: Apart from the fact that you should use slashes instead of backslashes, there isn't any need to use //./ in Cygwin 1.7. Just open Aux.pm. http://cygwin.com/1.7/cygwin-ug-net/using-specialnames.html Can't have any files named [aA][uU][xX] dot *anything* in Windows, or anything dot [aA][uU][xX]. Incorrect. This is a restriction in the Win32 API, it's not a restriction of the filesystem or the native NT API which Cygwin 1.7 uses for file access (almost) exclusively. The specific problem symptoms that the original poster mentioned, I was able to replicate WITH a windows app, which seems to me indicates that he was using a win32 app, i.e., GNU emacs for Win32? I apologize for my oversight and I certainly wasn't criticizing you, in any way! -- 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/
1.7: Problems with 'rsync'.
I'm having two problems with 'rsync' (over 'ssh'), that are
possible pilot error.
Here's the portion of the 'bash' script I use to run 'rsync':
--
rsync -vcrRt --stats --delete --force --prune-empty-dirs \
--compress --exclude *.ion *.txt --human-readable \
--itemize-changes --log-file=$LogFile -e ssh -p 8022 \
${Source} ${us...@${host}:html
--
I'm running rsync version 3.0.5 protocol version 30.
I would appreciate some feedback on whether anyone else has
experience with this.
First, and least importantly, each time I run 'rsync' (from
the script), I get the following error messages to the
screen regardless of whether I'm running 'mintty' or the
console as the terminal. Although it writes the log file
correctly each time, the error message disappears if I omit
the log file option.
--
stty: standard input: Invalid argument
stty: standard input: Invalid argument
--
Secondly, and most importantly, 'rsync' is copying the
entire source directory tree, rather than from the
terminating '/' of the source tree specification.
This contradicts both my reading of the 'man' page, version:
28 Dec 2008, as well as my prior experience.
Is this a bug, or pilot (EBCAK) error?
Lee
--
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/
'less': HOMEEND not working with 'mintty' v0.3.6
Andy, I hope I've got this right, but lately I seem to be so confused by the subtle differences between Cygwin 1.5 1.7, that I'm not sure. I believe that the settings we had previously discussed to get 'less' to accept HOME END as beginning and end of stream respectively, stopped working with the 'mintty' v0.3.7 release. And this is true for both Cygwin v1.5 and v1.7. My .lesskey file is: -- # Activate mousewheel scrolling in 'less' with the following two # lines in your .lesskey file. Run 'lesskey' to compile this # file into 'less' internal format. \eO1;2A back-line # UP-ARROW \eO1;2B forw-line # DOWN-ARROW \eOH goto-line # HOME -- Beginning of input \eOF goto-end # END -- End of input -- I tried a fresh recompile under Cygwin v1.7, with 'mintty' v0.3.8, to no avail. However, I thought the above settings worked with 'xterm' as well. They do not. ** PEBCAK?** Lee -- 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/
1.7.0: Getting a Windows app to run synchronously to a script from which it is invoked
This is in all probability, not a bug. I suspect it falls into CGF's category of works but isn't (wasn't) guaranteed. All of my scripts (developed under Cygwin 1.5 or earlier) that involve a Windows native app use: winapp $(cygpath -w $something) have stopped working properly since I installed Cygwin 1.7. Here's the script I use, FOR EXAMPLE, for invoking Windows Explorer to the current directory or a specified Cygwin directory path, AND that stops further use of the invoked from terminal window, until this Explorer window terminates: #!/usr/bin/bash if [[ -n $1 ]] ; then cd $1 ; fi explorer $(cygpath -w .) Explorer opens okay, but always to the Computer folder, rather than the current working or specified directory. (Yes, I know that there is a special option for Explorer in 'cygstart'. Please read on.) I found that I can make the above work by replacing the invocation using 'cygpath' with a 'cygstart' initiated invocation without 'cygpath', at all. The problem with this latter fix, however, is that 'cygstart' invokes the Windows app asynchronously to the script in which it is contained. Sometimes I want the script continuance to be tethered to the Windows app, and the only way to do this (that I can see), is to put an otherwise superfluous 'read' statement right after the Windows app invocation. Ugly, and not as obvious, to the user, as the old method. Is there no straight-forward way to invoke a windows app from a script synchronously with Cygwin 1.7? -- 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/
'cygstart' option? was Re: 1.7.0: Getting a Windows app to run synchronously to a script from which it is invoked
I figured out a solution, but it still has limitations. The solution: It just requires doing a cd into the path (complete directory path) of the argument, and cd'ing into that path. If the command operates on a directory as Explorer does, then you submit '.' as the argument. If the command requires a file name, you just submit the 'basename' as the argument. I used to do this years ago (starting with the MKS toolkit, and then the Thompson toolkit), but stopped once I became conversant with 'cygpath'. Brain damage is my excuse for forgetting. However, this will only work with Windows programs that themselves are synchronous, OTB (out of the box). This won't work, for example, with OpenOffice (OO) after about version 1.5, or WinWord after version 10, or thereabouts. OO really bummed me out, when they made the change, invalidating all my blogging scripts. That's when I started using the 'read' nonsense. Actually, more recently, they both require 'cygstart' or they flat out blow up. However, you don't have to specifiy the command name at all, just the file name argument. But you still end up with the asynch start. In brief, it would be very nice if there was a cygstart option that did not exit until the command which it starts exits. Is this possible? Lee Lee D.Rothstein wrote: This is in all probability, not a bug. I suspect it falls into CGF's category of works but isn't (wasn't) guaranteed. All of my scripts (developed under Cygwin 1.5 or earlier) that involve a Windows native app use: winapp $(cygpath -w $something) have stopped working properly since I installed Cygwin 1.7. Here's the script I use, FOR EXAMPLE, for invoking Windows Explorer to the current directory or a specified Cygwin directory path, AND that stops further use of the invoked from terminal window, until this Explorer window terminates: #!/usr/bin/bash if [[ -n $1 ]] ; then cd $1 ; fi explorer $(cygpath -w .) Explorer opens okay, but always to the Computer folder, rather than the current working or specified directory. (Yes, I know that there is a special option for Explorer in 'cygstart'. Please read on.) I found that I can make the above work by replacing the invocation using 'cygpath' with a 'cygstart' initiated invocation without 'cygpath', at all. The problem with this latter fix, however, is that 'cygstart' invokes the Windows app asynchronously to the script in which it is contained. Sometimes I want the script continuance to be tethered to the Windows app, and the only way to do this (that I can see), is to put an otherwise superfluous 'read' statement right after the Windows app invocation. Ugly, and not as obvious, to the user, as the old method. Is there no straight-forward way to invoke a windows app from a script synchronously with Cygwin 1.7? -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Problem with 575 man pages -- cygport problem?
A large number (575) of 'man' pages, that reference other man pages using a '.so' (source include) reference, fail to work because the plain text files have the '.gz' extension appended without actually being gzipped. Could this be due to a mishap in or with the 'cygport' package? Each reference appears to be okay (I've only tested a handful), iff you remove the '.gz' extension. Following is a list of such man page error messages with a few of them actually verified to have the situation I describe above. Lee gzip: /usr/share/man/man1/./reset.1.gz: not in gzip format - Text format: .so tset.1.gz -- valid gzip: /usr/share/man/man3/./addch.3x.gz: not in gzip format - Text format: .so curs_addch.3x.gz -- valid gzip: /usr/share/man/man3/./addchnstr.3x.gz: not in gzip format gzip: /usr/share/man/man3/./addchstr.3x.gz: not in gzip format gzip: /usr/share/man/man3/./addnstr.3x.gz: not in gzip format gzip: /usr/share/man/man3/./addnwstr.3x.gz: not in gzip format gzip: /usr/share/man/man3/./addstr.3x.gz: not in gzip format gzip: /usr/share/man/man3/./addwstr.3x.gz: not in gzip format gzip: /usr/share/man/man3/./add_wch.3x.gz: not in gzip format gzip: /usr/share/man/man3/./add_wchnstr.3x.gz: not in gzip format gzip: /usr/share/man/man3/./add_wchstr.3x.gz: not in gzip format gzip: /usr/share/man/man3/./assume_default_colors.3x.gz: not in gzip format gzip: /usr/share/man/man3/./attroff.3x.gz: not in gzip format gzip: /usr/share/man/man3/./attron.3x.gz: not in gzip format gzip: /usr/share/man/man3/./attrset.3x.gz: not in gzip format gzip: /usr/share/man/man3/./attr_get.3x.gz: not in gzip format gzip: /usr/share/man/man3/./attr_off.3x.gz: not in gzip format gzip: /usr/share/man/man3/./attr_on.3x.gz: not in gzip format gzip: /usr/share/man/man3/./attr_set.3x.gz: not in gzip format gzip: /usr/share/man/man3/./baudrate.3x.gz: not in gzip format gzip: /usr/share/man/man3/./beep.3x.gz: not in gzip format gzip: /usr/share/man/man3/./bkgd.3x.gz: not in gzip format gzip: /usr/share/man/man3/./bkgdset.3x.gz: not in gzip format gzip: /usr/share/man/man3/./bkgrnd.3x.gz: not in gzip format gzip: /usr/share/man/man3/./bkgrndset.3x.gz: not in gzip format gzip: /usr/share/man/man3/./border.3x.gz: not in gzip format gzip: /usr/share/man/man3/./border_set.3x.gz: not in gzip format gzip: /usr/share/man/man3/./bottom_panel.3x.gz: not in gzip format gzip: /usr/share/man/man3/./box.3x.gz: not in gzip format gzip: /usr/share/man/man3/./box_set.3x.gz: not in gzip format gzip: /usr/share/man/man3/./can_change_color.3x.gz: not in gzip format gzip: /usr/share/man/man3/./cbreak.3x.gz: not in gzip format gzip: /usr/share/man/man3/./chgat.3x.gz: not in gzip format gzip: /usr/share/man/man3/./clear.3x.gz: not in gzip format gzip: /usr/share/man/man3/./clearok.3x.gz: not in gzip format gzip: /usr/share/man/man3/./clrtobot.3x.gz: not in gzip format gzip: /usr/share/man/man3/./clrtoeol.3x.gz: not in gzip format gzip: /usr/share/man/man3/./color_content.3x.gz: not in gzip format gzip: /usr/share/man/man3/./COLOR_PAIR.3x.gz: not in gzip format gzip: /usr/share/man/man3/./color_set.3x.gz: not in gzip format gzip: /usr/share/man/man3/./copywin.3x.gz: not in gzip format gzip: /usr/share/man/man3/./current_field.3x.gz: not in gzip format - Text format: .so form_page.3x.gz -- valid gzip: /usr/share/man/man3/./current_item.3x.gz: not in gzip format gzip: /usr/share/man/man3/./curses_version.3x.gz: not in gzip format gzip: /usr/share/man/man3/./curs_set.3x.gz: not in gzip format gzip: /usr/share/man/man3/./data_ahead.3x.gz: not in gzip format gzip: /usr/share/man/man3/./data_behind.3x.gz: not in gzip format gzip: /usr/share/man/man3/./def_prog_mode.3x.gz: not in gzip format gzip: /usr/share/man/man3/./def_shell_mode.3x.gz: not in gzip format gzip: /usr/share/man/man3/./delay_output.3x.gz: not in gzip format gzip: /usr/share/man/man3/./delch.3x.gz: not in gzip format gzip: /usr/share/man/man3/./deleteln.3x.gz: not in gzip format gzip: /usr/share/man/man3/./delscreen.3x.gz: not in gzip format gzip: /usr/share/man/man3/./delwin.3x.gz: not in gzip format gzip: /usr/share/man/man3/./del_curterm.3x.gz: not in gzip format gzip: /usr/share/man/man3/./del_panel.3x.gz: not in gzip format gzip: /usr/share/man/man3/./derwin.3x.gz: not in gzip format gzip: /usr/share/man/man3/./doupdate.3x.gz: not in gzip format gzip: /usr/share/man/man3/./dupwin.3x.gz: not in gzip format gzip: /usr/share/man/man3/./dup_field.3x.gz: not in gzip format gzip: /usr/share/man/man3/./dynamic_field_info.3x.gz: not in gzip format gzip: /usr/share/man/man3/./echo.3x.gz: not in gzip format gzip: /usr/share/man/man3/./echochar.3x.gz: not in gzip format gzip: /usr/share/man/man3/./echo_wchar.3x.gz: not in gzip format gzip: /usr/share/man/man3/./endwin.3x.gz: not in gzip format gzip: /usr/share/man/man3/./erase.3x.gz: not in gzip format gzip: /usr/share/man/man3/./erasechar.3x.gz: not in gzip format gzip: /usr/share/man/man3/./erasewchar.3x.gz: not in gzip format gzip:
Re: clearing the scrollback buffer in mintty
Andy Koppe wrote: Lee said: For gui consoles, use alias cls='echo -e \033c' which does clear the scrollback buffer. Thanks Dave, this works on 'xterm' but not on 'mintty'. On 'mintty' it does a 'clear' (i.e., clears the screen), rather than a 'cls' (i.e., clears the screen and scrollback buffer). Thanks Lee. I entered issue 65 for this. Looks like PuTTY took a different view from xterm as to whether the Full Reset (RIS) sequence should clear the scrollback, but of course MinTTY is meant to be compatible with xterm. Meanwhile, this will do the reset and clear the scrollback: alias cls='echo -e \ec\e[3J' This works fine even from a batch file. Thanks. And also works with 'xterm'. -- 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/
Is there a problem with cygport?
---BeginMessage--- A huge number (575) of 'man' pages, that reference other man pages using a '.so' (source include) reference, fail to work because the plain text files have the '.gz' extension appended without actually being gzipped. Could this be due to a mishap in or with the 'cygport' package? Each reference appears to be okay (I've only tested a handful), if you remove the '.gz' extension. Attached is a list of such man page error messages with a few of them actually verified to have the situation I describe above. Lee gzip: /usr/share/man/man1/./reset.1.gz: not in gzip format - Text format: .so tset.1.gz -- valid gzip: /usr/share/man/man3/./addch.3x.gz: not in gzip format - Text format: .so curs_addch.3x.gz -- valid gzip: /usr/share/man/man3/./addchnstr.3x.gz: not in gzip format gzip: /usr/share/man/man3/./addchstr.3x.gz: not in gzip format gzip: /usr/share/man/man3/./addnstr.3x.gz: not in gzip format gzip: /usr/share/man/man3/./addnwstr.3x.gz: not in gzip format gzip: /usr/share/man/man3/./addstr.3x.gz: not in gzip format gzip: /usr/share/man/man3/./addwstr.3x.gz: not in gzip format gzip: /usr/share/man/man3/./add_wch.3x.gz: not in gzip format gzip: /usr/share/man/man3/./add_wchnstr.3x.gz: not in gzip format gzip: /usr/share/man/man3/./add_wchstr.3x.gz: not in gzip format gzip: /usr/share/man/man3/./assume_default_colors.3x.gz: not in gzip format gzip: /usr/share/man/man3/./attroff.3x.gz: not in gzip format gzip: /usr/share/man/man3/./attron.3x.gz: not in gzip format gzip: /usr/share/man/man3/./attrset.3x.gz: not in gzip format gzip: /usr/share/man/man3/./attr_get.3x.gz: not in gzip format gzip: /usr/share/man/man3/./attr_off.3x.gz: not in gzip format gzip: /usr/share/man/man3/./attr_on.3x.gz: not in gzip format gzip: /usr/share/man/man3/./attr_set.3x.gz: not in gzip format gzip: /usr/share/man/man3/./baudrate.3x.gz: not in gzip format gzip: /usr/share/man/man3/./beep.3x.gz: not in gzip format gzip: /usr/share/man/man3/./bkgd.3x.gz: not in gzip format gzip: /usr/share/man/man3/./bkgdset.3x.gz: not in gzip format gzip: /usr/share/man/man3/./bkgrnd.3x.gz: not in gzip format gzip: /usr/share/man/man3/./bkgrndset.3x.gz: not in gzip format gzip: /usr/share/man/man3/./border.3x.gz: not in gzip format gzip: /usr/share/man/man3/./border_set.3x.gz: not in gzip format gzip: /usr/share/man/man3/./bottom_panel.3x.gz: not in gzip format gzip: /usr/share/man/man3/./box.3x.gz: not in gzip format gzip: /usr/share/man/man3/./box_set.3x.gz: not in gzip format gzip: /usr/share/man/man3/./can_change_color.3x.gz: not in gzip format gzip: /usr/share/man/man3/./cbreak.3x.gz: not in gzip format gzip: /usr/share/man/man3/./chgat.3x.gz: not in gzip format gzip: /usr/share/man/man3/./clear.3x.gz: not in gzip format gzip: /usr/share/man/man3/./clearok.3x.gz: not in gzip format gzip: /usr/share/man/man3/./clrtobot.3x.gz: not in gzip format gzip: /usr/share/man/man3/./clrtoeol.3x.gz: not in gzip format gzip: /usr/share/man/man3/./color_content.3x.gz: not in gzip format gzip: /usr/share/man/man3/./COLOR_PAIR.3x.gz: not in gzip format gzip: /usr/share/man/man3/./color_set.3x.gz: not in gzip format gzip: /usr/share/man/man3/./copywin.3x.gz: not in gzip format gzip: /usr/share/man/man3/./current_field.3x.gz: not in gzip format - Text format: .so form_page.3x.gz -- valid gzip: /usr/share/man/man3/./current_item.3x.gz: not in gzip format gzip: /usr/share/man/man3/./curses_version.3x.gz: not in gzip format gzip: /usr/share/man/man3/./curs_set.3x.gz: not in gzip format gzip: /usr/share/man/man3/./data_ahead.3x.gz: not in gzip format gzip: /usr/share/man/man3/./data_behind.3x.gz: not in gzip format gzip: /usr/share/man/man3/./def_prog_mode.3x.gz: not in gzip format gzip: /usr/share/man/man3/./def_shell_mode.3x.gz: not in gzip format gzip: /usr/share/man/man3/./delay_output.3x.gz: not in gzip format gzip: /usr/share/man/man3/./delch.3x.gz: not in gzip format gzip: /usr/share/man/man3/./deleteln.3x.gz: not in gzip format gzip: /usr/share/man/man3/./delscreen.3x.gz: not in gzip format gzip: /usr/share/man/man3/./delwin.3x.gz: not in gzip format gzip: /usr/share/man/man3/./del_curterm.3x.gz: not in gzip format gzip: /usr/share/man/man3/./del_panel.3x.gz: not in gzip format gzip: /usr/share/man/man3/./derwin.3x.gz: not in gzip format gzip: /usr/share/man/man3/./doupdate.3x.gz: not in gzip format gzip: /usr/share/man/man3/./dupwin.3x.gz: not in gzip format gzip: /usr/share/man/man3/./dup_field.3x.gz: not in gzip format gzip: /usr/share/man/man3/./dynamic_field_info.3x.gz: not in gzip format gzip: /usr/share/man/man3/./echo.3x.gz: not in gzip format gzip: /usr/share/man/man3/./echochar.3x.gz: not in gzip format gzip: /usr/share/man/man3/./echo_wchar.3x.gz: not in gzip format gzip: /usr/share/man/man3/./endwin.3x.gz: not in gzip format gzip: /usr/share/man/man3/./erase.3x.gz: not in gzip format gzip: /usr/share/man/man3/./erasechar.3x.gz: not in gzip format gzip: /usr/share/man/man3/./erasewchar.3x.gz: not in gzip format gzip:
Problem with a large number of man pages that reference other man pages
A huge number (575) of 'man' pages, that reference other man pages using a '.so' (source include) reference, fail to work because the plain text files have the '.gz' extension appended without actually being gzipped. Could this be due to a mishap in or with the 'cygport' package? Each reference appears to be okay (I've only tested a handful), if you remove the '.gz' extension. Attached is a list of such man page error messages with a few of them actually verified to have the situation I describe above. Lee gzip: /usr/share/man/man1/./reset.1.gz: not in gzip format - Text format: .so tset.1.gz -- valid gzip: /usr/share/man/man3/./addch.3x.gz: not in gzip format - Text format: .so curs_addch.3x.gz -- valid gzip: /usr/share/man/man3/./addchnstr.3x.gz: not in gzip format gzip: /usr/share/man/man3/./addchstr.3x.gz: not in gzip format gzip: /usr/share/man/man3/./addnstr.3x.gz: not in gzip format gzip: /usr/share/man/man3/./addnwstr.3x.gz: not in gzip format gzip: /usr/share/man/man3/./addstr.3x.gz: not in gzip format gzip: /usr/share/man/man3/./addwstr.3x.gz: not in gzip format gzip: /usr/share/man/man3/./add_wch.3x.gz: not in gzip format gzip: /usr/share/man/man3/./add_wchnstr.3x.gz: not in gzip format gzip: /usr/share/man/man3/./add_wchstr.3x.gz: not in gzip format gzip: /usr/share/man/man3/./assume_default_colors.3x.gz: not in gzip format gzip: /usr/share/man/man3/./attroff.3x.gz: not in gzip format gzip: /usr/share/man/man3/./attron.3x.gz: not in gzip format gzip: /usr/share/man/man3/./attrset.3x.gz: not in gzip format gzip: /usr/share/man/man3/./attr_get.3x.gz: not in gzip format gzip: /usr/share/man/man3/./attr_off.3x.gz: not in gzip format gzip: /usr/share/man/man3/./attr_on.3x.gz: not in gzip format gzip: /usr/share/man/man3/./attr_set.3x.gz: not in gzip format gzip: /usr/share/man/man3/./baudrate.3x.gz: not in gzip format gzip: /usr/share/man/man3/./beep.3x.gz: not in gzip format gzip: /usr/share/man/man3/./bkgd.3x.gz: not in gzip format gzip: /usr/share/man/man3/./bkgdset.3x.gz: not in gzip format gzip: /usr/share/man/man3/./bkgrnd.3x.gz: not in gzip format gzip: /usr/share/man/man3/./bkgrndset.3x.gz: not in gzip format gzip: /usr/share/man/man3/./border.3x.gz: not in gzip format gzip: /usr/share/man/man3/./border_set.3x.gz: not in gzip format gzip: /usr/share/man/man3/./bottom_panel.3x.gz: not in gzip format gzip: /usr/share/man/man3/./box.3x.gz: not in gzip format gzip: /usr/share/man/man3/./box_set.3x.gz: not in gzip format gzip: /usr/share/man/man3/./can_change_color.3x.gz: not in gzip format gzip: /usr/share/man/man3/./cbreak.3x.gz: not in gzip format gzip: /usr/share/man/man3/./chgat.3x.gz: not in gzip format gzip: /usr/share/man/man3/./clear.3x.gz: not in gzip format gzip: /usr/share/man/man3/./clearok.3x.gz: not in gzip format gzip: /usr/share/man/man3/./clrtobot.3x.gz: not in gzip format gzip: /usr/share/man/man3/./clrtoeol.3x.gz: not in gzip format gzip: /usr/share/man/man3/./color_content.3x.gz: not in gzip format gzip: /usr/share/man/man3/./COLOR_PAIR.3x.gz: not in gzip format gzip: /usr/share/man/man3/./color_set.3x.gz: not in gzip format gzip: /usr/share/man/man3/./copywin.3x.gz: not in gzip format gzip: /usr/share/man/man3/./current_field.3x.gz: not in gzip format - Text format: .so form_page.3x.gz -- valid gzip: /usr/share/man/man3/./current_item.3x.gz: not in gzip format gzip: /usr/share/man/man3/./curses_version.3x.gz: not in gzip format gzip: /usr/share/man/man3/./curs_set.3x.gz: not in gzip format gzip: /usr/share/man/man3/./data_ahead.3x.gz: not in gzip format gzip: /usr/share/man/man3/./data_behind.3x.gz: not in gzip format gzip: /usr/share/man/man3/./def_prog_mode.3x.gz: not in gzip format gzip: /usr/share/man/man3/./def_shell_mode.3x.gz: not in gzip format gzip: /usr/share/man/man3/./delay_output.3x.gz: not in gzip format gzip: /usr/share/man/man3/./delch.3x.gz: not in gzip format gzip: /usr/share/man/man3/./deleteln.3x.gz: not in gzip format gzip: /usr/share/man/man3/./delscreen.3x.gz: not in gzip format gzip: /usr/share/man/man3/./delwin.3x.gz: not in gzip format gzip: /usr/share/man/man3/./del_curterm.3x.gz: not in gzip format gzip: /usr/share/man/man3/./del_panel.3x.gz: not in gzip format gzip: /usr/share/man/man3/./derwin.3x.gz: not in gzip format gzip: /usr/share/man/man3/./doupdate.3x.gz: not in gzip format gzip: /usr/share/man/man3/./dupwin.3x.gz: not in gzip format gzip: /usr/share/man/man3/./dup_field.3x.gz: not in gzip format gzip: /usr/share/man/man3/./dynamic_field_info.3x.gz: not in gzip format gzip: /usr/share/man/man3/./echo.3x.gz: not in gzip format gzip: /usr/share/man/man3/./echochar.3x.gz: not in gzip format gzip: /usr/share/man/man3/./echo_wchar.3x.gz: not in gzip format gzip: /usr/share/man/man3/./endwin.3x.gz: not in gzip format gzip: /usr/share/man/man3/./erase.3x.gz: not in gzip format gzip: /usr/share/man/man3/./erasechar.3x.gz: not in gzip format gzip: /usr/share/man/man3/./erasewchar.3x.gz: not in gzip format gzip:
Re: [ITP] iperf 2.0.4
Corinna Vinschen wrote: On Feb 25 05:56, Clifford George wrote: Sorry, thought I had followed the rules in 'submitting a new package', point 2, my apologies. As far as I am aware this is not in any Linux Distro. It's in Fedora, afaics. Corinna I vote yes.
[Fwd: Re: Reproducing the cygwin X problems; MinTTY, too]
---BeginMessage--- Lee D.Rothstein wrote: FWIW, I'm having a similar proble with MinTTY. If I select text in a MinTTY window, then copy text withing a GUI app, like TextPad (http://textpad.com), clipboard stops working for all apps. If I ten return to the original, MinTTY window, and reselect text, paste it, that works and then copy and paste work in all apps, again. MinTTY problems are probably better directed to the cygwin@cygwin.com list or at http://code.google.com/p/mintty/ -- 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/ ---End Message--- -- 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: Reproducing the cygwin X problems; MinTTY, too
Dan Tsafrir wrote: On Tue, Feb 24, 2009 at 2:13 PM, Jon TURNEY It seems likely that this clipboard contention between multiple applications might behave differently on machines with multi-core processors (which I don't have the capability to test on), so can you indicate if you are using single-core or multi-core processor? Indeed, I'm using a dual core machine. However, in an attempt to test your hypothesis, I've set the affinity of XWin.exe, emacs, and the vncviewer to only use CPU0 (through the task manager). This had no positive affect on the problem: the instant I highlighted some text within emacs my copy-paste functionality was dead, regardless of affinity. --Dan -- 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/ FWIW, I'm having a similar proble with MinTTY. If I select text in a MinTTY window, then copy text withing a GUI app, like TextPad (http://textpad.com), clipboard stops working for all apps. If I ten return to the original, MinTTY window, and reselect text, paste it, that works and then copy and paste work in all apps, again. Lee -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: How does one find where Cygwin was installed from Windows?
It's not like in Windows where you can add something to the linux-registry, /etc, or path-specific part /etc/profile.d and have other apps pick up this information. It would make more sense to put it in a registry environment variable. What do you think? 'setx.exe' a CLI utility on Vista and XP system (2000?), allows you to set an evironment variable, say, CYGWIN_ROOT, and/or CYGWIN_BIN, that percolates up to the System or User Enviroment variable space. It comes with Windows. Wouldn't this make more sense than messing with the registry directly. 'setx' can be run from a Cygwin shell. I've tried it. It works (Vista Home Premium 64b with Cygwin 1.5). -- 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/
Conjoining Setup CygWine Some Other Requirements. Was: Re: CygWine 1.0 Beta -- an new cygwin package manager
I found Brant Warren Young and Dave Korn, et al's comments about a possible conjoined 'setup', and the unfortunately named ( soon to be renamed -- TYVM), 'cygwine', and the requirements thereto (;-)), to be right to the point. I would like to suggest two new features for the setup/command line. The specification of an initial user- defined script (filename) that gets executed prior to getting into the meat of 'setup', and one that executes after. * The purpose of the initial script could be to (among other things) save some configuration info before running setup, including: Look to see if there is a newer 'setup.exe' that takes precedence over the one you are using Saving the registry On Vista, a recovery point. Running mount -m and saving to a script file. It doesn't even matter that Cygwin doesn't really impose any risk, it just creates a good excuse to save Windows/the user (e.g., me) from it-/his-/her-self. Saving .../bin, etc. directory lists for later diffs. Storage consumed by the /... tree, before update ... * The purpose of the concluding script could be to (among other things) Run 'makewhatis' to update the 'whatis'/'apropos' database Locate updated documentation: 'man', 'info', HTML, FAQs, README, etc. Creating PDF documents out of select new 'man', 'info', HTML and text documents. Create pseudo 'man' pages of 'info' trees using some of the 'info' command line dump options. Computing diffs on .../bin, etc directory lists. Storage consumed by the /... tree, after update. View the setup log file, automatically Download the latest OLOCA so you can be as hip as the Cygwin movers and shakers ;-) ... Now, you could run setup from within a script in order to invoke the initial and final scripts but this would create conflicts with installs of busy components caused by the script(s). Lee P.S. I volunteer, in advance, to write/organize/format/ whats-ever-required in/of/by/to/from the documentation, if anyone is interested, starting with the current 'setup' update effort and spanning through the conjoined effort. -- 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: 'man' page for 'mintty' for review
Christopher Faylor wrote: On Fri, Feb 06, 2009 at 10:04:36AM +0100, Peter Rosin wrote: On 2009-02-05 20:47 Lee D.Rothstein wrote: Please, if you would, review the attached 'man' page -- 'mintty.1'. Andy Koppe intends to fold it into the 0.3.6 MinTTY release. Comments, corrections, addtitions to this list, please. 'man ./mintty.1.gz' will render the file (in the current directory) without installing the page. 3. Make sure that the Windows file spec for the folder that contains both cygwin1.dll and mintty.exe (typically, c:/Cygwin/usr/bin) are on the PATH variable, in the Windows System or User environment variables space.I I would say that the typical location is C:\Cygwin\bin. ^ I have changed the text to 'C:\Cygwin\bin', correcting two errors by me: * path * path delimitor Thanks, Peter. BTB, the reason that I use the word typically, is because Cygwin can be installed in other directories (e.g., in my system, root is at 'c:\_r'), not because I thought a different directory besides 'bin' would have the executable. Later in the document: First, PATH must include the Windows path of the /bin, where typically both mintty.exe and cygwin1.dll' will be found. Remember, this is a Here, I think I have the path right, since, the Windows equivalent of '/bin' is 'c:\Cygwin\bin', which means I don't understand the following comment at all: I would say the Window path of /usr/bin here, since that is where the package is installed (but since /usr/bin is typically mirrored to /bin so that's perhaps a minor point). In both cases, I'm talking about invoking 'mintty' from Windows, not Cygwin. Windows can only see the excutables in /bin (through 'c:\Cygwin\bin' NOT through 'c:\Cygwin\usr\bin'), however, and we're talking about what Windows can see when you fire up the 'mintty' shortcut. -- Peter? /usr/bin is not in any way a Windows path so I don't think there is any reason to change this. Christopher? Did I create too much confusion by my other errors? I doubt that any/all of the above are the only things wrong with the doc. ;-) Thanks for the help. Lee -- 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/
'man' page for 'mintty' for review
MinTTY users, Please, if you would, review the attached 'man' page -- 'mintty.1'. Andy Koppe intends to fold it into the 0.3.6 MinTTY release. Comments, corrections, addtitions to this list, please. 'man ./mintty.1.gz' will render the file (in the current directory) without installing the page. Thanks, Lee Rothstein mintty.1.gz Description: GNU Zip compressed data -- 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/
Length of Command Line?!!!
I remember that in past versions of Windows, 'cmd.exe' imposed a draconianly short command line on Cygwin console. I was wondering whether the limitation applied to Xterm windows, as well. I have become quite adept at using xargs to avoid this limit. However, I was writing something about Cygwin and I thought it time to reverify. So, I ran a little test, on both console and Xterm bash windows, and discovered that command lines 260,000 characters are acceptable to _console_. (Xterm yields the same results.) I still haven't determined the upper limit. I am running Vista 64 Home Premium (Ver 6.0 Build 6001 Service Pack 1; AMD 64 Quadcore), and Cygwin DLL ver 1.5.25-15. Is this something new to Cygwin, or Windows Vista 64? As of which version of what? Sorry to be so anachronistic. So, once, again, Cygwin is better than I remember! ;-) BTB, at least one document turned up in a Google search (of documents dated in the last year) indicated that GNU/Linux had a 128KB limit, and Cygwin, under XP, a 32KB limit! Lee Lee Rothstein -- 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/
Redirecting Console Input
Is there a way to redirect console input /to/ (actually /from/ ;-) ) a file, for say a Vista console (CLI) command like 'sc'? I've tried: sc Ys.in sc.help.txt Where 'Ys.in' is a file containing a bunch of 'Y's, which is what 'sc' is waiting for. 'sc' ignores the file and waits for me to type 'Y', before it resumes the help output to stdout. I tried googling, but that was about as effective as US Government oversight of the financial sector. I don't seem to have the magic bean terms, or perhaps there is no such technique/utility. BTW, if this weren't tough enough, I'm running Vista 64bit. Thanks, Lee -- 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: A $ in my path...
ProblematicRoutes wrote: Mark J. Reed wrote: On Thu, Oct 23, 2008 at 10:34 AM, ProblematicRoutes wrote: This $ sign causes problems everywhere - with latex, with svn, with anything that uses ~ to refer to my home directory, because it expands to ...$/... and bash tries to parse the $/ as a variable. But the workaround, if you have the privileges to do it, would be to make a $-less symbolic link and change your passwd entry to I will try yours and Sid's solutions tomorrow (I think they're the same idea? Correct me if I've misunderstood your suggestion!) when I'm back in the office, and hopefully they will fix the problem. Andrew If shortcuts don't work, here's two other ideas: * Cygwin mount -- mount a sane path to the problematic path * NTFS junction point (like a *ux soft link) -- junction a sane path to the problematic path -- 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/
