小伙伴碰到一起奇怪的事故，从gitlab上拉取的docker镜像项目，在本地开发机上进行docker build后，启动容器会报错如下：
exec /app/run.sh : no such file or directory/app/run.sh文件是ENTRYPOINT启动的，注释掉ENTRYPOINT，直接进入容器后可以看到 /app/run.sh好好在那儿，文件的可执行权限也没有问题。那么问题在哪里？
其实这个问题很简单，但由于容器启动时的错误信息不全，产生了误导，让人误以为找不到sh脚本文件。
如果先启动容器，在容器内再手工执行 /app/run.sh，会看到报错信息略有不同。实际报错的是sh脚本的第一句：
#!/bin/bash那么是因为容器内缺失 /bin/bash解释器吗？也不是，基础镜像没有问题，/bin/bash好好的存在。
最关键的是，同样的git项目拉取到的sh脚本和Dockerfile在另外一台开发机上进行镜像编译和运行是没有问题的。
仔细观察，发现sh脚本文件在不同的机器上，有一点点不同：换行符。
出问题的开发机上，脚本换行符是Windows换行符CRLF，所以这个脚本进入Docker容器中，第一行变成了：
#!/bin/bash【看不见的CRLF】那执行脚本的时候，LF会被认为是Linux换行符，而解释器名称就成了"/bin/bashCR"，肯定找不到，所以就会报错"no such file or directory"。
这个报错的真实含义是"找不到脚本的解释器"，而不是找不到脚本本身。
那么为什么脚本文件的换行符被改变为CRLF呢，其实是git的core.autocrlf特性搞的鬼。参考 https://blog.upx8.com/3184
为了避免这种问题，有两个建议：
1，所有的开发机上，统一git的autocrlf设置，避免其为true。
2，VSCode上安装code-eol插件，显式的体现出每个文件的换行符，这样可以比较直观的察觉到问题。