Is there a list of keyboard shortcuts, specifically to break a running command?
I grepped a file and got more than I expected and couldn't break out of it.
The typical CNTL + C or Z didn't work, nor Command + C or Z.
I killed the session but that is definitely not desirable.
Roger
The shortcuts for terminate a process are defined by the shell you're using, for bash, it is Ctrl + C.
But if the process is printing large chunk of data through fast network, the Core Shell may actively parsing data, and has no chance to send kill signal to the remote.
It's a known defect and we will try to elevate priority of data sending in future release.
I have the same problem in Version 1.8.
reproducable:
A simple "ping -f 127.0.0.1" cannot be aborted !
Actually you can abort it, just need to wait more time than system Terminal.app.
The internal mechanism of Core Shell is designed to be asynchronous and high throughput capable. So if remote sending data in a high rate, Core Shell will try hard to receive and parse data as fast as it can, it makes Core Shell more responsive than system Terminal.app.
But the drawback is the local key strokes may not get opportunity to be sent to remote.
It's hard to change the original design, but it does not means it can't be changed, we need time to find a proper solution and do a deliberately test.
Thank you for your immediate response. I understand the concept, although to my opinion the drawback is not acceptable. However I seem to have some problem with the parser then, which might causing my issue here.
Scenario:
I ran an "rsync --progress" with a load of around 600.000 files to see the progress every now and then when returning to that tab window. Even the rsync process is finished already and all network buffers are empty, I can see Core Shell still struggling to display all the output on the screen (after DAYS!). So I turned on the feature of logging the output, which results in the following:
iMac27gar:RO043 alex$ ls -alstr
total 9520
0 drwx------@ 3 alex staff 96 Sep 8 09:30 ..
2056 -rw-r--r--@ 1 alex staff 1049670 Sep 8 09:38 io.coressh.shell 2019-09-08--07-37-11-031.log
2056 -rw-r--r--@ 1 alex staff 1050792 Sep 8 09:39 io.coressh.shell 2019-09-08--07-38-05-319.log
2056 -rw-r--r--@ 1 alex staff 1049907 Sep 8 09:41 io.coressh.shell 2019-09-08--07-39-57-420.log
2064 -rw-r--r--@ 1 alex staff 1050121 Sep 8 09:41 io.coressh.shell 2019-09-08--07-41-15-831.log
0 drwxr-xr-x@ 7 alex staff 224 Sep 8 09:41 .
1288 -rw-r--r--@ 1 alex staff 650711 Sep 8 09:43 io.coressh.shell 2019-09-08--07-41-54-412.log
iMac27gar:RO043 alex$ ls -alstr
total 8752
0 drwx------@ 3 alex staff 96 Sep 8 09:30 ..
2056 -rw-r--r--@ 1 alex staff 1050792 Sep 8 09:39 io.coressh.shell 2019-09-08--07-38-05-319.log
2056 -rw-r--r--@ 1 alex staff 1049907 Sep 8 09:41 io.coressh.shell 2019-09-08--07-39-57-420.log
2064 -rw-r--r--@ 1 alex staff 1050121 Sep 8 09:41 io.coressh.shell 2019-09-08--07-41-15-831.log
2056 -rw-r--r--@ 1 alex staff 1051178 Sep 8 09:43 io.coressh.shell 2019-09-08--07-41-54-412.log
0 drwxr-xr-x@ 7 alex staff 224 Sep 8 09:43 .
520 -rw-r--r--@ 1 alex staff 204105 Sep 8 09:44 io.coressh.shell 2019-09-08--07-43-47-563.log
iMac27gar:RO043 alex$ ls -alstr
total 8760
0 drwx------@ 3 alex staff 96 Sep 8 09:30 ..
2056 -rw-r--r--@ 1 alex staff 1048770 Sep 8 09:49 io.coressh.shell 2019-09-08--07-48-54-370.log
2056 -rw-r--r--@ 1 alex staff 1049891 Sep 8 09:51 io.coressh.shell 2019-09-08--07-49-49-462.log
2056 -rw-r--r--@ 1 alex staff 1050893 Sep 8 09:52 io.coressh.shell 2019-09-08--07-51-36-709.log
2072 -rw-r--r--@ 1 alex staff 1048926 Sep 8 09:53 io.coressh.shell 2019-09-08--07-52-40-789.log
0 drwxr-xr-x@ 7 alex staff 224 Sep 8 09:53 .
520 -rw-r--r--@ 1 alex staff 212548 Sep 8 09:53 io.coressh.shell 2019-09-08--07-53-19-549.log
iMac27gar:RO043 alex$ ls -alstr
total 9800
0 drwx------@ 3 alex staff 96 Sep 8 09:30 ..
2056 -rw-r--r--@ 1 alex staff 1050893 Sep 8 09:52 io.coressh.shell 2019-09-08--07-51-36-709.log
2072 -rw-r--r--@ 1 alex staff 1048926 Sep 8 09:53 io.coressh.shell 2019-09-08--07-52-40-789.log
2056 -rw-r--r--@ 1 alex staff 1049644 Sep 8 09:55 io.coressh.shell 2019-09-08--07-53-19-549.log
2056 -rw-r--r--@ 1 alex staff 1051591 Sep 8 09:56 io.coressh.shell 2019-09-08--07-55-24-022.log
0 drwxr-xr-x@ 7 alex staff 224 Sep 8 09:56 .
1560 -rw-r--r--@ 1 alex staff 762382 Sep 8 09:57 io.coressh.shell 2019-09-08--07-56-29-850.log
Next to the fact that log files get deleted before it makes sense (you cannot trace back the whole output of that rsync command) it looks to me like the parser needs about 1 minute to parse 1MB of output data, which is by far too slow to show an accurate progress of the process running.
If running 4-5 processes like such concurrently in different tabs, you cannot even type anything properly in a non busy tab connected to a different server, as echoing the characters typed takes about at least 500ms each. (feels like the good old modem connection with 300 Baud 
I see that as a dead criterion which renders the application useless, so what can I do against it?
How can I improve that? Can I at all? What else can I check to make things better?
1 Like
please dont get me wrong and consider all my reporting as constructive attempt to improve things!
Machine:
MacBookAir7,2 i7 2.2
macOS: 10.14.6
Core Shell: 1.8
remote host: any Linux machine
running "ping -f 127.0.0.1" for about 10 seconds and then pressing CTRL-C takes measured 330 secs (5.5 mins) to abort. Not good!
And yes, it happens on all machines.
same here, cant use page up or page down because window eat it and not forward
Has this been resolved? I am having the same issue. cat on a large file effectively ends the session
I'm working on decreasing the time lag after emitting a break signal. In my test environment, the delay has been reduced from 400s to 62s, and I think there is still has space for optimization.
Thanks a lot for reporting this problem @rogerk @alexbartl @Gergo_Dotvojen @akshai
1 Like
Thank You SOOOOO much
a good way to test and demonstrate the slowness:
open a terminal window and core shell next to each other and ssh to 127.0.0.1
run the following command in both windows and watch the result after one minute
while true; do date; done
try to control-c the running commands
Thank you for the command, I just tested command while true; do date; done with revised version, and it can be interrupted quickly without delay.
I also test under extreme condition with command yes, it simply pours out endless lines of y on screen very fast. In current public version it takes almost 400s to break, and I've managed to reduce the delay down to 2 seconds on local shell and 15 seconds on remote shell, it's a very big leap.
Will release it soon 
Thanks a lot,
Wow, thank you very much, if you need some whatsoever beta testing (ever), let me know (alex@bartl.net), at least it might be some help in future, as a little give back, if I could
Hello,
I have same issue. Is there a fix available soon?
Thanks.
BR
Michael
Works much better now
@rogerk @alexbartl @akshai @Gergo_Dotvojen @Michil
In version 2.0, Ctrl-C (aka. interrupt signal) now at least 6x shorter than previous releases. I'm going to close this bug report, although it still has room for improvement.
Please file another report if you feeling dissatisfied, thank you all for helping!
Yang