Re: echo $(cygcheck...) oddity
cygwin-owner wrote on 02/16/2011 01:13:37 PM: On 02/16/2011 11:07 AM, L Anderson wrote: Could the following signal a possible string buffering problem? Nope. Rather, it's an indication that cygcheck is a native windows program... However,when I do echo $(cygcheck /bin/sh.exe) I get: C:\WINDOWS\system32\GDI32.dl and as such, it outputs \r\n line endings. When echo is given only one argument, it outputs that argument literally, so the \r are immediately followed by newline, and you don't notice the difference. But when echo is given multiple arguments, as is the case when you don't use around $(), then each argument is separated by a space rather than a newline. And since word splitting ate the \n, that only leaves you with \r, which rewinds to the beginning of the line for each line printed. which clearly is unexpected. Then your expectations are wrong. Get in the habit of properly quoting command substitution. -- Eric Blake eblake at redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org This is an informational note - I wasn't sure where to bring this up. I suspected a problem with \r, so I tried it. However, I am using pdksh, and ended up with something that really was unexpected... Take careful note the first three lines of the output for the second command. It turns out this is the result of the behavior of the internal echo command that pdksh uses. If echo is replaced with echo -E or /bin/echo, the output looks like that found when executing the commands in bash. For what it is worth, the output of the third command piped into od -c (see below) shows why you get the reduced number of displayed lines - as Eric pointed out, the \r is not paired with a \n. $ cygcheck /bin/sh.exe C:\cygwin\bin\sh.exe C:\cygwin\bin\cyggcc_s-1.dll C:\cygwin\bin\cygwin1.dll C:\WINXP\system32\ADVAPI32.DLL C:\WINXP\system32\KERNEL32.dll C:\WINXP\system32\ntdll.dll C:\WINXP\system32\RPCRT4.dll C:\WINXP\system32\Secur32.dll C:\cygwin\bin\cygintl-8.dll C:\cygwin\bin\cygiconv-2.dll C:\cygwin\bin\cygreadline7.dll C:\cygwin\bin\cygncurses-9.dll C:\WINXP\system32\USER32.dll C:\WINXP\system32\GDI32.dll $ echo $(cygcheck /bin/sh.exe) C:ygwiin\sh.exe C:ygwiinyggcc_s-1.dll C:ygwiinygwin1.dll C:\WINXP\system32\ADVAPI32.DLL C:\WINXP\system32\KERNEL32.dll C:\WINXP\system32 tdll.dll C:\WINXP\system32\RPCRT4.dll C:\WINXP\system32\Secur32.dll C:ygwiinygintl-8.dll C:ygwiinygiconv-2.dll C:ygwiinygreadline7.dll C:ygwiinygncurses-9.dll C:\WINXP\system32\USER32.dll C:\WINXP\system32\GDI32.dll $ echo $(cygcheck /bin/sh.exe) C:\WINXP\system32\KERNEL32.dll C:\WINXP\system32\GDI32.d $ cygcheck /bin/sh.exe | od -c 000 C : \ c y g w i n \ b i n \ s h 020 . e x e \r \n C : \ c y g w i 040 n \ b i n \ c y g g c c _ s - 1 060 . d l l \r \n C : \ c y g 100 w i n \ b i n \ c y g w i n 1 . 120 d l l \r \n C : \ W I 140 N X P \ s y s t e m 3 2 \ A D V 160 A P I 3 2 . D L L \r \n 200 C : \ W I N X P \ s y s t 220 e m 3 2 \ K E R N E L 3 2 . d l 240 l \r \n C : \ 260 W I N X P \ s y s t e m 3 2 \ n 300 t d l l . d l l \r \n 320 C : \ W I N X P \ s y s t e 340 m 3 2 \ R P C R T 4 . d l l \r \n 360 C : \ W I N 400 X P \ s y s t e m 3 2 \ S e c u 420 r 3 2 . d l l \r \n C : \ c y 440 g w i n \ b i n \ c y g i n t l 460 - 8 . d l l \r \n C : \ c 500 y g w i n \ b i n \ c y g i c o 520 n v - 2 . d l l \r \n C : \ c 540 y g w i n \ b i n \ c y g r e a 560 d l i n e 7 . d l l \r \n 600 C : \ c y g w i n \ b i n \ c y 620 g n c u r s e s - 9 . d l l \r \n 640 C : \ W I N X P \ s y s 660 t e m 3 2 \ U S E R 3 2 . d l l 700 \r \n C : \ W I N X P 720 \ s y s t e m 3 2 \ G D I 3 2 . 740 d l l \r \n
Re: Accessing folders elsewhere than C:\cygwin
Eric wrote on 02/10/2011 12:15:33 PM: On 02/10/2011 10:13 AM, Buchbinder, Barry (NIH/NIAID) [E] wrote: Might the ability to identify cygwin's root be a good thing to add to cygpath? And what's so hard about 'cygpath -w /'? Under System information, one could have an option -R, --rootoutput cygwin root directory where $ cygpath -Rw C:\cygwin Trading / for -R doesn't justify the bloat and burning another short option character, in my opinion. -- Eric Blake eblake at redhat dot com+1-801-349-2682 Libvirt virtualization library http://libvirt.org If you need it ofetn enough, here is a simple script for displaying the cygwin root: case $1 in -w) mount | grep / | cut -d -f1 | sed 's:/:\\:g' ;; -u) DRIVE=$(mount | grep / | cut -d: -f1): echo $(mount | grep ^$DRIVE | \ cut -d -f3)$(mount | grep / | cut -d -f1) | \ sed 's/'$DRIVE'//' ;; *) echo Please specify -w (Windows) or -u (Unix) ;; esac - Phil -- 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: Accessing folders elsewhere than C:\cygwin
cygwin-owner wrote on 02/10/2011 03:35:53 PM: On Thu, Feb 10, 2011 at 03:23:38PM -0500, RISINGP1 wrote: Eric wrote on 02/10/2011 12:15:33 PM: On 02/10/2011 10:13 AM, Buchbinder, Barry (NIH/NIAID) [E] wrote: Might the ability to identify cygwin's root be a good thing to add to cygpath? And what's so hard about 'cygpath -w /'? Under System information, one could have an option -R, --rootoutput cygwin root directory where $ cygpath -Rw C:\cygwin Trading / for -R doesn't justify the bloat and burning another short option character, in my opinion. If you need it ofetn enough, here is a simple script for displaying the cygwin root: case $1 in -w) mount | grep / | cut -d -f1 | sed 's:/:\\:g' ;; -u) DRIVE=$(mount | grep / | cut -d: -f1): echo $(mount | grep ^$DRIVE | \ cut -d -f3)$(mount | grep / | cut -d -f1) | \ sed 's/'$DRIVE'//' ;; *) echo Please specify -w (Windows) or -u (Unix) ;; esac Why would we need a simple script to display the cygwin root when cygpath -w / works fine? cgf OK. You are right (somehow I missed the cygpath -w / mention in the thread - oops). Change -w) mount | grep / | cut -d -f1 | sed 's:/:\\:g' ;; to -w) cygpath -w / ;; But cygpath -u / will give / as an answer. The script will give (for me) /cygdrive/c/cygwin. I was merely trying to offer an alternative to Barry's request for the -R option on cygpath. Specifically, it answers this part of his request: $ cygpath -Ru /cygdrive/c/cygwin or, if the cygdrive prefix has been changed to a simple /, $ cygpath -Ru /c/cygwin - Phil -- 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
Fw: 1.7.7: window cuts off output / saving output
On Feb 2 11:13, Rachel Trent wrote: I have a seemingly simple problem that I either haven't found the answer to or I didn't understand the answer when I saw it. I presume I'm not describing it with the correct terminology... Short version: In layman's terms, the Cygwin window cuts off at the top, and I'd like to know if the output that's been cut off is forever lost or if I might be able to save it to a file or view it some other way. Long version: Within a larger script, I copied over a thousand files from one server to another using the following command: cp -R -n -p -v $package $destination | tee -a $destination/copiedfiles.txt In the future, to capture the errors as well: cp -R -n -p -v $package $destination 21 | tee -a $destination/copiedfiles.txt However, several files failed to copy due to permissions issues/etc, and the copiedfiles.txt file does not include the error information. The onscreen output does include this information (due to using the -v verbose option), however I can only scroll up to see about 300 lines of information (surprise! I wasn't expecting this). My question is: can I somehow access the output that was cut off? This is not a Cygwin problem. The scrollback buffer is provided by the underying Windows console. You can change that in the console window properties dialog. -- 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
How can I get mintty to not display my password?
When using cmd.exe, when I am prompted for a password, no characters are displayed, but the password gets entered. However, when I use mintty, the characters I type at the password prompt are displayed. TERM=xterm. How can I stop this from happening? In cmd.exe: --- sqlplus risin...@ctibeta2 SQL*Plus: Release 10.2.0.1.0 - Production on Fri Oct 22 14:38:07 2010 Copyright (c) 1982, 2005, Oracle. All rights reserved. Enter password: Connected to: Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - 64bit Production With the Partitioning, Data Mining and Real Application Testing options SQL In mintty: -- sqlplus risin...@ctibeta2 SQL*Plus: Release 10.2.0.1.0 - Production on Fri Oct 22 14:38:07 2010 Copyright (c) 1982, 2005, Oracle. All rights reserved. Enter password: hereISmyPASSWORD Connected to: Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - 64bit Production With the Partitioning, Data Mining and Real Application Testing options SQL Thanks, - Phil Phil Rising, Principal Consultant for Sogeti USA, LLC Contracted to Nationwide, Corporate Internet and Contact Center Solutions Team (Work) (614) 677-7445, (Fax) (614) 677-7046 Alternate email: phil.ris...@us.sogeti.com -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: simulating console input
On 9/2/2010 3:47 AM, Peter Münster wrote: Hello, I would like to run a Dos program, that needs keyboard input (just one Y), automatically via make in an ssh-session. How could I simulate the Y keypress? echo Y | DosProgram.exe does not work... The keypress is accepted only in a dos-console. Read http://cygwin.com/cygwin-ug-net/using-effectively.html#using-console. Then add this fact - the SSH server uses ptys. So your program will not work with a single character put in the input buffer. One could envision using 'yes' to fill the buffer of the pipe that the Windows program interprets the pty to be. Perhaps a nicer alternative is to build the problematic program with Cygwin, if that's an option, so that it will understand the pty. Would an inline document work? DosProgram.exe ! Y ! - Phil Phil Rising, Principal Consultant for Sogeti USA, LLC Contracted to Nationwide, Corporate Internet and Contact Center Solutions Team (Work) (614) 677-7445, (Fax) (614) 677-7046 Alternate email: phil.ris...@us.sogeti.com -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
How does one change the default shell?
I use pdksh as my login shell - I have been using the Korn shell (thanks Dave!) since 1984 or so, so it is what I am used to and has features I haven't been able to find in bash - at least not yet. So to expedite script writing, I use the ksh language and features Every time that I write a script, I have to remember to put in the shebang line (#!/bin/pdksh) or half the time my scripts won't work. Is there a way to change the default shell for cygwin? I checked the user guide and the FAQ, but no joy there. I tried setting and exporting the SHELL variable, but that did not work. Thanks, - Phil Phil Rising, Principal Consultant for Sogeti USA, LLC Contracted to Nationwide, Corporate Internet and Contact Center Solutions Team (Work) (614) 677-7445, (Fax) (614) 677-7046 Alternate email: phil.ris...@us.sogeti.com -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: How does one change the default shell?
On 09/02/2010 04:29 PM, risin...@nationwide.com wrote: I use pdksh as my login shell - I have been using the Korn shell (thanks Dave!) since 1984 or so, so it is what I am used to and has features I haven't been able to find in bash - at least not yet. So to expedite script writing, I use the ksh language and features Every time that I write a script, I have to remember to put in the shebang line (#!/bin/pdksh) or half the time my scripts won't work. Is there a way to change the default shell for cygwin? I checked the user guide and the FAQ, but no joy there. I tried setting and exporting the SHELL variable, but that did not work. Assuming you meant the default shell for your particular user id, it is just a matter of changing cygwin.bat or whatever shortcut you are using to start cygwin to call pdksh instead of bash. You can also edit /etc/passwd to set your preferred shell (some tools, like mintty, honor that setting). My /etc/passwd entry: RISINGP1:unused_by_nt/2000/xp:287838:10545:RISINGP1,U-NWIE\RISINGP1,S-1-5-21-725345543-616249376-1177238915-277838:/cygdrive/c/cygwin/home/risingp1:/bin/pdksh My cygwin.bat: @echo off C: chdir C:\cygwin\bin REM bash --login -i REM pdksh -l -i start mintty -p 70,0 -t Console -e - This starts me off in pdksh, but when I execute a shell script, it runs under bash. Any other ideas? Thanks, - Phil P.S. I did not realize I was commandeering the thread. My apologies - it won't happen again. -- 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: How does one change the default shell?
[ACK! I just realized I was continuing my usurping of the thread. Sorry.] On 09/02/2010 04:29 PM, risin...@nationwide.com wrote: I use pdksh as my login shell - I have been using the Korn shell (thanks Dave!) since 1984 or so, so it is what I am used to and has features I haven't been able to find in bash - at least not yet. So to expedite script writing, I use the ksh language and features Every time that I write a script, I have to remember to put in the shebang line (#!/bin/pdksh) or half the time my scripts won't work. Is there a way to change the default shell for cygwin? I checked the user guide and the FAQ, but no joy there. I tried setting and exporting the SHELL variable, but that did not work. Assuming you meant the default shell for your particular user id, it is just a matter of changing cygwin.bat or whatever shortcut you are using to start cygwin to call pdksh instead of bash. You can also edit /etc/passwd to set your preferred shell (some tools, like mintty, honor that setting). My /etc/passwd entry: RISINGP1:unused_by_nt/2000/xp:287838:10545:RISINGP1,U-NWIE\RISINGP1,S-1-5-21-725345543-616249376-1177238915-277838:/cygdrive/c/cygwin/home/risingp1:/bin/pdksh My cygwin.bat: @echo off C: chdir C:\cygwin\bin REM bash --login -i REM pdksh -l -i start mintty -p 70,0 -t Console -e - This starts me off in pdksh, but when I execute a shell script, it runs under bash. Any other ideas? Thanks, - Phil P.S. I did not realize I was commandeering the thread. My apologies - it won't happen again. -- 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: How does one change the default shell?
Ah, so you mean how to change /bin/sh to be pdksh instead of bash.
Simple:
cp /bin/{pdk,}sh
But be prepared to redo that every time you upgrade bash via
setup.exe,
and don't come crying to the list if things break that were expecting
bash when they got pdksh.
Thanks. I was hoping to effect the change environmentally - not
have to change exe's.
Should I follow that route, no crying will ensue.
I will probably just continue using the shebang line for safety.
- Phil
--
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: 'cp' utility bug when dest-name.exe file exist.
On 06/08/2010 10:52 AM, Eric Blake wrote: On 06/08/2010 08:43 AM, Steven Collins wrote: directory as can be demonstrated by a simple touch foo foo.exe command. Both files will be created. Arguably, both should NOT be created, for the same reasons. That is, it is probably worth a patch to make open(foo.exe,O_CREAT|O_EXCL,mode) fail if foo exists, and open(foo.exe,O_CREAT,mode) delete foo if it exists, effectively renaming foo to foo.exe. I disagree. This seems to me to be adopting the Microsoft policy of doing the user's thinking for them: I don't care what they want - we know what's best for them. If a person wants to have foo and foo.exe in the same directory, that should be allowed. A few times getting tripped up by the wrong thing executing will be a good life lesson for the person, and teach about how different operating systems work to boot. Should I create foo as an executable, and foo.exe exists, then if I want to run foo.exe, I should have to call it out specifically. I can see this might cause some confusion should, unbeknownst to the user, foo.exe exists earlier in the path than foo, but that would become an education on how to use the PATH variable. This confusion arises from Cygwin's kowtowing to Microsoft's dubious idea of using extensions to control the handling of files. As to the automatic deletion/renaming of a file - DON'T EVER DO THIS! As to the cp issue, while IMHO, it should go ahead and do the copy, a more instructive error message would be helpful: cp: cannot create regular file `my': File 'my.exe' exists which the magic gets applied and foo.exe, foo.bat, You are misunderstanding the magic. It only happens for .exe, and that is because the Unix world is steeped in the tradition of suffix-less executables, but Windows insists on having the .exe suffix for cmd to be able to run an executable. Cygwin goes to various lengths to try to support both, at the expense that you shouldn't have both exist in the same directory. .bat has nothing to do with .exe magic. There certainly appear to be inconsistencies within the tools. Yes, and as they get pointed out, we try to make them more consistent. -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org Phil Rising risin...@nationwide.com -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: 'cp' utility bug when dest-name.exe file exist.
On 06/08/2010 09:42 AM, risin...@nationwide.com wrote: As to the cp issue, while IMHO, it should go ahead and do the copy, a more instructive error message would be helpful: cp: cannot create regular file `my': File 'my.exe' exists Huh? Do the copy, then give a failure message? No. A failure message should only occur if the copy failed. Did you mean continue to fail, but make the failure message more friendly? If so: Patches to coreutils welcome. But be aware that this error message uses the equivalent of perror(), where EEXIST would not have quite that wording. In other words, such a patch would be pretty invasive, to recognize the exact errno value that cygwin1.dll returns in this particular failure-to-create case, then massaging just that error case into your desired message, so I probably won't be writing the patch any time soon (I've got higher-priority things on my plate at the moment). Or did you mean change it to succeed, in spite of the naming conflict, in which case there is no failure message and nothing to patch in coreutils. -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org Eric - Sorry for the confusion. I understand how it arose. What I meant: 1) IMHO, cp should do the copy. Also, IMHO, there is no naming conflict; foo and foo.exe are not the same name. (I come from a long UNIX background.) No error message should be issued. 2) If cp is going to fail the copy, a more instructive error message would be helpful. I understand the issue with using the generic (this is NOT a bad thing) perror(). But maybe in this case, the cp command could go the extra mile (needed because of Microsoft), and explain the reason for this particular failure if it is going to fail the command. I would not recommend changing perror() - what a mess (not to mention, a ton of work) that would create! Thanks. Phil Rising risin...@nationwide.com -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: 'cp' utility bug when dest-name.exe file exist.
I disagree. This seems to me to be adopting the Microsoft policy of doing the user's thinking for them: I don't care what they want - we know what's best for them. If a person wants to have foo and foo.exe in the same directory, that should be allowed. A few times getting tripped up by the wrong thing executing will be a good life lesson for the person, and teach about how different operating systems work to boot. Should I create foo as an executable, and foo.exe exists, then if I want to run foo.exe, I should have to call it out specifically. I can see this might cause some confusion should, unbeknownst to the user, foo.exe exists earlier in the path than foo, but that would become an education on how to use the PATH variable. This confusion arises from Cygwin's kowtowing to Microsoft's dubious idea of using extensions to control the handling of files. If you took away Cygwin's .exe extension handling and just relied on file permissions like Unix, then using Cygwin tools from a cmd.exe prompt would become problematic. Windows wants that .exe (or .bat or .cmd or .msi, etc) extension and doesn't give a whip if you chmod a file's permissions +x. Without an extension, Windows has no idea what to do with the file. That's fine if you never do anything with Cygwin commands outside of a Cygwin shell, but I don't think this is a globally desirable behaviour. Just a question: Shouldn't it be up to the user to determine how a file is to be used, and name the file accordingly? If the file is to used only in a Cygwin environment, leave the extension off is desired. If the file is to used in both a Cygwin and a Windows environment, add an extension (like .sh or .exe or whatever is needed). It is easy enough to teach Windows how to recognize what to do with a new extension (like .sh). I am just against operating systems making decisions for the user, or restricting him/her unnecessarily. And, yes, I know that this happens all the time... Phil Risingrisin...@nationwide.com -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: cygwin : bash doesn't recognize BackSpace
I was having trouble with the backspace key, but it was with pdksh, so I don't know if this will work for you, but it is worth a try... Andy Koppe andy.ko...@gmail.com wrote: From the cygwin-1.7.5 release announcement: - Support DEC Backarrow Key Mode escape sequences (ESC [ ? 67 h, ESC [ ? 67 l) in Windows console. (The first one switches to ^H. You'll need to set stty erase accordingly.) - Phil From: Christopher Faylor cgf-use-the-mailinglist-ple...@cygwin.com To: cygwin@cygwin.com Date: 05/27/2010 10:03 AM Subject: Re: cygwin : bash doesn't recognize BackSpace Sent by: cygwin-ow...@cygwin.com On Thu, May 27, 2010 at 05:49:53PM +0400, Andrei Dmitriev wrote: Dave Korn wrote: On 27/05/2010 11:48, Andrei Dmitriev wrote: after I installed the cygwin on May 19 the bash console don't recognize *BACKSPACE* and continue to follow to the right each time I press BACKSPACE. Although, seem it actually erases the chars from the left (ENTER says nothing - so I concluded the command is empty). MKS tools are interfering with Cygwin, because of these environment variable settings: TERM = 'nutc' TERMCAP = 'D:\PROGRA~1\MKSTOO~1\etc\termcap' TERMINFO = 'D:\PROGRA~1\MKSTOO~1\usr\lib\terminfo' You need to remove them from the environment, and should set your PATH so it doesn't have both Cygwin and MKS at the same time. Ok, I removed mks from my path but the problem persists. It sounds like you only did half of what you need to. You need to remove the other environment variables too. Setting TERM=nutc is obviously incorrect for cygwin, as is pointing to non-cygwin vesions of TERMCAP and TERMINFO. cgf -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Cygwin 1.7.5-1: backspace does not work correctly when using set -o vi in pdksh in the console window
When using the set -o vi mode in pdksh, the backspace key is no longer a movement key - it does not make the cursor move to the left over the existing characters leaving them unchanged when the command line edit mode is entered using the ESC key. The cursor does not move at all. Steps to reproduce: 1) Change the startup cygwin batch file @echo off C: chdir C:\cygwin\bin pdksh -l -i 2) Once the console window is open, enter the command stty erase ^? (this is the incorrect character value (0x7f) that the backspace key is now sending in the console window - it should be sending ^H (0x08) like it has for decades in every terminal interface I have used, except for one - the 0x7f value is what used to be generated by the Delete key.) 3) Enter the command set -o vi 4) Start typing a new command (e.g., xyzzy) 5) Press the ESC key to enter the command line edit mode (the cursor positions itself on the last y) 6) Press the backspace key Expected result:the cursor backs up over the characters leaving them unchanged Actual result: the cursor does not move The ability to modify the character value generated by the Backspace key is a logical solution rather than forcing people to accept a change to the 0x7f value. I have many programs that rely on the value generated by the Backspace key being 0x08. The PuTTY program allows the user to choose which character values get generated by the Backspace and Delete keys, and I consider this a nice feature as it allows programs to behave as expected no matter what interface they are expecting. Thank you, - Phil Phil Rising, Principal Consultant in the Managed Testing Practice for Sogeti USA, LLC Contracted to Nationwide, Corporate Internet and Contact Center Solutions Team (Work) (614) 677-7445, (Fax) (614) 677-7046 Alternate email: phil.ris...@us.sogeti.com -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
