Custom command I made.

RobbysTrash

New Member
Joined
Jan 9, 2022
Messages
1
Reaction score
0
Credits
11
To install this custom command open the .zip file then open up the "Read me" file
 

Attachments

  • help.zip
    15.3 KB · Views: 34


NorthWest

Member
Joined
Nov 4, 2021
Messages
34
Reaction score
24
Credits
395
I was able to make the program work but had to modify the file: help, to this:
Code:
less 'Cmds '
to account for the space at the end of the filename: "Cmds ". Otherwise it wouldn't run.

A few comments:
- The space in the filename "Cmds " is unnecessary.
- In relation to the file: "READ ME", again the space is unnecessary, but not fatal like the space in "Cmds "
- Placing the executable: help, in /usr/bin is unnecessarily adding a non-system file to the system filesystem.
A more appropriate location would be /usr/local/bin, or /home/<username>/bin, so that when a system is upgraded
the user doesn't get unexpected results.
- I guess this has been an exercise to create something helpful in script. There is a nice listing of commands and comments
that are produced. The script and terms however don't follow conventions commonly used in scripting, nor in file locations.
It's as well to note that there are so many commands already built into the shells such as bash to find help, that one would be hard pressed I think to prefer one such as this over the many others, but since I guess that this has been an attempt to script something helpful, it's been a useful exercise for the creator.
 

KGIII

Super Moderator
Staff member
Gold Supporter
Joined
Jul 23, 2020
Messages
4,629
Reaction score
4,278
Credits
37,176
Nice. I just checked for anything malicious. (They're a new user posting something they made themselves. Of course I'm going to check it - assuming I have time and ability.)
 

JasKinasis

Well-Known Member
Joined
Apr 25, 2017
Messages
1,378
Reaction score
1,949
Credits
9,117
I was able to make the program work but had to modify the file: help, to this:
Code:
less 'Cmds '
to account for the space at the end of the filename: "Cmds ". Otherwise it wouldn't run.

A few comments:
- The space in the filename "Cmds " is unnecessary.
- In relation to the file: "READ ME", again the space is unnecessary, but not fatal like the space in "Cmds "
- Placing the executable: help, in /usr/bin is unnecessarily adding a non-system file to the system filesystem.
A more appropriate location would be /usr/local/bin, or /home/<username>/bin, so that when a system is upgraded
the user doesn't get unexpected results.
- I guess this has been an exercise to create something helpful in script. There is a nice listing of commands and comments
that are produced. The script and terms however don't follow conventions commonly used in scripting, nor in file locations.
It's as well to note that there are so many commands already built into the shells such as bash to find help, that one would be hard pressed I think to prefer one such as this over the many others, but since I guess that this has been an attempt to script something helpful, it's been a useful exercise for the creator.
@RobbysTrash - To expand on some of the problems highlighted in this answer:
I'd recommend removing the trailing space from your file called "Cmds ".
Code:
mv "Cmds " Cmds
That should fix that problem.

One other comment that I have is that bash already has a builtin called help.
So by calling your script "help" - your script will not run if you install it globally.
Instead, bash will run it's builtin called help instead.
Bash's help builtin is like a built-in man-page for other bash-builtins like echo, exec, bg, fg, hash, history, etc etc.
So perhaps rename your script to something like "helpme"? or "helpcmds"?, or "cmdhelp"? Something that is unique and not already in use.

Also, @NorthWest mentions putting system-wide scripts into /usr/local/bin/ that's a good, solid suggestion for anything that you want to install system-wide, but without putting it into a main system directory like /usr/bin/.

Also, they mention creating a personal bin directory at /home/youruser/bin/.
And even if you're insistent that your help script should be a system-wide thing - if you're in the habit of creating scripts, then adding a personal bin directory is an absolute godsend. Literally all you have to do is add a bin directory to your home directory and you can copy your personal scripts and any ancillary files they rely on into there.
e.g.
Bash:
mkdir ~/bin
NOTE: ~ is a shorthand for $HOME, or /home/username. Where username is the name of the logged in user. All three are equivalent. It's the path to the home directory of the currently logged-in user.

Now you can copy your scripts to your personal bin directory. So copy your script and the text file it reads into ~/bin/. But you won't be able to run any scripts from your personal directory just yet. First the path to your personal bin directory needs to be added to $PATH.

So next you need open a terminal as root and use your favourite text editor to edit the file /etc/X11/Xsession, where we'll add some lines of code which will add your personal bin directory to $PATH.

$PATH is a system-wide environment variable containing search paths for executable files. By adding your personal bin directory to $PATH, you will be able to run your own personal scripts as if they are installed programs.

The file /etc/X11/Xsession is a system-wide script that is ran each time a user logs in and X is started up. So this is a good place to alter $PATH.

NOTE: You must edit the file as root, so remember to use sudo (or su to root BEFORE editing the file if your distro is one that still uses su instead of sudo).

As a vim user on Debian, I'd edit the file using the command:
Bash:
sudo vim /etc/X11/Xsession
If you're more comfortable with emacs, or nano - use that. If you want to fire up a GUI based editor from the terminal - that's entirely at your discretion too!
The editor you use is immaterial. The key thing is, you need to edit the file as root and add the following lines of code:
Bash:
# set PATH so it includes user's private bin if it exists
# First location ~/.local/bin
if [ -d "$HOME/.local/bin" ] ; then
    PATH="$HOME/.local/bin:$PATH"
# Second location ~/bin/
if [ -d "$HOME/bin" ] ; then
    PATH="$HOME/bin:$PATH"
fi
I'd recommend copy/pasting the above to prevent accidentally introducing any typo's or syntax errors.
I've attached an image in a spoiler below, so you can see exactly where I've added the above lines of code. I've added them at line 63 - just after a block of variables that have been set up:
2022-01-11@00-27-23_1366x768.png
But on your distro - the file might be slightly different.
Anyway, after adding those few lines of code - Save the file and quit your editor and that's another major step out of the way.

The lines of code starting with a # are comments, the other lines are actual code.

In the above, I've added two common locations for personal bin files. And I'll explain the rationale for each in detail:
The first location I've added is ~/.local/bin/ - which is where executable's typically get put if you install them with things like pip (for python applications) or gem (for ruby applications).

So for example, if you installed the Ruby based, CLI twitter client called 't' using gem, or if you installed the Python based, CLI Reddit client 'tuir' using pip - the executable's for these applications often end up in ~/.local/bin/. But this path is not typically included in $PATH. So it's a good idea to add this to $PATH, if it exists. The keyword there is IF!

So the first if statement we added, checks to see whether a directory exists at $HOME/.local/bin. If it does - then that path is added to $PATH. And if it doesn't, $PATH stays as it is. It is not modified. So if ~/.local/bin does not exist - it doesn't matter. But the key thing here is, if you do install something new in the future, and it gets installed to ~/.local/bin/, then it would become available to you the next time you log-in.

The second location is ~/bin/ - which is your personal bin directory, which we just created.
Depending on your distro - you may find that the code for this is already in the Xsession file, but is commented out - in which case, simply uncomment the existing lines with that code. Or you may even find that it is already present in the file and is uncommented - which means you're already set up to use a personal bin directory.

So the second if statement in my code checks for the existence of a directory at $HOME/bin. If a directory exists - then that path is also added to $PATH. Again - if not, then $PATH is not modified.

I deliberately haven't used if...elif.., or if..else.. type syntax because this isn't a "one or the other" type of situation.
If they both exist - they both get added to $PATH. If only one exists, then that one gets added to $PATH. If none of them exist, $PATH stays unchanged.

After saving the file and quitting your text editor, the final thing to do is to simply log out and log back in again. When you log back in - the edited script at /etc/X11/Xsession will be ran, your personal bin directories will be detected and added to $PATH and you will be able to run any scripts that you put into either of those directories.

And once you have this set up globally in /etc/X11/Xsession, then if any other users on your system want to have a personal bin directory, all they have to do is - create a personal bin directory at ~/bin/ and then log out and log back in again. And they will be able to run any scripts they have in their personal bin directories too. And likewise - if they have installed anything locally using something like pip, or gem - then any applications in ~/.local/bin/ will also be available to them.


Also - as an added, extra bonus - if you want to be able to run your personal scripts/applications from the desktop/GUI, you can even add .desktop files for your scripts/applications and put them into ~/.local/share/applications.

I'll put information about that as a spoiler - as this will probably be pretty long-winded, knowing me:
Oh you opened this?! Feeling brave eh?! Ha ha!

So as a bit of background for an example of a script that might require a .desktop file - I have a script called buildbl in my personal bin directory, which scours my home directory for ebooks and creates a sorted list of all books. So whenever I buy and download a new set of ebooks from Humblebundle.com - I will always run this script to update my list of ebooks.

I have another script, imaginatively called 'book', which allows me to search my library/book-list for a particular book. So if I want to see what ebooks I have related to python, I'll run the command book python and I'll see a list of books which have python in the path/file-name. And if I want to filter the list further, I'll use grep.
So if I want to find Python books that are related to robotics, I would use the following
Bash:
book python | grep -i robot
I'm too lazy to type robotics - robot will do! Ha ha.
And once I've found a book I want to read, I'll run another script, called rd - which takes the path to an ebook as a parameter and then opens it in Okular. Why do I have a script for that? Because typing rd /path/to/book is much faster than typing okular /path/to/book/ &> /dev/null & or typing xdg-open /path/to/book each time I want to open it up from the terminal.

Now, I'm a bit of an odd-bod. Normally, I live in the terminal - so I'll always run my personal scripts in the terminal. And I don't use a normal desktop either, I use dwm (a tiling window manager). So no GUI application menus/launchers or anything. I don't use the GUI a lot. So most of my scripts are pretty useless from the GUI too.

My book and rd scripts are really only useful in the terminal, they wouldn't be helpful to launch from the desktop. However my buildbl script could potentially be useful from the desktop.

So IF I was a typical desktop user, logged into Gnome (yuk), or KDE, or some other desktop, and I'd bought some new ebooks, and I wanted to update my list from the GUI - then I would need to create a .desktop file for my script, and add it to ~/.local/share/applications.

Any modern, freedesktop.org standards compliant desktop will look in this location for local application .desktop launchers and will add a icon for them to the application menus. So if you add a .desktop for one of your own scripts, or executable programs here - it should appear as an icon in your systems menu/launcher system.

So let's take a look at a typical .desktop file.
For the sake of an example, I'll create a .desktop file for my 'buildbl' (build book list) script. You can use the file as a template, and modify it for use with your own scripts/programs.

So this particular .desktop file would be called buildbl.desktop - obviously, you call yours whatever you like. And I would create it in ~/.local/share/applications/ (you should create yours here too!). And it would look something like this:
Code:
#!/usr/bin/env xdg-open
[Desktop Entry]
Encoding=UTF-8
Version=1.0
Name=buildbl
GenericName=build book list
Comment="Searches home directory for ebooks and creates a sorted list of books"
Type=Application
Icon=utilities-terminal
Categories=Utility;
#Exec=/home/jason/bin/buildbl
Exec=xterm -e '/home/jason/bin/buildbl;read -p "press any key to  continue..." -n1 -s'
Terminal=true

The first thing in the .desktop file is a shebang.
#!/usr/bin/env xdg-open
This tells the shell which interpreter should be used to interpret the file when it is opened.
In this case, we're using xdg-open, which is used by X to open/launch files based on their mime-type and their default application.
The next line [Desktop Entry] tells xdg-open that this is a desktop application launcher.
Then we have some information about the file encoding and the application version.
They speak for themselves.

Then we have the Name, Generic name and a Comment (which typically pops-up as a tool-tip when you hover your mouse over the desktop entry). Again, all pretty self explanatory. The Name is the short name for the application. The Generic name is a more long-winded name. And as mentioned - the comment is like a tool-tip.
Obviously, I've made these relevant to my script. If you are adding a .desktop for one of your scripts, or applications - then alter those fields to reflect the name and function of your script/application.

The Type field is set to Application, again - pretty self-explanatory. Our script is an application.

The Icon= field is an interesting one. This is used to set the icon for the entry. I've just used a default icon for it, called 'utilities-terminal', so the icon for my application will appear to be a terminal application - which makes sense, because it is a terminal application.
But you could look through /usr/share/icons and find another existing icon that you want to use for your application.

Or you could create your own fancy icon and then specify an explicit path to it in this field. So for example, I could create an icon of my own and set the Icon field to:
Code:
Icon=/home/jason/bin/buildbl-icon.png
And it would use the icon I created. But I'm too lazy for that! I just used a default icon! Icons are mostly in .tiff, .xpm, .png, or .svg format.

Next we have this entry:
Code:
Categories=Utility;
That tells the system that my application should be listed under the "Utility", or "Accessories" section in the menu.

There is a list of freedesktop.org application categories here:
If you have a script/program that belongs in a different category in the menu, you can see which categories are available in the above link.

Then we get to the Exec section of the .desktop.
This is where we specify what to run.
I've got two exec lines in there. The first one is commented out. The second is not.

The commented out one would run my buildbl script.But it would run my application in a hidden terminal, that wouldn't even show up. So I wouldn't see my application, or see if it completed successfully. Personally - I'd be OK with that - I know my buildbl script works. However, you probably might want to see your script running in a terminal so you could see its output.

So the second, uncommented Exec= line shows you how I'd go about starting my script in a new terminal window, so I could see what it was doing:
Code:
Exec=xterm -e '/home/jason/bin/buildbl;read -p "press any key to  continue..." -n1 -s'
That tells the system to run the xterm terminal emulator and to run my script and then afterwards there is a read command with a prompt "press any key to continue...".
So what that does is, it runs my script in a new instance of xterm. So an xterm window will pop up. My script will run in xterm, eventually the script will tell me how many books are in the new booklist and then I'll be prompted to "press any key to continue..." - I can then press any key and the terminal window will close.

And the final line in the .desktop file is:
Code:
Terminal=true
Which tells the system that this is a terminal-based application and not a GUI application. If you'd created a windowed, GUI application using C++ with QT, or wxWidgets, then you'd set that to false.

So that's how you'd create a simple .desktop file for a script!

Obviously, I've made it relevant to one of my own scripts - you may need to make some changes to fit whatever scripts you want to run.
Your script might be in your personal bin directory, or it might be something that you have installed system-wide in /usr/local/bin - so it can be used by other users on your system.
In which case, you would add the .desktop file to /usr/share/applications instead, which is where the .desktop launchers for system wide applications are stored.
Also /usr/share/applications is a great place to look if you want to see some examples of other .desktop launcher files and see what other fields you can use in your own .desktop launchers.

Also, my .desktop file is only in English. If you take a look at the .desktop launchers for some system-wide applications - you will see that the 'Name', 'Generic Name' and 'Comment' fields all have translations for multiple languages.
The field translations use this kind of syntax:
Code:
FieldName[Language-code]="Translated Value"
Where FieldName is either 'Name', 'Generic Name', or 'Comment'
'[Language-code]=' is a language code - e.g.
[cy]= for Welsh or [de]= for German etc. etc.
And "Translated Value" is the translated string for that language.
So in German, the GenericName entry for my application might look something like this:
Code:
GenericName[de]="Bücherliste erstellen"

So for any non-native, English speakers in the community here - who may well have their systems set up to use their own native language, or who perhaps might use a multi-lingual setup, where they regularly switch between their native language and any other languages they know. You could add some translations to your .desktop files too. That will make the .desktop files a little bigger, but the file-size is not really a problem. Most system-wide applications support a huge number of languages.
So some of you might also want to include translations for the name, generic name and comment fields in the .desktop file too!

Anyway, I think I've rambled on for far too long and taken things completely off-track.
But that's a pretty comprehensive guide on setting up a personal bin directory for your personal scripts and applications AND optionally - how to create .desktop files, in order to launch your scripts and applications from your desktop environments graphical menu-system/launcher too. Nobody asked, but I just included it anyway!
 
Last edited:
$100 Digital Ocean Credit
Get a free VM to test out Linux!

Members online


Top