I'm trying to convert some Ruby code to Swift. The Ruby code launches external programs with
system ...
I've managed to get almost the same behavior with the Process API in Swift:
Process
.launchedProcess(launchPath: ..., arguments: ...)
.waitUntilExit()
However, there are two differences:
The Swift version hangs when the launched program tries to do paging (so launching "git --no-pager diff ..." works, "git diff ..." hangs if the diff is long enough).
If I cmd+c to interrupt while the launched program is running, my Swift script exits but the launched program keeps running. In the Ruby version, both are interrupted.
How would I avoid these issues?
Update: worked around issue #2 by manually terminating any launched processes when my script receives an interruption signal:
var globalCommand: Process? = nil // May be set later
signal(SIGINT) { _ in
globalCommand?.interrupt()
exit(0)
}
Related
I set the path to a program, say "foo.exe", to my system path and so typing foo in cmd/powershell starts the program. However when I type exit to get out of cmd/powershell foo.exe also closes with it. Why does this happen and how do I prevent this from happening?
This doesn't happen for all programs, only certain ones which means those certain ones should be added to path in a different way probably or should be started in a different way I'm guessing. However, searching over the internet for a long time didn't give me anything so a little help would be appreciated.
If foo.exe is a console application (one compiled for the Windows console subsystem), it will run synchronously in cmd.exe / PowerShell: that is, control won't be returned to the calling shell until the application exits. This means that you won't even get a chance to type exit until foo.exe has already exited.
However, it is possible to run a console application asynchronously, namely if you use a job to run it, via Start-Job or Start-ThreadJob; that is, foo.exe will then run in the background.
In that event, exiting the calling shell with exit will terminate the foo.exe process.
To prevent that, you can use the Start-Process cmdlet instead; on Windows, you can use it to launch foo.exe directly, which will open in a new console window by default; on Unix-like platforms, you must launch it via the nohup utility (which sends the program's output to a file named nohup.out in the current directory).
By contrast, if foo.exe is a GUI-subsystem application, it launches asynchronously and independently of the calling shell: that is, control returns to the calling shell right after successful creation of the new process, and exiting the shell has no effect on that new process.
I'm using sys.process inside REPL as kind of shell. There are many uses for scala in a shell. And I invoke some external programs, of course. But I discovered that I could not leave the REPL with a background proccess running. And if I kill the sbt by either Ctrl-C or sending signal, the background process is killed also. I'd like to leave sbt and keep all invoked processes running. How can I do so?
The problem isn't with SBT or Scala but with the child process you created. The child needs to "daemonize" to become independent of the parent process. How to do that depends on what kind of process you are invoking and which OS you are running on. On Linux, using the following script as a wrapper around whatever process you are calling works:
#!/bin/bash
nohup $# 2>&1 >/dev/null &
I'm experimenting control-flow hijacking attacks on programs written in C on Linux. I'm trying to perform a simple ret-2-libc attack on a program with the No-eXecutable-stack countermeasure enabled. For this purpose I'm returning to system() function with argument /bin/sh.
But I have a problem: Although my attack works and a shell is spawned successfully, the shell exits immediately after entering the first character! That is, the shell closes after I press any key!
This behavior is also observable in this simple C code:
int main() { system("/bin/sh"); return 0; }
I compile it using: gcc code.c -o system
Why is this? And how can I fix it?
I'm experimenting on Ubuntu-9.04 with kernel 2.6.28 and glibc-2.9-1
Update: The shell becomes interactive if and only if the first key that I press is Enter. That is, if the first character that I enter is a new-line (\n) then the shell remains open and become interactive.
So can anyone explain what's going on here?
Okay I believe that system is successfully calling /bin/sh but it is calling it with the -c flag.
Try:
/bin/bash -c junk
That should behave similarly to what you are seeing. You need to play around with the registers to setup the system call so that /bin/sh is called without the -c flag.
I have a Win32 console application (built from Visual Studio as Win32 console project) which does some log file (.txt) processing. I have a separate perl program (legacy program) which now needs to start this Win32 console application and then stop when done.
Perl program starts an instance of Win32 console app using Win32::Process APIs. It can kill the console app when done by either "kill -x pid" or Win32:Process:Kill. The problem is console app needs to know if its being killed/terminated so that it can flush log handling. The console app has already registered a handler via SetConsoleCtrlHandler API but doesn't get called when killed from perl program by say kill -2/3 pid.
What do I change in perl program or in Win32 console app so that it can know when its being terminated?
Thanks!
Signal handling in Windows is a little quirky if you're used to Unix. I have done a lot of investigation into this, and wrote up my findings here (starting at line 261).
Short answer: Windows processes can set $SIG{INT}, $SIG{QUIT}, or $SIG{BREAK}. All other signal handlers are ignored. Signal them from you separate app with the builtin kill:
kill 'INT', $the_win32_logger_pid;
kill 'QUIT', $the_win32_logger_pid;
kill 'BREAK', $the_win32_logger_pid;
I'm using the Scala REPL to interactively test some hash functions I'm building. I'm constantly switching between the product code (Eclipse), the browser and the Scala interpreter, doing copy/paste of values and results. In the mix I'm often doing CTRL-C on the interpreter, exiting the session and loosing all my functions.
Is there any way to let the Scala REPL either ignore CTRL-C or, even better, perform "paste" with it? I'm working on Linux.
I only know how to prevent REPL from exiting. Remapping of CTRL+C to perform copy command could be done in the same way (if there is some command that ables to change keymap w/out restarting terminal -- I don't know is there one). Anyways, to block ^C wrap your REPL invocation in .sh script like this:
#!/bin/bash
#switch off sensitivity to ^C
trap '' 2
# here goes REPL invoke
scala
#get back sensitivity to ^C
trap 2
trap command
defines and activates handlers to be run when the shell receives
signals
or other conditions.
2 is a SIGINT value (that's the signal which is triggered when you press CTRL+C)
The repl already intercepts ctrl-C, but apparently it doesn't work on linux. It does work on osx. If someone who uses linux opens a ticket with sufficient detail to indicate why not, I can fix it.
As an alternative to the native Scala REPL, you can use Ammonite, which does handle Ctrl+C:
# while(true) ()
... hangs ...
^Ctrl-C
Interrupted!
#
The traditional Scala REPL doesn't handle runaway code, and gives you no option but to kill the process, losing all your work.
Ammonite-REPL lets you interrupt the thread, stop the runaway-command and keep going.