Would creating .desktop launchers for your scripts be a viable solution?
That way, you could get your scripts to appear in the systems main application menu, or main application launcher.
All you'd have to do is put your scripts into somewhere on $PATH, like
/usr/share/bin.
Then you create your .desktop launchers in
/usr/share/applications.
And a typical .desktop launcher for a terminal based script/application would look something like this:
Code:
[Desktop Entry]
Name=Your script
GenericName=set-up something
Comment=setup script for something useful
Icon=utilities-terminal
Type=Application
Categories=System;
Exec=/usr/local/bin/yourscript
Terminal=true
In the above, we've set up a .desktop file to launch a script at
/usr/local/bin/yourscript
The name that appears with the Icon in the menu will be "Your Script" as per the
Name field.
The
GenericName and
Comment fields are a short description of the script/program being launched. The text in the
Comment field is usually used as popup/tooltip text when you hover your mouse over the icon.
I've set
Icon to be
utilities-terminal, which is a common, default, system icon used for terminal based applications. If you want to use another Icon, you could create one of your own, or use another icon that is installed on the system. But you also need to be aware that for icons in lossey formats (.bmp, .tiff, .png, .jpg) - you should provide the icon in sizes ranging from 16x16, up to 256x256, or 512x512, in order to ensure your icon will be drawn at whatever size the user has specified in their system settings/preferences. Alternatively, create your icon as a .svg, which is a lossless, infinitely scalable format. That way, you only have to create the one icon at any size and it can be scaled up, or down by the system as required.
Type has been set to
Application - kinda speaks for itself.
Categories is where you specify the menu categories that your script belongs in.
I've specified
System, so it will appear in the menu/launcher alongside other system tools, like your process monitor etc. You might want to put it into Settings, or somewhere else. I'll add some links to the official freedesktop documentation for the .desktop format below, so you can see all of the available categories.
Exec is where you specify the script, or executable that the .desktop file will be launching.
In this case, it executes a fictional program at
/usr/local/bin/yourscript.
You should substitute
yourscript with the name of one of your scripts that you copied to
/usr/local/bin/.
NOTE: As the path to the executable/script is on the systems $PATH (
/usr/local/bin/ is in
$PATH) - we could have just put:
Exec=yourscript - but it doesn't hurt to specify the full path.
Terminal is a boolean variable that tells the system whether or not the application is a terminal application. In this case it is, so we've set it to
true. This will cause a default, system terminal window to be opened and your script will be ran inside it.
With your scripts in
/usr/local/bin and a .desktop launcher like the above one for each of your scripts in /usr/share/applications/ - you should be able to just open up your systems menu (if you're using a desktop/wm with a traditional, cascading menu system), or go to your systems launcher (if using something launcher based, like Gnome3, or Unity) and you should see desktop icons for your scripts in the main system menu. It might be a better option than trying to create a GUI script with buttons.
And don't let my huge wall of text put you off. This is REALLY simple to do. Literally copy your scripts to a location that is on $PATH, create a .desktop launcher for each script in
/usr/share/applications, which will run those scripts. Then your users should be able to run your scripts by finding them in the appropriate category of their systems menu system and clicking on their icons.
And optionally - you might want to create a custom, (ideally .svg) icon and specify the path to that icon in the .desktop file. Again, whether you use the same icon for all of them, or use a different icon for each script is completely up to you.
Full documentation for freedesktop.org's .desktop format can be found here:
You can see what other fields are available in the .desktop format on this page:
You can also see the various application categories that are available in freedesktop.org's menu specification here:
Specifically on these pages:
Finally, I'm aware that many users here on Linux.org are from foreign countries, with English as a second language. So I feel it's worth mentioning that if you're using a non-english locale, you can add translations for specific locales by adding the locale-name in square brackets at the end of the field-names, alongside the translated text.
e.g.
For German:
Code:
Name[de]={German translation}
GenericName[de]={German translation}
Comment[de]={German translation}
Where {German translation} should be the actual translated text for the corresponding english field.
e.g.
Name[de]=Deine Skript or something - IDK?! I used to be quite fluent in German 25-30 years ago. But I can barely remember a word nowadays, ha ha!
Either way - the basic syntax for adding localised/translated fields to .desktop files is:
{FieldName}[{locale}]={translated/locallised text}.
So if you and/or your users are using any non-english locales, that's how to add translations for different languages/locales to your .desktop files. Even if you're from an English speaking country - you may have users on your systems who prefer to have things running in their native languages. So again, if this is a consideration - you can set up your .desktop launchers to support users who use other languages.
And even your scripts are not using any kind of translation - your launchers will at least be more friendly towards any foreign users you might have using your systems.
EDIT:
One minor caveat to using .desktop launchers to launch terminal-based scripts/applications is - if the script is something that does not run interactively (i.e .does not require any user input) and doesn't take very long to run - users will click on the icon and will just see a flash as a terminal window appears, the program/script runs and then the terminal quickly disappears. So they may not know whether or not the program/script completed sucessfully, or if it even ran at all. They might just see a blur.
One way around this is to make the following change to the
Exec field:
Code:
Exec=/usr/local/bin/yourscript; read -p "Press any key to continue..." -n1 -s
That should pop up the systems default terminal, run your script and then prompt the user to press any key to continue. Upon pressing any key, the terminal window will disappear.
Or alternatively, you could leave the
Exec field as it was
e.g.
Exec=/usr/local/bin/yourscript
And add the
read -p command to the end of each of your scripts instead.
Either way, you may need some way of pausing things, to allow the users to see the status of the script and dismiss the terminal window when they're ready.
Again, sorry for the wall of text. But this may be another valid way of solving your problem.
One last thing. You can do exactly the same thing with personally created programs/scripts too.
If you have a bunch of scripts, or executable programs in a personal bin directory in your home directory (e.g.
~/bin) and you've added your personal bin directory to $PATH in ~/.profile, you can add .desktop launchers to
~/.local/share/applications, which will allow you to access your own personal scripts/programs from your desktop (or window manager)'s main menu/launcher as if they were "first-class"/system-wide applicatons. But those applications will only be available to your user, NOT to other users.
Which can be handy if you're administering a multi-user system. You can add custom scripts and programs for all other users to use by installing them system wide, using the methods initially described (executables/scripts in $PATH and .desktop launchers in /usr/share/applications/).
And you can add your own personal, custom applications/tools for yourself via executables/scripts in your personal bin directory and .desktop launchers in
~/.local/share/applications/.
