On Thu, 18 Mar 2021 15:11:27 -0500 Bruce Dubbs <bruce.du...@gmail.com> wrote:
> On 3/18/21 1:32 PM, Scott Andrews wrote: > > Although the init-functions and rc scripts currently run properly, > what you propose below is a bit cleaner. > > I'll note that the scripts were initially written to be posix > compatible (no bashisms) and changing that is a different > discussion. That's not correctly implemented in the rc, console, > ifup, and ifdown scripts because of the use of == for comparisons. > > > example follows......... > > > > remove SCRIPT_STAT from init-functions > > > > Correctly write check_script_status in rc > > > > function check_script_status { > > 'function' is not posix compatible. It's not in any current script. http://www.gnu.org/software/bash/manual/html_node/Shell-Functions.html 3.3 Shell Functions Shell functions are a way to group commands for later execution using a single name for the group. They are executed just like a "regular" command. When the name of a shell function is used as a simple command name, the list of commands associated with that function name is executed. Shell functions are executed in the current shell context; no new process is created to interpret them. Functions are declared using this syntax: fname () compound-command [ redirections ] or function fname [()] compound-command [ redirections ] This defines a shell function named fname. The reserved word function is optional. If the function reserved word is supplied, the parentheses are optional. The body of the function is the compound command compound-command (see Section 3.2.5 [Compound Commands], page 10). That command is usually a list enclosed between { and }, but may be any compound command listed above, with one exception: If the function reserved word is used, but the parentheses are not supplied, the braces are required. compoundcommand is executed whenever fname is specified as the name of a command. When the shell is in posix mode (see Section 6.11 [Bash POSIX Mode], page 102), fname must be a valid shell name and may not be the same as one of the special builtins (see Section 4.4 [Special Builtins], page 72). In default mode, a function name can be any unquoted shell word that does not contain ‘$’. Any redirections (see Section 3.6 [Redirections], page 35) associated with the shell function are performed when the function is executed. A function definition may be deleted using the -f option to the unset builtin (see Section 4.1 [Bourne Shell Builtins], page 44). Anyway the script in question is not POSIX anyway, and it is not run in Bash POSIX Mode so your point is mute https://www.gnu.org/software/bash/manual/html_node/Bash-POSIX-Mode.html #!/bin/bash ######################################################################## # Begin rc # # Description : Main Run Level Control Script # # Authors : Gerard Beekmans - ger...@linuxfromscratch.org # : DJ Lucas - d...@linuxfromscratch.org # Update : Bruce Dubbs - bdu...@linuxfromscratch.org # # Version : LFS 7.0 # ######################################################################## also see https://www.tutorialspoint.com/unix/unix-shell-functions.htm > > > local script=${1} > > SCRIPT_STAT="0" > > if [ ! -f ${script} ]; then > > log_warning_msg "${script} is not a valid file." > > SCRIPT_STAT=retval="1" > > The = sign in scripts is overloaded. Is it a comparison or an > assignment? I've never seen the above in a script before, although > it is used in C/C++. We should not use it in a script. SCRIPT_STAT=retval="1" should read SCRIPT_STAT="1" typo by me as I was typing this into claws instead of coping and pasting from the server the reworked script is currently running on. > > > fi > > if [ ! -x ${script} ]; then > > log_warning "${script} is not executable." > > SCRIPT_STAT=retval="1" > > as above > > > fi > > return > > } > > > > # Check script for file and executable > > check_script_status > > if [ "1" = ${SCRIPT_STAT} ]; then continue; fi > > > > That fixes the issue but I would rewrite check_script_status to > > return true or false then then do this > > > > function check_script_status { > > as above > > > local script=${1} > > local retval="0" > > if [ ! -f ${script} ]; then > > log_warning_msg "${script} is not a valid file." > > retval="1" > > fi > > if [ ! -x ${script} ]; then > > log_warning "${script} is not executable." > > retval="1" > > fi > > [ "0" = ${retval} ] && return 0 || return 1 > > } > > > > if [ check_script_status ]; then continue; fi > > > > or simply > > > > [ check_script_status ] || continue > > I prefer the more specific: > > [ check_script_status = 0 ] || continue > > From a style standpoint, there should always be an explicit test > when using [ ]. Nope from the gnu bash reference manual test [ test expr Evaluate a conditional expression expr and return a status of 0 (true) or 1 (false). Each operator and operand must be a separate argument. Expressions are composed of the primaries described below in Section 6.4 [Bash Conditional Expressions], page 92. test does not accept any options, nor does it accept and ignore an argument of -- as signifying the end of options. When the [ form is used, the last argument to the command must be a ]. So it could have been written: test check_script_status = 0 || continue It is exactly the same. I stated this was an example, not a finished product. -- http://lists.linuxfromscratch.org/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page Do not top post on this list. A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? http://en.wikipedia.org/wiki/Posting_style