8

Lets suppose that there are two binary files, e.g. XXX and YYY, at destination /usr/bin/. I want to start them at once, always! In other words, when I type the name of either of those in unity, I want to make both of them start. How could I change the corresponding files at destination /home/username/.local/applications/ to do so? I tried this /usr/bin/XXX;/usr/bin/YYY; on terminal but it doesn't seem to work.

efthialex
  • 3,831
user88349
  • 309
  • 1
    There are TWO aspects to this question. One of them is running TWO apps apparently simultaneously. The other is making both run when the command name of just one (either) of them is typed into. – Skaperen Feb 27 '13 at 14:04

4 Answers4

9

As I understand you need to edit your .desktop file. Add this line next to Exec:

sh -c "/usr/bin/XXX & /usr/bin/YYY"

The -c flag tells to the shell that it has to read the commands from string, instead of from the standard input.

If you use only /usr/bin/XXX & /usr/bin/YYY it won't work. Just to add the reason why & doesn't work in a launcher, it's because & is a feature of the shell, and the launcher isn't a shell, its a much simpler environment for running commands.

efthialex
  • 3,831
  • 3
    Thanks, in fact, based on the answers bellow, I used a singe & instead. Therefore, the solution that worked for me is: sh -c "/usr/bin/XXX & /usr/bin/YYY;" – user88349 Feb 27 '13 at 10:59
  • 2
    in this case, it should be &, not && - the latter waits for the first command to finish, and then only runs the seccond if the first was successful. & starts the first one and then starts the second straight away. – jackweirdy Feb 27 '13 at 13:18
  • 1
    @jackweirdy I updated the post. – efthialex Feb 27 '13 at 13:54
2
/usr/bin/app_first & 
/usr/bin/app_second

Using '&' you are sending process into background.

bluszcz
  • 212
1

You should use

/usr/bin/XXX && /usr/bin/YYY;

Note the use of && (no need to use & to run something in the background).

don.joey
  • 28,662
  • 3
    This is not exactly true. If the XXX is not detaching by itself - the YYY is not run as long XXX will be dead - so you are not gonna run two apps at once. – bluszcz Feb 27 '13 at 10:25
  • @bluszcz && doesn't work in my case. Plus, I notice some differences on terminal’s output when XXX is called first compared to the case where YYY is called first. What's the reason for that? – user88349 Feb 27 '13 at 10:29
  • And saying more, 'YYY' will work if 'XXX' finished it lifetime with success. If 'XXX' fails - you will never get YYY running. – bluszcz Feb 27 '13 at 10:29
  • @eualin ? what do you mean by 'does not'? – bluszcz Feb 27 '13 at 10:30
  • The exit status of XXX should indeed be zero, but I think that is what the OP wants. To run two programs successfully. If the first is unsuccessful, no need for the second. Check http://askubuntu.com/questions/23549/is-there-a-difference-between-the-and-symbols-in-a-standard-bash-termin – don.joey Feb 27 '13 at 10:30
  • 1
    It seems that putting process to background worked out for him - and this is why I understood that question. – bluszcz Feb 27 '13 at 10:33
  • It might work for the OP but I still feel it is inelegant. If you need two programmes to be up and running, you need the non-zero exit status of the first. – don.joey Feb 27 '13 at 10:36
0

You will need to add the command names XXX and YYY into a directory at an earlier point in the search path. For both this command named file will run the original XXX and YYY by using the full path names /usr/bin/XXX and /usr/bin/YYY. This is to prevent the script from re-running itself forever in a loop (or until your computer runs out of memory). An alternative to this is replacing the commands with your script and moving the original commands to another path like /usr/local/bin.

This script needs to run both /usr/bin/XXX and /usr/bin/YYY in the background so they are running at the same time. The classic way to do this is:

/usr/bin/XXX &
/usr/bin/YYY

As described by bluszcz above. You might also want to put the " &" on the 2nd command as well. An alternative way to more quietly put these commands in the background is with screen, which could be coded in the script like this:

screen -dmS XXX /usr/bin/XXX
screen -dmS YYY /usr/bin/YYY

That can have the advantage in cases where you might want to go see the progress of the commands without doing logging, bu using screen to attach to the sessions that creates.

Skaperen
  • 435