【发布时间】:2015-04-22 17:05:49
【问题描述】:
更好的 BASH?
我对 BASH 非常缺乏经验,但最近我一直在使用它来执行我的程序代码,以便对实验室中的各种实验的数据进行批处理。
我已经使用 C/C++ 好几年了,所以我认为自己是“相当称职”的程序员。
...在 bash 方面并非如此...
我意识到 BASH(或至少 SH 或其前身)可能从 1971 年就已经存在,因此非常古老,因此可能有 10^6 + 1 个原因说明语法是这样的(向后兼容性是其中之一),但是,今天我尝试这样做:
for DEPTH in {$START..$END}
do
...
done
这不起作用,因为在这种情况下,{$START..$END} 的计算结果为 {9..9}(字符串,而不是扩展 '9')...
为了解决这个问题,我必须执行以下操作:
for DEPTH in $(eval echo "{$START..$END}")
do
...
done
这……呃……很奇怪。比 Matlab 偶尔毛茸茸的语法更重要。 (我不认为这是一个太有争议的声明,我的假设是任何使用像 Fortran、C 或 Python(或任何其他)这样的语法一致语言的人都可能同意这真的不是很好。除此之外否则,要完成这么简单的任务,需要输入 (IMO) 太多了。
我知道 BASH 现在支持类似 C 的语法:
for (( c=$START; c<=$END; c++ ))
但这并没有好很多...主要是因为我们有一些奇怪而神秘的双括号,现在我们使用像 <= 和 ++ 这样的东西不能在其他任何地方使用(在 BASH 脚本中) 据我所知。
还有一些其他的东西让我很困惑,比如== 用于字符串比较,但-eq 用于数字比较。 (同样,与上述评论相关。)这里发生了什么?
所以我的问题是,有没有一个“更好的 BASH”在语法上更“抛光”?为什么 BASH 会坚持这种疯狂的做事方式?那 10^ + 1 个原因是什么?
我知道 tcsh/csh,但我不认为foreach n ( 1 2 3 4 5 ) 有很大改进,所以我一直在使用 BASH,因为至少它被广泛使用,所以当我遇到这些“语法”时,我可以轻松获得帮助坑洼”。
【问题讨论】:
-
{a..b}问题来自 Bash 试图包含来自csh的功能。 :( -
如果你觉得 bash 语法笨拙(我不一定不同意你的观点),我想你会发现 csh/tcsh 更糟糕。它使一些简单的事情变得简单,但总体而言,它的语法远没有那么连贯。必填链接:perl.com/doc/FMTEYEWTK/versus/csh.whynot
-
zsh 人们喜欢 zsh 的原因之一和至少一些 bash 人(包括我自己)喜欢 bash 的原因是一样的:当旧的行为很愚蠢时,zsh 会破坏向后兼容性。我的阵营认为有时候为了兼容性而做一些愚蠢的事情是值得的,但它肯定不是一刀切。
-
顺便说一句——字符串比较应该是
=,而不是==,如果你想养成与POSIX兼容的习惯;==是一个 bash 扩展。 -
Bash 和 C/C++ 使用不同的范例,所以这有点像问为什么 Haskell/Prolog 疯狂地不允许你增加变量。 Bash 的评估模型实际上更像是一个递归的单通道宏处理器。