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
