tcsh，shebang和clojure

starwing83

恩，今天和OwnWaterloo发生了一场争执。争执到后来我好像都没啥自信了，所以想看看大家对于这个问题有什么看法。

@Ager @OwnWaterloo

事情最开始是这样的，OW想用clojure写脚本，使其能独立运行。UNIX上面最简单的办法是shebang，即：

1. 
   
2. #!/usr/bin/env java clojure.main
   
3. 
   
4. (prn "Hello World")
   

复制代码

shebang是一种能让文本文件被当做可执行文件执行的方式，shell如果发现一个文件的头两个字符是#!，它会提取后面的所有参数，并带上这个文本文件的文件名来组成一个命令行并执行，比如上面这个程序假设叫test，shell会组装一个命令行“/usr/bin/env java clojure.main ./test”，然后执行这个命令行。最终的结果就是好像这个文本文件能被直接执行一样。这个技术叫做shebang。

但是，bash的shebang有问题，它会将这个程序在shebang中提取的所有参数都当做一个参数来传递给实际的程序，比如说上面这个命令行，env程序实际收到的参数是"java clojure.main"和"./test"，而env显然不知道这个带空格的"java clojure.main"是何方神圣，自然就执行失败了。

OwnWaterloo觉得，clojure至少应该提供一个标准的可执行的文件（可能是shell脚本，或者其他的什么的），这个文件可以作为直接执行clojure程序的工具。假设这个文件叫clj，那么shebang可以这么写：

1. 
   
2. #!/usr/bin/env clj
   
3. 
   
4. ....
   

复制代码

在这种情况下，clj是第一个参数，./test是第二个参数，env会在环境中查找clj的位置并执行，就不会有问题了。OwnWaterloo觉得，即使是不提供这么一个工具，哪怕是给一个标准化的名字，也可以让这个工作变得轻松。clojure这么做很不考虑那些希望让clojure的程序能够当做脚本独立运行的人的感受。

我个人觉得clojure本身是基于java-vm的一种语言。它本身其实并不考虑作为脚本这么一个用途，所以不提供这样的命名约定什么的其实也是合理的。不过OwnWaterloo这个观点似乎有点“王垠”化，用他的原话说：

OwnWaterloo 2:33:24
只有自己遇见的需求才是需求， 其他人的需求就是无理取闹？
其他人不以自己的习惯做法并并且没达到目标， 就一定是其他人的方法不对？
你什么时候变成王垠那种货色了？

必须提到的是，OwnWaterloo自己已经提供了一个方案来做这件事情，其实就是“可以同时被当做shell脚本和clojure程序的脚本”

1. 
   
2. #!/bin/sh
   
3. 
   
4. ":"; /usr/bin/env java clojure.main "$0" $*
   
5. 
   
6. (prn "Hello World")
   

复制代码

我在考虑这么一个问题，就是软件本身的设计目的，和用户的需求不明确的时候，用户到底应该怎么办。我对OwnWaterloo说，你应该去clojure邮件列表发言，说明这个问题，而不是跟我讨论，因为这完全没有用。不过我也不知道OwnWaterloo自己的看法是如何，大概是“我已经想到一种解决方案了，我为什么要等待别人去解决这个问题呢？”

我自己其实也遇到了这种关于“需求”的情况。我用tcsh，tcsh本身的shebang我很少用（其实我是根本就没用过，脚本我都是直接用Vim执行，或者在命令行会写解释器来执行，很少会直接执行脚本），所以在测试的时候，我发现tcsh的windows版本竟然不认shebang，然后经过了Stack Overflow提问、自行编译等等方式最后都没有解决这个问题。这本质上依然是“软件的开发者没有满足使用者的需求”。我认为，我遇到的情况是不合理的，因为作为一个shell，在任何系统上行为一致应该是很有必要的。tcsh不支持shebang的原因是它支持Windows式的“按照后缀名判断文件类型”，可是在这之前，先打开文件并检测一下#!应该是很简单的。而且tcsh的源代码中的确也表示Win32移植版本应该支持HASHBANG特性。

我认为我遇到的现象和OwnWaterloo遇到的现象是不一样的。Clojure的官方主页上完全没有提到过支持在shell中直接执行clojure程序的做法。而tcsh作为一个shell，是必须满足POSIX对shell的要求的——即至少在某种情形下识别shebang。所以这并不是一种情况。对clojure来说，这种用途是作者“完全没有考虑过，或者没有考虑透彻的使用情景”，而对tcsh来说，这应该是“宣称的功能没有达到”。

因为#字符在clojure中并不是注释符。可以发现clojure的确是对clojure程序中包含shebang做出了支持。问题在于这个支持不全面，并不能保证clojure一定能够通过shebang调用到。一方面，shell不支持shebang参数分割是一个缺陷，另一方面，clojure本身没有提供独立的可执行的工具来直接执行clojure程序也是一个问题。两者共同造成了clojure无法通过shebang执行的情况。

这其实是另一个话题了，在两个软件的缺陷同时造成一个困难的时候，谁应该为这个困难负责？OwnWaterloo认为应该是clojure，我不知道这是基于什么情况的考虑，反正我觉得应该负责的是shell。因为归根结底，是shell的shebang不完善造成的，clojure提供独立执行文件的方式只是一个work around而已，而shell的shebang仍然不完善。

这次争吵让我正视了关于软件开发中，需求和设计目标不匹配的一系列问题。包括没有完成设计目标、出现了设计者没有考虑过的情况、数个应该共同协助完成目的的特性之间的不协调等等问题。我想知道大家的看法。


我想知道：
1. 软件的开发者选择软件的应用场景，并决定软件支持的限度（如clojure不提供独立执行文件），究竟是不是开发者自己的自由。
2. 软件没有达到宣称的目标，和软件在自己没考虑过的范畴没有达到设计目的，是不是同样的情况。
3. 对于遇到这个问题的用户的抱怨，向其说明“产品并没有考虑在这种情况使用，这是产品的自由”，是否是正确的行为。
4. 如果你是使用者，你在向人抱怨自己的“正常”使用没有达到预期的目标，反而需要自己去想work around，并埋怨其设计糟糕的时候，如果有人提出相反意见，你是否能保持冷静并考虑。
5. clojure究竟有没有考虑作为shebang程序使用？是设计者考虑不周，还是设计者的shell本身是支持参数分割的，还是设计者自己私人使用了一个独立的可执行驱动呢？
6. 对待这种情况，作为抱怨者，和作为被抱怨者，以及作为聆听抱怨者，应该采取什么样的行为是合适的？

希望能和大家深入讨论这个问题。

Ager

@starwing83
@OwnWaterloo

用shebang、用java、用clojure，都是可以的，这是在我的机器（zsh）上做的测试：

ager@gnugcc.org:~/cljs $ cat hello-sw-ow.clj #^:shebang '[ exec java -cp "/usr/share/java/clojure.jar" clojure.main "$0" -- "$@" ] ;  FILE : hello-sw-ow.clj (prn "大虾们啊 —— 这样行不行啊？") (prn (+ 1 2 3 4 5 6 7)) ;  END ager@gnugcc.org:~/cljs $ chmod +x *.clj ager@gnugcc.org:~/cljs $ ./hello-sw-ow.clj "大虾们啊 —— 这样行不行啊？" 28 ager@gnugcc.org:~/cljs $

以上，仅供参考，呵呵 —— ：）

Ager

@starwing83
@OwnWaterloo



有美女了，还要env干啥？

呵呵……

KanonInD

LZ用的clojure是哪个版本？

1. k@myhost:/home/k> pacman -Ql clojure                                                                       12-10-09 9:11
   
2. clojure /etc/
   
3. clojure /etc/profile.d/
   
4. clojure /etc/profile.d/clojure.sh
   
5. clojure /usr/
   
6. clojure /usr/bin/
   
7. clojure /usr/bin/clj
   
8. clojure /usr/share/
   
9. clojure /usr/share/clojure/
   
10. clojure /usr/share/clojure/clojure.jar
    

复制代码

1. 
   
2. k@myhost:/home/k> pacman -Qi clojure                                                                       12-10-09 9:12
   
3. 名称　　　： clojure
   
4. 版本　　　： 1.4.0-1
   
5. URL地址　： http://www.clojure.org/
   
6. 软件许可　： CPL
   
7. 软件组　　： 无
   
8. 提供　　　： 无
   
9. 依赖于　　： java-environment  sh
   
10. 可选依赖　： rlwrap: for a friendlier shell with readline support
    
11. 要求被　　： 无
    
12. 冲突与　　： 无
    
13. 取代　　　： 无
    
14. 安装后大小：3384.00 KiB
    
15. 打包者　　： Alexander Rødseth <rodseth\atgmail.com>
    
16. 架构　　　： any
    
17. 编译日期　： 2012年04月18日 星期三 23时43分40秒
    
18. 安装日期　： 2012年07月21日 星期六 14时27分54秒
    
19. 安装原因　： 单独指定安装
    
20. 安装脚本　： 是
    
21. 描述　　　： LISP dialect for the JVM
    

复制代码

huxk_cu

有次在一个系统下遇到一个python脚本 #!/usr/bin/env python 这样不行 改成#!/usr/bin/python倒是可以。因为环境没有配置。

个人觉得这些问题都无解，如果是软件公司的话，领导应该多找几个美女去攻关。哈哈。

用户很多时候也是被惯出来的。开发很多时候也是被逼出来的。

Ager

KanonInD 发表于 2012-10-09 09:19
LZ用的clojure是哪个版本？

大虾你也喜欢用 Arch Linux 呀？

fender0107401

除了用Octave写计算程序以外，对脚本编程基本上没啥兴趣。

mirnshi

除了简单的工作，用shell脚本，复杂都用python或php解决了。python和php都能很好地支持shebang。既然不支持，只能说明用户没这个需求或者开发者没有这个意图，因为支持shebang是非常简单的事情。在很多解释语言里，#是注释，很容易解决，但在不是注释，需要特别处理#!。

对于不能拆解的参数：java clojure.main ./test，应该算是env的缺陷，env的本意是设置环境，然后运行一个程序，给一个空格间隔的字符串，用意很明显，就是这个字符串包含程序及其参数。Linux下的env参数比FreeBSD的少，FreeBSD的支持将传过来的参数分拆后再执行。

__BlueGuy__

笑而不语 ，  

gvim

完了，又干上了。。。应该猩猩相吸啊！