Member Avatar for RikTelner

Hey there!

I learned that when I want to open Terminal in one direction that my terminal is at. I can use nautilus . for Gnome and dolphin . for the glassy DE. But what it does, it starts the program in Terminal and runs GUI. But as soon as I forcibly close terminal and kill the process, the GUI of Nautlius or Dolphin closes? How to run my window manager as entirely seperate process?

  • 4 Contributors
  • 6 Replies
  • 317 Views
  • 1 Day Discussion Span
  • Latest Post Latest Post by JasonHippy

Dani AI

Generated

Short answer: the file manager dies because the terminal/PTY teardown causes a hangup (SIGHUP) to reach the session/foreground process group, and the terminal or shell will forward that to child processes. Several detached-launch strategies exist; pick one depending on how robust you need the detachment to be. (man7.org)

For a quick fix that makes the new process ignore hangups, run it under nohup so it won’t be terminated by SIGHUP. Example (replace the placeholders with your file manager and path):

nohup <file-manager> <path> >/dev/null 2>&1 &

This tells the process to ignore hangups and puts it into the background; it’s simple and portable. (manpages.debian.org)

If you prefer shell-only tools, use the shell builtin disown after starting a job in the background. disown -h marks the job so the shell won’t resend SIGHUP on exit — but note: disown changes only the shell’s job table behavior, it does not actually create a new session or stop the kernel from delivering signals to that process group. In short, disown prevents the shell from re-sending SIGHUP but doesn’t fully detach the process at the kernel/session level. (gnu.org)

For a stronger detach use a new session or a service manager. setsid runs the program in a new session (no controlling terminal), and systemd-run --user --scope starts it as a transient unit managed by your user service manager — both keep the GUI alive independently of the terminal. Use these when you want a robust, terminal-independent process. (man7.org)

Notes tied to this thread: ’s Python spawn and ’s detached-screen approach are valid alternatives (Python spawns a child; screen/tmux hosts it in a detached session). ’s observation about Konsole — that “exit” can behave differently than closing the window — is expected: how the terminal process and shell are closed changes which SIGHUPs get delivered, so prefer the explicit detach methods above for predictable results.

Recommended Answers

All 6 Replies

Member Avatar for Gribouillis

As a pythonista, my first try is

python -c "import subprocess as sp; sp.Popen(['/usr/bin/dolphin'])" 2>/dev/null

and it works. Dolphin is launched and the terminal is not locked. You can even close the terminal.

Edit: there must be a bash solution too, but I don't know it :)

EDIT 2: if you define this in your .bash_aliases (or .bashrc)

alias dolphin2="python -c \"import subprocess as sp, sys; sp.Popen(['/usr/bin/dolphin']+sys.argv[1:])\" 2>/dev/null"

you can use dolphin2 in a terminal, and you can even pass arguments for dolphin. For example

$ dolphin2 .

will open dolphin on the current directory.

EDIT3: Actually, it is not so interesting as

$ xdg-open .

works very well =)

Edited by Gribouillis
Member Avatar for L7Sqr

You can do this with screen. For example:

screen -d -m nautilus .

Will start a screen session to host the nautilus process (without attaching to it) and will exit the session once the nautilus process exits. The net effect is that you will get a GUI that will stay around even if you kill your shell/terminal session.

A nice feature of screen (compared to xdg-open) is that you can use it to execute any command in this 'detached' way (including over remote ssh connections or during system startup).

commented: screen is very nice! +14
Member Avatar for JasonHippy

Another way would just be to run the file manager in the background like this:
name-of-file-manager ./ &> /dev/null &
Substitute name-of-file-manager for your file-manager of choice (nautilus, dolphin, thunar etc etc.)

With the file manager running in the background, the terminal should still be reponsive. If you close the terminal down the file-manager should still remain running onscreen until you close it.

NOTE: The & at the end of the line makes the command run in the background. The &> redirects all stdout/stderr output to /dev/null to prevent the terminal getting flooded with output from the file manager (error messages/warnings from the GUI library etc.)

Member Avatar for Gribouillis

It doesn't work with konsole and dolphin. When I close the konsole, it kills dolphin.

Member Avatar for JasonHippy

Oh right! :/ works for me on my kde system, but I use terminator instead of konsole. I also use dwm as my DE/WM, instead of plasma... Perhaps this only works with my specific setup. :/

Screen or another terminal multiplexer, like tmux are more elegant solutions.

Member Avatar for JasonHippy

Aha, just fired up a plasma session. My method does work, it just depends on how you close the terminal. I knew I wasn't going crazy!

If you close the konsole session with the close button on the window, or if you force kill the konsole process, both the dolphin and konsole windows will close.

But if you use ctrl-d or type exit to end konsole, then konsole will close, but dolphin will remain open until you close it.

I get the same results with terminator, uxterm and the other terminals I've tried.
I guess when you use exit or ctrl-d, the terminal window will close, but it waits in the background for its child processes to terminate before closing down fully?? IDK?!

When using dwm, I always use ctrl-d to close my terminal sessions!
If I close the terminal using the close window shortcut (super + alt + c), which is equivalent to pressing the x in the top corner (but there are no close, minimise or maximise buttons in dwm - hence the keyboard shortcut!) I've just discovered that the terminal and the file-manager will close. Which fits the pattern I've already seen in plasma!

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.