[PATCH] Cygwin: Correct /proc/*/stat for processes without ctty
Hi, I had noticed that selecting or excluding processes without a controlling terminal doesn't work in procps on Cygwin. For example, the mintty process shouldn't appear in the following, as the 'f' (for forest) argument triggers procps's "BSD personality", where processes without a controlling terminal are supposed to be excluded by default: $ procps f PID TTYSTAT STIME COMMAND 1809 ? Ss19:49 /usr/bin/mintty - 1810 pty0 Ss19:49 \_ -zsh 2075 pty0 R 21:14 \_ procps f Similarly, this should list the processes without a terminal, but comes up empty: $ procps -t - I tracked this down to a difference in the tty field of /proc/*/stat (which is the 7th field). On Linux, processes without a terminal have value 0 there, and that's what procps expects. Cygwin 3.3 has -1 instead, whereas on master the bits of the tty field were rearranged in commit 437d0a8f88, which turns the -1 into 268435455 (i.e. 0xFFF). Either way, procps treats such processes as having terminals. (The ? in the TTY column output is generated by a different code path in procps that uses /proc/*/ctty on Cygwin.) Patches for the 3.3 branch and master attached. Regards, Andy 0001-Cygwin-proc-stat-ctty.patch Description: Binary data 0001-Cygwin-proc-stat-ctty-3.3.patch Description: Binary data
Re: [ANNOUNCEMENT] Updated: procps-ng 4.0.1-1
On Wed, 9 Nov 2022 at 18:06, Achim Gratz wrote: > > Andy Koppe writes: > Hmm. The man page exists and gets built (albeit as ps.1), but not > installed apparently. I'll have to check why that is happening and if > it's a bug or just some missing configuration. > > > I gather libproc has been rolled into the procps-ng package? > > No. Part of the 4.x branch is that the library has been renamed > libproc2 and it continues to be available as a separate package. Thanks for clarifying. > > It still pulls in libprocps8 at version 3.3.17-1 as a dependency, but > > I guess that's due to a setup.exe limitation? > > Huh? It doesn't do that here, which package has that dependency on your > installation? I can't reproduce it either, so apologies for the false alarm. Regards, Andy -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: [ANNOUNCEMENT] Updated: procps-ng 4.0.1-1
On Sat, 22 Oct 2022 at 20:20, Achim Gratz wrote: > The package procps-ng has been updated to its latest upstream version. > > This package provides command line and full screen utilities for > browsing procfs, a pseudo file system dynamically generated by the > kernel to provide information about the status of entries in its process > table (such as whether the process is running, stopped, or a zombie). > > It contains free, prockill, pkill, pgrep, pmap, procps, tload, top, > uptime, vmstat, w, and watch. Hi Achim, Thanks for the update. I noticed the procps(1) manpage has gone missing, although there is a procps(3) for the libproc API now. I gather libproc has been rolled into the procps-ng package? It still pulls in libprocps8 at version 3.3.17-1 as a dependency, but I guess that's due to a setup.exe limitation? Regards, Andy -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: [mintty] Suppress a key completely
On Sun, 10 Jul 2022 at 15:35, Andrey Repin wrote: > > Greetings, All! > > I'm experimenting with programs to replace my current keyboard switcher (which > is good, but do not behave well with "modern" idiotic applications based on > Chromium/Electron). > found one that works nearly exactly as I'd like, but one problem had arisen: > to implement non-intrusive "CapsLock as keyboard switch" functionality, it > using native Windows functionality to remap the key to F24, and use that one > to switch layouts. Everything is good until I launch mintty, where every press > of the key prints "5~" in console in addition to switching the layout. > I suppose it is in its own right on this one (the key is real, after all), but > is there a way to filter the key so that it does not get down to the > applications? Hi Andrey, I think adding this setting to the .minttyrc should do the job: KeyFunctions=F24:void Alternatively, if you get a choice in the matter, you might want to use the even more obscure yet quite fittingly named VK_SELECT (0x29) as your switching keycode. Also, Windows has the builtin Win+Space combination for switching keyboards, but I expect you've tried that. Regards, Andy -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: [ANNOUNCEMENT] Updated: mintty 3.6.1
On Sun, 24 Apr 2022 at 15:42, Thomas Wolff wrote: > > I have uploaded mintty 3.6.1 with the following changes: > > Window handling >* Terminal reflow (#82, #219): fixed crash condition on irregular > reflow chunks. >* Terminal reflow (#82, #219): fixed memory leak. > > Terminal features >* Visual input feedback: don't obscure text when just pressing Alt. >* Separate foreground and background values for ANSI colours (#1151). >* OSC 7704 for setting ANSI colours distinct from palette colours > (#1151). > > Keyboard handling >* Support longer multi-char keyboard input (a.k.a. "ligatures" in > Windows) (#1155). > > Configuration (contributed by Andy Koppe) >* ANSI colour specification accepts foreground ; background values > (#1151). >* Tuned themes helmholtz (default) and kohlrausch for legibility (#1156). > > The homepage is at http://mintty.github.io/ > It also links to the issue tracker. Thanks Thomas. In the default 'helmholtz' theme, the separate foreground and background colour settings are used for blue, red, magenta and grey (aka "BoldBlack"), with the background variants darker than the foreground ones. Foreground blue is significantly brighter again than before, to help readability on a black background. It's still not as bright as the other colours, because it's also often used on bright backgrounds, but I think it now looks ok in syntax highlighting schemes that use it. The 'kohlrausch' theme is repurposed as a black-on-white version of 'helmholtz', with the foreground colour variants darker than the background ones. It's probably best used with the "show bold as font" mode. Note that as the theme contains settings for the default foreground and background colours, those can't then be changed in the options dialog. To be able to change them anyway, copy the colour settings from /usr/share/mintty/themes/kohlrausch into ~/.minttyrc and remove the ThemeFile setting. Andy -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: [ANNOUNCEMENT] Updated: mintty 3.6.0
On Fri, 25 Mar 2022 at 18:18, Thomas Wolff wrote: > > I have uploaded mintty 3.6.0 with the following changes: > > Highlights >* Optional feature: Reflow terminal lines when resizing terminal width. >* Visual feedback of numeric or composed character input. >* New themes helmholtz and luminous (contributed by Andy Koppe). >* Setting helmholtz theme as default colour scheme. > > Window handling >* Reflow terminal lines when resizing terminal width (#82, #219, > mintty/wsltty#154). > > Terminal features >* Tweak pending auto-wrap state affected when switching wrap modes. >* Fixed unscroll (CSI +T) in case width has changed meanwhile. >* Visual feedback of numeric or composed character input. > > Keyboard handling >* Support user-defined mappings for Super-/Hyper-modified character keys. >* Support optional user-defined mappings for Control-/Alt-modified > character keys (#399, #252, #523, #602, #645, ~#524, ~#817, ~#451). >* Suspend shortcut handling during numeric character input. >* Revise and fix numeric character input. >* Distinct Unicode vs. hexadecimal numeric character input. >* Menu key opens menu inside terminal, also stops numeric input. >* Fixed Compose sequences with more than 2 characters (broken since > 3.1.5). > > Font rendering >* Right-to-left font fallback (#1148). >* Fixed auto-widening of ambiguous-width letters (broken since 3.4.4). >* Speedup rendering of replacement indication of invalid character > codes (#1145). >* Extend cell zoom to some Geometric Shapes U+25E2.., Dingbats > U+1F67C.., and Symbols U+1FB00..U+1FBB3. > > Startup >* Trimming irrelevant and possibly confusing environment variables > before child invocation (xterm). > > Configuration >* New themes helmholtz and luminous (contributed by Andy Koppe). >* Setting helmholtz theme as default colour scheme. >* New option -Rt to report the tty name of the child process / shell. >* New option ShootFoot (#399, #252, #523, #602, #645, ~#524, ~#817, > ~#451). >* New option RewrapOnResize (#82), interactive (Options dialog). >* New user-definable function unicode-char. >* Updated X11-derived data: compose sequences and colour names. > > The homepage is at http://mintty.github.io/ > It also links to the issue tracker. This is years too late, but I'd still like to take this opportunity to say a huge Thank You to Thomas for rescuing mintty from the ashes of Google Code and maintaining and developing it so well since. The rewrap on resize is another great and long-requested feature he's added. It's on the Window page of the options for anyone who wants to give it a try. Re the colour themes, my original default has orderly colour values, but rather uneven actual colours. For example, non-bold blue is barely legible on a black background, and red is significantly darker than green in diffs. So I tried adjusting the colours to equal luminance according to the formulas of the sRGB colour space, which resulted in the 'luminous' theme. Unfortunately that has pretty much the opposite problem of the original: e.g. red is too bright and yellow is too dark. And that's because of this: https://en.wikipedia.org/wiki/Helmholtz-Kohlrausch_effect As I didn't find a suitable formula to compensate for that, I used experimentally determined correction factors to get to roughly (and subjectively) equal brightness, resulting in the 'kohlrausch' theme. The 'helmholtz' theme that is now the default is identical to that, except for a somewhat darker non-bold blue, as a compromise between legibiility on black and use as a background colour itself in programs like mc. The bold blue is similar to what's used for links on dark-themed websites. The original theme can be restored using the 'mintty' entry in the dropdown on the 'Looks' page of the options. Existing colour customisations should not be affected by the change of default. Andy -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: Closing the Command Prompt using the "x" button doesn't update shell history file
On Thu, 24 Mar 2022, 08:34 Takashi Yano wrote:
> On Wed, 23 Mar 2022 15:11:20 -0400 Mitchell Hentges wrote:
> > To reproduce the issue:
> > 1. Run Cygwin.bat to open a Cygwin shell in the "Command Prompt" terminal
> > 2. Run some command, such as "echo test"
> > 3. Click the Windows "x" button in the top-right corner of the terminal
> >
> > The terminal closes, but `$HOME/.bash_history` is not updated to include
> > the "echo test" command.
> > Interestingly, when using mintty, the shell history is indeed saved when
> > the "x" button is pressed.
>
> I looked into this problem, and found cygwin sends SIGHUP on
> window closure, however, bash is terminated before SIGHUP is
> processed.
>
> The following patch solves the issue, however, I wonder if
> there is better way to wait completion of signal handling.
>
> diff --git a/winsup/cygwin/exceptions.cc b/winsup/cygwin/exceptions.cc
> index f946bed77..87b419ea7 100644
> --- a/winsup/cygwin/exceptions.cc
> +++ b/winsup/cygwin/exceptions.cc
> @@ -1119,6 +1119,7 @@ ctrl_c_handler (DWORD type)
> {
> sig_send (NULL, SIGHUP);
> saw_close = true;
> + Sleep (100);
> return FALSE;
> }
>if (!saw_close && type == CTRL_LOGOFF_EVENT)
Rather than have a timeout, how about just sending SIGHUP first time
around, on the assumption that the shell will usually quit on that. If
it doesn't, a second click on the close button could kill it more
forcefully.
Andy
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: xterm (or x11) pastes are highlighted
On Fri, 18 Mar 2022 at 07:23, n952162 wrote: > > Am 18.03.2022 um 00:22 schrieb Andy Koppe: > > On Thu, 17 Mar 2022 at 20:32, René Berber wrote: > >> On 3/17/2022 1:03 PM, n952162 wrote: > >> > >>> Does anyone know how I can disable the highlighting that occurs when I > >>> copy and paste in xterm? > >>> > >>> Escape sequences are added to achieve that and sometimes they're not > >>> being properly interpreted. > >>> > >>> Why would I want that anyway? > >> The same thing happens to (plain, non X windows) mintty. > >> > >> It started recently, maybe a couple of weeks. No idea how to fix it, > >> haven't really tried. > >> > >> Very annoying. > > It came in with the readline 8.1 update in September last year, which > > enabled "bracketed paste mode" by default. (I think zsh has had it > > enabled for a few years.) > > > > As n952162 said, it tells the terminal to enclose pasted text in > > escape sequences. > > > > There are several points to this: > > - It stops accidental multi-line pastes from getting immediately > > executed line by line. > > - It makes it easier to undo a paste, as you can cut it out in one go > > rather than deleting manually. > > - Pasting can be faster, as the application can process the paste in > > one chunk rather than treating it as char-by-char keyboard input. > > > > But yep, sometimes it can go wonky, in particular when the bracketing > > mode for some reason is left on for an application that doesn't expect > > it. > > > > For readline, it can be disabled in ~/.inputrc: > > > > set enable-bracketed-paste off > > > > Regards, > > Andy > > > Andy, perhaps you can speak to another, almost related issue, which I > posted on 10th of March: > > /xterm*VT100.Translations only when mouse is over the window with focus/ > > A copy is attached here. This is only a Cygwin issue, as far as I know. > > Perhaps you can recommend someone who I could turn to, to get a fix, an > explanation, a workaround, or help to get started doing a fix? I'm afraid I can't help with that, but hopefully the Cygwin/X maintainer has seen your report. It might be interesting whether it happens in the different XWin modes (single window, rootless, multiwindow), or on a Linux host. -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: xterm (or x11) pastes are highlighted
On Thu, 17 Mar 2022 at 20:32, René Berber wrote: > > On 3/17/2022 1:03 PM, n952162 wrote: > > > Does anyone know how I can disable the highlighting that occurs when I > > copy and paste in xterm? > > > > Escape sequences are added to achieve that and sometimes they're not > > being properly interpreted. > > > > Why would I want that anyway? > > The same thing happens to (plain, non X windows) mintty. > > It started recently, maybe a couple of weeks. No idea how to fix it, > haven't really tried. > > Very annoying. It came in with the readline 8.1 update in September last year, which enabled "bracketed paste mode" by default. (I think zsh has had it enabled for a few years.) As n952162 said, it tells the terminal to enclose pasted text in escape sequences. There are several points to this: - It stops accidental multi-line pastes from getting immediately executed line by line. - It makes it easier to undo a paste, as you can cut it out in one go rather than deleting manually. - Pasting can be faster, as the application can process the paste in one chunk rather than treating it as char-by-char keyboard input. But yep, sometimes it can go wonky, in particular when the bracketing mode for some reason is left on for an application that doesn't expect it. For readline, it can be disabled in ~/.inputrc: set enable-bracketed-paste off Regards, Andy -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
shell-init: error retrieving current directory
This might be the same issue as a couple of previous unresolved reports with the same error message, but I'm not sure, so here's a new thread. Steps to reproduce: - On Windows 7, install 64-bit Cygwin into C:\cygwin, and let it create a desktop shortcut. - Edit /etc/fstab to change the cygdrive prefix to /. - Double click 'Cygwin64 Terminal' desktop shortcut. Result: a bunch of errors before the bash prompt. shell-init: error retrieving current directory: getcwd: cannot access parent directories: Bad file descriptor job-working-directory: error retrieving current directory: getcwd: cannot access parent directories: No such file or directory job-working-directory: error retrieving current directory: getcwd: cannot access parent directories: No such file or directory job-working-directory: error retrieving current directory: getcwd: cannot access parent directories: No such file or directory chdir: error retrieving current directory: getcwd: cannot access parent directories: No error The errors remain if the shortcut target is changed from invoking mintty to invoking bash directly: 'C:\cygwin\bin\bash.exe -l'. The errors go away if 'C:\cygwin\bin' is put into the shortcut's otherwise empty 'Start In' field. (But they stay if 'C:\' is put there instead.) They also go away if the cygdrive prefix is changed to anything but the root directory. I couldn't reproduce the issue with a 32-bit install. Regards, 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
Re: Redirecting cat and paste to file gives garbage
On 8 August 2013 17:07, Ryan Johnson wrote: On 08/08/2013 11:48 AM, Corinna Vinschen wrote: On Aug 8 17:32, Corinna Vinschen wrote: On Aug 8 09:48, Ryan Johnson wrote: Hi all, (no, that's not a typo in the subject line) 64-bit install, bash inside mintty, all latest packages with the cygwin1.dll snapshot shown below... # --- begin STC --- $ uname -a CYGWIN_NT-6.1 ryan-laptop-v02 1.7.23s(0.268/5/3) 20130729 19:11:42 x86_64 Cygwin $ echo Reading /dev/clipboard # hit [shift]+[insert] to paste # (hopefully 8 characters is not too long to paste into a TTY) # then hit ^D to finish $ cat tmp.txt $ cat tmp.txt Rg eRaedaidnign g The only idea I have is this. The clipboard data is stored as CF_UNICODETEXT and as the Cygwin-private CYGWIN_NATIVE_CLIPBOARD format. How's shift-insert implemented in mintty? If it reads the CF_UNICODETEXT part and sends it to the pty unchanged, that could explain this behaviour. The pty already gets 16 chars. And pasting the text into CMD or, FWIW, any Windows console window works as expected. So this looks like a mintty bug right now. That's what I thought at first, too, but it pastes fine directly into the terminal... and then I had a brain cramp and didn't add that to the STC: $ echo reading /dev/clipboard # press [shift]+[insert] here... $ echo reading Still a mintty bug? Don't think so. Mintty has no idea what it's pasting to; it just writes the clipboard content to the pty (which it obtains from CF_UNICODETEXT and converts to the current charset). I couldn't reproduce the problem with 1.7.22, but I could with the 20130729 snapshot. With 1.7.22, when you paste during the 'cat tmp.txt', the text is correctly echoed back to the terminal and put into the file. With the snapshot, it looks like the actual input and the echo both end up in the file. 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
Re: BLODA extension: console interoperability
On 26 July 2013 05:14, Warren Young wrote: On 7/25/2013 17:06, Larry Hall (Cygwin) wrote: I might personally prefer to describe and list them differently. DONOPWOL: DOes NOt Play Well with Others List I don't think that's fair, since such apps were designed for the Windows console, without being aware of Cygwin's pipe-based ptys. And unfortunately that list would be very long anyway: basically anything interactive that hasn't been explicitly adapted to Cygwin ptys, for example by disabling buffering and not relying on the console's history facility. Speaking of which: somebody on the mintty mailing list would like to make a Windows program Cygwin-aware by detecting whether it's running in a Cygwin terminal (as opposed to having its input or output redirected to plain pipes). Does anyone know a way to do this? https://groups.google.com/forum/#!topic/mintty-discuss/NKXaYjF8jqk 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
Re: pty issue causes 'screen' to hang when run from mintty as detached
On 11 June 2013 01:51, Andrew Schulman wrote: See here for additional information and reproducible steps in the mintty support ticket: https://code.google.com/p/mintty/issues/detail?id=390 I can reproduce this using cygwin 1.7.20, 1.7.19, 1.7.18, 1.7.15, and 1.7.7. Screen does NOT hang when is is created by calling the first command through cygwin started by cygwin.bat (commands typed through Windows terminal 'cmd.exe' instead of mintty) and then attempting to attach through mintty with the second command. Workaround is to use: 'cygstart --hide screen -S name -d -m' I get a little different result: $ screen -S scrn -d -m $ screen -S name -x Remove dead screens with 'screen -wipe'. $ and then I have to run 'reset' to get input echoing back. I've never observed this behavior before, because I always start screen as 'screen -AURD', which works fine. Do we have any idea whether the problem is with mintty or with screen? I observed the same behaviour as the OP, but also reproduced it in rxvt and xterm, so not a mintty issue. Since it works in a console, the Cygwin pty layer has to be the main suspect, unless screen has specfic code for Cygwin consoles or ptys? 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
Re: 64-bit toolchain questions
On 17 May 2013 08:07, Fedin Pavel wrote: Hello! I have noticed that Cygwin64 toolchain is available and installed it. Then i tried to compile a simple Hello world using it. A 64-bit .exe file was created. I am even able to start this file from terminal, but it prints nothing. What's wrong ? You need a 64-bit Cygwin install to run it in. Well, actually just the 64-bit cygwin1.dll in case of Hello World. Unfortunately you don't get an error message in case of a missing DLL. ftp://cygwin.com/pub/cygwin/64bit/setup64.exe (Warning: this is still very much in beta.) 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
Re: Setup.exe - pending view does not show all pending packages
On 17 May 2013 14:10, David Balažic wrote: Hi! If I start Setup.exe v2.774 on a PC where cygwin is already installed and I select to install new package (not yet installed), then the Pending view only shows this selected package and misses all the other pending packages (they would be upgraded as a newer version is available). I'd guess you used the search box to find the new package, and didn't clear it afterwards, so the Pending view was still being filtered by your search term. 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
Re: Base Cygwin now requires Python?
On 16 May 2013 07:41, Steven Penny wrote: Because of this dependency line mintty cygutils Hmm, mintty doesn't depend on cygutils anymore since setup.exe creates the Cygwin Terminal shortcut for it, and its setup.hint reflects that. Yet setup.ini does indeed contain the following line for mintty: requires: bash cygutils cygwin Is the problem that the setup.hint doesn't contain a 'requires:' line at all (since mintty has no dependencies apart from the implicit 'cygwin')? Does upset keep previous dependencies in that case? Andy
Re: Base Cygwin now requires Python?
On 16 May 2013 23:59, Christopher Faylor wrote: On Thu, May 16, 2013 at 07:39:59PM +0100, Andy Koppe wrote: On 16 May 2013 07:41, Steven Penny wrote: Because of this dependency line mintty cygutils Hmm, mintty doesn't depend on cygutils anymore since setup.exe creates the Cygwin Terminal shortcut for it, and its setup.hint reflects that. Yet setup.ini does indeed contain the following line for mintty: requires: bash cygutils cygwin Is the problem that the setup.hint doesn't contain a 'requires:' line at all (since mintty has no dependencies apart from the implicit 'cygwin')? Does upset keep previous dependencies in that case? What??? No! Of course it doesn't! What a daft notion! Oh. Actually, now that I think of it, the way upset is run, it's the union of an existing setup.ini and setup.hint. So, if there is no requires: line it would get pulled from setup.ini. I've taken the liberty of adding a requires: line to mintty's setup.hint. Thanks, I've updated the copy in mintty svn accordingly. Andy
Re: What comes with Cygwin?
On 14 May 2013 15:26, Warren Young wrote: On 5/14/2013 07:28, Andrew Pennebaker wrote: I'm looking through the docs, but I can't find a comprehensive list of which executables come with Cygwin by default. It changes from time to time. The basic rule is, whatever is in the Base category in the package repository. At the moment, that's these packages: alternatives, base-cygwin, base-files, bash, coreutils, cygwin, cygwin-docs, dash, editrights, file, findutils, gawk, grep, gzip, ipc-utils, libgcc1, libreadline7, login, man, mintty, rebase, run, sed, tar, terminfo, tzcode, vim-minimal, which, zlib0 I think there are additional ones that get pulled in as dependencies of the Base packages. One that I'm aware of is cygutils, which is pulled in by cygwin-docs. 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
Re: mintty, xterm and rxvt freezes when displaying a binary stream
On 13 May 2013 22:35, Adrian H wrote: I inadvertently dumped a binary stream to the terminal and it froze mintty. When I tried to kill the process dumping the data, it wouldn't die, even when using -9 switch. When I used Process Explorer to kill it, it died and mintty resumed working. I narrowed the stream down to 370 'lines' by catting the file and heading and tailing its output. For some reason, I wasn't able to narrow it down any further. This issue doesn't occur within cmd running bash (bash is what is running through mintty when this occurred). I've also tested it with xterm and rxvt and they also froze the terminal, so it appears to be something to do with the terminal interpreter which may be shared across these three terminal programmes. I've tried to attached the compressed narrowed down stream for you viewing pleasure, but this mailing list doesn't support it. If anyone wants to debug this further, just tell me where to put the binary file and you can do your thing. Not sure what that stream is doing to the terminal to do that to the process, but I don't think it should be doing that. Any idea what's happening? http://cygwin.com/ml/cygwin/2013-04/msg00362.html 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
Re: mintty, xterm and rxvt freezes when displaying a binary stream
On 14 May 2013 01:23, Jack Adrian Zappa wrote: On Mon, May 13, 2013 at 5:45 PM, Andy Koppe wrote: On 13 May 2013 22:35, Adrian H wrote: I inadvertently dumped a binary stream to the terminal and it froze mintty. When I tried to kill the process dumping the data, it wouldn't die, even when using -9 switch. When I used Process Explorer to kill it, it died and mintty resumed working. http://cygwin.com/ml/cygwin/2013-04/msg00362.html Sounds like its related, however, if I only send 369 of the 370 lines, it is fine and the characters sent to the terminal end up on my command line. I.e. I get this on my command line after the cat of 369 lines. $ 1;2c1;2c1;2c Which is part of the return string sans the leading \x5b\x3f a.k.a. \e[. The \e[ is swallowed by bash/readline. According to that link, you provided, it sounds like only one key is necessary to cause this problem. It also requires a large amount of output from the application, so that the pty's output buffer overflows and hence the application's write() to it blocks. In any case, how does Linux deal with this issue? I don't know. A buffer on the terminal's side of the pty? Automatic deadlock detection in the kernel, causing one of the blocking writes to fail? 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
Re: BUG: Pasting Smiling Cat with Heart-Shaped Eyes into ZSH locks MinTTY, requires force close
On 23 April 2013 17:58, Jeff Crowell wrote: Bug report below. Let me know if you need anything else Product: zsh/MinTTY Version: zsh 5.0.2 (i686-pc-cygwin) Component: In which component does the bug exist? Platform: i686-pc-cygwin OS: Windows 8, probably all versions of windows Summary: Pasting certain characters into MinTTY running zsh locks up MinTTY requiring a force close Steps to Reproduce: 1) Copy http://www.fileformat.info/info/unicode/char/1f63b/index.htm 2) paste into ZSH 3) press enter Actual Results: MinTTY hangs and does not respond Works fine for me, except that apparently zsh doesn't support UTF-16 surrogate pairs, so they're shown as separate codepoints: d83dde3b. Line editing works fine though. Result: zsh: command not found: \ud83d\ude3b So, more info needed: please see http://cygwin.com/problems.html, in particular: Run cygcheck -s -v -r cygcheck.out and include that file as an attachment in your report. Also, does the CPU usage shoot up? And what's the output of 'ps' (in a separate window, obviously)? (Note besides: bash actually displays the cat character, but treats it as if it was two characters, so line editing goes wrong with the cursor wandering off the line and that sort of thing. Surrogate pairs do work properly in vim, emacs and mined.) 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
Re: BUG: Pasting Smiling Cat with Heart-Shaped Eyes into ZSH locks MinTTY, requires force close
On 23 April 2013 18:32, Christopher Faylor wrote: Similar happens when doing: cat /bin/gdb.exe for example. Something seems to overflow. I can reproduce that one. 'ps' output shows that 'cat' and 'mintty' are both waiting for output to finish, i.e. they're deadlocked waiting for each other's output to be read. O827667648276 3860 pty01004 20:52:17 /usr/bin/cat O3448 13448 3448 ? 1004 20:34:15 /usr/bin/mintty It's a long-standing problem for which there is no easy fix. Yep. This situation also happens if you hit a key that sends something during an ongoing cat command. I think what's happening in this particular case is that the gdb binary contains some control sequence that triggers a response to be sent by the terminal, thus triggering this issue in Cygwin's pty implementation. For now Just don't do that. Quite. Or just kill the cat. 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
Re: mintty and Control-` , Control-~
On 21 March 2013 15:53, Ryan Johnson wrote: On 21/03/2013 11:30 AM, Igor Bukanov wrote: It seems that mintty in Cygwin under Windows-7 does not pass C-` (Control-backtick, in US keyboard this is the key above the tab) nor C-~ (or Control-Shift-backtick) to terminal applications. Any reason for that? A quick test [3] in shortcut override mode [1] suggests that mintty never receives that key combination in the first place. Nah, it does receive it alright. Well, for me anyay. Shortcut override mode only affects combinations that mintty normally uses for its own purposes, for example Shift+Insert for paste. However, trying the same test in xterm, I get \000 and \036 for C-` and C-~, respectively. Neither of those seems to be correct [2] (\000 is ^@ and \036 is ^^) Indeed. Backtick and tilde don't directly correspond to control characters, so mintty doesn't send anything for them. What you can do is enable the so-called modifyOtherKeys mode (which comes from xterm), in which case mintty sends the keycodes specified on the following page for combinations that don't have a standard keycode: http://www.leonerd.org.uk/hacks/fixterms/ The following will enable modifyOtherKeys mode level 1: $ echo -ne '\e[4;1m' There's also a level 2, in which those special keycodes are sent even for standard combinations such as Ctrl+letter. $ echo -ne '\e[4;2m' but it's still odd that xterm can receive key codes that mintty misses. I guess I decided not to support those keycodes for Ctrl+` and Ctrl+~ because they're not intuitive and they just send the same as Ctrl+@ and Ctrl+^ (and also Ctrl+Space and Ctrl+Enter) anyway. In order to make them useful without enabling modifyOtherKeys mode, how about if Ctrl combinations with backtick (ASCII 0x60), opening and closing brace (0x7B and 0x7D), pipe (0x7C), and tilde (0x7E) were mapped to C1 control characters (in the U+0080 to U+009E range). Incidentally, on US and UK keyboards (and others) that's what already happens for the braces and pipe symbol, because for example the pipe symbol is typed with Shift+\, and mintty maps Ctrl+Shift+\ to U+009C as explained at http://code.google.com/p/mintty/wiki/Keycodes#Ctrl. I hope I've suitably confused matters now. 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
Re: mintty and Control-` , Control-~
On 20 April 2013 21:28, Thomas Wolff wrote: In order to make them useful without enabling modifyOtherKeys mode, how about if Ctrl combinations with backtick (ASCII 0x60), opening and closing brace (0x7B and 0x7D), pipe (0x7C), and tilde (0x7E) were mapped to C1 control characters (in the U+0080 to U+009E range). I don't think it's useful to support C1 control characters because virtually nobody will ever want to input them via keyboard; I don't know of applications that need those by default either; the point is to make such key combinations available for custom mappings in places such as ~/.inputrc and ~/.vimrc. even more if only a random subset of C1 can be supported this is only confusing. The entire set is supported already. See http://code.google.com/p/mintty/wiki/Keycodes#Ctrl. 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
Re: `perldoc` and terminal size
On 18 April 2013 22:27, terminatorul wrote: Hello I am using `perldoc` to read the perl manual pages.I can use the black background it gives in mintty with a full-screen console, with low light intensity so I can read it during night o I can use the black background in mintty with a full-screen console window with low-light conditions during night or when someone else is sleeping. But it has the problem that it formats and displays text with a limited with (of 80 character columns I guess), despite my mintty window being twice as wide. I tried it on a Linux system and there `perldoc` uses the entire console width. Currently I have to use something like PAGER=lynx -force_html -xhtml_parsing -nocolor \ perldoc -o xhtml perl but I would still like the man format if possible. Is there an option to fix the display width for `perldoc` in cygwin to the console width ? I'm afraid I don't know, this is just to say that the same happens when running in a console or xterm, so this does indeed appear to be an issue with perldoc's setup. 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
Re: Recent cygport and cygwin-specific READMEs [Was: Re: GCC-4.7.2-2: Go/No-go?]
On 14 April 2013 04:45, Yaakov (Cygwin/X) wrote: On 2013-04-13 00:55, Andy Koppe wrote: Cygport prints mintty requires: at the end, which is correct as it doesn't require anything beyond the Cygwin DLL, but there's no setup.hint. As Corinna already pointed out, this is a sign that the setup.hint generation succeeded, and in this case the requires: line is blank (and rightfully so, since mintty uses only cygwin1.dll and Win32 APIs). If it had failed, there would have been a warning about a missing .hint file instead. I've also tried installing cygport from git master but got this after running ./autogen.sh make: make: *** No rule to make target `data/gnuconfig/config.guess', needed by `all-am'. Stop. This is one quirk of git that I've never understood: git clone does not expand submodules by default without the --recursive flag. Run git submodule update --init to get these after a clone. Yep, that did it. BTW: _CYGPORT_RESTRICT_postinst_doc_=1 Variables beginning with an underscore are for internal use only. This should be RESTRICT=postinstall-doc. But what problem did you encounter to necessitate this? Took me a while to remember, but it's there to stop the LICENSE file from being installed, because that's the same as /usr/share/doc/common-licenses/GPL-3.0. RESTRICT=postinstall-doc didn't do this, but RESTRICT=postinst_doc does. Thanks, Andy
Re: Recent cygport and cygwin-specific READMEs [Was: Re: GCC-4.7.2-2: Go/No-go?]
On 13 April 2013 10:03, Corinna Vinschen wrote: On Apr 13 06:55, Andy Koppe wrote: On 11 April 2013 23:37, Yaakov (Cygwin/X) wrote: On 2013-04-11 07:37, Charles Wilson wrote: #2) Is it possible to use the auto-setup.hint-generator functionality for multi-part package sets (e.g. which contain multiple separate tarballs, in addition to -src and -debuginfo)? If so, how? Yes; it just works, and also handles inter-subpackage dependencies (e.g. apps in foo will dep libfooX, and implibs in libfoo-devel will dep the corresponding DLL in libfooX). Just define CATEGORY/SUMMARY/DESCRIPTION (there are also subpackage-specific variants of these) and omit the hint files from $C; at the end of the package stage, cygport will show you the dependencies it computes for each package so you can check them. I'm struggling to get setup.hint generation to work. Is it supported with cygport 0.11.3 as currently in the distros? Below is the mintty.cygport I've got. Do I need to do anything else to trigger it? Cygport prints mintty requires: at the end, which is correct as it doesn't require anything beyond the Cygwin DLL, but there's no setup.hint. Sure? Did you look into the dist subdir in your builddir after the install stage? It should contain a complete mintty dir for upload. You're right, there is, inside the working directory created by cygport, and it looks correct. I'd expected the setup.hint to appear next to the .cygport and the packaged .tar.bz2 files. Thanks, Andy
Re: Recent cygport and cygwin-specific READMEs [Was: Re: GCC-4.7.2-2: Go/No-go?]
On 11 April 2013 23:37, Yaakov (Cygwin/X) wrote:
On 2013-04-11 07:37, Charles Wilson wrote:
#2) Is it possible to use the auto-setup.hint-generator functionality
for multi-part package sets (e.g. which contain multiple separate
tarballs, in addition to -src and -debuginfo)? If so, how?
Yes; it just works, and also handles inter-subpackage dependencies (e.g.
apps in foo will dep libfooX, and implibs in libfoo-devel will dep the
corresponding DLL in libfooX). Just define CATEGORY/SUMMARY/DESCRIPTION
(there are also subpackage-specific variants of these) and omit the hint
files from $C; at the end of the package stage, cygport will show you the
dependencies it computes for each package so you can check them.
I'm struggling to get setup.hint generation to work. Is it supported
with cygport 0.11.3 as currently in the distros? Below is the
mintty.cygport I've got. Do I need to do anything else to trigger it?
Cygport prints mintty requires: at the end, which is correct as
it doesn't require anything beyond the Cygwin DLL, but there's no
setup.hint.
I've also tried installing cygport from git master but got this after
running ./autogen.sh make:
make: *** No rule to make target `data/gnuconfig/config.guess', needed
by `all-am'. Stop.
Andy
mintty.cygport:
NAME=mintty
VERSION=1.2-beta1
RELEASE=1
CATEGORY=Base Shells
DEPEND=make gcc-core w32api
HOMEPAGE=http://mintty.googlecode.com;
SRC_URI=http://mintty.googlecode.com/files/mintty-${PV}-src.tar.bz2;
SUMMARY=Terminal emulator with native Windows look and feel
DESCRIPTION=\
Mintty is a terminal emulator for Cygwin. It is based on code
from PuTTY 0.60 by Simon Tatham and team.
Features include:
* Xterm-compatible terminal emulation.
* Full Unicode support.
* Native Windows user interface that tries to keep things simple.
* Graphical options dialog. Options stored in a text file.
* Drag drop and copy paste of text, files and folders.
* Extensive mouse support.
* Window transparency.
_CYGPORT_RESTRICT_postinst_doc_=1
src_compile() {
lndirs
cd ${B}
cygmake
}
src_install() {
cd ${B}
dobin mintty.exe
insinto /usr/share/man/man1
doins docs/mintty.1
dodoc COPYING
dodoc LICENSE.Oxygen
dodoc LICENSE.PuTTY
}
[ANNOUNCEMENT] Updated: mintty-1.1.3-1
mintty 1.1.3-1 is on its way to the Cygwin mirrors.
CHANGES
===
- Tweaked cursor colour handling to avoid the cursor becoming
invisible under certain circumstances.
- Fixed incorrect response to OSC sequence for querying colour settings.
- Page-by-page scrolling now scrolls by one line less than a whole page.
- Added 'AppID' setting for overriding the default taskbar grouping on
Windows 7 and above. (Note that the AppID of a pinned shortcut is
separate from that of the program pointed to. It can be set with the
free win7appid utility.)
Previous changes can be found at http://code.google.com/p/mintty/wiki/Changes.
DESCRIPTION
===
Mintty is a terminal emulator for Cygwin with a native Windows user
interface and minimalist design. Among its features are Unicode
support and a graphical options dialog. Its terminal emulation is
largely compatible with xterm, but it does not require an X server.
QUESTIONS
=
The mintty manual is installed as a manpage ('man mintty'). It is also
available at http://mintty.googlecode.com/svn/tags/1.1.3/docs/mintty.1.html.
Questions and comments can be sent to the mintty discussion group at
http://groups.google.com/group/mintty-discuss or the Cygwin mailing
list.
Please use the issue tracker at http://code.google.com/p/mintty/issues
to report bugs or suggest enhancements.
To update your installation, click on the Install Cygwin link on the
http://cygwin.com web page. This downloads setup.exe to your system.
Then, run setup and answer all of the questions.
*** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***
If you want to unsubscribe from the cygwin-announce mailing list, look
at the List-Unsubscribe: tag in the email header of this message.
Send email to the address specified there. It will be in the format:
cygwin-announce-unsubscribe-you=yourdomain@cygwin.com
If you need more information on unsubscribing, start reading here:
http://sourceware.org/lists.html#unsubscribe-simple
--
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
Updated: mintty-1.1.3-1
mintty 1.1.3-1 is on its way to the Cygwin mirrors.
CHANGES
===
- Tweaked cursor colour handling to avoid the cursor becoming
invisible under certain circumstances.
- Fixed incorrect response to OSC sequence for querying colour settings.
- Page-by-page scrolling now scrolls by one line less than a whole page.
- Added 'AppID' setting for overriding the default taskbar grouping on
Windows 7 and above. (Note that the AppID of a pinned shortcut is
separate from that of the program pointed to. It can be set with the
free win7appid utility.)
Previous changes can be found at http://code.google.com/p/mintty/wiki/Changes.
DESCRIPTION
===
Mintty is a terminal emulator for Cygwin with a native Windows user
interface and minimalist design. Among its features are Unicode
support and a graphical options dialog. Its terminal emulation is
largely compatible with xterm, but it does not require an X server.
QUESTIONS
=
The mintty manual is installed as a manpage ('man mintty'). It is also
available at http://mintty.googlecode.com/svn/tags/1.1.3/docs/mintty.1.html.
Questions and comments can be sent to the mintty discussion group at
http://groups.google.com/group/mintty-discuss or the Cygwin mailing
list.
Please use the issue tracker at http://code.google.com/p/mintty/issues
to report bugs or suggest enhancements.
To update your installation, click on the Install Cygwin link on the
http://cygwin.com web page. This downloads setup.exe to your system.
Then, run setup and answer all of the questions.
*** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***
If you want to unsubscribe from the cygwin-announce mailing list, look
at the List-Unsubscribe: tag in the email header of this message.
Send email to the address specified there. It will be in the format:
cygwin-announce-unsubscribe-you=yourdomain@cygwin.com
If you need more information on unsubscribing, start reading here:
http://sourceware.org/lists.html#unsubscribe-simple
Re: [64bit RFU] emacs-24.3-3
On 6 April 2013 22:27, Corinna Vinschen wrote:
On Apr 6 16:50, Ken Brown wrote:
D=http://sanibeltranquility.com/cygwin/64bit/release/emacs
wget -x -nH --cut-dirs=3 \
${D}/emacs-24.3-3-src.tar.bz2 \
${D}/emacs-24.3-3.tar.bz2 \
${D}/emacs-X11/emacs-X11-24.3-3.tar.bz2 \
${D}/emacs-X11/setup.hint \
${D}/emacs-debuginfo/emacs-debuginfo-24.3-3.tar.bz2 \
${D}/emacs-debuginfo/setup.hint \
${D}/emacs-el/emacs-el-24.3-3.tar.bz2 \
${D}/emacs-el/setup.hint \
${D}/emacs-w32/emacs-w32-24.3-3.tar.bz2 \
${D}/emacs-w32/setup.hint
Done.
People testing these packages should be aware that the postinstall
scripts will fail to set up the usual /usr/bin/emacs and
/usr/bin/emacsclient symlinks because the alternatives package is
not yet available. So you will have to create your own symlinks if
you want them.
Unfortunately I can't upload. The 64bit/release/emacs dir has only
write permissions for Andy Koppe.
The same goes for yasm and libggi, which are 755 for Marco Atzeri
only. This is weird, the release parent dir has 2775 permissions
and the subdirs should have the same permissions.
Sorry about that.
Andy, Marco, can you please chmod -R g+w the aforementioned directories
ASAP? Thank you.
Done, and umask adjusted in ~/.bashrc.
Andy
Re: [64bit RFU] alternatives-1.3.30c-10
On 6 April 2013 22:37, Ken Brown wrote:
D=http://sanibeltranquility.com/cygwin/64bit/release/alternatives
wget -x -nH --cut-dirs=3 \
${D}/alternatives-1.3.30c-10-src.tar.bz2 \
${D}/alternatives-1.3.30c-10.tar.bz2 \
${D}/setup.hint
Done.
Thanks,
Andy
Re: 64bit: man misconfigured
On 30 March 2013 11:17, Thomas Wolff wrote: Due to changed /etc/man.conf, man64 uses escape sequences for bold display while man32 uses backspace combinations. Backspace combinations? However, the escape sequences are not by default interpreted by less (less -r would work), so that PAGER=less man ... produces garbage display. The 32-bit /etc/man.conf has this: PAGER /usr/bin/less -isrR Whereas the 64-bit one has this: PAGER /bin/less -is As Thomas alludes to, the -r option tells 'less' to pass escape characters through to the terminal rather than turn them into a highlighted ESC. The 32-bit man sources have a source patch that contains the following, so I guess that hasn't been applied in the 64-bit version. -DEFAULTLESSOPT=-is +DEFAULTLESSOPT=-isrR Andy
Re: 64bit: man misconfigured
On 1 April 2013 13:11, Thomas Wolff wrote: Am 01.04.2013 14:03, schrieb Andy Koppe: On 30 March 2013 11:17, Thomas Wolff wrote: Due to changed /etc/man.conf, man64 uses escape sequences for bold display while man32 uses backspace combinations. Backspace combinations? The traditional Unix way to indicate bold, by explicit overprinting, like B^HBO^HOL^HLD^HD. Compare man ls ls.man.out with 32/64 bit versions. Oh, I see. Apparently that's due to another change in the 32-bit source patch, where the -c option is added to the 'nroff' command line. (Note besides: confused as to how that overprinting trick could possibly work in a terminal, I learned that it is implemented by 'less', by translating it to SGR sequences. If you send ls.man.out directly to the terminal, you don't see any bold or underline because a backspace followed by a character will simply replace the previous character rather than do anything special.) Andy
Re: 64bit package: mined
On 30 March 2013 19:44, Thomas Wolff wrote: wget http://towo.net/mined/cygwin/64/mined-2012.22-0.tar.bz2 wget http://towo.net/mined/cygwin/64/mined-2012.22-0-src.tar.bz2 Done. # is this needed? (identical to 32 bit source package) 'fraid so, as it's a completely separate distro. A setup.hint is also needed. I've copied the one from the 32-bit distro. Andy
Re: [64bit RFU] emacs-24.3-2
On 29 March 2013 23:55, Ken Brown wrote:
D=http://sanibeltranquility.com/cygwin/64bit/release/emacs
wget -x -nH --cut-dirs=3 \
${D}/emacs-24.3-2-src.tar.bz2 \
${D}/emacs-24.3-2.tar.bz2 \
${D}/setup.hint \
${D}/emacs-debuginfo/emacs-debuginfo-24.3-2.tar.bz2 \
${D}/emacs-debuginfo/setup.hint
Done. GEN-sware reported no errors against this.
Andy
Re: RFU: cppcheck-1.59-1
On 29 March 2013 22:14, Chris Sutcliffe ir0nh...@gmail.com wrote: Please upload: --- wget -x -nH --cut-dirs=3 \ http://dl.dropbox.com/u/5530441/cygwin/cppcheck/setup.hint \ http://dl.dropbox.com/u/5530441/cygwin/cppcheck/cppcheck-1.59-1.tar.bz2 \ http://dl.dropbox.com/u/5530441/cygwin/cppcheck/cppcheck-1.59-1-src.tar.bz2 \ http://dl.dropbox.com/u/5530441/cygwin/cppcheck/cppcheck-debuginfo/setup.hint \ http://dl.dropbox.com/u/5530441/cygwin/cppcheck/cppcheck-debuginfo/cppcheck-debuginfo-1.59-1.tar.bz2 --- Please feel free to remove anything older than 1.58-1. Done. Andy
Re: building 64 bit packages
On 28 March 2013 13:36, Corinna Vinschen wrote: Hi guys, right now it's only possible to build a 64 bit package using the native toolchain. Yaakov is working on a 32 bit cross toolchain, but this may take another couple of days. Anyway, the latest 64 bit Cygwin DLL seems to be stable enough to call it post-alpha or pre-beta or something like that. So I'd like to invite all of you maintainers to participate in building 64 bit packages, foremost those packages other packages rely upon, like libraries. If you have a 64 bit machine, please try the test release and see if you can build your packages. For the time being, just download ftp://cygwin.com/pub/cygwin/64bit/setup64.exe, install the test distro (what's already existing of it) and do your worst ;) Great stuff. Thanks to the kind person who contributed a mintty package. Andy
Re: building 64 bit packages
On 28 March 2013 14:12, Corinna Vinschen wrote: On Mar 28 15:09, Corinna Vinschen wrote: On Mar 28 14:05, Andy Koppe wrote: On 28 March 2013 13:36, Corinna Vinschen wrote: Hi guys, right now it's only possible to build a 64 bit package using the native toolchain. Yaakov is working on a 32 bit cross toolchain, but this may take another couple of days. Anyway, the latest 64 bit Cygwin DLL seems to be stable enough to call it post-alpha or pre-beta or something like that. So I'd like to invite all of you maintainers to participate in building 64 bit packages, foremost those packages other packages rely upon, like libraries. If you have a 64 bit machine, please try the test release and see if you can build your packages. For the time being, just download ftp://cygwin.com/pub/cygwin/64bit/setup64.exe, install the test distro (what's already existing of it) and do your worst ;) Great stuff. Thanks to the kind person who contributed a mintty package. That's your package ;) I just added a source package for licensing reasons. To be more clear, I simply took the mintty binary you provided a couple of days ago and tar'ed it up. It's not *really* a serious mintty binary package. I've now uploaded a cygport-built mintty 1.2-beta1-1 package. (I've also run ./GEN-sware in /sourceware/ftp/anonftp/pub/cygwin/64bit. This threw a bunch of errors such as not enough package files in 64bit/release/gcc, but the resulting setup.ini looks ok, so I guess those errors are expected?) Andy
Re: problems with COM running native win32 applications through cygwin's bash
On 18 March 2013 06:26, Edward Peschko wrote:
All,
We are having difficulties running various windows utilities through
bash. Through a regular windows cmd, one can run commands like
diskshadow without issue, but with bash, we are having problems with
COM calls not working. We have posted an example below.
I'd recommend reporting this to MS if you haven't already. While
there may be something in Cygwin that needs tweaking for this, it
would be best if MS could diagnose what is failing and why. That
would make any Cygwin fix happen quicker.
Larry,
After further analysis, it looks like the reason diskshadow is failing
is because it requires a fully-fledged 64 bit running environment to
execute COM calls. As a workaround (and for whomever runs into this
same issue and needs a fix) we have downloaded ActiveState's 64 bit
native perl, and are doing:
perl -e system('cmd');
to get a native 64 bit environment, which allows the COM calls to
happen for diskshadow.
The 64-bit cmd.exe can be invoked directly like this:
/cygdrive/c/sysnative/cmd
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
Re: bash script under cygwin fails to recognize simple commands
On 13 March 2013 09:03, Bob Brusa wrote: Hi, it seems I miss something. The primitive script t1.sh #!/bin/bash echo script running ls -l echo script terminating exit 0 produces a rather unexpected result when running it from cygwin terminal: rwb@w500 ~ $ ./t1.sh script running ls: unknown option -- „ls --help“ gibt weitere Informationen. script terminating : Ein numerischer Parameter ist erforderlich. rwb@w500 ~ Why is this? Your script has DOS line endings in it. The dos2unix utility will fix that for you. 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
Re: RFU: mksh-42b-1
On 15 February 2013 23:13, Chris Sutcliffe ir0nh...@gmail.com wrote: Upstream found a regression in 42 so 42b was released. Please upload: wget -x -nH --cut-dirs=3 \ http://dl.dropbox.com/u/5530441/cygwin/mksh/setup.hint \ http://dl.dropbox.com/u/5530441/cygwin/mksh/mksh-42b-1.tar.bz2 \ http://dl.dropbox.com/u/5530441/cygwin/mksh/mksh-42b-1-src.tar.bz2 \ http://dl.dropbox.com/u/5530441/cygwin/mksh/mksh-debuginfo/setup.hint \ http://dl.dropbox.com/u/5530441/cygwin/mksh/mksh-debuginfo/mksh-debuginfo-42b-1.tar.bz2 Please remove 42-1 and leave 41-1 as previous. Done, Andy
Re: hiding cursor on text terminals
On 7 January 2013 18:24, Damian Rodriguez Sanchez wrote: I have compiled a Linux ncurses gcc application on Cygwin. Everything works fine except for curs_set(0) calls which do not hide the cursor on text mode terminals (they work on X though). Does anybody know of a way to achieve this, even if it's not a portable solution? What terminals have you tried running it in? There's a DEC control sequence called DECTCEM for hiding or showing the cursor, which is implemented in mintty (the default Cygwin terminal), xterm, rxvt, and presumably others. However, it isn't implemented in the Cygwin console layer used when running a Cygwin program in a console window. (It could probably be implemented in the Cygwin DLL using Windows' SetConsoleCursorInfo() function.) 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
Re: mintty: Ctrl-Q does not work?
On 21 October 2012 06:44, Christopher Faylor wrote:
On Sun, Oct 21, 2012 at 05:38:11AM +0100, Andy Koppe wrote:
On 19 October 2012 16:00, Christopher Faylor wrote:
On Fri, Oct 19, 2012 at 02:17:29PM +0200, Corinna Vinschen wrote:
On Oct 19 12:26, Andy Koppe wrote:
On 13 October 2012 16:38, Christopher Faylor wrote:
On Sat, Oct 06, 2012 at 05:48:44AM +0100, Andy Koppe wrote:
The issue isn't specific to any of mintty, cat or Ctrl+S; for example,
I've managed to reproduce it with xterm, hexdump, and just hitting
Enter. Any other key that sends a keycode will do too. Ctrl+Q isn't
needed for the freeze to happen. In xterm I've even managed it with
find, by hitting Enter repeatedly.
If you then look at the situation in ps, you'll see something like this:
O3396 13396 1472 ? 1004 05:11:07
/usr/bin/xterm
O352844603528528 pty31004 05:25:01 /usr/bin/cat
The interesting bit there is the two 'O's in the first column, which
means both processes are waiting to output. I think what's happening
is that both of them are trying to write to their side of the
underlying pty device, but that those writes are blocking until data
is read from the other side of the pty. Result: deadlock. If the cat
is killed (possibly with -9, because of its nine lives), the terminal
happily continues on its way.
So why doesn't this happen more often? Not sure. The speed difference
between the client process output and the terminal seems to play a
role here. I can only guess that the issue occurs if a buffer in the
pty's slave-master pipe overflows and something is written to the
master-slave pipe at the same time (which is unbuffered?).
I don't understand the pty implementation enough to verify any of
that, so cgf would need to comment further. Note besides: I couldn't
make this deadlock happen on Ubuntu.
This should work in the latest snapshot. I added a polling kludge for
1.7.17 while I mull over the best way to handle this.
Using snapshot 2012-10-16, I confirmed that Ctrl+S during a long cat
no longer freezes the terminal and that Ctrl+Q
However, I still see the deadlock described above when hitting any
other key that sends something, e.g. just Enter.
Too bad. Are you sure? I tried really hard to get a deadlock and could
not reproduce it anymore under W7. My Enter key is still on paracetamol.
I can't duplicate it either.
Sorry I didn't get round to have another look at this before the 1.7.17
release.
I found that it's the CYGWIN=pipe_byte option that makes the
difference. In 1.7.16, the deadlock occurs with and without that
option. It 1.7.17, it only occurs with pipe_byte enabled.
Still can't duplicate it. pipe_byte was designed to be used only with
anonymous pipes and not with ptys so it shouldn't have any effect on
pty handling.
You're right, on further tests, pipe_byte doesn't matter. Not sure
what happened; a case of seeing what one expects to see, probably.
Sorry.
However, I can still reproduce the issue (without pipe_byte), and I
did a fresh Cygwin install into the default location to try to
minimise variables. Cygcheck output attached.
Here's what I did:
- Make sure no Cygwin processes are running.
- Open the Cygwin Terminal desktop shortcut
- cd to the winsup/cygwin directory in a pre-existing checkout of the
Cygwin sources
- cat *.cc
- Hit Enter once: output stops, soon after the terminal window goes
grey and (Not Responding) is added to the window title. (I'd also
had cases where I had to hit Enter repeatedly to make this happen.)
- Open another terminal.
- ps
O 2243792 224 2884 pty01004 06:14:33 /usr/bin/cat
O1544 11544 1544 ? 1004 06:08:36 /usr/bin/mintty
- kill 224: first window comes back to life, with output ending like this:
ntdev, S_IFBLK, true},
{/dev/sdcf4, BRACK(FH_SDCF | 4), \\Device\\Harddisk83\\Partition4,
exists_ntdev,
S_IFBLK, true},
{/dev/sdcf5, B
Terminated
Please let me know if I can provide anything else.
Regards,
Andy
cygcheck.out
Description: Binary data
--
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: Ctrl-Q does not work?
On 19 October 2012 16:00, Christopher Faylor wrote: On Fri, Oct 19, 2012 at 02:17:29PM +0200, Corinna Vinschen wrote: On Oct 19 12:26, Andy Koppe wrote: On 13 October 2012 16:38, Christopher Faylor wrote: On Sat, Oct 06, 2012 at 05:48:44AM +0100, Andy Koppe wrote: The issue isn't specific to any of mintty, cat or Ctrl+S; for example, I've managed to reproduce it with xterm, hexdump, and just hitting Enter. Any other key that sends a keycode will do too. Ctrl+Q isn't needed for the freeze to happen. In xterm I've even managed it with find, by hitting Enter repeatedly. If you then look at the situation in ps, you'll see something like this: O3396 13396 1472 ? 1004 05:11:07 /usr/bin/xterm O352844603528528 pty31004 05:25:01 /usr/bin/cat The interesting bit there is the two 'O's in the first column, which means both processes are waiting to output. I think what's happening is that both of them are trying to write to their side of the underlying pty device, but that those writes are blocking until data is read from the other side of the pty. Result: deadlock. If the cat is killed (possibly with -9, because of its nine lives), the terminal happily continues on its way. So why doesn't this happen more often? Not sure. The speed difference between the client process output and the terminal seems to play a role here. I can only guess that the issue occurs if a buffer in the pty's slave-master pipe overflows and something is written to the master-slave pipe at the same time (which is unbuffered?). I don't understand the pty implementation enough to verify any of that, so cgf would need to comment further. Note besides: I couldn't make this deadlock happen on Ubuntu. This should work in the latest snapshot. I added a polling kludge for 1.7.17 while I mull over the best way to handle this. Using snapshot 2012-10-16, I confirmed that Ctrl+S during a long cat no longer freezes the terminal and that Ctrl+Q However, I still see the deadlock described above when hitting any other key that sends something, e.g. just Enter. Too bad. Are you sure? I tried really hard to get a deadlock and could not reproduce it anymore under W7. My Enter key is still on paracetamol. I can't duplicate it either. Sorry I didn't get round to have another look at this before the 1.7.17 release. I found that it's the CYGWIN=pipe_byte option that makes the difference. In 1.7.16, the deadlock occurs with and without that option. It 1.7.17, it only occurs with pipe_byte enabled. 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
Re: mintty: Ctrl-Q does not work?
On 13 October 2012 16:38, Christopher Faylor wrote: On Sat, Oct 06, 2012 at 05:48:44AM +0100, Andy Koppe wrote: On 25 September 2012 14:32, Ryan Johnson wrote: On 25/09/2012 6:05 AM, Helmut Karlowski wrote: I type cat [some long ascii-file] then Ctrl-S (output stops), then Ctrl-Q (terminal hangs, can only be terminated by closing the window). Using minty 1.1.2 and 1.7.16(0.262/5/3) 2012-07-20 22:55 i686 Cygwin Can anybody reproduce this? Confirmed with mintty 1.1.1 and the same version of cygwin (w7-64). FWIW, doing it with `find .' rather than `cat' works fine. The issue isn't specific to any of mintty, cat or Ctrl+S; for example, I've managed to reproduce it with xterm, hexdump, and just hitting Enter. Any other key that sends a keycode will do too. Ctrl+Q isn't needed for the freeze to happen. In xterm I've even managed it with find, by hitting Enter repeatedly. If you then look at the situation in ps, you'll see something like this: O3396 13396 1472 ? 1004 05:11:07 /usr/bin/xterm O352844603528528 pty31004 05:25:01 /usr/bin/cat The interesting bit there is the two 'O's in the first column, which means both processes are waiting to output. I think what's happening is that both of them are trying to write to their side of the underlying pty device, but that those writes are blocking until data is read from the other side of the pty. Result: deadlock. If the cat is killed (possibly with -9, because of its nine lives), the terminal happily continues on its way. So why doesn't this happen more often? Not sure. The speed difference between the client process output and the terminal seems to play a role here. I can only guess that the issue occurs if a buffer in the pty's slave-master pipe overflows and something is written to the master-slave pipe at the same time (which is unbuffered?). I don't understand the pty implementation enough to verify any of that, so cgf would need to comment further. Note besides: I couldn't make this deadlock happen on Ubuntu. This should work in the latest snapshot. I added a polling kludge for 1.7.17 while I mull over the best way to handle this. Using snapshot 2012-10-16, I confirmed that Ctrl+S during a long cat no longer freezes the terminal and that Ctrl+Q However, I still see the deadlock described above when hitting any other key that sends something, e.g. just Enter. 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
Re: RFE: make non-x11 emacs mouse-aware
On 8 October 2012 11:59, Ryan Johnson ryan.john...@cs.utoronto.ca wrote: On 07/10/2012 11:37 AM, Ken Brown wrote: On 10/1/2012 5:54 PM, Ken Brown wrote: On 10/1/2012 4:29 PM, Ryan Johnson wrote: On 01/10/2012 3:20 PM, Ken Brown wrote: On 10/1/2012 2:49 PM, Ryan Johnson wrote: Hi all, esp. emacs maintainer(s), I'd like to request that the non-x11 emacs be made mouse aware. Right now, terminal mouse mode is broken in normal emacs because the emacs core doesn't recognize the resulting mouse events. You can use emacs-x11 in terminal mode as a heavyweight workaround, but it turns out that mouse awareness is controlled by the src/config.h file created by ./configure: /* Define if you have mouse support. */ /* #undef HAVE_MOUSE */ There doesn't seem to be an explicit configure switch for it (it's enabled indirectly by --with-x11 or --with-ns), but editing directly produced the desired results on a headless linux machine, with no undesirable side effects so far. I see no reason it shouldn't also work under cygwin. I'd be happy to do it if I could be sure there were no bad side effects. But I never use emacs-nox, so it isn't easy for me to test it on a long-term basis. Maybe you should build it yourself and report back. As noted, I have tested on a headless linux machine, with no problems so far (several days). There seems to be a clean division between the window management and the mouse handling code. This makes sense, because the mouse events themselves are handled by keymaps and such, in elisp land, while the generation of those events is deeper and varies depending on their source (X11, NS, terminal). If you worry that cygwin might behave differently than linux, I could build emacs locally and test as well, but I don't expect any difference. And can you be more specific about what you expect emacs to do with mouse events when it's running in a terminal? I thought mintty captured mouse events. In particular, when I run emacs-x11 under mintty, C-h k mouse-click produces no response; the cursor stays in the minibuffer, and emacs continues to wait for me to press a key. Running under X, however, emacs does see the mouse click in that same situation. For another example, if I run emacs-x11 under mintty, I can highlight text with the mouse and then paste it with shift-insert. But again it's mintty doing the work, not emacs. On any emacs, xterm-mouse-mode puts the terminal in mouse-reporting mode and starts watching stdin for the xterm mouse escape sequences: left, right, scroll, modifier keys, anything the terminal makes available (most xterm-like terminals intercept shift + mouse, for example). You can peek in xt-mouse.el to see how mouse escapes are turned into appropriate mouse events, but that's not really important here. The issue is that emacs-nox doesn't know what to do with 'mouse-1' etc that it suddenly starts receiving. I suppose you could manually wire up all the various events by hand, but on emacs-x11 they're already there (even in terminal mode) and terminal-generated mouse events work out of the box. I didn't know about xterm-mouse-mode. OK, I've built emacs-nox with mouse support, and it works, as far as I can tell. I'll upload it as a test release after I've tested it a little more. Before going ahead with this, I decided to ask for comments on the emacs-devel list, to make sure no one could see a downside. This led to a question about your tests on Linux. The default on Linux is to provide mouse support in a terminal via GPM (which is not available on Cygwin). Did you explicitly disable GPM when you built emacs for Linux? If not, then your tests may not be an accurate indication of what will happen on Cygwin. I'm sorry, my test machine was actually running Solaris, so GPM was definitely disabled... mixed up which VM guest on my laptop I was using, sorry. I redid the tests with a non-VM Ubuntu 11 machine, and AFAICT GPM is *not* the default, at least with emacs-24.2. Neither HAVE_GPM nor HAVE_MOUSE was defined, and (unsurprisingly) mouse clicks under xterm-mouse-mode mouse give the error: mouse-1 is undefined. Manually defining HAVE_MOUSE and recompiling fixed the problem. In any case, I thought GPM was only useful in console mode? Apparently the gpm client library can not only connect to a gpm server handling mouse events in a Linux console, but it can also translate xterm mouse events, and present the same API with both approaches. Alas, there's no gpm client library package for Cygwin, and I don't know whether it can be built for Cygwin. 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
Re: Terminal font-size changes
On 5 October 2012 17:24, Jim Schueler wrote: Assuming you're using the default terminal: Some key stroke combination makes the font-size smaller. Actually, under font-size settings, the settings never change. In order to reset the font size, I need to manually change it to another font size, then change it back again. Ctrl+zero resets it. Maybe the key-stroke generates a zoom out request. That's Ctrl+minus. This problem is annoying enough that I have effectively discontinued using Cygwin. Can anyone help me disable this feature? Right Click-Options-Keys-Shortcuts-Zoom 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
Re: mintty: Ctrl-Q does not work?
On 25 September 2012 14:32, Ryan Johnson wrote: On 25/09/2012 6:05 AM, Helmut Karlowski wrote: I type cat [some long ascii-file] then Ctrl-S (output stops), then Ctrl-Q (terminal hangs, can only be terminated by closing the window). Using minty 1.1.2 and 1.7.16(0.262/5/3) 2012-07-20 22:55 i686 Cygwin Can anybody reproduce this? Confirmed with mintty 1.1.1 and the same version of cygwin (w7-64). FWIW, doing it with `find .' rather than `cat' works fine. The issue isn't specific to any of mintty, cat or Ctrl+S; for example, I've managed to reproduce it with xterm, hexdump, and just hitting Enter. Any other key that sends a keycode will do too. Ctrl+Q isn't needed for the freeze to happen. In xterm I've even managed it with find, by hitting Enter repeatedly. If you then look at the situation in ps, you'll see something like this: O3396 13396 1472 ? 1004 05:11:07 /usr/bin/xterm O352844603528528 pty31004 05:25:01 /usr/bin/cat The interesting bit there is the two 'O's in the first column, which means both processes are waiting to output. I think what's happening is that both of them are trying to write to their side of the underlying pty device, but that those writes are blocking until data is read from the other side of the pty. Result: deadlock. If the cat is killed (possibly with -9, because of its nine lives), the terminal happily continues on its way. So why doesn't this happen more often? Not sure. The speed difference between the client process output and the terminal seems to play a role here. I can only guess that the issue occurs if a buffer in the pty's slave-master pipe overflows and something is written to the master-slave pipe at the same time (which is unbuffered?). I don't understand the pty implementation enough to verify any of that, so cgf would need to comment further. Note besides: I couldn't make this deadlock happen on Ubuntu. 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
Re: Possible changes to setup.exe interface and name
On 20 September 2012 16:11, Michael Benford wrote: I would like to change the setup.exe so that it loads the package selection page when it starts. Better have a look at its -M/--package-manager option first. Andy
Re: [ANNOUNCEMENT] Updated: mintty-1.1.2-1
On 14 September 2012 00:57, Daniel Colascione wrote: On 9/13/2012 12:57 PM, Andy Koppe wrote: mintty 1.1.2-1 is on its way to the Cygwin mirrors. CHANGES === - Fixed buffer overflow in processing of the control sequence for querying font coverage. - Tweaked double-click word selection algorithm to handle shell variable references such as $FOO and %FOO%, and also exclamation marks in URLs. - Changed clicks-place-cursor feature to respect application cursor key mode when sending left/right arrow keycodes. Can you please consider doing something about the exit behavior? You don't have to use my match, but please provide some sort of option for those of us who prefer traditional xterm behavior. I'm sorry I'm only finding time for bug fixes, trivial enhancements and basic support at the moment. This request is in the issue tracker (as issue 319) and I've said what I want to do with it. Reminding me after every release is not going to speed things up. 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
[ANNOUNCEMENT] Updated: mintty-1.1.2-1
mintty 1.1.2-1 is on its way to the Cygwin mirrors.
CHANGES
===
- Fixed buffer overflow in processing of the control sequence for
querying font coverage.
- Tweaked double-click word selection algorithm to handle shell
variable references such as $FOO and %FOO%, and also exclamation marks
in URLs.
- Changed clicks-place-cursor feature to respect application cursor
key mode when sending left/right arrow keycodes.
Previous changes can be found at http://code.google.com/p/mintty/wiki/Changes.
DESCRIPTION
===
Mintty is a terminal emulator for Cygwin with a native Windows user
interface and minimalist design. Among its features are Unicode
support and a graphical options dialog. Its terminal emulation is
largely compatible with xterm, but it does not require an X server.
QUESTIONS
=
The mintty manual is installed as a manpage ('man mintty'). It is also
available at http://mintty.googlecode.com/svn/tags/1.1.2/docs/mintty.1.html.
Questions and comments can be sent to the mintty discussion group at
http://groups.google.com/group/mintty-discuss or the Cygwin mailing
list.
Please use the issue tracker at http://code.google.com/p/mintty/issues
to report bugs or suggest enhancements.
To update your installation, click on the Install Cygwin link on the
http://cygwin.com web page. This downloads setup.exe to your system.
Then, run setup and answer all of the questions.
*** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***
If you want to unsubscribe from the cygwin-announce mailing list, look
at the List-Unsubscribe: tag in the email header of this message.
Send email to the address specified there. It will be in the format:
cygwin-announce-unsubscribe-you=yourdomain@cygwin.com
If you need more information on unsubscribing, start reading here:
http://sourceware.org/lists.html#unsubscribe-simple
--
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
Updated: mintty-1.1.2-1
mintty 1.1.2-1 is on its way to the Cygwin mirrors.
CHANGES
===
- Fixed buffer overflow in processing of the control sequence for
querying font coverage.
- Tweaked double-click word selection algorithm to handle shell
variable references such as $FOO and %FOO%, and also exclamation marks
in URLs.
- Changed clicks-place-cursor feature to respect application cursor
key mode when sending left/right arrow keycodes.
Previous changes can be found at http://code.google.com/p/mintty/wiki/Changes.
DESCRIPTION
===
Mintty is a terminal emulator for Cygwin with a native Windows user
interface and minimalist design. Among its features are Unicode
support and a graphical options dialog. Its terminal emulation is
largely compatible with xterm, but it does not require an X server.
QUESTIONS
=
The mintty manual is installed as a manpage ('man mintty'). It is also
available at http://mintty.googlecode.com/svn/tags/1.1.2/docs/mintty.1.html.
Questions and comments can be sent to the mintty discussion group at
http://groups.google.com/group/mintty-discuss or the Cygwin mailing
list.
Please use the issue tracker at http://code.google.com/p/mintty/issues
to report bugs or suggest enhancements.
To update your installation, click on the Install Cygwin link on the
http://cygwin.com web page. This downloads setup.exe to your system.
Then, run setup and answer all of the questions.
*** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***
If you want to unsubscribe from the cygwin-announce mailing list, look
at the List-Unsubscribe: tag in the email header of this message.
Send email to the address specified there. It will be in the format:
cygwin-announce-unsubscribe-you=yourdomain@cygwin.com
If you need more information on unsubscribing, start reading here:
http://sourceware.org/lists.html#unsubscribe-simple
Re: [ITA] w32api-3.0b_svn5368-1
On 14 August 2012 09:02, Kai Tietz wrote: 2012/8/14 Corinna Vinschen: On Aug 14 08:46, Andy Koppe wrote: Yep, mintty builds fine with that, and appears to work. For some reason it's 9K bigger than with the current w32api though. I think this is because the mingw-w64 libs come with a couple more static elements built into the libs (GUIDs and stuff). Kai, can you explain the difference? Corinna Well, major difference here is - as you already mentioned - the fact that mingw-w64 provides some helper-routines (as described by msdn) in ws2_32 and some other libraries. Also the uuid-library is a bit bigger. Also we provide some of the intrinsic-function as inline-code, which might be responsible for some size-improvment - but better optimization - you notice. Fair enough. I just highlighted it in case it's unexpected. Btw have you checked size with debugging-information, or without? Without. Andy
Re: Password prompts for remote system echoing and not attaching
On 29 August 2012 19:02, Larry Hall (Cygwin) wrote: On 8/29/2012 12:58 PM, Mike Casile wrote: New install of latest cygwin (CYGWIN_NT-6.1-WOW64 1.7.16(0.262/5/3) 2012-07-20 22:55) on a new Windows 7 system. When I do ftp host it prompts for uid, then prompts for pw (normal). Problem is, password echoes on the screen ... and then it hangs and connection is never made. If I do ftp -s:script host ... and the script starts with uid/pw ... it all runs fine. Same with pscp. With putty, no problem because putty gets control and prompts for uid/pw itself. I am thinking this is a config fat-finger on my part ... but I am out of my depth. You have two alternatives here: 1. Install the inetutils package so you're using the Cygwin FTP client (or pick an alternative Cygwin package offering your favorite FTP client). 2. Continue to use the Windows FTP client but only do so from a shell prompt started from cmd.exe (i.e. no Mintty, xterm, etc). Again: cmd.exe and console windows are different things. Invoking bash.exe (or tcsh.exe, or zsh.exe, or ...) directly from an Explorer shortcut or the Run dialog or whatever will work just fine, with Windows automatically creating a console window for it. No cmd.exe needed there. 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
Re: Windows clipboard and Emacs yank, kill-region, and kill-ring-save
On 19 August 2012 22:18, Ken Jackson wrote: On 08/19/2012 03:54 PM, Ken Brown wrote: On 8/19/2012 2:50 PM, Ken Jackson wrote: I have this in my ~/.emacs file on both Linux and Cygwin: (setq x-select-enable-clipboard t) I see in the news file that it's now set by default. It has always worked in graphical emacs but has never worked in a terminal on either Linux or Cygwin. But I sure would like it to work in a terminal. Are you able to paste clipboard text in emacs in a terminal? When I run emacs in mintty, I can paste clipboard text with Shift-Insert. Ken Ah! That works! Thank you. But there are still a couple problems. 1) Shift-Insert is a huge improvement, but is still a little clunky. I'd like to tie it to Shift-Ctrl-Y In mintty, you can enable Ctrl+Shift+letter shortcuts including Ctrl+Shift+Y for Paste on the Keys page of its options. 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
Re: Strange mouse behavior in mintty
On 14 August 2012 04:43, Ryan Johnson wrote: On 13/08/2012 10:04 PM, Herbert Stocker wrote: Hi Ryan, On 13.08.2012 15:33, Ryan Johnson wrote: Hi all, I'm hitting a mouse-related (?) problem with mintty in non-mouse mode. STC A: Log into a remote machine, invoke `sleep 10', and -- during the wait --- click anywhere on the line containing the cursor. STC B: Open tinyirc and click anywhere on the text entry line at the bottom Both cases will insert a long string like this: ^[[C^[[C^[[C^[[C^[[C^[[C^[[C^[[C^[[C^[[C^[[C^[[C^[[C (only about 4x longer) Did you notice that when you click somewhere in the command line, the cursor moves to that position? i think it has to do with that. Go to the options dialog, select Mouse and uncheck Clicks place command line cursor. The effect should go away. Yes, that's the feature I was saying is probably related (see quote below). I don't want to disable it because it's immensely useful... I just don't want it dumping a mountain of ^[[C escapes at odd times. The feature is a hack, which is why it's off by default. Mintty simply sends the number of arrow left/right keypresses that it thinks should take the cursor to the right position, whereby ^[[C is the keycode for arrow right. Obviously this relies on the application handling such keypresses in the expected way. However, are you finding that the arrow keys work where the mouse feature doesn't? I think there is a problem with mintty here actually, in that it doesn't take account of application cursor key mode when sending those mouse events. (In that mode, the arrow left/right keycodes change to ^[OD and ^[OC.) 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
Re: [ITA] w32api-3.0b_svn5368-1
On 14 August 2012 08:18, Corinna Vinschen wrote: On Aug 13 21:51, Yaakov (Cygwin/X) wrote: On 2012-08-12 01:49, JonY wrote: New w32api preliminary upload, now with mingw-w64 parts. Nack. Both mintty and xorg-server FTBFS with this w32api. Er... what? I had to look it up: Fails To Build From Source. /usr/lib/gcc/i686-pc-cygwin/4.5.3/../../../../include/w32api/windef.h:23:27: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘ULONG’ windef.h:23: typedef unsigned __LONG32 ULONG; It doesn't like the __LONG32. Andy
Re: [ITA] w32api-3.0b_svn5368-1
On 14 August 2012 08:34, Corinna Vinschen wrote:
On Aug 14 09:29, Corinna Vinschen wrote:
On Aug 14 08:25, Andy Koppe wrote:
On 14 August 2012 08:18, Corinna Vinschen wrote:
On Aug 13 21:51, Yaakov (Cygwin/X) wrote:
On 2012-08-12 01:49, JonY wrote:
New w32api preliminary upload, now with mingw-w64 parts.
Nack. Both mintty and xorg-server FTBFS with this w32api.
Er... what?
I had to look it up: Fails To Build From Source.
/usr/lib/gcc/i686-pc-cygwin/4.5.3/../../../../include/w32api/windef.h:23:27:
error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘ULONG’
windef.h:23: typedef unsigned __LONG32 ULONG;
It doesn't like the __LONG32.
Ok, that's fixable. Do you include windef before windows.h? If so,
does it work if you switch the includes?
I haven't included windows.h, but just the headers that are actually
needed. (Yeah, I know MSDN doesn't like that, but then why do they
bother documenting which header each function is in.)
Alternatively, can you apply this patch to windef.h and try again?
Index: windef.h
===
--- windef.h(revision 5370)
+++ windef.h(working copy)
@@ -14,6 +14,8 @@
extern C {
#endif
+#include _mingw.h
+
#ifndef WINVER
#define WINVER 0x0502
#endif
Yep, mintty builds fine with that, and appears to work. For some
reason it's 9K bigger than with the current w32api though.
Andy
Re: problem using recursive grep (-r option)
On 7 August 2012 16:57, marco atzeri wrote:
On 8/7/2012 5:08 PM, AngusC wrote:
If I use the command:
grep -nH -r my pattern *.*
I get results back as expected
But if the file pattern is like this:
grep -nH -r my pattern *.log
I get no results back (Even though I have a ton of files with this pattern
with .log file extension).
Am I doing something wrong?
in the second case the -r is looking for *.log
file or directories and I guess the directory does not match.
Try
find . -name *.log -exec grep -nH my pattern \{\} \;
Or have a look at grep's --include option.
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
Re: Internal echo of shell beaves (sometimes) different to external echo
On 20 July 2012 11:46, Ralf wrote: My problem is not that the script is in ISO-8859-1, nor that the strings or ttt.txt are in ISO-8859.1. They have to be in ISO-8859-1 because all my scripts are in ISO-8859-1 and they are used together with Windows-Programs (in the DOS-Box) which read and write only ISO-8851-1. My Problem is to handle in Shell-Scripts strings which are coded in ISO-8851 (and line-endings which depend on relative/absolute filenames, mounting and so on) without rewriting all the stuff. So what't the best setting in cygwin to echo ISO-88591? I still don't unterstand why the internal echo behaves in a different way from the external echo. It's because setting LC_ALL in a bash script is too late for the bash process itself, which will be using the default C.UTF-8 locale unless something else is set when bash is invoked. When stuff is written to a console (but not a pty-based terminal), the Cygwin DLL converts it from the process charset (UTF-8 in this case) to UTF-16 to pass it to the relevant Windows API function. Your ISO-8859-1 encoded 'ü' is an invalid byte when interpreted as UTF-8, hence the error character. /usr/bin/echo on the other hand is invoked as a separate process, with LC_ALL already set appropriately, hence they're you're getting the expected output. 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
Re: mintty and modifier keys
On 19 July 2012 16:37, Ryan Johnson wrote: Hi all (mostly Andy), I notice that mintty 1.1 handles certain key combinations differently than xterm: ctrl+enter produces 0x1e (RS) vs. CR in xterm alt+enter produces ESC CR vs. nothing at all in xterm ctrl+shift+letter emits the unicode C2 control codepoints (0xc281 through 0xc29a); xterm emits the C0 control value as if shift were unpressed. So, two questions: 1. Is there a particular reason for this behavior? Yes, I tried to make as many key combinations as reasonably possible available to applications without having to enable a special mode. I chose ^^ (0x1e) for Ctrl+Enter rather than a multi-character code so as to be able to use it in stty settings. Similarly, Ctrl+Backspace sends ^_ (0x1f). Perhaps rxvt or some other non-xterm terminal emulator does it? Nope, they're mintty-specific. 2. Is there documentation somewhere of what convention mintty follows for the various special cases? Yep: http://code.google.com/p/mintty/wiki/Keycodes#Ctrl http://code.google.com/p/mintty/wiki/Keycodes#Special_keys See also this on how those keycodes could be put to use in the stty settings: http://code.google.com/p/mintty/wiki/Tips#Terminal_line_settings (these questions are partly triggered by frustration at shift+enter not working, which lead to me finding a reasonably sane proposal to fix these kinds of terminal woes [1]; I was surprised to find that mintty can already distinguish some key presses that xterm can't) [1] www.leonerd.org.uk/hacks/fixterms/ Hmm, that basically describes xterm's modifyOtherKeys mode, which mintty supports too. This can be enabled with the sequence \e[4;1m. (That's for level 1. There's also level 2, enabled with \e[4;2m, where the suggested CSI u keycodes are sent even for Ctrl+letter combinations.) 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
Re: Why won't my .sh file work with cygwin?
On 4 July 2012 11:04, Thorsten Kampe wrote: * Gundament (Tue, 3 Jul 2012 22:38:36 -0700 (PDT)) I am new to Cygwin but I understand it does it's best to simulate a linux terminal. No. Cygwin is: a collection of tools which provide a Linux look and feel environment for Windows. http://cygwin.com/ That doesn't exactly contradict what the OP was saying. Needlessly unwelcoming. I want to make a little program and I have written out the entire code and saved it as a .sh file. I have paired my Windows computer to open .sh files with Cygwin's mintty.exe (terminal) You are confusing a terminal (like Mintty) with a shell (like bash). Maybe so, but invoking a shell script in that way does work, if it has executable permission. That's because the exec() function that mintty uses to invoke the program passed on its command line automatically runs /bin/sh if the program isn't a binary. Same for other terminals. 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
Re: Opinions sought on TeX Live packaging
On 30 June 2012 23:38, Ken Brown wrote: TeX Live upstream has thousands of packages, grouped into collections. Cygwin's TeX Live distribution, as originally packaged by Yaakov, has one texlive-collection-* package for each upstream collection. I've just discovered that about 1800 of the upstream packages, falling into about 40 collections, have documentation that is currently not included in the Cygwin packages. I don't know if this was on oversight on Yaakov's part or a deliberate decision to omit most of the documentation. In any case, I think that the documentation is an integral part of TeX Live and needs to be part of the Cygwin distribution. If I simply add it to the texlive-collection-* packages, however, some of them drastically increase in size. For example, the installation tarball for texlive-collection-latex would increase from about 1MB to about 40MB. And for texlive-collection-latexextra it would increase from under 10MB to over 300MB. Out of curiosity: what makes the documentation that outragreously big? Is it provided in every format known to mankind? Andy
Re: /dev/clipboard corrupted
On 27 June 2012 23:16, Thomas Wolff wrote: If the clipboard contains large data, the contents retrieved from /dev/clipboard gets corrupted. I compared the following in a few cases: * cat /dev/clipboard or cp /dev/clipboard (which are equal) * mouse-paste into mintty, read with cat * read /dev/clipboard within application and I found all three results to be different, the correct one sometimes being cat /dev/clipboard but not always. In today's case, the differences occured at byte 10240 and 65536 respectively, thus 10K-1 bytes or 64K-1 bytes being equal. I don't know anything about that problem, but note that mintty accesses the clipboard directly via the Windows API, and that it converts both Windows line endings (\r\n) and Unix line endings (\n) to carriage returns (\r), because that's what the Enter key sends. 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
Updated: mintty-1.1.1-1
mintty 1.1.1-1 is on its way to the Cygwin mirrors. This is a feature release.
CHANGES
===
Colours:
- Turned up brightness of ANSI bold blue by a couple of notches.
- Allow colours in settings to be specified in X-style hexadecimal
formats such as #RRGGBB or rgb:RR/GG/BB (rather than just comma-
separated decimal).
- Re-rendered the program icon in true colour rather than 256 colours,
with proper alpha channel.
- Fixed a bug where the background erase colour wasn't being updated
when a saved cursor was restored, which caused problems with custom
vim colour schemes.
Mouse:
- Implemented xterm's private mode 1006 for encoding mouse events,
which unlike the other three existing encodings includes the button
number in button release events.
- Fixed off-by-one error in encoding of mouse coordinates in urxvt's
private mode 1015.
- Tweaked mouse handling to make it easier to select a single
character.
- When the right click action is set to extend the selection, a left
click with Shift pressed now pastes the clipboard instead of extending
the selection, as in rxvt.
Compatibility:
- Improved handling of VK_PACKET messages, which tools like AutoHotKey
or AllChars use to send characters, so as to accept characters outside
the system's ANSI codepage.
- Tweaked RTF clipboard output to make it work in Lotus Notes.
- Fixed some xterm incompatibilities regarding saved cursors and the
alternate screen: origin and autowrap mode should be saved with the
cursor, and the alternate screen shouldn't have its own cursor, scroll
margins or insert mode.
Misc:
- Log output can now be sent to standard output by specifying a dash
instead of a filename.
- Fixed rough display of some bold fonts, e.g. Consolas.
- Stopped selection from moving when the active screen is scrolling
while looking at the other screen (via the Flip Screen command).
Build:
- Added manifest spell to keep the Program Compatibility Assistant
away.
- Changed compiler options to build for i686 rather i586, and optimise
for speed rather than size.
- Mintty now is built using gcc 4.5 rather than 3.4, and tuned for the
Atom processor (because Atom's in-order architecture should have most
to gain from this).
Previous changes can be found at http://code.google.com/p/mintty/wiki/Changes.
DESCRIPTION
===
Mintty is a terminal emulator for Cygwin with a native Windows user
interface and minimalist design. Among its features are Unicode
support and a graphical options dialog. Its terminal emulation is
largely compatible with xterm, but it does not require an X server.
QUESTIONS
=
The mintty manual is installed as a manpage ('man mintty'). It is also
available at http://mintty.googlecode.com/svn/tags/1.1.1/docs/mintty.1.html.
Questions and comments can be sent to the mintty discussion group at
http://groups.google.com/group/mintty-discuss or the Cygwin mailing
list.
Please use the issue tracker at http://code.google.com/p/mintty/issues
to report bugs or suggest enhancements.
To update your installation, click on the Install Cygwin link on the
http://cygwin.com web page. This downloads setup.exe to your system.
Then, run setup and answer all of the questions.
*** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***
If you want to unsubscribe from the cygwin-announce mailing list, look
at the List-Unsubscribe: tag in the email header of this message.
Send email to the address specified there. It will be in the format:
cygwin-announce-unsubscribe-you=yourdomain@cygwin.com
If you need more information on unsubscribing, start reading here:
http://sourceware.org/lists.html#unsubscribe-simple
Re: Small request for the new cygwin terminal
On 12 June 2012 14:11, Nellis, Kenneth wrote: -BEGIN Original Message- From: Andy Koppe On 11 June 2012 13:55, Nellis, Kenneth wrote: I don't get the U+009F result from the / key from any combination of Ctrl and Shift. On a US keyboard, Shift+/ is ?, and Ctrl+? is itself a valid control character combination, producing ^? (i.e. 0x7F). Andy -END Original Message- I hate to prolong this relatively uninteresting thread, but I don't see how you addressed my point, which is that the table at http://code.google.com/p/mintty/wiki/Keycodes#Ctrl indicates that one can generate U+009F with the /, Ctrl, and Shift keys... +-+--++ | Key | Ctrl | Ctrl+Shift | +-+--++ | / | ^_ | U+009F | +-+--++ ...but this doesn't seem to be the case, at least with a standard US keyboard. Can you take a look at the latest revision of that wiki page section? Note the 'Char' instead of 'Key' in the table header, along with a bit of extra text. Thanks, 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
Re: Small request for the new cygwin terminal
On 11 June 2012 13:55, Nellis, Kenneth wrote: I don't get the U+009F result from the / key from any combination of Ctrl and Shift. On a US keyboard, Shift+/ is ?, and Ctrl+? is itself a valid control character combination, producing ^? (i.e. 0x7F). 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
Re: Small request for the new cygwin terminal
On 11 June 2012 21:07, Helmut Karlowski wrote: I don't get anything for Shift-F4. Works for me, producing ^[[1;2S. Is this a windows-shortcut? Not that I know of. 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
Re: Small request for the new cygwin terminal
On 8 June 2012 13:55, Helmut Karlowski wrote: Andy Koppe wrote: I've added csin=\233, but I'm not sure if it's really necessary, and if it's wrong when I switch the Character Set. tgetstr() returns the value defined in xterm-terminfo, which may be wrong for another character set. When csin is missing in xterm, tgetstr() returns 0. Looking at the standard, 'csin' isn't meant for a keycode, but for a command sent to the terminal, namely for the Init sequence for multiple codesets. I'm afraid I don't know what that means though, That was the closest I've found in the terminfo-manpage. What is the terminfo-code for CSI (if any)? I don't know of one, and I'm not sure it's necessary, since CSI is a well-defined control character. How does vi know about CSI and its sequence as mentioned in your previous post? It's hardcoded to U+009B (decimal 155) in vim: http://vimdoc.sourceforge.net/htmldoc/intro.html#%3CCSI%3E And since it works in both UTF-8 and ISO-8859-x, it would appear that vim does the charset decoding before matching mappings, which is great. 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
Re: Small request for the new cygwin terminal
On 8 June 2012 19:02, Nellis, Kenneth wrote: -Original Message- From: Andy Koppe Sent: Thursday, June 07, 2012 2:45 PM snip/ Oops, documentation error. Now fixed. Thanks very much for testing that. The intention is that the Shift combination sends the basic control character plus 0x80. See also the preceding section (which I've now added a link to from the Special Keys section): http://code.google.com/p/mintty/wiki/Keycodes#Ctrl Also, when I press either Ctrl+Tab or Ctrl+Shift+Tab, instead of getting what the table indicates, I don't get anything at all. You've probably got the shortcuts for switching among mintty windows enabled on the Keys page of the options. -END Original Message- Appreciate the doc fix and, indeed, your shortcut explanation applied to me. Regarding, the @ key in the table referenced by your URL, how does one enter Ctrl+Shift+@, when to get @ you need to already be holding down the Shift key. Hold down both Shift keys. Yes, really. (For the record, I wouldn't expect anyone to really use that, and I'm a bit surprised that I bothered to implement it. Remember though that different keyboard layouts have the relevant characters in different positions.) 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
Re: Small request for the new cygwin terminal
On 7 June 2012 09:40, Lluís Batlle i Rossell wrote: Hello, thank you first for such a helpful software, for those that use Windows but are used to the Linux interface. I'd like to request some heavy annoyance I encounter with the new cygwin terminal, compared to rxvt. In 'vim', it looks like I'm used to press ESC *before* releasing *shift* (if I was inserting some text innvolving shift). On xterm, rxvt, windows terminal, if I pressed shift-esc in vim, it had the same effect as esc. But in the cygwin terminal, in insert mode it inserts some weird character. Could it be made so shift-esc has the same effect as esc, in cygwin terminal? I imagine that the difference is not done on purpose. It is done on purpose, to allow Shift+Esc to be bound to a different function if desired. It's documented here: [1] http://code.google.com/p/mintty/wiki/Keycodes#Special_keys Shift+ESC sends the Unicode codepoint U+009B, aka the Control Sequence Introducer (CSI) character. In vim, you could map it to Esc like this: map CSI Esc map! CSI Esc 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
Re: Small request for the new cygwin terminal
On 7 June 2012 15:56, Nellis, Kenneth wrote: -Original Message- From: Andy Koppe snip/ It is done on purpose, to allow Shift+Esc to be bound to a different function if desired. It's documented here: [1] http://code.google.com/p/mintty/wiki/Keycodes#Special_keys Shift+ESC sends the Unicode codepoint U+009B, aka the Control Sequence Introducer (CSI) character. snip/ -END Original Message- My experience does not agree with the Special keys table at the page referenced by that URL. When pressing the unmodified Pause/Break key, I get ^], which maps to Pause in your table, and pressing Ctrl+Pause/Break, I get ^\, which maps to Break in your table, so this agrees with the statement, Pause and Break usually share a key, whereby Ctrl has to be pressed to get the Break function. But, when I press Shift+Pause/Break, because I'm not pressing Ctrl, I should get your table's Pause/Shift result, U+009C, but I get 9D. Similarly, when I press Ctrl+Shift+Pause/Break, because I am pressing Ctrl, I should get your table's Break/Shift result, U+009D, but I get 9C. Oops, documentation error. Now fixed. Thanks very much for testing that. The intention is that the Shift combination sends the basic control character plus 0x80. See also the preceding section (which I've now added a link to from the Special Keys section): http://code.google.com/p/mintty/wiki/Keycodes#Ctrl Also, when I press either Ctrl+Tab or Ctrl+Shift+Tab, instead of getting what the table indicates, I don't get anything at all. You've probably got the shortcuts for switching among mintty windows enabled on the Keys page of the options. 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
Re: Small request for the new cygwin terminal
On 7 June 2012 17:10, Helmut Karlowski wrote: Helmut Karlowski, 07.06.2012 17:52:43: Nellis, Kenneth, 07.06.2012 16:56:57: -Original Message- From: Andy Koppe snip/ It is done on purpose, to allow Shift+Esc to be bound to a different function if desired. It's documented here: [1] http://code.google.com/p/mintty/wiki/Keycodes#Special_keys Shift+ESC sends the Unicode codepoint U+009B, aka the Control Sequence Introducer (CSI) character. snip/ -END Original Message- My experience does not agree with the Special keys table at the page referenced by that URL. On my german keyboard I receive ^[^[ (2x ESC) for Shift-ESC. Character Set is CP850 if that matters. As of my understanding CSI is something like ESC[ (at least on an ANSI-terminal, is this different on xterm?). Switching to ISO-8859-1 emits 0x9b which seems to be correct. See the preceding section on the wiki page: http://code.google.com/p/mintty/wiki/Keycodes#Ctrl If Shift is held in addition to a control character combination, the corresponding character from the so-called C1 control character set is sent. The C1 control characters are shown as Unicode codepoints in the table below. How exactly C1 control characters are sent depends on the selected character encoding. In ISO-8859 encodings, they are encoded as single bytes, e.g. \x81 for U+0081. With UTF-8, they are encoded as two-byte sequences, which effectively means that the character code is prefixed with a \xC2 byte, so for example U+0081 becomes \xC2\x81. C1 codepoints that are not supported by the selected character encoding are sent by prefixing the corresponding ASCII control character with an ESC character, so U+0081 would be sent as ^[^A. CP850 doesn't support the C1 control characters, so you get the fallback instead, which is the scheme for encoding the Meta modifier when bit 7 isn't available. This means that Ctrl+Shift+letter combinations can't be distinguished from Ctrl+Alt+letter, but since Ctrl+Alt+letter combinations are suppposedly reserved for global shortcuts in Windows, they might still come in handy occasionally. There indeed is another scheme of encoding C1 control characters with an ESC followed by the base character, e.g. ^[A instead of ^[^A, but that would have made the Ctrl+Shift+letter keycode the same as Alt+letter rather than Ctrl+Alt+letter, which is why I chose the Meta scheme. I hope that makes some sense. 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
Re: Small request for the new cygwin terminal
On 7 June 2012 21:14, Helmut Karlowski wrote: Andy Koppe, 07.06.2012 21:12:05: CP850 doesn't support the C1 control characters, so you get the fallback instead, which is the scheme for encoding the Meta modifier when bit 7 isn't available. This means that Ctrl+Shift+letter combinations can't be distinguished from Ctrl+Alt+letter, but since Ctrl+Alt+letter combinations are suppposedly reserved for global shortcuts in Windows, they might still come in handy occasionally. There indeed is another scheme of encoding C1 control characters with an ESC followed by the base character, e.g. ^[A instead of ^[^A, but that would have made the Ctrl+Shift+letter keycode the same as Alt+letter rather than Ctrl+Alt+letter, which is why I chose the Meta scheme. I hope that makes some sense. Yes. One question remains: Does the Character Set (ISO, CP, etc.) have an effect on the terminfo-terminal-description? I don't think you can have different terminfo entries for different character sets for the same terminal type, i.e. you'd need to create charset-specifc types such as xterm-cp850. I've added csin=\233, but I'm not sure if it's really necessary, and if it's wrong when I switch the Character Set. tgetstr() returns the value defined in xterm-terminfo, which may be wrong for another character set. When csin is missing in xterm, tgetstr() returns 0. Looking at the standard, 'csin' isn't meant for a keycode, but for a command sent to the terminal, namely for the Init sequence for multiple codesets. I'm afraid I don't know what that means though, nor why the xterm terminfo for it is empty. I'm not sure if this can be solved inside mintty, is there a fallback if an entry in terminfo is missing? There isn't a fallback in the terminfo system itself, so I guess that's up to each terminfo-using program (or its configuration). 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
Re: Mintty Log Off problem (now 1.7.16s)
On 29 May 2012 13:57, Ryan Johnson wrote: On 28/05/2012 1:32 PM, Harry G McGavran Jr wrote: On 02/18/12 11:28, Harry G McGavran Jr wrote: I've found a little more information -- this problem goes away if I change my default shell to dash. Seems tcsh is involved somehow. It comes back when I change my default shell back to tcsh. Going back to tcsh 6.18.00-2 does not help. Given the deathly silence to my request below, I must be the only one experiencing this, but it happens on both of my machines. Harry On 02/15/12 10:43, Harry G McGavran Jr wrote: With Cygwin 1.7.10(0.259/5/3) upon logging off Windows XP SP3 I get a pop-up window End Program - C:\cygwin\bin\mintty.exe with a End Now and Cancel button every time I log off Windows and I have somewhere in that Windows session run the Mintty shortcut which has C:\cygwin\bin\mintty -u - in it and my default shell is tcsh. This never happened with previous Cygwin releases. What's even more interesting is that in all cases I exit all my programs before logging off, including the mintty window. I've even tried hitting the Cancel button and then looking for a process named mintty or Terminal (since that's what mintty's description is and that is used by some process tools) with both Process Explorer and Task Manager, but I can find no such process -- and then when I try to log off again not having found such a process the pop-up comes back and I can't log off until I hit End Now. Since I haven't seen any reports of this on this list, I must be about the only one this is happening to. Any clues as to what I can do to find out what Windows is actually failing to stop when I try to log off having run mintty beforehand? I'm puzzled why others aren't seeing this or aren't reporting it, but this problem seems to be back with 1.7.15 and I've now tried the latest snapshot (May 25) and it's back there too. It occurred with 1.7.10 and then got fixed, but now it seems to be back. I routinely encounter mintty windows that don't close after I exit the login shell they run (even though they contain no visible child processes), but they can still be closed using the big red X in the corner... Mintty closes when it gets an EOF from the underlying pseudo terminal device. This happens when there are no more processes connected to it. The Cygwin console behaves similarly, but other terminal emulators do not: they close once the direct child process exits no matter whether other processes are still connected. Backgrounding a process with '' or nohupping it doesn't break that connection, but invoking it through the 'setsid' utility from the util-linux package does. See also http://code.google.com/p/mintty/issues/detail?id=319. 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
Re: Mintty Log Off problem (now 1.7.16s)
On 29 May 2012 17:17, Harry G McGavran Jr wrote: Ryan Johnson wrote: I routinely encounter mintty windows that don't close after I exit the login shell they run (even though they contain no visible child processes), but they can still be closed using the big red X in the corner... your problem sounds like something more sinister. Ryan There is never an X to deal with here. One never know there is a problem until he does start-Log Off to log out of windows. I can normally close any/all mintty windows and then with various process explorers try to find a mintty process and never find any. Then when I log out of Windows, Windows claims it has to close mintty.exe. This was fixed once in a snapshot of 1.7.10, but has since returned with 1.7.15. In this incarnation it seems to occur whenever I've run a Cygwin X app from a mintty window. If I've signed on in Windows and never run a Cygwin X app it generally doesn't happen, but I can't be sure it never happens. Every time I've run a Cygwin X app though I can expect to see it after closing (apparently normally) all mintty windows and then log off of Windows. Do I understand you correctly that you no longer have any mintty windows open when this happens? That's puzzling indeed. Have you looked at ye olde Big List Of Dodgy Applications? http://cygwin.com/faq/faq.using.html#faq.using.bloda 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
Re: [RFU] subversion-1.7.5-1 and subversion-1.7.5-2
On 21 May 2012 18:30, David Rothenberger wrote: On 5/20/2012 9:10 PM, Andy Koppe wrote: On 20 May 2012 02:22, David Rothenberger wrote: Please upload subversion-1.7.5-1 as the new current release and -2 as the new test release (built against the test Perl). Please delete 1.7.4-1 and leave 1.6.17-1 as prev. I'm getting error 403 (not authorized) for these. This should be fixed now. Uploaded. Thanks, Andy
Re: [RFU] {emacs,emacs-X11,emacs-el}-{23.4-2,24.0.96-2}
On 16 May 2012 16:57, Ken Brown wrote:
D=http://sanibeltranquility.com/cygwin/release/emacs
wget -x -nH --cut-dirs=2 \
${D}/emacs-23.4-2-src.tar.bz2 \
${D}/emacs-23.4-2.tar.bz2 \
${D}/emacs-24.0.96-2-src.tar.bz2 \
${D}/emacs-24.0.96-2.tar.bz2 \
${D}/setup.hint \
${D}/emacs-X11/emacs-X11-23.4-2.tar.bz2 \
${D}/emacs-X11/emacs-X11-24.0.96-2.tar.bz2 \
${D}/emacs-X11/setup.hint \
${D}/emacs-el/emacs-el-23.4-2.tar.bz2 \
${D}/emacs-el/emacs-el-24.0.96-2.tar.bz2 \
${D}/emacs-el/setup.hint
Please delete the 23.4-1 and 24.0.96-1 packages, leaving 23.3-3 as previous,
23.4-2 as current, and 24.0.96-2 as test.
Done.
Thanks,
Andy
Re: [RFU] fftw-3.3.2-1
On 19 May 2012 08:59, marco atzeri wrote: new upstream release to download (remove the index.html's) : wget -r -np -nH --cut-dirs=2 \ http://matzeri.altervista.org/cygwin-1.7/fftw3/index.html rm ./fftw3-doc/index.html \ ./index.html \ ./libfftw3-devel/index.html \ ./libfftw3_3/index.html \ ./fftw3-doc/md5.sum \ ./libfftw3-devel/md5.sum \ ./libfftw3_3/md5.sum | ./md5.sum File list: fftw3-3.3.2-1-src.tar.bz2 fftw3-3.3.2-1.tar.bz2 fftw3-doc/fftw3-doc-3.3.2-1.tar.bz2 fftw3-doc/setup.hint libfftw3-devel/libfftw3-devel-3.3.2-1.tar.bz2 libfftw3-devel/setup.hint libfftw3_3/libfftw3_3-3.3.2-1.tar.bz2 libfftw3_3/setup.hint setup.hint Done. Thanks, Andy
Re: [RFU] cyrus-sasl-2.1.25-1
On 20 May 2012 02:19, David Rothenberger wrote: Please leave cyrus-sasl-2.1.23-1 as the previous version. wget -x -nH --cut-dirs=2 \ http://home.comcast.net/~david.rothenberger/cygwin/cyrus-sasl/cyrus-sasl-2.1.25-1-src.tar.bz2 \ http://home.comcast.net/~david.rothenberger/cygwin/cyrus-sasl/cyrus-sasl-2.1.25-1.tar.bz2 \ http://home.comcast.net/~david.rothenberger/cygwin/cyrus-sasl/libsasl2/libsasl2-2.1.25-1.tar.bz2 \ http://home.comcast.net/~david.rothenberger/cygwin/cyrus-sasl/libsasl2/setup.hint \ http://home.comcast.net/~david.rothenberger/cygwin/cyrus-sasl/libsasl2-devel/libsasl2-devel-2.1.25-1.tar.bz2 \ http://home.comcast.net/~david.rothenberger/cygwin/cyrus-sasl/libsasl2-devel/setup.hint \ http://home.comcast.net/~david.rothenberger/cygwin/cyrus-sasl/libsasl2-ldap/libsasl2-ldap-2.1.25-1.tar.bz2 \ http://home.comcast.net/~david.rothenberger/cygwin/cyrus-sasl/libsasl2-ldap/setup.hint \ http://home.comcast.net/~david.rothenberger/cygwin/cyrus-sasl/libsasl2-sql/libsasl2-sql-2.1.25-1.tar.bz2 \ http://home.comcast.net/~david.rothenberger/cygwin/cyrus-sasl/libsasl2-sql/setup.hint \ http://home.comcast.net/~david.rothenberger/cygwin/cyrus-sasl/setup.hint Done. Thanks, Andy
Re: [RFU] subversion-1.7.5-1 and subversion-1.7.5-2
On 20 May 2012 02:22, David Rothenberger wrote: Please upload subversion-1.7.5-1 as the new current release and -2 as the new test release (built against the test Perl). Please delete 1.7.4-1 and leave 1.6.17-1 as prev. Thanks! wget -x -nH --cut-dirs=2 \ http://home.comcast.net/~david.rothenberger/cygwin/subversion/setup.hint \ http://home.comcast.net/~david.rothenberger/cygwin/subversion/subversion-1.7.5-1.tar.bz2 \ http://home.comcast.net/~david.rothenberger/cygwin/subversion/subversion-1.7.5-1-src.tar.bz2 \ http://home.comcast.net/~david.rothenberger/cygwin/subversion/subversion-1.7.5-2.tar.bz2 \ http://home.comcast.net/~david.rothenberger/cygwin/subversion/subversion-1.7.5-2-src.tar.bz2 \ http://home.comcast.net/~david.rothenberger/cygwin/subversion/subversion-apache2/setup.hint \ http://home.comcast.net/~david.rothenberger/cygwin/subversion/subversion-apache2/subversion-apache2-1.7.5-1.tar.bz2 \ http://home.comcast.net/~david.rothenberger/cygwin/subversion/subversion-apache2/subversion-apache2-1.7.5-2.tar.bz2 \ http://home.comcast.net/~david.rothenberger/cygwin/subversion/subversion-devel/setup.hint \ http://home.comcast.net/~david.rothenberger/cygwin/subversion/subversion-devel/subversion-devel-1.7.5-1.tar.bz2 \ http://home.comcast.net/~david.rothenberger/cygwin/subversion/subversion-devel/subversion-devel-1.7.5-2.tar.bz2 \ http://home.comcast.net/~david.rothenberger/cygwin/subversion/subversion-gnome/setup.hint \ http://home.comcast.net/~david.rothenberger/cygwin/subversion/subversion-gnome/subversion-gnome-1.7.5-1.tar.bz2 \ http://home.comcast.net/~david.rothenberger/cygwin/subversion/subversion-gnome/subversion-gnome-1.7.5-2.tar.bz2 \ http://home.comcast.net/~david.rothenberger/cygwin/subversion/subversion-perl/setup.hint \ http://home.comcast.net/~david.rothenberger/cygwin/subversion/subversion-perl/subversion-perl-1.7.5-1.tar.bz2 \ http://home.comcast.net/~david.rothenberger/cygwin/subversion/subversion-perl/subversion-perl-1.7.5-2.tar.bz2 \ http://home.comcast.net/~david.rothenberger/cygwin/subversion/subversion-python/setup.hint \ http://home.comcast.net/~david.rothenberger/cygwin/subversion/subversion-python/subversion-python-1.7.5-1.tar.bz2 \ http://home.comcast.net/~david.rothenberger/cygwin/subversion/subversion-python/subversion-python-1.7.5-2.tar.bz2 \ http://home.comcast.net/~david.rothenberger/cygwin/subversion/subversion-ruby/setup.hint \ http://home.comcast.net/~david.rothenberger/cygwin/subversion/subversion-ruby/subversion-ruby-1.7.5-1.tar.bz2 \ http://home.comcast.net/~david.rothenberger/cygwin/subversion/subversion-ruby/subversion-ruby-1.7.5-2.tar.bz2 \ http://home.comcast.net/~david.rothenberger/cygwin/subversion/subversion-tools/setup.hint \ http://home.comcast.net/~david.rothenberger/cygwin/subversion/subversion-tools/subversion-tools-1.7.5-1.tar.bz2 \ http://home.comcast.net/~david.rothenberger/cygwin/subversion/subversion-tools/subversion-tools-1.7.5-2.tar.bz2 I'm getting error 403 (not authorized) for these. Andy
Re: mintty suggestion
On 10 May 2012 20:34, Nellis, Kenneth wrote: With X-Windows, one can independently set the titles of the terminal window and the window's icon. to set window title: ESC ] 2 ; title ^G to set icon title: ESC ] 1 ; title ^G Analogously, it would be nice if Mintty would allow me to independently set the titles of the window and the associated taskbar button. As far as I know, Windows doesn't have a way to set different titles for a window and its taskbar button. Hence you'll find that the icon title sequence doesn't work in xterm running on Xwin in multiwindow mode either. 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
[ANNOUNCEMENT] Testing: mintty-1.1.0-1
mintty 1.1.0-1 (aka 1.1-beta1) is on its way to the Cygwin mirrors.
This is a test release.
To install it using setup.exe, find mintty on the package selection
screen and click on the cycle symbol by its version number until the
required version appears. Make sure the checkbox in the 'Bin?' column
next to it is ticked.
Alternatively, just click on the 'Exp' button at the top of the
package selection screen to install available test versions of all
installed packages, thereby helping to make sure they're stable.
CHANGES
===
- Implemented xterm's private mode 1006 for encoding mouse events,
which unlike the other three existing encodings includes the button
number in button release events.
- Fixed off-by-one error in encoding of mouse coordinates in urxvt's
private mode 1015.
- Tweaked mouse handling to make it easier to select a single character.
- When the right click action is set to extend the selection, a left
click with Shift pressed now pastes the clipboard instead of extending
the selection, as in rxvt.
- Improved handling of VK_PACKET messages, which tools like AutoHotKey
or AllChars use to send characters, so as to accept characters outside
the system's ANSI codepage.
- Tweaked RTF clipboard output to make it work in Lotus Notes.
- Turned up brightness of ANSI bold blue by a couple of notches.
- Re-rendered the program icon in true colour rather than 256 colours,
with proper alpha channel.
- Fixed a bug where the background erase colour wasn't being updated
when a saved cursor was restored.
- Fixed some xterm incompatibilities regarding saved cursors and the
alternate screen: origin and autowrap mode should be saved with the
cursor, and the alternate screen shouldn't have its own cursor, scroll
margins or insert mode.
- Added manifest spell to keep the Program Compatibility Assistant away.
- Switched to gcc 4.5 from 3.4, targeting i686 rather than i586,
optimising for speed rather than size, and tuning for the Atom
processor (because Atom's in-order architecture should have most to
gain from this).
Previous changes can be found at http://code.google.com/p/mintty/wiki/Changes.
DESCRIPTION
===
Mintty is a terminal emulator for Cygwin with a native Windows user
interface and minimalist design. Among its features are Unicode
support and a graphical options dialog. Its terminal emulation is
largely compatible with xterm, but it does not require an X server.
QUESTIONS
=
The mintty manual is installed as a manpage ('man mintty'). It is also
available at http://mintty.googlecode.com/files/mintty-1.1-beta1.pdf.
Questions and comments can be sent to the mintty discussion group at
http://groups.google.com/group/mintty-discuss or the Cygwin mailing
list.
Please use the issue tracker at
http://code.google.com/p/mintty/issues/list to report bugs or suggest
enhancements.
To update your installation, click on the Install Cygwin link on the
http://cygwin.com web page. This downloads setup.exe to your system.
Then, run setup and answer all of the questions.
*** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***
If you want to unsubscribe from the cygwin-announce mailing list, look
at the List-Unsubscribe: tag in the email header of this message.
Send email to the address specified there. It will be in the format:
cygwin-announce-unsubscribe-you=yourdomain@cygwin.com
If you need more information on unsubscribing, start reading here:
http://sourceware.org/lists.html#unsubscribe-simple
--
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
Testing: mintty-1.1.0-1
mintty 1.1.0-1 (aka 1.1-beta1) is on its way to the Cygwin mirrors.
This is a test release.
To install it using setup.exe, find mintty on the package selection
screen and click on the cycle symbol by its version number until the
required version appears. Make sure the checkbox in the 'Bin?' column
next to it is ticked.
Alternatively, just click on the 'Exp' button at the top of the
package selection screen to install available test versions of all
installed packages, thereby helping to make sure they're stable.
CHANGES
===
- Implemented xterm's private mode 1006 for encoding mouse events,
which unlike the other three existing encodings includes the button
number in button release events.
- Fixed off-by-one error in encoding of mouse coordinates in urxvt's
private mode 1015.
- Tweaked mouse handling to make it easier to select a single character.
- When the right click action is set to extend the selection, a left
click with Shift pressed now pastes the clipboard instead of extending
the selection, as in rxvt.
- Improved handling of VK_PACKET messages, which tools like AutoHotKey
or AllChars use to send characters, so as to accept characters outside
the system's ANSI codepage.
- Tweaked RTF clipboard output to make it work in Lotus Notes.
- Turned up brightness of ANSI bold blue by a couple of notches.
- Re-rendered the program icon in true colour rather than 256 colours,
with proper alpha channel.
- Fixed a bug where the background erase colour wasn't being updated
when a saved cursor was restored.
- Fixed some xterm incompatibilities regarding saved cursors and the
alternate screen: origin and autowrap mode should be saved with the
cursor, and the alternate screen shouldn't have its own cursor, scroll
margins or insert mode.
- Added manifest spell to keep the Program Compatibility Assistant away.
- Switched to gcc 4.5 from 3.4, targeting i686 rather than i586,
optimising for speed rather than size, and tuning for the Atom
processor (because Atom's in-order architecture should have most to
gain from this).
Previous changes can be found at http://code.google.com/p/mintty/wiki/Changes.
DESCRIPTION
===
Mintty is a terminal emulator for Cygwin with a native Windows user
interface and minimalist design. Among its features are Unicode
support and a graphical options dialog. Its terminal emulation is
largely compatible with xterm, but it does not require an X server.
QUESTIONS
=
The mintty manual is installed as a manpage ('man mintty'). It is also
available at http://mintty.googlecode.com/files/mintty-1.1-beta1.pdf.
Questions and comments can be sent to the mintty discussion group at
http://groups.google.com/group/mintty-discuss or the Cygwin mailing
list.
Please use the issue tracker at
http://code.google.com/p/mintty/issues/list to report bugs or suggest
enhancements.
To update your installation, click on the Install Cygwin link on the
http://cygwin.com web page. This downloads setup.exe to your system.
Then, run setup and answer all of the questions.
*** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***
If you want to unsubscribe from the cygwin-announce mailing list, look
at the List-Unsubscribe: tag in the email header of this message.
Send email to the address specified there. It will be in the format:
cygwin-announce-unsubscribe-you=yourdomain@cygwin.com
If you need more information on unsubscribing, start reading here:
http://sourceware.org/lists.html#unsubscribe-simple
Re: mintty randomly switches keyboard-layout
On 1 May 2012 10:32, Helmut Karlowski wrote: Hi, I notice quite often that my german keyboard-layout in mintty gets changed into an english one. Alt-F8 (Reset) does not bring back the german layout, so I can only exit and restart mintty. I think it mostly happens when doing Copy/Paste-operations using Ctrl-Ins/Shift-Ins but I'm not sure about this. Is there a way to avoid this or to reset the layout back to german? I'm using mintty 1.0.3 on cygwin 1.7.13. I'd suspect a system-wide shortcut for switching keyboard layout. Those are well hidden in the Control Panel, under 'Region and Languages - Keyboard and Languages - Change Keyboard - Advanced Key Settings' (on an English Windows 7). Looks like the default shortcut for switching between input languages is 'Left Alt + Shift', which might collide with shortcuts in terminal applications. 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
Re: Change dark blue terminal colour
On 20 April 2012 18:26, Dotan Cohen wrote: Hello all, I am a new Cygwin user. I have been looking online for a way to change the default ANSI BLUE to CYAN, as it is very difficult to see on the black terminal background. However, all I have been able to find were suggestions to use Putty's terminal or Console 2 instead of Cygwin's terminal. Is there no way to make this change in Cygwin's terminal? Assuming you're using Cygwin's default terminal, stick this into ~/.minttyrc: Blue=0,0,191 And in case you want to change bold blue as well: BoldBlue=64,64,255 Adjust the RGB values as desired. The values shown are the default ones. 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
Re: utf-8 support with getclip?
On 17 April 2012 13:35, Chris Sutcliffe wrote: I'm having an issue with getclip and pasting utf-8 strings (like PONIEDZIAŁEK for example). Using mintty and right clicking I get exactly what's in the clipboard. If I call getclip from the command line, I get PONIEDZIA?EK. My LANG is set to en_CA.UTF-8. Yep, getclip (and putclip) don't have Unicode support (yet?), so characters outside your system's ANSI codepage end up as question marks. The special /dev/clipboard device does have Unicode support though, so you could just use 'cat /dev/clipboard' instead of getclip. 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
Re: Win2000 compatibility
On 12 April 2012 16:48, jojelino wrote: GetModuleHandleEx is known to be supported in minimum winxp (0x0501), according to http://msdn.microsoft.com/en-us/library/windows/desktop/ms683200(v=vs.85).aspx MSDN no longer supports Windows 2000. Even something as basic as CreateFile() now allegedly requires at least Windows XP. 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
Re: TERM problem with mintty and latest tmux in OpenBSD
On 30 March 2012 10:03, Michael Simpson wrote: On 29 March 2012 06:29, Andy Koppe wrote: I don't see any evidence here that this is a problem with mintty rather than OpenBSD's tmux or xterm terminfo entry. Can you try this using Cygwin's xterm? Cygwin's xterm works as expected Thanks for checking. Sounds like a mintty incompatibility with xterm then. I'll need your help to try to narrow down the issue though, as I haven't got access to an OpenBSD system. Can you invoke mintty with the --log option for logging output into a file, do as little as possible to reproduce the problem, and send the resulting log? The aim here is that I can cat the log file to see the issue and then try to narrow it down to the problematic control sequence. Regards, 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
Re: A momentous day (was Re: Setup and Mintty)
On 22 November 2011 10:57, Andrew Schulman wrote: On Fri, Nov 18, 2011 at 08:58:49PM +, Andy Koppe wrote: On 18 November 2011 20:57, Andy Koppe wrote: On 18 November 2011 10:59, Corinna Vinschen wrote: On Nov 18 05:36, Andy Koppe wrote: On 17 November 2011 17:17, Corinna Vinschen wrote: the latest setup sources implement the mintty desktop and start menu shortcuts. ??So, afaics, if you would just change the mintty package so that it doesn't install its own shortcuts, we could update setup on sourceware to the new version. A shortcut-less mintty package is here: http://mintty.googlecode.com/files/mintty-1.0.1-2.tar.bz2 http://mintty.googlecode.com/files/mintty-1.0.1-2-src.tar.bz2 http://mintty.googlecode.com/svn/tags/1.0.1-2/cygport/setup.hint Thanks. Actually, it's time for a minor mintty update anyway. Please use this lot instead: http://mintty.googlecode.com/files/mintty-1.0.2-1.tar.bz2 http://mintty.googlecode.com/files/mintty-1.0.2-1-src.tar.bz2 http://mintty.googlecode.com/svn/tags/1.0.2-1/cygport/setup.hint D'oh, that last one should be: http://mintty.googlecode.com/svn/tags/1.0.2/cygport/setup.hint setup.exe has been updated and the above files have been uploaded. Gold stars all around! cgf Awarded: Andy http://cygwin.com/goldstars/#AK Corinna http://cygwin.com/goldstars/#CV Jon http://cygwin.com/goldstars/#JTy Sorry to be so late in pointing this out, but Warren Young missed out here. I think he deserves a gold star for redesigning the Cygwin logo. Andy
Re: TERM problem with mintty and latest tmux in OpenBSD
On 22 March 2012 21:43, Michael Simpson wrote: Hi there using MinTTY-1.0.3-1 cygwin-1.7-11-1 tmux on OpenBSD -current When reattaching tmux (tmux attach) there was a series of 3 sets of semi-colon separated numbers appearing after the ksh prompt. This behaviour in tmux only appeared after recent changes to tmux in OpenBSD This behaviour only disappeared when TERM in .bashrc was set to cygwin from xterm a TERM of xterm does not cause this problem in CentOS5.8 or Fedora 17 I don't see any evidence here that this is a problem with mintty rather than OpenBSD's tmux or xterm terminfo entry. Can you try this using Cygwin's xterm? 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
Re: [RFU] base-files-4.1-2
On 2 March 2012 23:10, David Sastre Medina wrote: Hello, Please upload base-files-4.1-2. I'd like to release 4.1-2 as a test release, so setup.hint has changed, too. http://crapsteak.org/cygwin/release/base-files/base-files-4.1-2.tar.bz2 http://crapsteak.org/cygwin/release/base-files/base-files-4.1-2.tar.bz2.sig http://crapsteak.org/cygwin/release/base-files/setup.hint I've left 4.1-1 as current and 4.1-2 as test. Please delete any older releases. Done. Thanks, Andy
Re: mintty scroll to bottom
On 2 March 2012 20:39, Ryan Johnson wrote: BTW, what happens in mintty if the part of the output you're looking at falls out of the scrollback buffer while you're looking at it? Does it start scrolling at line rate but 5000 lines back in time? 'fraid so. Obviously, increasing the scrollback size can reduce the chances of this happening. Scrollback storage is reasonably efficient, so setting it to a million or even higher shouldn't be a problem with today's RAM sizes. 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
Re: mintty scroll to bottom
On 2 March 2012 08:41, Corinna Vinschen wrote: On Mar 1 20:43, Andy Koppe wrote: On 29 February 2012 12:46, Lemke, Michael SZ/HZA-ZSW wrote: What is the mintty equivalent to rxvt/xterm's -si|+si Turn on/off scroll-to-bottom on TTY output inhibit; resource scrollTtyOutput has opposite effect. There's no such option. Shift+End will get you back to the current output after looking at something in the scrollback, as will any keypress that sends something to the terminal. Any chance to implement this? Automatic scroll-to-bottom is a useful feature, IMHO. I disagree. The point of being able to scroll back to earlier output is to read and perhaps copy something. When doing that, having the scrollback jump back to the bottom without the user asking for it is rather unhelpful. The Windows console does this, and I always found it really frustrating. 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
Re: mintty scroll to bottom
On 29 February 2012 12:46, Lemke, Michael SZ/HZA-ZSW wrote: What is the mintty equivalent to rxvt/xterm's -si|+si Turn on/off scroll-to-bottom on TTY output inhibit; resource scrollTtyOutput has opposite effect. There's no such option. Shift+End will get you back to the current output after looking at something in the scrollback, as will any keypress that sends something to the terminal. 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
Re: mintty scroll to bottom
On 1 March 2012 10:19, Corinna Vinschen wrote: On Feb 29 13:46, Lemke, Michael SZ/HZA-ZSW wrote: What is the mintty equivalent to rxvt/xterm's -si|+si Turn on/off scroll-to-bottom on TTY output inhibit; resource scrollTtyOutput has opposite effect. I'd like to have it turned on, i.e., scroll to bottom whenever there is new output. Couldn't find anything for mintty and it seems mintty doesn't scroll. Maybe you should ask this on the mintty mailing list mintty-discuss AT googlegroups DOT com I don't mind mintty questions being sent here (unless of course they're not relevant to Cygwin's mintty), not least because there's more of a chance of someone else answering them here. 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
Re: [ANNOUNCEMENT] Uploaded base-files-4.1-1
On 28 February 2012 19:58, David Sastre Medina wrote: Version 4.1-1 of base-files has been uploaded. Base-files is a set of system configuration and setup files. 4.1-1 * Setting a system locale and a per-user locale breaks some configs and doesn't play well with mintty. Changed to a user-defined setting in /etc/profile/lang.* Reported by Peter Rosin and Andy Koppe. See cygwin.com/ml/cygwin/2012-02/msg00448.html Thanks! 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
Re: base-files 4.0-9: LANG is set to the system default, why not the user selection?
On 16 February 2012 20:05, David Sastre Medina wrote: For the first, I apologize. WRT the second, here's a new attempt: 'locale' is set system-wide in /etc/profile.d/tzset.* to provide a new functionality, that, IIRC, was included in the announcement of the base-files' release. Also, 'locale' _can_ be set at a user-defined level, to provide the user the ability to set 'locale' despite system-wide setting, wich could be needed in multi-user environments, for instance. What's the reason for setting LANG to the system language in /etc/profile though? /etc/profile may be a system-wide file, but it is always sourced in a particular user context. There are several problems with relying on ~/.bash_profile to set it to the user's language: 1. It incurs an extra fork. 2. As Peter pointed out, it only works for new users. Existing users can't reasonably be expected to merge /etc/skel/.bash_profile changes into their own file. 3. The override in ~/.bash_profile is unconditional, which means that LANG settings in mintty's options, in cygwin.bat, or the user's Windows environment are ignored. Therefore, please consider changing /etc/profile.d/lang.[c]sh to use `locale -uU` and dropping the LANG setting from /etc/skel/.bash_profile. Regards, 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
Re: base-files 4.0-9: LANG is set to the system default, why not the user selection?
On 15 February 2012 13:59, Peter Rosin wrote:
My Windows is Swedish, but I generally like it to show as little as
possible in Swedish so my display language is English. I want
English, to not suffer from strange translations that don't make
sense, to be able to search for error messages, etc.
A recent change seems to have LANG set to the output of the system
default language, but I think that's just wrong, it should be the
language of the current user.
Please change lang.{c}sh to do locale -uU instead of locale -sU.
I agree.
Where is the recommended position to override LANG until such a
change is made, or if it is not an agreeable change?
If you're using the default terminal, i.e. mintty, you can set it on
the Text page of its options.
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
