umask不赋予执行权限，只限制默认权限：新文件默认666（无x），故脚本创建后需chmod +x才可./执行；bash script.sh仅需读权限，不受umask影响。
Linux文件权限掩码（umask）本身不直接影响Shell脚本的“执行”行为，但它决定了新创建文件或目录的默认权限，间接影响脚本能否被创建后直接运行——尤其是当脚本由编辑器保存、构建工具生成，或通过重定向写入时，其初始权限由umask决定。
umask如何决定新建脚本的默认权限
umask是一个屏蔽值，它从系统默认权限中“减去”对应位，得到实际创建文件的权限。对普通文件，默认基础权限是666（即 rw-rw-rw-），对目录是777（rwxrwxrwx）。umask按位取反后与基础权限做与运算。
例如：
– umask 022 → 文件默认权限 = 666 & ~022 = 644（rw-r--r--）
– umask 002 → 文件默认权限 = 666 & ~002 = 664（rw-rw-r--）
注意：即使脚本内容正确，若新建时权限不含x（执行位），就无法直接 ./script.sh 运行。
为什么脚本常因umask缺失执行位而失败
多数文本编辑器（如vim、nano）、重定向操作（echo "...">script.sh）、或自动化工具（make、CI脚本）创建的是普通文件，不主动设置x权限。此时脚本是否可执行，完全取决于umask是否允许执行位落地：
- umask含002/022/027等（第二位或第三位为偶数），会屏蔽组/其他用户的x位；但用户（owner）的x位始终不会被umask屏蔽（因为文件默认无x位，umask只影响已有权限的“减法”）
- 关键点：umask无法赋予x位，只能限制。所以新建文件永远不会有x权限，除非显式 chmod +x 或使用支持执行位的创建方式（如 cp -p、install -m 755）
- 常见误区：以为设 umask 000 就能让新脚本自动可执行——实际仍为666 → rw-rw-rw-，无x
确保脚本可执行的实用做法
依赖umask控制执行权限不可靠。应主动管理：
- 编写完立即 chmod +x script.sh（最直接）
- 在Makefile中用 install -m 755 script.sh /usr/local/bin/
- Git用户可在仓库中保留chmod状态：git update-index --chmod=+x script.sh
- Shell函数封装：alias mksh='touch && chmod +x'（慎用于生产环境）
- 检查执行前提：运行前用 [ -x "script.sh" ] || { echo "Missing exec perm"; exit 1; }
特殊场景：shell解释器调用 vs 直接执行
权限掩码对以下两种调用方式影响不同：
- bash script.sh：只要读权限（r）即可，无需x。umask导致644也完全可用
- ./script.sh：内核需验证当前用户对该文件有x权限，否则报 “Permission denied”，与shebang无关
- 结论：若脚本总用解释器显式调用，umask对执行无实质影响；若依赖直接执行，则必须补x位
理解umask的作用边界比盲目调整它更重要——它管的是“创建时的起点”，不是“运行时的能力”。真正可控的，是明确赋予权限的动作。
