批改留学生期末试卷，测试其所提交的脚本程序，发现一个Perl脚本殊为奇怪。根据脚本自带的使用用法反馈行及脚本Shebang行下的注释与提示，其使用方式为 perl script.pl seq1 seq2。于是PUTTY登录到服务器相应目录，输入./script.pl seq1 seq2测试，结果提示：No such file or directory。学生却说，在自己的Windows系统上测试了，正常工作。看起来，遇到的问题是，脚本非要或者说只能把命令行参数理解为文件名或目录名，而不把其做为普通字符串。问题出在哪呢？

都知道，perl自身有系列使用参数（相当于Eclipse/EPIC开发环境RUN设置中的Perl arguments），在命令行窗口输入perl --help就可以看个大概。此外，Perl脚本自身也可以从命令行窗口接收一系列程序参数（相当于Eclipse/EPIC开发环境RUN设置中的Program arguments），并存在特殊数组@ARGV中。例如./script.pl seq1 seq2命令行执行后，seq1和seq2传递到脚本script.pl的@ARGV中分别对应$ARGV[0]和$ARGV[1]。按理说，无论是文件名、目录名还是字符串都可以传递，怎么现在似乎就只能按文件名或目录名理解，而不能按字符串传递了？怪的是在本地Windows系统上测试都可以的，到远程Linux服务器上测试就不行了。看源代码中读取程序参数的部分，也没有发现什么问题。

这时忽然发现：在本地Windows上，由于script.pl不是可执行文件，所以，严格按perl script.pl seq1 seq2进行，而在远程Linux服务器上，是按./script.pl seq1 seq2进行的。马上在远程Linux服务器按perl script.pl seq1 seq2进行，果然一切顺利，不再反馈No such file or directory。如此看来，问题的原因一定就在第一行（Shebang行）里。一看，果然不是传统的#!/usr/bin/perl，而是#!/usr/bin/env perl。删除env ，按./script.pl seq1 seq2测试，一切正常。看来，使用/usr/bin/env perl，固然可以帮助脚本在系统环境变量相应目录里找到存在的perl解释器，避免perl没有安装在/usr/bin/目录就不能运行的情况，但同样会面临各种个性化、兼容性问题，甚至引起如这里所提到的新问题。