我一直试图找到一种方法来将选项文件提取到我的案例脚本中,如下所示:
主文件
case "$1" in
. options
esac
选项文件
#options file
1 ) do something
2 ) do something else
有没有人有任何想法,因为我得到的只是'解析错误' 在此先感谢您的帮助
答案 0 :(得分:1)
在行之间阅读,真正想要做的是能够从外部源文件添加$1
的不同值的处理程序 - 可能是任意数量的此类文件,没有他们彼此了解。
这是一件非常好的事情。不要使用case
来执行此操作。
请考虑以下事项:
# base-options
do__1() { echo "doing something"; }
do__2() { echo "doing something else; }
......也许是一个单独的文件:
# extra-options
do__foo() { echo "doing yet another thing"; }
现在,您可以从主文件中获取所有这些内容:
# this loop will source in both base-options and extra-options
for f in *options; do
source "$f"
done
# and here, if we *have* a command -- either as a shell function or an external command --
# corresponding to our $1, we run that command.
if type "do__$1" >/dev/null; then
cmd="do__$1"; shift
"$cmd" "$@"
else
echo "Handler for $1 not found" >&2
exit 1
fi
采用上述方法也意味着您的处理程序根本不需要是shell函数!如果你有一个名为do__1
的可执行文件,只要它在你的PATH中就会被type
找到,所以你可以用你想要的任何语言编写处理程序 - 你没有锁定自己进入bash。
这与git
处理子命令的方式密切相关 - 请参阅处理git-foo
命令的所有git foo
可执行文件。这是一种常见的做法,也是一种很好的做法。使用它。
答案 1 :(得分:0)
以下工作正常:
# options
case "$1" in
1) something ;;
2) something else ;;
esac
并且,在原始代码中:
. options "$@"
...所有与您尝试做的不同的是,您要向options
添加页眉和页脚。
.
(或source
)本身就是一个命令。如果你不能将任意命令放在某个位置,那么就不能在那里放置源命令。
由于你的选项文件必须写成知道它会进入case
语句,为什么不把case
和esac
行放在里面它?这不会降低灵活性:$1
命令本身可以覆盖source
:
. my.sh "$@" # this passes the current arguments through...
,而:
# this still works without changing options
. my.sh "$foo" # this passes $foo as $1
作为一个非常丑陋,糟糕的黑客,它会破坏一堆调试功能,你可以做一些事情:
# Don't do this; it'll cause headaches later.
eval 'case "$1" in '"$(<options)"'; esac'
答案 2 :(得分:0)
首先需要与$1
匹配的内容,否则case
语句的重点是什么?
case "$1" in
options) . options ;;
things) echo "What should I do with things?" ;;
*) echo "I don't know what you want" ;;
esac
看到更新后,正确的做法是将整个 case语句包装在外部文件中定义的函数中。
handle_options () {
case "$1" in
1 ) do something ;;
2 ) do something else ;;
esac
}
然后从源文件的脚本中调用该函数。
. somefile
handle_options "$1"