The ctrl + c command to interrupt operations does not work.
I tested mine with the new update and it's working.
It doesn't work for me, either. Ctrl+c is completely ignored running on Windows 10 build 1607 running cmd.exe (not bash.exe). In bash.exe, ctrl+c works, but the up arrow key does not work.
ctrl + c works for me. Having issues with ctrl+ r, up arrow, down arrow, and ctrl + backspace.
Here I cannot copy test to clipboard but ctrl+c to interrupt processes seems to work as expected.
When trying to copy selected text to the keyboard, the moment I press 'shift' or 'ctrl', the text I have selected gets unselected, so keeping shift+ctrl down and pressing c to paste does nothing as there's nothing left selected.
Not sure if it's related: but that's with a French keyboard layout.
i also facing the same problem in copy text to clipboard, no matter i click Ctrl+C or Shift+Ctrl+C, once i click any of key those text will deselected.
P/S: Windows 10 64 bit user.
All of the issues described so far are happening on my machine as well. Win10 64bit with Bash on Ubuntu on Windows.
I just want to point out that ctrl+c works in a bash.exe shell, even though it does not work in the standard cmd.exe shell.
@mqudsi just to remove any shadow of doubt, it doesn't perform a copy, but cancels the current command (as it should)
@warpdesign Fix in #1218
The problem isn't only Ctrl+C alone, but any hotkeys bound to menu items under Linux and Windows. They're intercepted by Electron and not delivered to main window, I guess. For example, all my keybindings for tmux start from Ctrl+A and don't work in Hyper under Linux (instead, Select All is executed), but work well in macOS (Select All is Cmd+A there)
@kvj +1
@liuyang1204 there's a +1 button.
@kvj I'm not so sure about that. If that were the case, ctrl+c would not suddenly function if a bash.exe session is started under Windows.
Having quite the same problem in #1199 . I bound the "Close Session" shortcut to another key, but Ctrl+W is not working at all in vim.
Pressing Ctrl + C
closes the window for me, but I want to use this keyboard command to stop processes running, for example Gulp.
Running Windows 10 64bit.
+1 on Windows 10,
OS version and name: windows 10 x64
Hyper.app version: 1.0.0
I have also this problem
Still having this issue:
Hyper 1.0.0
Electron 1.4.7
win32 x64 10.0.14393
I don't think it's really worth people continuing to state they are still having the issue. There's a subscribe button on the right of this page so you can get notified of changes.
As I understand it the accelerator keys assigned to copy (and select all) in the menus are capturing the keys before they get to the app.
It appears VSCode has a similar issue so I'm just going to leave this here.
https://github.com/Microsoft/vscode/issues/9347#issuecomment-269923903
Something else I noticed is that the up and down keys work in PowerShell for going through history but it doesn't in the bash.exe shell even though ctrl+c
works there.
Regarding the copy shortcut (Ctrl+Shift+C): please test #1406 ๐
@matheuss Can we change the keybinding, cause I find this one pretty odd?
EDIT: Ctrl (Strg) + Shift + C is not working. It's not cancelling the current running task.
So what's the deal here? Is this a node-pty issue? I see some issues such as https://github.com/Tyriar/node-pty/issues/7 which talk about sporadic problems with ctrl+c, so I doubt it's that one. Is it a hyper problem? Electron?
Actually, upon looking into this once more, I remember. To clarify for myself and others: the command ctrl-c
works when running certain applications but not others under Windows. By default it does not work. _However_ if a bash.exe
process is started on Windows, it "magically" begins working. Meaning it's not an electron issue (or it would never on Windows) and likely not a node-pty issue, though I'm far less certain of that.
@mqudsi What Windows build are you on?
15048 now, but I've had this from the very start on the GA build.
Please be sure you're running the latest version of Hyper and re-test.
I am running Hyper 1.3.1 on Windows 10 Insider build 15058 and (as best I can tell) CTRL+C and cursor up and down work as expected in Cmd and Bash/WSL.
ctrl+c
works in git-bash
but not in cmd
or powershell
for me.
Thank you @sparebytes
My experience is the same. Note that in cmd (not powershell), not even ^C is posted to the terminal. Just absolutely nothing happens. In bash it works. In powershell, it posts ^C.
I have been repeatedly very clear about my experience with this bug. I have not tried 15058 but I did try 15055. I don't think that's the issue, but when I upgrade to 15058 I'll again report back.
Hey @sparebytes & @mqudsi
In Windows Console, Cmd outputs a blank line after each CTRL+C:
In Hyper, "nothing happens" whenever I hit CTRL+C:
HOWEVER in Hyper, if I execute dir c:\ /s
I can hit CTRL+C to terminate the recursive directory listing, so the CTRL+C is being send to CMD.
I don't know why Hyper doesn't cause Cmd to print a blank line while waiting for input.
Now, run PowerShell in Hyper and from Cmd in Console.
CTRL+C outputs ^C [CRLF] in Console:
... but Hyper doesn't output the [CRLF] in between each CTRL+C
My guess here is that Hyper is omitting a CRLF after each CTRL+C - this fix would likely solve both the PowerShell and Cmd behavior above
@bitcrazed nice detective work. I'm not sure if it explains everything though, but I could be wrong.
Try this:
echo Hello, ^CRich<Enter>
In a cmd window, that should give an error after <Enter>
. But in hyper, this outputs "Hello, Rich".
If it were just that cmd were getting the ^C
but hyper was not displaying the new line, you'd expect to have the same error output as you would in cmd.exe, no?
Whenever I press ctrl + c
it closes my Hyper window instead of stopping a program
Hyper 1.3.1
Electron 1.4.15
win32 x64 10.0.14393
I can report exactly the same situations as described by @sparebytes @mqudsi @bitcrazed on my machine, using Win10 14393.953. I am not on the Insider ring, but it isn't relevant; the only relevant difference between the Insider and Pro builds is fixes in Bash on Windows (WSL), and the problem is reportedly occurring in CMD and Powershell.
@richiekastl I just installed Hyper and I'm having the exact same behaviour: Ctrl+C closes the terminal.
I assume this isn't expected behaviour because it's extremely annoying.
+1 here. I'm running Hyper under Windows 10 and on my environment CTRL + C immediately closes the Hyper terminal's itself, instead stopping any running command.
to clarify @eness's comment: it closes the current tab. It's just that it closes Hyper because it's the only one.
To clarify, this only happens for me on my Windows 7 computer. On my Windows 10 computer Ctrl+C works as expected.
interestingly it works on my Windows 8.1 env but not on Windows 10. it still closes the active terminal tab down.
Running Win 10 release (14393). In a bash shell, Ctrl+C works typically. But in something like nano all the Ctrl+C, X, T etc get captured, so you cannot quit the process.
try CTRL + SHIFT + [key] while you are inside nano's interface. Use ie. CTRL + SHIFT + X to quit
try CTRL + SHIFT + [key] while you are inside nano's interface. Use ie. CTRL + SHIFT + X to quit
Great that works!
Quick compare of Ctrl C in powershell in Hyper compared to expected behavior (in ConEmu):
This is a total deal breaker. I can't user Hyper until this is fixed. Going back to ConEmu.
@giggio I agree. Its one of the common shortcuts any developer generally uses. I have also returned to ConEmu. Its like driving a car that has no breaks, which makes it annoying but also dangerous.
The current behavior is that ctrl+c will interrupt running programs as expected, but it will not send it to the underlying shell as expected (with hyper 1.3.1). escape does clear the current input, as expected.
My experience with Ctrl+C is that it will kill a running process, but if nothing is running, it will close the entire terminal window. Suuuuuper annoying.
Got a trick, thanks to @cnswico, to make ctrl+c
work properly when using bash from Git for Windows
: use the bash.exe
in usr/bin/
and not in bin/
.
shell: 'C:/Program Files/Git/bin/bash.exe
โ ctrl+c
closes the tabshell: 'C:/Program Files/Git/usr/bin/bash.exe
โ ctrl+c
seems to work as expected!! ๐ I'm on Windows 10 x64, with Hyper 1.3.1
, and I have the environment variable TERM
set to cygwin
.
@math2001
Can you paste a full gist to your .hyper.js file? I can't seem to get all the settings right.
I just went back to Hyper to see if anything evolved. Version 1.3.3 is out, maybe something is new, I thought, but I was wrong. This deal breaker bug is now 7 months old. It is such a pity, because Hyper seems such a nice editor, that I just can't use.
@giggio Hyper are relying on node-pty for emulation and node-pty in turn relies on win-pty for Windows support.
There is an upcoming fix in the next version (0.4.4) of win-pty. So we're waiting for a win-pty release. Then it requires node-pty to update to win-pty 0.4.4 and make a release of their own. Finally Hyper need to update to the would-be version of node-pty, and release a new version themselves.
It seems we have some more waiting to do.
Thanks for the update and explanation @stereokai !
I can confirm this issue present as of 23/07/2017 with latest Hyper. Especially annoying when working with IPython/Python.
Suggestion: default key mapping shouldn't clash with OS's terminal commands -e.g don't intercept ctrl-c,ctrl-z,ctrl-d etc.
Not to pile on, but since my combination isn't mentioned explicitly and differs from the only other Win7 mention, I'm experiencing the following:
I will close this after reading the discussion comments. The keybinding is fixed in #1876. However the functionality of ctrl+c
is internal to hterm
. We are in the making of moving to xterm
. In the meantime this is closed.
@ppot If ctrl + c does not work it does not make sense to close the issue. It sends the message that the issue is resolved, and it is not.
Closing this issue seems counter intuitive before it is fixed
@ppot big of you to re-open. Thank you.
Yeah again, I like this app. But without ctrl+c ctrl+r its worthless as a xterm emulator.
@ppot after a quick test, it seems that xterm doesn't handle it either.
Shift+Ctrl+C and Shift+Ctrl+V are functioning in Linux installation, but when selecting, copying and then pasting many lines I get a new tab added to the beginning of each line that was not there in selection that was copied.
@jaredgalanis is is related to shorcut ?
If you use menu to copy/paste, new tabs are not here?
@chabou, I now see that it's a vim set paste issue. Terminator (the previous terminal I used) handled this for you, but that's an added bonus, I don't think this is a bug in Hyper. So this is resolved for me. Thank you!
Also, yes, it's not a shortcut issue apparently. I didn't even know there was a menu in the Hyper version of Linux, but I've updated my .hyper.js file to reveal the hamburger menu. The pasting works the same with the shortcut or through the menu.
Tried on 2.0.4 which has xterm.js supposedly fixing the Ctrl+C issue but it's still there. Windows 10 1703.
@borekb @chabou
Of course it's still there! Because it's not xterm! It's win-pty and node-pty and until the respectful guys in Hyper don't wake up and update these dependencies (to be honest, the most they can do is put pressure on the win-pty and node-pty groups) we won't see a fix for Windows. Read my comment above
@stereokai Thanks for explanation but @ppot said they were moving to xterm above. I honestly have no idea which is true.
@mikemaccana there are two parts to a terminal - a PTY (node-pty/win-pty in Hyper) and a renderer (hterm in Hyper).
Hyper is moving from hterm to xterm, which is the renderer layer
The bug itself is in win-pty, which is the PTY layer
@mikemaccana @Eugeny exactly. Like I said, if this bugfix is important to you, you should put pressure on the win-pty team, the node-pty team and the Hyper team.
Thanks for the explanation @Eugeny
@sterokai or you can fork Hyper. There is always this option. Yey for FOSS!
If I interrupt a process with Ctrl-C Hyper stops printing what I type, but output works just fine (Windows 10). Is it the same bug as this one?
I just tried the latest canary, which comes with xterm, and the problem persists. Here is how to test it: https://github.com/zeit/hyper/issues/1275#issuecomment-342061997
Still happens on 2.0.0 canary 11
Linking to the win-pty issue:
https://github.com/rprichard/winpty/issues/116
and the fix https://github.com/rprichard/winpty/commit/c9ce3ad1e347d9535eef5c79927a82c9f8eb5f29
Looks like 0.44 hasn't been released yet, when it does, and the other projects adopt it, as @stereokai says we'll have the fix.
I just tested the latest canary (18), and CTRL+C
now breaks. It still does not work as expected in every scenario, but it breaks.
It still ouputs ^C
on the screen if you type it on a open line, and it still does not copy, as it is expected on the normal Windows Prompt on Windows 10. And CTRL+V
does not paste. It is better, but not there yet.
But we shouldn't expect it to copy in windows i don't think. By now I
don't know about you but in terminals I am used to shift+insert or
ctrl+shift+c
On Wed, Apr 18, 2018, 1:56 PM Giovanni Bassi notifications@github.com
wrote:
I just tested the latest canary (18), and CTRL+C now breaks. It still
does not work as expected in every scenario, but it breaks.
It still ouputs ^C on the screen if you type it on a open line, and it
still does not copy, as it is expected on the normal Windows Prompt on
Windows 10. And CTRL+V does not paste. It is better, but not there yet.โ
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/zeit/hyper/issues/1121#issuecomment-382474585, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AFB-9XHidtnZtiCI8xw22k9hEd3fwnoyks5tp35fgaJpZM4LKzS_
.
I can understand you not wanting it to copy, as I would expect the Hyper team to expect me to want it. I want it because this is the normal behavior on Windows now, and I use it like that when I am on plain cmd or posh. CTRL+SHIFT+C
and CTRL+SHIFT+V
are also coming to WSL (announced recently), so I expect that when it does, Hyper supports it. What it should do is work as expected. No surprises. And it should be configurable if I want it, so both @cnoffsin has his way, and I have mine.
I found that ctrl-h produces the character ^? (ASCII 127), the same as backspace. This makes it impossible to trigger any of the help functions in Emacs, since they start with ctrl-h. Do you consider this issue to be the same or do you want me to file this as a separate bug?
I'm using Hyper version 2.0.0 on Windows 10.
Is there any known workaround for cancelling a command in Windows until a fix for CTRL+C
is pushed? I see scenarios where the only remediation I can find is to close the tab. Ex: when running PowerShell and cmdlet prompts for argument values.
Ctrl + C to stop execution of a script. This is still seriously lagging for me on Mac using Hyper ver: 2.0.0 (Stable)
Tested on Terminal.app and Hyper.app ssh'd into a remote Fedora machine:
cd / && find . -mtime -2 -ls
Results:
Terminal.app stops execution right after Ctrl + C key combo.
Hyper.app keeps running after multiple attempts and then finally breaks 30 seconds to a minute after.
I read lots of the comments above although I'm not sure what the current status of this issue is. Does anyone have an update, or more examples (if that helps.)
Is this not fixed yet? I'm on hyper 2.0.0 stable on Win 10 x64, and Hyper's editor break still doesn't work when using ctrl + c
...
It's shift+ctrl+c by default on windows @sgarcia-dev
It should be ctrl+c
, which is the default.
This issue is about cancelling / interrupting (Ctrl C), not copying. Please report / discuss copying in another issue, as there's many people subscribed to this issue.
Still not working guys, using Windows 10 WSL
still not working on 2.1.0 canary
Still not working now.
There is no point in commenting to say it's not working. That's what the subscribe button is for, and until a developer actually cares about the problem and does something about it, it's going to continue not working because bugs don't randomly get fixed on their own.
It's very clear that cross-platform support is very low on the list of priorities for hyper developers. Anyone that actually cared about this has moved on from hyper a long time ago. There's no need for everyone to spam this issue with "new build came out today, still not working" because that accomplishes nothing.
For anyone who's really concerned about this, you may want to follow https://github.com/Microsoft/node-pty/issues/216. It seems like the only way this is ever going to be fixed.
Yes, the ConPTY
will change everything, but this is something that will only work on Windows 1809, that has not yet even come out (it should be out in the next weeks).
Even then, developers of terminal apps for Windows will have to create a ton of code to get it to work, and after it is done their app won't work on older Windows versions, which is a hard decision to make. Or even worse, support two different approaches. The good news is that Windows 10 versions are consolidating really fast. The bad news is that there are still a lot of users on Windows 7 and 8.
We hear ya @giggio and feel your pain. We wish that there was an easy solution here, but alas, there are a complex long-tail of issues preventing us from backporting the ConPTY API.
Do ping me if we can be of any help or if you find any issues, etc.: richturn at you know where .com!
FYI Windows folks: it's worth trying 'Terminus' https://github.com/Eugeny/terminus until this is fixed as Ctrl C works and it's quite similar (it's electron, uses CSS for styling etc) to Hyper!
@bitcrazed I am aware, I know this is a large effort, and I am happy it is finally happening! In time most of the terminal apps will have migrated, Windows 10 is more consolidated each day. Thank you and your team for your effort, you have been making our lives on Windows much much better.
@mikemaccana This Terminus looks cool! Trying it now!
@giggio No, thank YOU and the amazing community members who report issues and help us improve Windows and the Windows Console/Command-Line every day :) Exciting things ahead ๐ And of course, they Hyper devs and community who've built such a beautiful terminal ๐
Any updates?
I just saw that NodePTY is finally supporting ConPTY!
The Release:
https://github.com/Microsoft/node-pty/releases/tag/0.8.0
The PR:
https://github.com/Microsoft/node-pty/pull/236
And it seems to already have been integrated 2 weeks ago:
https://github.com/zeit/hyper/commit/dd68286c5f88c5a124049e0bcd7562e7d40c6a20
I don't know what is needed to enable ConPTY with Hyper, but if there was an option I would love to try it.
Ok, I just updated to the latest canary, and CTRL+C works!
I am on Windows version 10.0.17763.195
, which is version 1809.
This works because according to Node-PTY release notes, ConPTY works by default, unless you disable it. https://github.com/Microsoft/node-pty/releases/tag/0.8.0
So now I can go back to trying Hyper. Cool! I have been trying to leave ConEmu for a while, maybe now I can.
Thanks for confirming @Giggio - glad to see @Tyriar & @Zadjii-msft's work finally arrive ๐
I think it's safe to (finally) mark this as closed?
Awesome! Thank you so much @bitcrazed :pray:
LOL :) Thanks @chabou, but all credit to @Tyriar & @zadjii-msft who did the work ;)
@chabou FYI I've disabled conpty in vscode because:
After I fix the last problem I'm going to enable it by default on the latest Windows Insiders version.
Link to canary builds for those wondering https://github.com/zeit/hyper/releases
You'll also need to fix a couple of settings as it looks like Hyper doesn't start powershell by default:
shell: 'C:\\Program Files\\PowerShell\\6-preview\\pwsh.exe',
shellArgs: [],
Most helpful comment
@ppot If ctrl + c does not work it does not make sense to close the issue. It sends the message that the issue is resolved, and it is not.