Writing Learning Bash

[alemorvan]

Author checklist (Completed by original Author)

• Contribution a good fit for the Rocky project? Title and Author MetaTags inserted ?
• Is this a non-English contribution?
• If applicable, steps and instructions have been tested to work on a real system
• Did you perform an initial self-review to fix basic typos and grammatical correctness

Rocky Documentation checklist (Completed by Rocky team)

• 1st Pass (Check that document is good fit for project and author checklist completed)
• 2nd Pass (Technical Review - check for technical correctness)
• 3rd Pass (Basic Editorial Review)
• 4th Pass (Detailed Editorial Review and Peer Review)
• Final pass/approval (Final Review)

[sspencerwire]

Sorry! I hadn't finished the review, so they all said "pending"

[sspencerwire]

You can also call other scripts from within to make a single script less cumbersome and easier to understand.

[alemorvan]

I mean, basically you need a file and the commands in it to make it work. This is an introduction, keep it simple.
If I add "at least" or something like that.

[sspencerwire]

I've never had to use the shebang this way. For instance, all of my bash scripts represent the path to bash which on my workstation is /usr/bin/bash... The shebang that I would use is #!/usr/bin/bash ... I'm not saying this way is wrong, I've just not seen it before.

[alemorvan]

Yes me too. I have always put #!/bin/bash.
In the case of python for example,
#!/usr/bin/env python will use the python version defined by alternative.
I have read that it's good to do this, because it does not matter of the path to bash (in your case #!/usr/bin/bash)

[NezSez]

Using env in the shebang line has been around a long time, and was designed to allow scripts to work portably on nix's that had executables in alternate dirs (like /usr/local/bin, /opt/bin, etc). Like many "improvements" regarding abstraction it didn't really catch on and many devs/admins never even knew about it, another classic example is using "info" rather than "man", or surrounding program calls in scripts with parenthesis (for security). Later, others who either were unaware of, or just dissagreed with this method developed other solutions like alternatives, "environment-modules", and "direnv", while some devs devised specific program solutions like python's "virtualenv" and "anaconda" etc. env has been the std for a very long time, but was primarily used to temporarily alter environment settings to pass to autotools utils like configure, as well as gcc. The bottom line is that what you use for shebang depends on what the system admins implement systemwide, and/or per user and sadly there is currently no real "best-practice" in any universal sense because there is so much variance in system setup techniques, but using env has gained some traction and offers the most flexibility for admins and users. I have used it in the shebang for 15 or so years and not had any major issues, however I was the admin for all the systems I used and set things up so that there would be consistency among the various elements (alternatives, environment-modules, $PATH, /etc/skel/ , etc)

[alemorvan]

Hey thanks @NezSez for this explanation!
The review is really a good thing 👍

[sspencerwire]

Throughout this section, you are using "$" at the beginning of each line, which does not work in practice and will generate an error when executed:

test.sh: 3: $: not found
test.sh: 4: $: not found

Also, while it is not "necessary" for function in this case, the best practice recommendation is to give the entire path of the command you are calling (in this case /usr/bin/touch)

When you remove the "$" from the beginning of these lines, the script executes fine.

Suggestion: Somewhere during your chapters, you should introduce the concept of a replaceable parameter (variable). This is a variable entered at the command line along with the script name. If the variable is empty, the script responds with "usage" text, so that the command can be executed correctly the next time it is run. Here's an example of this from https://docs.rockylinux.org/gemstones/bash_stub/:

# Check for missing parameter.
# Display usage message and exit if it is missing:

if [ "$1" = "" ]
then
    echo "$PGM : parameter 1 is required"
    echo "Usage: $PGM param-one"
    exit
fi

[sspencerwire]

This is what I was referring to before. The difference is that the command would respond with a "usage" message if the argument did not exist. Think of this as a script with commands that are good for a lot of things, but require input from the user at the time of execution. This could be done with the read command and a prompt within the script. Depends on how you want your script to operate. Both methods should be explored.