fff-vpn-select: improve logic for fastd start/stop #13

Closed
adschm wants to merge 1 commits from adschm/firmware:vpnlogic into master
2 changed files with 6 additions and 4 deletions

View File

@ -1,7 +1,7 @@
include $(TOPDIR)/rules.mk
PKG_NAME:=fff-vpn-select
PKG_RELEASE:=5
PKG_RELEASE:=6
PKG_BUILD_DIR:=$(BUILD_DIR)/$(PKG_NAME)

View File

@ -52,10 +52,12 @@ if [ -s "$hoodfile" ]; then
# fastd start/stop for various situations
pidfile="/tmp/run/fastd.fff.pid"
if [ "$(ls /etc/fastd/fff/peers/* 2>/dev/null)" ]; then
([ -s "$pidfile" ] && [ -d "/proc/$(cat "$pidfile")" ]) || /etc/init.d/fastd start
if [ -s "$pidfile" ] && [ -d "/proc/$(cat "$pidfile")" ]; then
jkimmel marked this conversation as resolved Outdated

[ -s "$pidfile" ] && [ -d "/proc/$(cat "$pidfile")" ] sollte aequivalent zu [ -s "$pidfile" -a -d "/proc/$(cat "$pidfile")" ] sein und spart einen aufruf an test

`[ -s "$pidfile" ] && [ -d "/proc/$(cat "$pidfile")" ]` sollte aequivalent zu `[ -s "$pidfile" -a -d "/proc/$(cat "$pidfile")" ]` sein und spart einen aufruf an test

shellcheck sagt "Prefer [ p ] && [ q ] as [ p -a q ] is not well defined."

shellcheck sagt "Prefer [ p ] && [ q ] as [ p -a q ] is not well defined."
# Stop if service is running but no peers present
[ "$(ls /etc/fastd/fff/peers/* 2>/dev/null)" ] || /etc/init.d/fastd stop

Gibt es einen Grund

[ "$(ls /etc/fastd/fff/peers/* 2>/dev/null)" ] || ...

statt einfach direkt

ls /etc/fastd/fff/peers/* 2>/dev/null || ...

zu nutzen?

Gibt es einen Grund `[ "$(ls /etc/fastd/fff/peers/* 2>/dev/null)" ] || ...` statt einfach direkt `ls /etc/fastd/fff/peers/* 2>/dev/null || ...` zu nutzen?

Ich fand das auch ekelig, habe dann gegoogled und tatsächlich wird genau das bestehende als Optimum empfohlen. Bei ls ohne [] muss man ja noch den Output unterdrücken ... Außerdem bin ich mir nicht sicher, wie ls mit return values umgeht, wenn man wildcards verwendet ...

Ich fand das auch ekelig, habe dann gegoogled und tatsächlich wird genau das bestehende als Optimum empfohlen. Bei ls ohne [] muss man ja noch den Output unterdrücken ... Außerdem bin ich mir nicht sicher, wie ls mit return values umgeht, wenn man wildcards verwendet ...

ls /etc/fastd/fff/peers/* &>/dev/null || ...

scheint zu funktionieren, aber ob das jetzt besser ist?

`ls /etc/fastd/fff/peers/* &>/dev/null || ...` scheint zu funktionieren, aber ob das jetzt besser ist?

also $(...) wuerde meines wissens eine neue subshell aufmachen. Die wuerden wir uns mit dem Ansatz sparen.

also `$(...)` wuerde meines wissens eine neue subshell aufmachen. Die wuerden wir uns mit dem Ansatz sparen.

Die Sach ist ganz simpel. ls wirft bei einem leeren Verzeichnis keinen Fehler. Mit * hinten dran bekommen wir den Fehler weil das globbing nicht funzt. D.h. nicht unbedingt, dass das Verzeichnis leer ist. Darum der Test auf "leere" Ausgabe von ls.
In unserem Fall koennte es sogar besser sein, den * wegzulassen.

Die Sach ist ganz simpel. ls wirft bei einem leeren Verzeichnis keinen Fehler. Mit * hinten dran bekommen wir den Fehler weil das globbing nicht funzt. D.h. nicht unbedingt, dass das Verzeichnis leer ist. Darum der Test auf "leere" Ausgabe von ls. In unserem Fall koennte es sogar besser sein, den * wegzulassen.
else
([ -s "$pidfile" ] && [ -d "/proc/$(cat "$pidfile")" ]) && /etc/init.d/fastd stop
# Start if service is not running but peers are present
[ "$(ls /etc/fastd/fff/peers/* 2>/dev/null)" ] && /etc/init.d/fastd start
fi
fi
exit 0