2

I'm using Ubuntu 20.04 and I'm looking for a bash script to start Quodlibet (a music application) and conky simultaneously. Edit: The idea is to use the sh script in a .desktop launcher

  1. Start Quodlibet
  2. Start conky 2 seconds later
  3. Close conky if Quodlibet is closed

I made some tests but I believe the following script won't work because I doesn't catch the closing of Quodlibet. Conky is still running when I close Quodlibet.

#!/bin/bash trap "exit" INT TERM ERR trap "kill 0" EXIT quodlibet & sleep 2 && conky & wait

EDIT: Standalone .sh solution

Working script, thanks to @berndbausch.

#!/bin/bash quodlibet & QUODPID=$! sleep 3 && conky & CONKYPID=$! wait $QUODPID kill $CONKYPID

EDIT: Using a custom launcher

As explained by @xhienne in his answer, using exec=setsid /path/to/script.sh in the .desktop file as well as his script works well.

Improve this question
5
  • 2
    Store Quodlibet's PID right after starting it QUODPID=$!, then, after starting conky, store its PID as well. Wait for Quodlibet's termination with wait $QUODPID. Then kill conky. Commented Apr 21, 2021 at 13:45
  • 1
    I want to create a .sh file that I will execute with a custom launcher (.desktop). Commented Apr 21, 2021 at 13:57
  • @berndbausch I edited my question but I can't figure it out, conky is not killed. Commented Apr 21, 2021 at 14:13
  • 2
    The ampersand behind CONKYPID=$! puts the assignment into a subshell, so that the CONKYPID in the main program is not affected. Remove the ampersand and it should work. Same for the QUODPID, by the way. Commented Apr 21, 2021 at 14:26
  • This solution is working great when I only run the script inside a terminal. But when I create a launcher, it open quodlibet and conky as planned, but it never closes conky when I exit quodlibet. Commented Apr 21, 2021 at 16:47

1 Answer 1

Reset to default
4

Just start Quodlibet in the current shell, not in a sub-process:

#!/bin/bash trap "exit" INT TERM ERR trap "kill 0" EXIT (sleep 2 && conky) & quodlibet

[update] You mention that you want to run this script from a .desktop file in a graphical environment. @fra-san made me aware that every process run this way are likely to inherit their parent's process group and that, as a consequence, kill 0 will kill that launcher process and (potentially) all the processes it has started. This is certainly not what you want.

The solution to this is to start your script with setsid so as to create a new process group dedicated to it:

setsid /path/to/script.sh
Improve this answer
8
  • The intention of putting the script in a .desktop file didn't make it to the question's body, but it makes kill 0 quite dangerous because programs invoked by means of .desktop files share their process group with the process that started them (at least in some desktop environments, I could check with KDE). Commented Apr 21, 2021 at 14:48
  • I didn't know putting the script in a .desktop file would change anything, I'll edit my question so that it appears. Commented Apr 21, 2021 at 14:52
  • As I said, I can only check on KDE, where I confirm that a script Executed from a .desktop file, when started by means of the launcher widget (krunner), belongs to the same process group of the launcher widget itself (also shared by all other applications that don't take care of changing their own process group). Same thing happens if the .desktop file is double-clicked in a file manager. By default, child processes share the same group of their parent. Commented Apr 21, 2021 at 15:33
  • This solution works well using a custom launcher. It closes conky as expected but there's a weird thing happening just after, it's like my session is closed and restart Commented Apr 21, 2021 at 16:52
  • 1
    @xhienne (re to a previous comment of yours) a terminal emulator started from a .desktop file may have the same pgrp of its parent process (e.g. Konsole, the one I'm using, does), but each pseudo-terminal it creates needs its own session leader, hence its own session and its own process group. Combining this with job control, by default enabled in interactive shells, and the fact that they ignore INT/QUIT/TERM, there's usually no way a kill 0 could terminate the terminal emulator or its ancestors... Commented Apr 21, 2021 at 19:07

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.