SSH环境下CP脚本批量复制时文件名异常问题咨询

安全阿岳

2026-5-28

问题分析：文件名意外多出"g"字符的成因与修复方案

这种部分文件出现file_*.jpgg/file_*.jpggg的异常，大概率是脚本生成逻辑错误或者SSH会话传输时的字符重复导致的，下面分情况拆解：

一、常见成因

如果你是用sed、awk或者Python脚本批量生成这25万条cp命令，很可能是生成环节出了问题：

比如误用了全局替换规则，比如写了sed 's/\.jpg/\.jpgg/g'（最后的g是全局替换标记），如果原路径里有多个.jpg相关字符（比如目录名带.jpg），就会导致文件名被重复追加g；
或者生成脚本的循环逻辑有漏洞，比如变量没有正确重置，导致文件名被多次拼接g字符。

当通过SSH运行大量密集命令时，如果网络不稳定或者终端伪终端（pty）配置异常，可能出现字符重复传输：

SSH传输命令流时，若数据包重传，可能会把.jpg里的g重复发送，导致执行的命令变成cp directory_a/file_1.jpg new_directory/file_1.jpgg；
这种情况通常随机出现，和网络波动的时间点对应，刚好在执行某几条命令时触发了重传。

如果脚本是在Windows下编辑后传到Linux服务器，部分编辑器的自动补全或替换规则，可能意外给文件名追加了g字符（虽然CRLF换行符通常只会导致^M错误，但特殊规则可能触发这类问题）。

首先检查脚本文件，确认异常文件名对应的命令行是不是已经在脚本里写错了：

# 搜索脚本里的异常命令
grep "jpgg" your_script.sh

如果能找到匹配结果，说明是脚本生成时的错误：

修复方法：重新生成脚本，调整批量生成逻辑。比如用sed时，只匹配文件名末尾的.jpg：sed 's/\.jpg$/.jpg/'（确保原样保留后缀）；如果是Python生成脚本，检查字符串拼接逻辑，避免循环中重复追加字符的bug。

如果脚本里的命令都是正确的.jpg，但执行后出现异常，那就是SSH会话的问题：

修复方法1：后台执行脚本，避免终端交互干扰：
```
nohup sh your_script.sh > cp_log.log 2>&1 &
```
修复方法2：优化SSH连接稳定性，减少数据包重传：
```
ssh -o TCPKeepAlive=yes -o ServerAliveInterval=30 user@server
```

修复方法3：先把脚本传到服务器本地，再执行：

# 本地传脚本到服务器
scp your_script.sh user@server:/path/to/script/
# 登录服务器后执行
sh /path/to/script/your_script.sh

对于已经生成的错误文件名，用以下命令批量修正：

cd new_directory
# 把所有后缀带多余g的文件重命名回.jpg
for file in *.jpgg*; do
  mv "$file" "${file%g*}.jpg"
done

如果系统支持rename命令，也可以用更简洁的方式：

rename 's/\.jpg(g+)$/.jpg/' *.jpgg*

内容的提问来源于stack exchange，提问作者Ezra-Shimon