Re: Is it OK to mount cygdrive on / ? (usually, but may not be as portable).
Greetings, L. A. Walsh! >> If you want to access Windows path, recommended route lies through the use of >> cygpath utility to convert native paths to the Cygwin scheme. Et vice versa. >> > I wouldn't recommend that -- it's too hard to type: I didn't say "typing" anywhere. I did mean permanent use, i.e. scripting. -- With best regards, Andrey Repin Sunday, February 5, 2017 11:47:10 Sorry for my terrible english... -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Bug in lrzip 0.631-1 (32 bit version) with -d -o - options
On 5 February 2017 at 07:37, Marco Atzeri wrote: > can you check if latest cygwin test solves the issue ? I did, it doesn't, see my previous message in thread. David -- 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] Updated: mintty 2.7.4
Hi Achim, Am 04.02.2017 um 17:13 schrieb Achim Gratz: Thomas Wolff writes: I have uploaded mintty 2.7.4 with the following changes: Since about November/December last year I'm having problems with screen and tmux sessions in mintty not correctly refreshing and leaving garbage characters displayed in the terminal. It seems that the terminal size is not always correctly reported, especially if you make the window occupy the left or right half of the screen via Windows shortcut. Is this within tmux or after leaving tmux (see comment below)? It would be help to cross-test this; if it's mintty, which version would show the behaviour first? What happens in xterm? Additionally, there seems to be an off-by-one bug when the last line of the terminal needs to be scrolled up in order to show content that is longer than the remaining width. This happens when you for instance recall a long command from history. It's hard to see what exactoly happens, but it looks like the one character too many gets printed (and wraps onto the next line) before the whole terminal window gest scrolled up and the rest of the command gets printed in the line below the single wrapped character. That remainder is in various states of disarray, showing both remnants from the original prompt on the last line (now three lines up), empty /spaces where there should have been characters from the command and then of course parts of the command. This might be related to some issue with terminal geometry as perceived by the shell (see https://github.com/mintty/mintty/issues/377#issuecomment-137728631). Have you checked that? Recently changed your prompt? Try with basic prompt (PS1="\w> ") please. -- Thomas -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: [ANNOUNCEMENT] Updated: mintty 2.7.4
Thomas Wolff writes: > Is this within tmux or after leaving tmux (see comment below)? It > would be help to cross-test this; if it's mintty, which version would > show the behaviour first? What happens in xterm? Within tmux or more often screen within tmux. I'll have to try what happens in plain mintty. > This might be related to some issue with terminal geometry as > perceived by the shell (see > https://github.com/mintty/mintty/issues/377#issuecomment-137728631). Have > you checked that? Recently changed your prompt? Try with basic prompt > (PS1="\w> ") please. No, I don't think it's related to that issue and I haven't changed my prompt in years. It's specifically happening only on the last line in the terminal window with the first character that should wrap onto the next line and not anywhere else and only when scrolling the window happens. If the shell has lost the correct terminal geometry, then it's wrong on all lines of the terminal, not just the last in my experience. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Samples for the Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#BlofeldSamplesExtra -- 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
Console buffer width always 1 column less than setting
This issue has bothered me for some time, but I never got around to reporting it. The issue is that the Cygwin buffer via Cygwin.bat is always 1 less than what is set. For example, the default buffer is 80 columns, same as the window size. Cygwin window size is correct, but that last column can never be accessed, it always stays blank and the text wraps on column 79. Here is a test: 1. Enter spaces until you reach next line, this way the prompt is not adding to our count 2. Enter: 12345678901234567890123456789012345678901234567890123456789012345678901234567890 Now with cmd.exe, you get all 80 characters on the same line, but with Cygwin it always wraps 1 character before. I don’t remember this always being the case, I believe it used to work correct 1-2 years ago. -- 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: Console buffer width always 1 column less than setting
> On Feb 5, 2017, at 1:53 PM, Steven Penny wrote: > > This issue has bothered me for some time, but I never got around to reporting > it. The issue is that the Cygwin buffer via Cygwin.bat is always 1 less than > what is set. > > For example, the default buffer is 80 columns, same as the window size. Cygwin > window size is correct, but that last column can never be accessed, it always > stays blank and the text wraps on column 79. Here is a test: > > 1. Enter spaces until you reach next line, this way the prompt is not adding > to > our count > > 2. Enter: > 12345678901234567890123456789012345678901234567890123456789012345678901234567890 > > Now with cmd.exe, you get all 80 characters on the same line, but with Cygwin > it > always wraps 1 character before. I don’t remember this always being the case, > I > believe it used to work correct 1-2 years ago. I'm on Win7 64-bit with 64-bit Cygwin 2.6.0(0.304/5/3). To clarify, the above occurs with bash 4.3.46(7) in a Windows console, and I see the behavior there as well. This does not happen with the same bash in mintty 2.7, so it appears to be specific to the combination of bash and the Windows console. -- 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: Is it OK to mount cygdrive on / ?
On 2/3/2017 4:09 PM, Rustam wrote: > I've added an extra / mountpoint in /etc/fstab in order to be able to > access C: without /cygdrive like this: > > none /cygdrive cygdrive binary,posix=0,user 0 0 > none / cygdrive binary,posix=0,user 0 0 > > It seems to work, I can access the C: drive with just /c. > > But normally an "ls /cygdrive" should list the drives, whereas "ls /" > lists the contents of the Cygwin root. So it seems there are now two > root mountpoints overlaying each other. > > So I was wondering if my approach is if this is technically undefined > behavior and might conceivably break something or is it OK (less the > drive listing limitation mentioned above). > I've used the / as /cygdrive since the beginning of /cygdrive. The issue you see is the fact that Cygwin doesn't require a physical directory to mount as Linux and friends do. If you want to see them then you simply create a physical empty directory in the Cygwin root directory. I do find it interesting that the mount also changes the output of `ls /proc/cygdrive/` but that is a different issue. Another method to see which drive letters are available is to simply type mount at the command prompt. -- cyg 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
Re: [ANNOUNCEMENT] Updated: mintty 2.7.4
On 2017-02-05 11:35, Thomas Wolff wrote: > Hi Achim, > > Am 04.02.2017 um 17:13 schrieb Achim Gratz: >> Thomas Wolff writes: >>> I have uploaded mintty 2.7.4 with the following changes: >> Since about November/December last year I'm having problems with >> screen and tmux sessions in mintty not correctly refreshing and >> leaving garbage characters displayed in the terminal. It seems that >> the terminal size is not always correctly reported, especially if >> you make the window occupy the left or right half of the screen via >> Windows shortcut. > Is this within tmux or after leaving tmux (see comment below)? It > would be help to cross-test this; if it's mintty, which version > would show the behaviour first? What happens in xterm? >> Additionally, there seems to be an off-by-one bug when the last >> line of the terminal needs to be scrolled up in order to show >> content that is longer than the remaining width. This happens when >> you for instance recall a long command from history. It's hard to >> see what exactoly happens, but it looks like the one character too >> many gets printed (and wraps onto the next line) before the whole >> terminal window gest scrolled up and the rest of the command gets >> printed in the line below the single wrapped character. That >> remainder is in various states of disarray, showing both remnants >> from the original prompt on the last line (now three lines up), >> empty /spaces where there should have been characters from the >> command and then of course parts of the command. > This might be related to some issue with terminal geometry as > perceived by the shell (see > https://github.com/mintty/mintty/issues/377#issuecomment-137728631). > Have you checked that? Recently changed your prompt? Try with basic > prompt (PS1="\w> ") please. Thanks for supporting and enhancing mintty to be even better in Cygwin, and able to be used as a console for other environments. The test below may be relevant to the above problem, or may be unrelated. Running vttest 2.7 (20140305) http://invisible-island.net/vttest/vttest.html updated by and used by xterm maintainer for testing. Test 1. Test of cursor movements screens 3 80 col mode and 4 132 col mode gives results looking like below (shortened lines to 71 characters to avoid wrap issues and fixed content to match display results): Test of autowrap, mixing control and print characters. The left/right margins should have letters in order: M m N n O o P p Q q R r S s T t U u V v W w X x Y y Z z Push Unfortunately most of the test documentation is in the source as tables. If you find vttest useful, it might be worth adding to the mintty package as a test program, where you or others could ask users with problems to run specific tests, as xterm does. It may also be useful if mintty had some character hex value box display mode switch to display the actual codes at each visual position, or maybe a font used to display the character hex value in a box, often used in fonts as glyphs for non-printing control characters and those in the Private Use Area, in which case that could perhaps be added to the mintty package for use in testing. I have been searching for such a font with no success so far. -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada -- 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: Console buffer width always 1 column less than setting
On Sun, 5 Feb 2017 14:12:04, Vince Rice wrote: > > On Feb 5, 2017, at 1:53 PM, Steven Penny wrote: Please fix your email client. You should not be quoting people’s email directly. -- 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
