anderen Parameter des Befehls WrappingBash - Wrapping einen anderen Befehl der Parameter
Ich habe einen Befehl tool1
, die Argumente auf diese Weise analysiert:
#!/usr/bin/env bash
# ...
while [[ $# -ge 1 ]]
do
key="$1"
case $key in
-o|--option)
OPT="$2"
shift
;;
-u|--user)
USR="$2"
shift
;;
-*)
echo -e "Unrecognized option: \"$key\"" && exit 1
;;
*)
OTHERS+=("$1")
;;
esac
shift
done
# ...
ich tool2
haben, die tool1
nennt. Daher muss tool2
Parameter an tool1
übergeben werden. nur durch tool2
#!/usr/bin/env bash
# ...
while [[ $# -ge 1 ]]
do
key="$1"
case $key in
-O|--option2)
opt2="$2"
shift
;;
-u|--user)
USR="$2"
OTHERS+=("-u $2")
shift
;;
-*)
echo -e "Unrecognized option: \"$key\"" && exit 1
;;
*)
OTHERS+=("$1")
;;
esac
shift
done
## Call tool1 with other parameters to pass
bash tool1.sh ${OTHERS[@]}
# ...
Zusammengefasst --option2
ist eine Option verwendet: Es kann auch die gleichen Parameter (--user
)
tool2
aussieht verarbeiten müssen. --user
ist beiden Tools gemeinsam und wird möglicherweise auch von verwendet, bevor tool1.sh
aufgerufen wird. Aus diesem Grund muss in diesem Beispiel --user
explizit an tool1
dank dem Array OTHERS
übergeben werden.
Ich würde gerne über mögliche und/oder alternative Möglichkeiten im Umgang mit solchen Parameter Redundanzen wissen. Eine Methode, die mir helfen würde, die erwarteten Parameter/Optionen eines anderen Tools zu umhüllen, ohne die Zeilen in Bezug auf das Parsen solcher redundanter Parameter/Optionen kopieren/einfügen zu müssen.
Warum benutzen Sie 'getopt' nicht? – jehutyy
Für Portabilitätsprobleme. 'getopt' ist nicht standardisiert. 'getopts' unterstützt jedoch keine langen Optionen. – kaligne
Was ist, wenn eine Option im zweiten Skript ist, aber nicht im ersten? Auch wenn beide Skripte auf einen Parameter einwirken können, wie ist es redundant? – 123