I copied /etc/init.d/functions from a Redhat based system onto an embedded project and got
a "syntax error ( Bad Substitution ) on this line:
[ -z "${p//[0-9]/}" -a -d "/proc/$p" ] && pid="$pid $p"

when I do service crond start.

I found one redhat change which I put in ( commented 4 lines, added to "to here" ) , didn't help.

Whole function below:

__pids_var_run() {
local base=${1##*/}
local pid_file=${2:-/var/run/$base.pid}

pid=
if [ -f "$pid_file" ] ; then
local liine p

#https://fedorahosted.org/initscripts...b5fbb9a9e0b745
# read line < "$pid_file"
# for p in $line ; do
# [ -z "${p//[0-9]/}" -a -d "/proc/$p" ] && pid="$pid $p"
# done
while : ; do
read line
[ -z "$line" ] && break
for p in $line ; do
echo $p
[ -z "${p//[0-9]/}" -a -d "/proc/$p" ] && pid="$pid $p"
done
done < "$pid_file"
# to here
if [ -n "$pid" ]; then
return 0
fi
return 1 # "Program is dead and /var/run pid file exists"
fi
return 3 # "Program is not running"
}

Ideas? Thanks, dB

Hi,

Check what that line expands to when executing the script

Are you using bash or any other shell?

...or make the Bourne Again code Bourne shell compatible.

I would be querying what this code does?

If I am reading this correctly, take the variable p and replace all occurrences of nothing "//"
with a boundary "[0-9]" and then an extra slash at the end that should not be there.

I could be wrong, but if this was copied from any other system, I am unsure how this would have ever worked?

In bash it removes all the digits from the valueAccording to the GNU Bash Reference, it takes the variable p and replaces all occurrences of 0 to 9 with the null string. The trailing / is optional so ${p//[0-9]} would be functionally equivalent.

My apologise ... was in my own little world and looked at first reference:

And jumped to conclusions before reading:

Thanks for the re-education in RTFM <sheesh>

MMC, NP

That double / to indicate a global replacement is neither intuitive nor consistent with other usage AFAIK -- and making the final / optional doesn't help legibility. IMHO ${varname/match/replacement/g} would have been a better choice but there may, of course, have been factors in the decision that I wot not of.

Thanks, all - it was running under another shell; its fine in bash.