I've been forced into using a command line in windows and wondered if there were Linux-like keyboard shortcuts? I googled and didn't find what I was looking for.
Things like ^C, ^Z and such?
Try Ctrl+Break: some programs respond to it instead of Ctrl+C. On some keyboards Ctrl+Break translates to Ctrl+Fn+Pause.
Note also that nothing can cancel synchronous network I/O (such as net view \\invalid) on Windows before Vista.
You can trap ^C on Windows with SIGINT, just like Linux. The Windows shell, such as it is, doesn't support Unix style job control (at least not in a way analogous to Unix shells), and ^Z is actually the ^D analog for Windows.
There are two keyboard combinations that can be used to stop process in Windows command line.
Ctrl+C is the "nicer" method. Programmers can handle this in software. It's possible to write programs that ignore Ctrl+C as SIGINT signal completely, or handle Ctrl+C like a regular keyboard combination.
Ctrl+break is the "harder" method, always sends SIGBREAK signal and cannot be overridden in software.
Ctrl-C does a similar thing in windows as it does in linux.
Related
Why is the following empty program exiting on Ctrl + C with 130 on Linux (which is what I suspect, because my shell bash wraps SIGINT to 130 (128+2).
On Windows with Git Bash (git-bash.exe), I get exit code 2.
package main
func main() {
for {
}
}
Is that Go's behavior on Windows or git-bash.exe? Because I need exit code 2 internally, do I need to wrap it using the signal package?
Well, it's two-fold.
On the one hand, as #Flimzy pointed out, it's shell intervening.
On the other hand, what is missing from his remark is why this happens.
The explanation is, again, two-fold:
A process has certain default signal handling disposition which is how the process reacts to certain signals. A signal can be ignored, handled or left as is which, in most if not all cases means killing the process.
You can read more about this here.
Note that in non-trivial processes such as programs written in Go which have intricate runtime system, the default signal disposition may be different from that of "more plain" processes.
By default the SIGINT signal is not handled meaning it kills the process.
The bash she'll adds 128 to the exit code of a process if it was killed with a fatal signal. More about this — in the bash manual.
Update on the behaviour in Windows.
Let's first put up a quick fact sheet:
Windows does not support the concept of Unix signals, at all.
The way terminal-aware programs work on Unix-like systems is very different from the way console-aware programs work on Windows.
Say, the way Vim looks and behaves in a "Git bash" windows on Windows may look very similar to how it looks in a GNOME Terminal window on a Linux-based OS but the underlying differences are profound.
Let's now dig a bit deeper.
Unix was born without any notion of GUI and the users would interact with a Unix system using hardware terminals.
In order to support them, kernels of Unix-like OSes implement special standardized way to make terminal-aware programs interact with the system; if you're "into" deep-diving into technical details, I highly recommend reading the "TTY demystified" piece.
The two more important highlights of this approach are:
The terminal subsystem is used even by programs running in what the contemporary generation of freshmen calls "terminals"—in windows which typically start out running a shell, in which you call various command-line programs, including those using "full screen"—such as text editors.
This basically means if you take, say Vim or GNU Nano, it will run just fine in any graphical terminal emulator, or directly on Linux's "virtual terminal" (those textual screen you can get on a PC by hitting Ctrl-Alt-F1 or booting with GUI turned off) or on a hardware terminal attached to the computer.
The terminal subsystem allocates certain codes a keyboard may send to it to perform certain actions—as opposed to sending those coder directly to the program attached to that terminal, and Ctrl-C is one of them: in a common default setup pressing that combination of keys makes the terminal subystem send the foreground process the SIGINT Unix signal.
The latter is of particular interest. You can run stty -a in a terminal window on your Linux system; amoung the copious output you'd see something like intr = ^C; quit = ^\; which means Ctrl-C sends interactive attention (SIGINT) signal and Ctrl-\ sends SIGQUIT (yes, "INT" in "SIGINT" does not stand for "interrupt"—contrary to a popular belief).
You could reassign these key combos almost at will (though it's not a wise thing to do as many pieces of software expect ^C and ^\ to be mapped the way they usually do and do not assign their own actions to these gestures—rightfully expecting to not be able to actually ever receive them.
Now back to Windows.
On Windows, there is no terminal subsystem, and no signals.
Console window on Windows was an artefact required to provide compatibility with the older MS-DOS system, and there the situation was like this: Ctrl-Break would trigger a hardware interrupt usually handled by the OS, and Ctrl-C could be explicitly enabled to do the same. The implementation of the console emulation on Windows carefully emulated this behaviour, but since Windows does not have Unix-like signals, the handling of these keyboard combos is done differently—though with much the same effect:
Each console process has its own list of application-defined HandlerRoutine functions that handle CTRL+C and CTRL+BREAK signals. The handler functions also handle signals generated by the system when the user closes the console, logs off, or shuts down the system. Initially, the handler list for each process contains only a default handler function that calls the ExitProcess function.
What this all means to Go?
Let's first see the docs:
~$ GOOS=windows go doc os.Interrupt
package os // import "os"
var (
Interrupt Signal = syscall.SIGINT
Kill Signal = syscall.SIGKILL
)
The only signal values guaranteed to be present in the os package on all systems are os.Interrupt (send the process an interrupt) and os.Kill (force the process to exit). On Windows, sending os.Interrupt to a process with os.Process.Signal is not implemented; it will return an error instead of sending a signal.
So, in a Go program running on Windows you can handle these two "signals"—even though they were not really be implemented as signals.
Let's now move to explaning the difference in the exit codes.
As you know by now, pressing Ctrl-C when a program is running in a terminal emulator windows on a Unix-like system will make the terminal subsystem send the process the actual SIGINT signal.
If this signal is not explicitly handled, the process gets killed by the OS (as that's what the default signal disposition says).
The shell notices that a process it spawned suddenly died, collects its exit code and adds 128 to it (because it wasn't expecting it to die that way).
On Windows, hitting Ctrl-C makes the process perform the ExitProcess system call, which, form the point of view of the shell process looks like normal process exit: it cannot tell this exit apart from the one occured if the process were to call os.Exit(0) explicitly.
Reason being is that I use emacs-nox, meaning the text-editor program runs inside the terminal.
And many of my binds conflict with the terminal keybinds (such as Ctrl+i)
So are there any terminals out there that allow for any given command signal to be turned off.
Yes indeed there is.
Most definitely.
xterm
I have been reading how to use a shell inside EMACS, along the way I found the concept of Terminal, which is an abstraction for the old physical devices which interacted with the shell.
But, nowadays, I really can't understand which are the advantages regarding its use, so, can you please point me out a couple of situations or examples where one should use it instead of the shell in Emacs?
Running a term buffer is much closer to an actual terminal. Here are a few differences:
Shell mode provides very limited terminal emulation. Programs that take advantage of the terminal's full-screen capabilities (e.g. less, mtr, mutt, top) won't work properly. Terminal mode will generally handle these without any problem.
In shell mode, emacs provides tab completion. In terminal mode, the shell or command-line program provide it themselves.
Shell mode buffers the input and sends it to the process on newline. Terminal mode sends the characters to the running process immediately.
Shell mode works like a regular buffer with the usual emacs key bindings. Terminal mode doesn't intercept most control characters unless you explicitly put it into line mode.
The shell is like another emacs buffer, so the same keys work in it which work in other buffers. It is not true for the terminal.
You can launch the console programs that clear the screen like mc in terminal.
Physical terminals are long obsolete, but the terminal emulators which replaced them are pretty important, and I would presume that most shells outside of Emacs are run within one, so it's not such a mysterious concept to use one within Emacs too.
It's only tangential to your question, but The TTY demystified is an excellent article which you might find enlightening.
I have a lot of perl scripts that are on infinite loop running on my windows system. It is terribly inconvenient to have that many command prompts open not to mention the likelihood of closing them by mistake(strangely, they also seem to pause when I click on the prompt)
Is there someway I can handle this? Like maybe minimize this to the tray and maximize whenever necessary?
If it is of any use, I use activeperl
You can use Console2 utility, which is a Windows console window enhancement, it has a multiple tab feature.
Install GNU Screen. You can get it for Windows as part of Cygwin. You can then have multiple command line shells running in a single window, and can detach that window to run in the background.
Have you considered Win32::Daemon?
Maybe a simple question.
When I attach to a process, I run "continue" to make it continue to run.
Then I want to some other job like "add-symbol-file" with need not interactive with target process, but after the "continue" command, the gdb console will block, so I can not do any action before I break the process.
Is there any way that I can do such thing without suspend the process?
Make sure the console which gdb is running in has keyboard focus, then press CTRL-C. This will usually result in a SIGINT signal to be sent to gdb.
With me, GDB then pauses execution of the program and accepts user commands again.
Should the CTRL-C not work (perhaps different config) try to send the signal manually:
Find out the pid of gdb such as with command top and then send a SIGINT to gdb:
kill -2 pidhere
Until recently you couldn't do what you want, but the newly released
version 7.0 of gdb has what is called a "non-stop" mode, in which the
gdb prompt / console can be used while the program is running.
See http://sourceware.org/gdb/current/onlinedocs/gdb_6.html#SEC47
You may want to study the remote gdb mechanisms a bit for something like that.
For understanding the debugging process more read this short article.