Debian Stretch下Symfony bin目录ls显示脚本内容而非文件名问题

先明确一下你的问题场景：

在Debian Stretch的Atlassian Pipelines环境中，执行php composer.phar update后，查看Symfony项目的bin/目录时，ls -la输出的居然是bash脚本的内容而非文件名；但本地手动执行完全相同的命令却一切正常，你怀疑是Composer在特定场景下的bug导致返回文件内容而非文件名。

结合我遇到过的类似CI环境问题，给你几个排查和解决的方向：

• 先检查文件类型与权限差异
  Atlassian Pipelines的容器环境和本地机器的权限、文件系统配置可能有不小差异。Symfony的bin/console这类文件通常是可执行脚本或者符号链接，你可以在Pipelines中执行file bin/console，把输出和本地环境的结果对比，看文件类型是否一致。如果在Pipelines里它变成了普通文本文件而非可执行脚本/符号链接，那大概率是Composer在CI环境下的文件处理出了问题。

• 清理Composer缓存，统一版本
  CI环境的Composer缓存有时候会引发奇怪的问题，建议在Pipelines脚本里先加一步清除缓存：

  php composer.phar clear-cache
  

  然后再执行update。另外，一定要确认Pipelines里的Composer版本和本地完全一致——不同版本的Composer在处理bin目录文件时可能有逻辑差异，执行php composer.phar --version对比两边的版本号，不一致的话就指定版本安装。

• 排查CI脚本的命令与环境变量
  看看你的Pipelines脚本里，composer update前后有没有修改文件权限、设置特殊环境变量的操作？比如是否误设置了COMPOSER_BIN_DIR这类会影响Composer生成bin文件路径的变量？可以在脚本里加env命令输出所有环境变量，和本地对比找差异。另外，如果你在CI里用了--no-plugins或者--no-scripts参数执行update，也可能导致Symfony Flex插件无法正常生成bin目录的文件，这时候就得去掉这些参数试试。

• 手动修复Symfony bin目录文件
  如果是Symfony Flex生成bin文件的过程出了问题，可以在composer update之后手动重新生成：

  php composer.phar dump-autoload --optimize
  

  要是确认是符号链接丢失，也可以手动重建：

  cd bin && ln -sf ../vendor/symfony/framework-bundle/Resources/bin/console console
  

• 验证Composer的异常行为
  如果上面的方法都没用，就开启Composer的详细日志来抓问题：

  php composer.phar update -vvv
  

  把CI环境下的日志和本地执行的日志对比，重点看处理bin目录文件的部分。如果确实发现Composer在写入文件时把内容当成文件名处理的异常逻辑，就可以去Composer的官方仓库提交issue，带上你的环境信息、日志和复现步骤。

内容的提问来源于stack exchange，提问作者Your Common Sense