【问题标题】:Detect & remove leading space in file or folder name检测并删除文件或文件夹名称中的前导空格
【发布时间】:2019-12-08 15:21:21
【问题描述】:

我需要检测并删除我的文件夹和文件中的大量前导空格。

我尝试了一些代码,例如:

find /home/account -depth -name " *" -exec sh -c 'f="{}"; mv -v "$f" "...."' \;

但我找不到任何代码可以从文件名或文件夹中删除前导空格。

我需要:

mv "/home/account/folder/ folder 1"  "/home/account/folder/folder 1"

(因为我使用 find,并让它检测子文件夹上的前导空格)

如何使用上面提到的代码删除那些前导空格? 任何建议都会有所帮助。 顺便说一句,我使用的是 centos 7。

【问题讨论】:

  • 您能否说明您是否需要修复文件夹名、文件名或两者兼而有之?问题文本仅暗示文件夹,解决方案暗示所有文件。
  • 对不起,我的错误,实际上我需要修复文件和文件夹,并且解决方案可以同时完成。
  • 您还在寻找解决方案,还是对已接受的解决方案感到满意?

标签: linux bash removing-whitespace


【解决方案1】:

-name "* " 匹配名称中包含 尾随 空格的文件名。我在下面修复了这个问题,并使用了-execdir,以便更轻松地使用参数扩展来删除前导空格。

find /home/account -depth -name ' *' -execdir sh -c '
for f; do
    mv -v "$f" "${f#./[[:space:]]}"
done' _ {} +

对于试运行,在 mv 之前加上 echo


如果可能有多个前导空格,那么方便的方法是在参数扩展中使用 extglob(这是一个 bash 扩展):

find /home/account -depth -name ' *' -execdir bash -c '
shopt -s extglob
for f; do
    mv -v "$f" "${f#./+([[:space:]])}"
done' _ {} +

【讨论】:

  • find "/home/account" -depth -name " *" -execdir sh -c 'for f; do mv -v "$f" "${f#./[[:space:]]}"; done' _ {} + 它正在工作,谢谢伊斯梅尔:D
【解决方案2】:

使用rename

  • -name "* " :匹配名称中包含尾随空格的文件名
  • rename 's/ //gi' : 用空替换空格

-->

find /home/account -depth -name "* " | rename 's/ //gi'

【讨论】:

  • 我尝试使用重命名,但挑战是如何仅替换文件名中的 LEADING 空格。我相信建议的解决方案将替换目录和文件名中的所有空间。
  • 只搜索文件而不是目录,使用这个命令:find。 -depth -type f -name "* *" |重命名's///gi'
【解决方案3】:

试试这个:

find /home/account -depth -name "* " | sed "s/\/ /\//g"

【讨论】:

    【解决方案4】:

    您可以使用 bash 替换来提取文件名,并消除前导空格。

    小提示:-name "* " 模式会查找带有尾随空格的文件。如果您正在寻找前导空格的过滤器,请使用-name " *",或-name "* * " 以外的任何空格。示例代码使用前导空格模式。您可以根据需要调整模式和 sed。

    find /home/account -depth -name " *" | while read fn ; do
       d=${fn%/*}
       b=$(echo "${fn##*/}" | sed -e 's/^ *//')
       mv "$fn" "$d/$b"
    done
    
    

    【讨论】:

    • 我不知道我发表了多少次这条评论,但是用循环读取 find 的输出是没有意义的。包含不明确字符的文件名会破坏这一点。而且,这也是对 sed 的无用使用; bash 支持所有 posix 参数表达式以及 extglob、替换等;因此它可以通过内部函数处理这些琐碎的修改
    • 虽然我同意制作每个防弹脚本的目标,但让每个脚本和单行代码支持最复杂、最不常见的情况并不总是可行(并且值得)文件名等)。
    • 不过,这样的答案可能会误导未来的观众。至少添加一个声明,告诉这个答案下次在某些极端情况下不起作用。
    • 个人意见:你可能设置的门槛太高了。快速浏览最近的答案(包括主要贡献者)显示了许多有风险的模式,包括像 'rm *' (当文件以 '-' 开头时可能被滥用为 'rm -r')、类似的 find/xargs 和 find /read 问题,更不用说语法错误等。我认为这是每个贡献者都会做出的个人选择,具体取决于上下文等。必须包含一长串免责声明,每个答案上的警告并不是解决问题的方法去。但是,这可能是对“元堆栈溢出”的一个很好的讨论
    猜你喜欢
    • 2016-03-29
    • 1970-01-01
    • 2013-05-02
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2014-01-04
    相关资源
    最近更新 更多