I'm on OSX, using canopy. Does anybody know what the shortcut for interrupting the kernel is? Thanks.
There is no shortcut for interrupting the kernel. That command, along with restarting the kernel, is in the Run menu, which also shows the shortcut for the restart kernel command. Note that because of the nature of the interaction between Python and C extensions, neither command is guaranteed to work, though restart is more likely to in a pinch.
Related
How would I go about detecting if my go CLI program is in focus or minimized?
Current program based off https://github.com/jroimartin/gocui
I require the functionality as it is a chat program and I would like to send OS notifications but only when the program is not in focus or is minimized.
Your help/direction is much appreciated as of right now unsure where to start.
This is not possible from the library itself. A command line program does now have a focus, but the terminal program it is running in.
To implement that (if possible at all) would be dependent on os, window manager etc.
To refine the answer provided by #mbuechmann, I suggest the OP not to try to resort to APIs etc.
The reasoning is simple.
"Contemporary" users are used to running programs in terminal emulators which are typically presented as separate windows, and so the users naturally think of these programs as not really different from GUI apps.
But the reality is different: a terminal emulator—whether graphical or not (for instance, so-called "virtual consoles" provided by the Linux kernel running on an x86/amd64 hardware are terminal emulators as well)—really emulates a typical work session on a real hardware terminal, and there, a program would work in foreground solely, and the only means of "switching" to another program was using the shell's job control (those jobs, bg and fg commands).
In other words, the whole concept of a program working in a terminal has an inbuilt assumption that the terminal is always "foreground"—since at the time the concept was developed, a terminal was a physical device.
Now please also consider that "terminal emulation" may be more pervasive on a contemporary system than you might think: screen and tmux on a Unix-like OS are multiplexing terminal emulators—which may themselves be run in a terminal emulator, and a console window on Windows™ may be considered to be a terminal emulator of sorts as well.
So, "resorting to APIs" have several technical problems:
Terminal emulation tries to actually decouple the program which uses this facility from being aware of how the facility is actually provided.
To put it simple, there's, say, no easy way on X Window System, to know what window is used by the terminal emulator running your program.
You'd need to cover diverse set of APIs in order for your program to still be useful: X Window System on Unix-like systems, Mac OS, Windows™. And contemporary GUI stacks running on Linux tend to be switching to Wayland instead of X.
In certain cases, like running a program in a "nested" terminal emulation sessions (for example, a pane in a "window" of a tmux running in xterm), figuring out such facts about the environment might be next to impossible.
And still the crucial problem is that if your program really needs to know whether it's focused or not, it actually wants to be aware about the concepts currently hardly accessible to it. I mean, it wants to be GUI. And if so, just make it GUI.
In fact, it may be simpler than you think. The core of your program might still be a CLI app with a thin GUI wrapper around it which uses any sort of IPC to talk with the app (which might be two-way, if needed).
The simplest is to write some (usually line-wise) data to the program's standard input.
I am developing an ncurses program. So running this in Xcode fails because the Console is just for stdout/stderr, but it is not a full terminal emulation (and hence can’t run ncurses programs).
To easily use the debugger, I would like to tweak the Scheme that the “Run” feature starts the application in Terminal.app or iTerm.app instead.
Does anyone know how to achieve this? My first attempts to change the Executable in the “Run” section of the scheme editor to use Terminal.app and use arguments were not successful (but then again, I am not familiar with possible arguments for Terminal.app).
Update: Thanks for pointing to How to run command-line application from the terminal? - this is indeed almost what I am after. The problem is that at least on OS X 10.11, SIP (System Integrity Protection) requires to turn off the "Debug Executable" option (besides, I don't want to debug Terminal.app, but rather my application).
So the remaining question is if it is possible to let the "Run" also start the debugger the debug the built executable (i.e. without manually attaching the debugger after the executable was started).
Is it's possible to detect inside app from where it was run? From cmd/bash or from GUI? Assume that we are working in graphical mode, not in pure console.
Not really, but sort of. Short answer: better not to try, get the user to tell you via an argument, which you can pre-fill in a shortcut.
Long answer:
In both cases, the program is launched in a similar way: the shell application (whether cmd/bash or Windows explorer/whatever gui launcher linux has) call CreateProcess or ShellExecute on Windows or fork+exec on Linux and the way the user executed it gets lost.
However, the process does have a parent ID which might be useful.... but it isn't reliable either for a few reasons: telling if it is a gui or command line shell isn't easy (best you can do is look at the image name) and the parent might terminate as soon as you launch, so there'd be no parent! (Linux gui apps often fork themselves to detach from the terminal. Of course, if you do this you'd probably know, but if you use a library it might happen without you realizing it.)
Well, the fact that I'm going off on parenthetical asides after every sentence shows how unreliable and complicate that is. If you want to try though, looking at your parent process ID before doing any fork/detaching might be helpful.
BTW looking for a parent console isn't very helpful: a Windows GUI subsystem program won't attach to the parent console even if one exists and a Linux GUI program may attach to the controlling tty of the X window manager.
What I'd actually recommend though is passing an argument to your function to tell it how it got started. When you create the GUI shortcut, make it automatically pass the "started by gui" argument to you. Then you can check args for it and react accordingly.
It still isn't perfect, but it is fairly easy to implement and probably good enough - gui launchers would probably use a shortcut anyway and you can pass arguments through them, so the user doesn't need to know about how it is implemented.
Or you could install two programs, one which is convenient from the command line and one which is optimized for the gui environment.
But I think that's the best you can do.
I have a process that is already running, and I want to debug it with GDB. I've been using
gdb --pid $PID
However, when I do this, the process pauses. I'd like to attach to the process without pausing it, and look around in its memory while it's still running. Is this possible? Alternatively, is there a way to "fork" the process so that I can look at its memory, without stopping/pausing the process?
There's no way in gdb to attach without some sort of pause.
The Linux kernel provides some support for this via PTRACE_SEIZE, but gdb doesn't use this yet. There's a bug in bugzilla you can track, "Bug 15250 - use PTRACE_SEIZE and PTRACE_INTERRUPT"
Meanwhile you could try setting gdb into "observer mode". Then you could attach and use continue & to continue the process in the background. You may need to set various settings, like target-async, depending on the gdb version.
I am not totally certain if this will work. It is worth a try. Note that there is a window in which the program will be paused. This is unavoidable right now.
Is there any way I can crash a kernel on purpose (e.g., kernel panic, blue screen, black screen, or whatever). Assume I can change any registers and have administrative privilege of the system. I would like to demonstrate this on both Windows and Linux platforms.
Thanks for any inputs!
In Linux, you must compile the kernel with the CONFIG_MAGIC_SYSRQ option, then you can crash the kernel by writing the crash command into /proc/sysrq-trigger, or by pressing Alt+SysRq+C.
See the documentation for details.
In Windows, you must set the CrashOnCtrlScroll registry key for the keyboard driver, and reboot, then you can press Ctrl+Scroll Lock to crash the kernel.
See the documentation for details.
echo c > proc/sysrq-trigger
There are several ways to do this:
Write your own kernel module and load it, make sure you call BUG() or BUG_ON().
Use sysrq; echo c > /proc/sysrq-trigger, with this make sure to install kdump if you are interested in capturing a vmcore file.