I'm trying to launch a process such the same way that I do in OS X with /usr/bin/open like this: open -a /Applications/Firefox.app --args -profile "blah blah" -no-remote.
As I learned from this topic here: launchd from terminal to start app.
However Linux doesn't have this open as I thought it did. I verified this with my searching. But in my searching I couldn't find an alternative. How can I launch process so that the launching process doesn't share its file descriptors with the launched process as explained in this SO topic: Close all File Handles when Calling posix_spawn
This is a video showing my desktop files. I'm trying to launch them somehow so that the file descriptors don't mix between each other here is my screen cast: https://www.youtube.com/watch?v=Yc19BzLTnDE
This video shows the PIDs are mixing: https://www.youtube.com/watch?v=YJsyV6tK7FA
Use xgd-open.
xdg-open is a desktop-independent tool for configuring the default applications of a user.
You can launch X11 applications in Linux simply by running the binary, so the open command is unnecessary for this use. (Another use of open would be to launch documents with the associated application, for which you can use either a desktop-manager-specific command or xdg-open.)
To avoid sharing file descriptors you can simply close them from the shell, e.g., in bash /usr/bin/x11/firefox 3>&- 4>&- … (up to 9) or if it's just the standard ones then perhaps you can redirect them: </dev/null >/dev/null 2>/dev/null. Or maybe you just want to use nohup to avoid closing the program on SIGHUP when the terminal closes.
Solution found that launches the .desktop file with the custom icon it used. I couldn't get xdg-open to work on i, no clue why.
https://askubuntu.com/questions/591736/any-c-functions-to-simulate-double-click-on-file/592439
Related
I have a python command-line tool that allows the user to select a variety of options, each a module.
One of the options is a standalone python script that doesn't share any I/O or state with the main program, but it runs continuously and would be blocking. I'd really like to launch it in a separate console window, where the user will be prompted for input and it will run until they manually exit.
I've tried several subprocess options thus far, but the farthest I've gotten is launching a new window that just...hangs.
Of course, I'd like to be as OS-agnostic as possible. I'm guessing the type of terminal emulator matters here, though, among other things. Should I looking at the multiprocessing module?
I welcome any advice that would help me get on the right track or point out any obvious (or perhaps not-so-obvious) flaws in my perspective. I'd like to adhere to the best-practice for this situation but am just not experienced enough. Thanks.
Edit: I got this to work by calling the actual submodule:
os.system("gnome-terminal -e 'bash -c \"python3 -m name.of.module; exec bash\"'")
This works splendidly, but I get all this ugly output from Gnome inside of the main program that launched the second process:
# Option “-e” is deprecated and might be removed in a later version of gnome-terminal.
# Use “-- ” to terminate the options and put the command line to execute after it.
# _g_io_module_get_default: Found default implementation local (GLocalVfs) for ‘gio-vfs’
# posix_spawn avoided (fd close requested)
# _g_io_module_get_default: Found default implementation dconf (DConfSettingsBackend) for ‘gsettings-backend’
# watch_fast: "/org/gnome/terminal/legacy/" (establishing: 0, active: 0)
# unwatch_fast: "/org/gnome/terminal/legacy/" (active: 0, establishing: 1)
# watch_established: "/org/gnome/terminal/legacy/" (establishing: 0)
Using -- in lieu of -e causes a child process error. I've also tested other subprocess calls with the -- option and I still get some ugly output from Gnome. I can pipe stderr to /dev/null but I don't feel like this very clean.
Is this generally a sensible solution, or is this bad design (on my part, that is)?
Thus far, I've gotten this to work on both Linux and Mac. It's ugly, though; I'd welcome a better answer, but haven't found one.
def open_new_window(module_name):
if (operating_sys == "linux" or operating_sys == "linux2"):
os.system(f"gnome-terminal -e 2>/dev/null 'bash -c \"python3 -m app.{module_name}; exec bash\"'")
if (operating_sys == "darwin"):
os.system(f"""osascript -e 'tell app "Terminal"
do script "cd {root_path}; python3 -m app.{module_name}"
end tell' """)
else:
print("[-] Your operating system does not support this utility.\n")
It works. Passing stdout to /dev/null on the linux option will get rid of the messy Gnome output. This method allows me to dynamically call modules that need to run in their own console window, detached from the main program. For running scripts that don't need to share state, it works just fine and manages to be somewhat cross-platform.
Still, I feel like there must be a more Pythonic way to do this.
Note: I've noticed on many related posts, the statement "in a new window" causes some confusion. "In a new window" here means the app literally opens a new shell window (unfortunately, which shell will need to be hardcoded for you) and starts the module as a standalone process (the main app does not keep track of it). For others using this solution, keep this in mind - this is certainly NOT a good way to do this if you need to manage I/O from main instance.
I recently put together my first Raspberry Pi 3. I want to be able to safely shut down the Pi without corrupting the SD card. I found code online to shut it down:
sudo shutdown -h now
I'm wondering how to paste this into a new text file, and save that file so that it can be opened to shut down the computer, in the way that one can use a .bat file on windows to run commands.
It's running Raspbian.
Create a text file like this:
#!/bin/sh
sudo shutdown -h now
Save it under /usr/local/bin possibly with an extension ".sh"; perhaps the name could be "myshutdown.sh".
Then you must give execution permission to that file, with chmod +x "thatfile", or with a graphical tool.
Now you can type "myshutdown.sh" in a console, or make a link (launcher) from the desktop to that file.
Anyway, in unix and similar, "shell scripts" are the equivalent (but better) to m$ .bat files. They don't need to have a particular exstension, even if ".sh" can be nice; but they MUST have "execution permission" (given for example using chmod(1)). Also: the first line, "#!/bin/sh" is not always necessary, but it is best to use it.
Basically i'm connecting to a cygwin terminal on another computer and running a program(CodeWarrior) that has TCL support. Running tcl commands inside the program is not a problem.
What i am trying is to redirect output (from puts for example) in tcl to my running cygwin console.
Provided the terminal is the current one, you can do this:
set terminal [open /dev/tty]
puts $terminal "Hi there!"
You might make the terminal handle a global one and never close it (until the program exits).
Other terminals can be written to — provided you have permission — by just opening the correct device. Or you can open a file descriptor if you can find it in /proc, though that's a little bit of a black art in itself.
Is there a command line utility that I can use for executing X based applications that will detach my applications from the terminal so they aren't closed if the terminal is closed?
I guess such a app could be called something like gnome-run if it existed.
I have tried dtach, but it seems that you have to provide a socket file which is a bit clunky to type. I have also tried nohup, but found that also to be a bit clunky to type by the time std out and err are redirected to /dev/null.
I guess I'm looking for a simple program that will do something similar to this:
#!/bin/bash
nohup $1 > /dev/null 2>&1 &
Yes, there is a way to do it: first you need to run your GUI app and send it to background, then you (probably) want to detach it from Bash task management. For example if I wanted to run gedit this way:
gedit &
disown %1
After that you can close your terminal window and gedit will not be killed. Enjoy!
You already wrote your program, it is called a shell script and you give it the name you like and put it somewhere. Then you either add that directory to your $PATH or in your bashrc you set:
alias gnome-run=<path>/my-awesome-script.sh
Why waste earth's resources on a program?
If you want to run an application (say, gedit) as if it was run from the GUI, use:
xdg-open /usr/share/applications/gedit.desktop
See this answer on superuser.
I've got a program running in a GNOME Terminal, but the screensaver is acting up and won't let me back in with my password. While waiting for a fix for the gnome-screensaver bug, is there some way to see the output (or even take over the process) in a virtual console (Ctrl-Alt-F1) without being able to interact with the GNOME Terminal?
Clarification: The original issue was the screensaver, but the question I'd like answered is how to see the output from a process running in another terminal, after starting the process without any logging to file. I'm guessing it should be possible to set the output device of a process from a different shell? Or is it possible to put a process in another shell into background mode, and get it into the foreground in the current shell? Or even ask GNOME Terminal to redirect or copy the output?
I've had luck in the past killing the screensaver from a virtual console, unlocking X session.
# Get the pid (xscreensaver, gnome-screensaver, etc.)
ps -f -u $(whoami) | grep screensaver
kill -9 12345 # Replace 12345 with the real pid
EDIT: Seems like this has been thought of, and you should use one of these commands, depending on which screensaver program you use:
xscreensaver-command -exit
gnome-screensaver-comand --exit
See the man page for those commands for more details.
Usual way is to pipe the output to a file, like program > program.log
Do tail -f program.log in another tab of Gnome console, and the same in the non-X console.
Alternatively, use tee to duplicate the output in the same console: program | tee program.log
ssh in to the box. kill the screensaver. su to become root and kill -9 if it's really acting up.
Usually Gnome-Terminal displays the output of one vty out of /dev. So just connect your console to that vty.
Launch program with screen.
Open another terminal, launch screen -x and you have two terminals acting like one. Try it, it's fun :)