less 'Cmds '
@RobbysTrash - To expand on some of the problems highlighted in this answer:I was able to make the program work but had to modify the file: help, to this:
to account for the space at the end of the filename: "Cmds ". Otherwise it wouldn't run.Code:
less 'Cmds '
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.
mv "Cmds " Cmds
helpbuiltin is like a built-in man-page for other bash-builtins like
history, etc etc.
/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
bindirectory to your home directory and you can copy your personal scripts and any ancillary files they rely on into there.
~is a shorthand for
usernameis 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.
/etc/X11/Xsession, where we'll add some lines of code which will add your personal bin directory to $PATH.
/etc/X11/Xsessionis 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.
suto root BEFORE editing the file if your distro is one that still uses
sudo vim /etc/X11/Xsession
# 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
#are comments, the other lines are actual code.
~/.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).
~/.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!
$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/bindoes 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.
~/bin/- which is your personal bin directory, which we just created.
$HOME/bin. If a directory exists - then that path is also added to $PATH. Again - if not, then $PATH is not modified.
if..else..type syntax because this isn't a "one or the other" type of situation.
/etc/X11/Xsessionwill 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.
/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.
buildblin 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.
book pythonand 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.
book python | grep -i robot
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/bookis much faster than typing
okular /path/to/book/ &> /dev/null &or typing
xdg-open /path/to/bookeach time I want to open it up from the terminal.
rdscripts are really only useful in the terminal, they wouldn't be helpful to launch from the desktop. However my
buildblscript could potentially be useful from the desktop.
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:
#!/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
[Desktop Entry]tells xdg-open that this is a desktop application launcher.
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.
Execsection of the .desktop.
buildblscript works. However, you probably might want to see your script running in a terminal so you could see its output.
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:
Exec=xterm -e '/home/jason/bin/buildbl;read -p "press any key to continue..." -n1 -s'
/usr/share/applicationsinstead, which is where the .desktop launchers for system wide applications are stored.
/usr/share/applicationsis 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.