Author Topic: execute shell script on startup  (Read 3327 times)

atzz

  • Newbie
  • *
  • Posts: 3
    • View Profile
execute shell script on startup
« on: March 07, 2012, 03:06:15 »
Hello Quentin, hello everybody!

First of all, let me say that gmusicbrowser is awesome (you already heard that, but still). It doesn't get in your face, and it does what it promises to do. This quality becomes a rarity these days, sigh...

Now, to my question.
Is there a way to make gmusicbrowser execute some system commands (e.g. run a shell script) when it's starting?

I needed this functionality to mount my music collection volume if it's available. Having failed to find an official way to do it, I've made a "quick and dirty" hack by plugging a system() call in the main perl executable (/usr/bin/gmusicbrowser). The patch, if it deserves such name, is attached (I have gmusicbrowser 1.1.7). When the patched GMB starts, it will run ~/.config/gmusicbrowser/autoexec.sh, if that file exists and executable.

Did I miss a better way to accomplish what I need?

If such functionality does not exist, do you think it may be useful to add it?

Best regards,
-atzz

laite

  • Jr. Member
  • **
  • Posts: 96
    • View Profile
    • Gmusicbrowser-plugins by laite
Re: execute shell script on startup
« Reply #1 on: March 07, 2012, 09:57:45 »
Did I miss a better way to accomplish what I need?

Why not just make a shell script that first mounts music collection volume (if available), then starts gmusicbrowser, and run the script instead of gmb?

atzz

  • Newbie
  • *
  • Posts: 3
    • View Profile
Re: execute shell script on startup
« Reply #2 on: March 07, 2012, 11:34:34 »
Because I don't want to lose the integration (e.g. with volume control applet), and don't want to hunt through the system for all places that reference GMB directly and modify them.

BTW, I realized that my "patch" is flawed, as it runs the script every time GMB is executed to pass commands to the running GMB instance (e.g. system-wide media key shortcuts do that). In my case it doesn't do anything bad (except for some delay), but still it's better to run the script at a different point.

laite

  • Jr. Member
  • **
  • Posts: 96
    • View Profile
    • Gmusicbrowser-plugins by laite
Re: execute shell script on startup
« Reply #3 on: March 07, 2012, 11:50:26 »
Because I don't want to lose the integration (e.g. with volume control applet), and don't want to hunt through the system for all places that reference GMB directly and modify them.

gmusicbrowser can run system command when launched with -cmd RunSysCmd, example:
Code: [Select]
gmusicbrowser -cmd "RunSysCmd mousepad" &
I don't really understand how you would 'lose integration' - it shouldn't matter whether gmb is launchen 'manually' or from the script, as long as the script is exited after launch?

One option that comes to mind is to rename /usr/bin/gmusicbrowser to something else and create symlink by that name, which would then run the script to mount music & launch gmb.

atzz

  • Newbie
  • *
  • Posts: 3
    • View Profile
Re: execute shell script on startup
« Reply #4 on: March 07, 2012, 14:58:24 »
Quote
gmusicbrowser can run system command when launched with -cmd RunSysCmd
Yes, seen that... but it still requires to modify each place in the system where GMB is launched, so from the logistics perspective it's no different from using a wrapper script.

Quote
I don't really understand how you would 'lose integration' - it shouldn't matter whether gmb is launchen 'manually' or from the script, as long as the script is exited after launch?

What I mean is that there are existing places in the system where GMB is launched (including the volume control applet). If I to use a wrapper script, I'd have to modify all these places to launch the wrapper script instead of GMB. Or, if I don't do that, these places will launch GMB without the script.

Quote
One option that comes to mind is to rename /usr/bin/gmusicbrowser to something else and create symlink by that name, which would then run the script to mount music & launch gmb.
Yes, but this approach is logistically the same as patching the GMB executable itself. It'll cause the same questions during package upgrade and the same need to re-apply after upgrade.