Windows环境下Dockerfile复制shell脚本到/usr/bin报错兼容方案

首先明确一个基础逻辑：Dockerfile中所有操作的路径，都是构建生成的容器内部的文件系统路径，和你宿主机运行的是Windows还是Linux没有任何关联。你用的ruby:2.6.2是Linux基础镜像，容器内部天生就存在/usr/bin/目录，完全不需要在宿主机上找对应等效路径，你之前猜测的宿主机路径对应关系是完全错误的。

出现exec /usr/bin/entrypoint.sh: no such file or directory报错，绝大多数情况是两个问题叠加导致的：

1. 你在Windows系统下编辑的entrypoint.sh使用了Windows默认的CRLF换行符，而Linux容器内只识别LF换行符。换行符不匹配会导致脚本第一行的shebang声明#!/bin/bash被系统识别为寻找/bin/bash\r（末尾带隐藏的回车符）这个不存在的解释器，直接抛出文件不存在的错误。
2. 你的Dockerfile中ENTRYPOINT指令没有写脚本的绝对路径，靠系统PATH变量解析路径时存在偶发的解析失败问题。

不需要修改容器内的/usr/bin/路径，这套配置本身在Linux、macOS、Windows宿主机下都可以正常运行，只需要做以下修正：

• 修正shell脚本换行符
  用VS Code打开entrypoint.sh，点击编辑器右下角显示的CRLF标识，在弹出的选项中选择LF后保存文件，确保脚本使用Linux兼容的换行格式。
  为了避免后续Git拉取代码时自动把sh脚本转成CRLF，可以在项目根目录新建.gitattributes文件，加入如下配置：

  *.sh text eol=lf
  

• 修正Dockerfile的ENTRYPOINT指令，使用绝对路径避免解析歧义，把原有配置：

  ENTRYPOINT ["entrypoint.sh"]
  

  修改为：

  ENTRYPOINT ["/usr/bin/entrypoint.sh"]
  

• 重新构建镜像时跳过缓存，避免旧的错误文件残留在镜像层中，执行如下命令：

  docker-compose build --no-cache
  

  构建完成后再执行docker-compose up即可正常启动。

绝对不要把Dockerfile里的容器内路径改成Windows格式的C:\Program Files这类路径，Linux容器内部根本不识别Windows盘符规则，改完之后无论在什么宿主机环境下都会运行失败。

内容的提问来源于stack exchange，提问作者sigil