使用时
$ find . -name string~ -exec cp {} FOO \;
有没有办法像我们通常使用 bash 子字符串那样使用{}inFOO删除波浪号字符
例如：
$ echo ${string%substring}
我的目标是将名为 string~ 的文件复制到 string（与 相反$ find . -name string -exec cp {} {}~ \;）。
在此脚本中，将拉取所有 git 存储库：
#!/bin/bash
find / -type d -name .git 2>/dev/null |
while read gitFolder; do
if [[ $gitFolder == *"/Temp/"* ]]; then
continue;
fi
if [[ $gitFolder == *"/Trash/"* ]]; then
continue;
fi
if [[ $gitFolder == *"/opt/"* ]]; then
continue;
fi
parent=$(dirname $gitFolder);
echo "";
echo $parent;
(git -C $parent pull && echo "Got $parent") &
done
wait
echo "Got all"
不wait等待所有git pull子 shell。
为什么会这样？我该如何解决？
如果我只使用 basename {} .txt，它会起作用：
find . -iname "*.txt" -exec basename {} .txt \;
它只会打印 xxx 而不是 ./xxx.txt
如果我想在 -exec 选项中使用 $(basename {} .txt) ，它将失败：
find . -iname "*.txt" -exec echo "$(basename {} .txt)" \;
它只会打印 ./xxx.txt
我怎么解决这个问题？我希望我可以$(basename {} .txt)用作其他 cmd 的参数。我必须用 xargs做sh -c或管道-exec basename {} \;吗？
我不知道是否有可能包括空的大括号{}A内sed从一个叫做替代find -exec。
一个例子：
find "$dir" -type f -name "*" -exec sed -i s/hello{}a/hello{}b/g '{}' +
这带来了重复的错误消息{}：
find: Only one instance of {} is supported with -exec ... +
有没有办法保留{}在sed命令中并被视为文字，而不是替换找到的文件find？
我正在尝试扫描文件系统以查找与特定关键字匹配的文件，然后将其删除。到目前为止我有这个：
find . -iregex '.*.new.*' -regex '.*.pdf*'
然后我如何将此命令的结果通过管道传输到删除命令（例如rm）
我经常发现自己根据文件名称的一部分在当前文件夹和子文件夹中搜索文件。在我看来，在这种情况下find + grep需要的输入少于find. 例如
find . | grep user #19 chars typed
必须写成只找到：
find . -path "user*" #21 chars typed
当使用一个用于查找文件的命令时输入更多字符感觉有点傻……然后组合使用它们中的两个。
有什么方法可以让使用 only find 在键入的字符方面更有效？
我在一个包含0.2remor的文件夹下有几个 CSS 文件0.5rem 0.6rem，现在我希望它们全部除以 2，变成0.1rem和0.25rem, 0.3rem。我如何使用awk或sed或gawk来完成此操作？
我尝试了以下命令但没有成功：
find . -name "*.css" | xargs gawk -i inplace '{gsub(/([0-9\.]+)rem/, "(\\1 * 0.5)rem"); print $0}'
我喜欢使用以下命令来打印文件名，但它会打印带有扩展名的文件名。
find . -type f -printf '%f\n'
在我的目录中，有许多具有不同扩展名的文件。我尝试--ignore='*.*'在 before 和 after 中添加-printf，但没有用。例子; 我有文件 myfile1.txt、myfile2.mp3 等。我需要它打印 myfile1、myfile2 等。我该怎么做？
给定一个包含以下内容的目录：
note 1.txt, 昨天最后修改note 2.txt，上次修改前天note 3.txt，今天最后修改获取数组的最佳方法是什么note 3 note 1 note 2？
为了定义“最佳”，我更关心稳健性（在 macOS 中的 ZSH 上下文中），而不是效率和可移植性。
预期的用例是一个包含数百或数千个纯文本文件的目录，但是——冒着混淆问题的风险——这是我有一个更普遍的问题的一个特定案例，在文件路径上执行字符串操作的最佳实践是什么由命令打印喜欢ls，find，和mdfind。
我一直在使用一个调用此命令的宏来实现上述目的：
ls -t | sed -e 's/.[^.]*$//'
它从来没有失败过，但是：
ls. （解析ls；实践，在“5. 永远不要做这些”下）。sed在参数扩展会做的地方调用效率低下吗？使用find（用 NUL 字符而不是换行符安全地分隔文件路径）和参数扩展来提取基本名称，这会产生一个未排序的列表：
find . -type f -print0 | while IFS= read -d '' -r l ; do print "${${l%.*}##*/}" ; done
但是按修改日期排序似乎需要调用stat …
类 Unix 系统上的大量（且不断增长的）实用程序似乎选择 JSON 格式进行数据交换\xc2\xb9，尽管 JSON 字符串无法直接表示任意文件路径、进程名称、命令行参数以及更常见的 C strings\xc2\xb2 可能包含以各种字符集编码的文本或根本不意味着是文本。
\n例如，许多 util-linux、Linux LVM、systemd实用程序、curlGNU parallel、ripgrep、sqlite3、tree、许多 FreeBSD 实用程序及其--libxo=json选项...可以以 JSON 格式输出数据，然后据称可以以编程方式“可靠”地解析数据。
但是，如果它们要输出的某些字符串（例如文件名）包含未以 UTF-8 编码的文本，那么似乎一切都会崩溃。
\n在这种情况下，我看到公用事业之间存在不同类型的行为：
\n?（如）exiftool或 U+FFFD (\xef\xbf\xbd) 替换它们，或者有时以不可逆的方式使用某种形式的编码（"\\\\x80"例如在column）"json-string"到[65, 234]字节数组 injournalctl或 from {"text":"foo"}to {"bytes":"base64-encoded"}in rg。curl