I used Msys1 for many years and was used to CTRL+C for killing processes that I start within my shell.
After updating from Msys1 to Msys2 CTRL+C does not work any more.
For example: I start "make" press CTRL+C. Shell prompts to finished and enables typing more commands, but make.exe is still running+working.
Result of my analysis:
In Msys1: shell.exe(12345) starts make.exe(23456) and make.exe(23456) has the information, that its parent is (12345).
In Msys2: shell.exe(12345) starts make.exe(23456) and make.exe(23456) has the information, that its parent is the (34567), which is not alive anymore. So I guess Msys2 uses an additional process for starting subprocesses.
I tried bash.exe, shell.exe, mintty.exe,... all seems to have the same problems.
Content I found searching
:
This ticket just focuses on missing signal types -> I don't care about that.
https://sourceforge.net/p/msys2/tickets/135/
The issue in this mailing list seems to be near my problem, but I do not understand what I should change, or if the change can only be made within the msys2 implementation. (What is CREATE_NEW_PROCESS_GROUP? and how to change it):
https://www.cygwin.com/ml/cygwin/2012-08/msg00062.html
Kindest regards
Luke
It looks like mintty provides the default terminal for MSYS2 (note that this is different from the shell that is run within). If so, then the "Ctrl+C kills native (e.g. MSYS2 compiled) programs abruptly rather than sending a catchable signal" problem is the same one as described over on https://superuser.com/questions/606201/how-to-politely-kill-windows-process-from-cygwin and the MSYS2 wiki porting FAQ.
If what you're attempting works when you are using Windows' default terminal (e.g. when using cmd.exe from the start menu) then this is the issue you're seeing.
It is in fact suggested in the other answer but you can just run each program by winpty.exe which will make CTRL-C working again.
Related
I'm trying to use LLDB to debug a program on OSX and control-C is not working to stop the program. It seems to be in an infinite loop and I want to see where it is; hence I can't just use breakpoints. This used to work for me -- I used to be able to control-C to send SIGINT and LLDB respected it and stopped the program on this computer with this same toolchain. I see the ^C in the terminal but it's being ignored. I also tried to send the signal to the lldb process in two other ways:
via the Activity Monitor's send signal to process feature
via pkill -SIGINT lldb
However, that didn't work either. control-z DOES work to stop lldb, on the other hand but that's not what I need (which is to be able to inspect program state).
I tried this both with the built-in Terminal app as well as iTerm2 - but I'm seeing the same behavior on both.
Version info
lldb --version
lldb-1000.11.38.2
Swift-4.2
I think this is the version of lldb installed with XCode. It's possible that an upgraded XCode (which I don't use directly) broke this.
Update: I'll add that variable names are not auto-completing for me in lldb either -- I'm pretty sure this also used to work. For example, if I type p and then start typing a variable name, it doesn't tab-complete. I'm adding this update in case it may be related.
See comment above -- it seems that this was a bug with lldb version 1000.11.38.2 when using a command script that contained run in it. Upgrading and/or not using a command script with run allows the program to be interrupted.
Whenever I start terminal on my Macbook Pro it is running a process. I have to use ctrl+C to kill it. If I close the window directly it warns me that following processs are running: login, bash, bash, perl5.12.
Any idea what might be going on here and how I get back to the normal state?
I personally had this issue a while ago. First check to see if it is from one of your profiles. Assuming you are using bash, we will look at your bash profile.
First, make sure the problem is actually stemming from your bash profile. Source the scrips as follows.
source ~/.bash_profile
source ~/.profile
If after running those you observe the same hanging problem where you have to cntrl+c, then you know what script has the problem.
The best way to remedy the situation is to comment out different parts of your script to figure out where the problem is. Backup your profile and then comment out half of your profile and do a
source ~/.bash_profile
and if it hangs or not will tell you what half the problem is on. Keep repeating this until you find the problem. It sounds longer than it actually is.
When VIM to used make builds using GNU make utility, there are two issues I see with the default configuration.
Background execution without freezing the editor.
Showing execution progress like emacs compile/grep command
Background execution is possible with simple !start or with plugins like dispatch or AsyncExecute etc
None of these options show the progress in a scratch window with warnings/errors emitted during build progress.
Is there anything I am missing ?
Searching the web took me to shellpipe/tee workaround which does not seem to work on Windows even after installing tee.exe
Vim only parses the :make output after the command has finished.
If you launch the build asynchronously, you'd also have to periodically read the resulting output and tell Vim to parse it via :cfile errorfile. There may be a plugin that provides such auto-reload logic, but I'm not aware of any.
In general, there's very little asynchronicity and parallelism built into Vim (possibly due to its age and implementation in C).
On the rare occasion that I have to use a windows command prompt rather than bash, it drives me nuts that tab completion doesn't add a slash to the end of directory names. Is there a setting or script that I can run to force the full completion?
The answer these days is PowerShell. It is superset of the windows command line. It has many of the Linux commands. It has an object-based pipeline and has full access to the .NET framework from the command line.
And it adds a trailing slash when using tab to expand a directory name.
No there is no such setting. Your best bet is to use bash through cygwin but I expect you already knew that bit.
this is quite an old thread but I thought it might still be helpful for others.
I could not find a parameter in Windows to do the trick but I found a executable (GNU, with the Pyton source available) named PyCmd which is an improvement (according to my and my work habits) to regular CMD console.
It can be launched by double click it and it starts a regular console with cmd.exe and it loads itself in the memory to allow a lot of command line editing goodies, among them the same TAB completion behaviour I used to have under Unix Korn Shell (including the Emacs-like keys) with the trailing slashes or back-slaches for directories.
You can find it at:
https://sourceforge.net/projects/pycmd/
The last version is a December 2017 snapshot (but stable for me, could not meet any major trouble compared to the 2013 0.9 stable release), at:
https://sourceforge.net/projects/pycmd/files/pycmd/snapshots/
You can also launch it from an existing console, from CMD.EXE and it starts a sub shell with all its editing goodies. You exit this sub-shell by exit or ^D on an empty line.
Note that I have tested it to under an alternative console like "Hyper" (MIT License, at https://hyper.is/ and https://github.com/zeit/hyper), which I prefer compared to Windows default console, and it works perfectly with it too. I think it's fair to assume that it will work well for other consoles like ConEmu or others, but I did not test it with them.
This answer goes perhaps a little far beyond the original question but -- I hope -- still can provide some help to people like me who like to get the same kind of command-line behaviour as they used to have under Unix Korn shell (possibly Linux bash, I don't know).
Have a nice command line interface to all!
GM
At work, I use Cygwin a lot because it offers me a small oasis in the vast desert of Windows. I inevitably end up running some non-Cygwin programs through the bash shell, such as build scripts (batch files created in-house) and the Subversion CLI binaries (I have the Windows ones installed). 99% of the time, I don't have any problems using this setup. The other 1%, however, causes a strange issue:
With both the build scripts and SVN, most of the time the enter key is interpreted correctly. For instance, I'll kick off the database creation script and it will prompt me for the server name. I type in "localhost" and hit enter. Everything's fine. Then it gets to the end, if there are errors, and prints things out using more. No key that I press is recognized by more. I have to Ctrl-C out of it.
Similarly, if I do a Subversion update, normally everything is fine. In the case where the interactive conflict resolution happens, however, I'll usually type in "tf" for "theirs-full" and hit enter, but nothing happens. I have to Ctrl-C out of it and re-run the update with force merge or use TortoiseSVN in Windows to do it.
Any idea why Cygwin seems to randomly not be passing the enter key through to the programs? I considered that it may have something to do with Unix vs Windows style line endings, so I've tried typing those characters manually, but that doesn't seem to make a difference. Thanks.
Edit: I just had this happen to me again and I realized something. It was SVN prompting me for a password. I typed in the password, which it echoed to the screen (bad) and hit enter... nothing. Hit enter a few more times, the cursor moves, but nothing happens. I hit Ctrl-C and it dumps me back to bash, which then says "bash: [my password]: command not found" followed by a number of new prompts equal to the number of times I hit the enter key. So what happened is the input never made it to SVN, but somehow got read by bash after SVN exited. I thought that may help someone figure out what is going on.
Unfortunately, I think you are hitting one of the issues of Cygwin and windows/dos console apps. See "Console Programs" at http://www.cygwin.com/cygwin-ug-net/using-effectively.html.
It is just a limitation on windows console apps. This behavior is common for the windows myqsl cmd client and svn client, for example.
Here are some things to note -- I've successfully used this approach with both the Windows mysql as well as Windows svn clients:
1) Try making sure you do NOT have "tty" in your CYGWIN environment variable and see if that helps (unset it in My Computer->properties->advanced->Environment Variables and close/restart any cygwin bash prompts).
2) Do not use RXVT -- instead, use the basic Cygwin cmd prompt. This is because RXVT implies "tty" and will break #1 above.
3) Try finding a "native" Cygwin package for the cmds you are having issues with instead of using the Windows cmds. (I haven't found a 1.6 svn client for cygwin yet, though.)
Good luck!
Dustin
The lengthy discussion on the mintty project is here - http://code.google.com/p/mintty/issues/detail?id=56
One solution mentioned which worked in my case (entering authentication passwords for native subversion) is conin - http://code.google.com/p/mintty/downloads/detail?name=conin-0.0.2.zip&can=1&q=label%3ADevelopment
$ conin svn list https://{repo}
Password for 'user': ******