在查找与 的匹配项时grep，我经常注意到后续搜索所需的时间明显少于第一次——例如 25 秒与 2 秒。显然，它不是通过重用上次运行的数据结构——那些应该已经被释放的。在 上运行time命令grep，我注意到一个有趣的现象：
real 24m36.561s
user 1m20.080s
sys 0m7.230s
剩下的时间去哪儿了？有什么我可以做的让它每次都跑得快吗？（例如，在grep搜索文件之前让另一个进程读取文件。）
当我输入scp file1 user@host.com:file2命令提示符时，我收到消息
Can't open display
Can't open display
Can't open display
Can't open display
Can't open display
file1 100% 589KB 589.0KB/s 00:00
然后我等待大约 10 秒钟，然后scp返回到命令行。这不会发生在ssh，只会发生在scp. 我正在使用 Fedora 18。
有一个 .desktop 编译脚本，需要在终止后保持打开状态，以防出现错误需要更正。在 Windows 中，我会运行cmd /k script.bat，并且 /k 会在终止后保持一个 cmd 窗口打开。
在 Linux 中，我的解决方案是创建一个 bash 脚本，它由“compile”命令和最后的“bash”命令组成。.desktop 文件调用脚本，由于 bash 命令，脚本在完成后保持打开状态。
有没有办法用单个文件来做到这一点？如果是这样，我需要使用单个命令执行以下任一操作，例如通过 bash 的命令行参数：
让 bash 在启动前运行一个命令（相当于 Windows 中的 cmd /k 命令）
使 bash 在某个目录下启动（我可以将编译配置为在其目录打开时触发）
在执行其命令后使 .desktop 文件保持打开状态（这是最不可取的，因为我需要打开第二个窗口来纠正错误，如果有的话）
请让我知道其中之一是否可行。
我有多个 .png 文件（例如：pic_001.png, pic_002.png... pic_200.png）。这些基本上是本书的单独页面。
我想创建一个打印作业，每一个物理页面打印 2 张这样的图片，所以它看起来像一个普通的书本。
我试过这样做：
lp pic_001.png pic_002.png pic_003.png pic_004.png -d color-printer-1 -o sides=one-sided -o number-up=2
但它每 1 页只打印 1 张图片。
与 for 循环相同的结果：
for i in `seq 1 2 8`; do lp pic_00$i.png pic_00$[$i + 1].png -d color-printer-1 -o sides=one-sided -o number-up=2; done
但这也会为每对图片创建单独的作业。
我试图将一组 7 个文件移动到我的计算机上，通过mv g* dir. 命令行移动了其中的 6 个，最后一个文件给出了以下错误：
mv: g.tex: Argument list too long
由于其他文件，包括之前和之后的文件，已经被移动，我试过mv g.tex dir. 同样的错误。移动其他文件工作正常。（注意：g.tex是文件，不是目录。）
更新：通过重命名文件mv也可以正常工作；将其移动到 USB 驱动器上的另一个目录也可以正常工作。但是，即使我重命名它，或将其移动到 USB 驱动器上的另一个目录，我仍然无法将其移动到我的计算机。
我尝试cat将此文件，将其内容复制到桌面：
cat: g.tex: Argument list too long
还有什么可能导致这个问题？
更新：在将输出dtruss与成功移动的文件进行比较后，以下是不同的日志行：
read(0x3, "\0", 0x20000) = -1 Err#7
write_nocancel(0x2, "mv: \0", 0x4) = 4 0
getrlimit(0x1008, 0x7FFF5A00BC78, 0x4) = 0 0
write_nocancel(0x2, "g.tex\0", 0x5) = 5 0
write_nocancel(0x2, ": \0", 0x2) = 2 0
write_nocancel(0x2, "Argument list too …我使用 Linux 格式化了一个文件系统sudo mkfs.ntfs，并运行了一个脚本，最终生成了 1T 字节的信息。我需要在 Windows 中处理这些信息。事实证明，该文件系统无法在 Windows 中读取。我认为这是因为创建的文件系统实际上是fuseNTFS 文件系统 - 然而，我在 Windows 中格式化了 NTFS 中的另一个分区，并且它生成的文件系统具有完全相同的标志：
type fuseblk (rw,nosuid,nodev,relatime,user_id=0,group_id=0,default_permissions,allow_other,blksize=4096,uhelper=udisks2)
除了我的文件系统的块大小是 2048，而 Windows 文件系统的块大小是 4096。
您知道为什么在 Linux 中格式化的文件系统在 Windows 10 中无法被识别吗？我能以某种方式使其在 Windows 中被识别而无需重新格式化吗？我应该采取什么不同的措施来确保创建的文件系统在 Windows 中得到识别？
更新：
对于第二个分区，我在 Windows 中将其删除，然后重新创建它，并将其格式化为 NTFS。然后我转到 Linux，并运行mkfs.ntfs与在第一个分区上运行的相同命令，该分区在 Windows 中仍然可以识别。所以可能不是格式造成了影响。
也许分区的开始和/或结束位置？我将第一个分区设置为从扇区 2048 开始，因此这可能与 Windows 无法识别它的原因有关......
我试图在我的目录中查找包含字符串“<3”的所有文件。这样做应该很简单：
grep "<3" *
但是，运行此打印
grep: <3: No such file or directory
然后继续为其他东西 grep 所有文件......（我不确定究竟是什么，但显示的行根本不包含 3 ......）
原因：显然-f我的目录中有一个文件，当它通过 传递给 grep 时*，grep 将其视为一个标志，导致这种行为。
尝试删除此文件通常也不起作用，因为rm它也将其视为标志。感谢 Nick 的建议，可以使用以下命令删除此文件
rm ./-f
如果我希望将所有标准输出重定向到一个文件，我会运行
my_prog 1> out
如果我想对 stderr 做同样的事情，我会运行
my_prog 2> err
但是，我知道在 shell 中还有其他文件描述符。例如，这个问题的最高答案使用第三个文件描述符，可以通过以下方式从命令行发送数据
echo "Some console message" 1>&3
C 程序有没有办法写入这个文件描述符？在没有其他程序读取它时写入它，是否也将其输出发送到终端？
来自高级 Bash 脚本指南：
特殊符号 << ... 类似于 Interactive-program < command-file
事实上，我能想到的与<<here-document 符号有关的所有事情，我已经可以简单地使用< command-file或 来完成<<< 'list of commands'。也就是说，我可以做到
cat < <(echo fdsa
echo asdf)
或者
cat <<< 'fdsa
asdf'
代替
cat << a
fdsa
asdf
a
一个（明显的）例外是，如果您希望命令列表以不同的方式终止，这取决于您传入的终止参数。但是，我想不出任何可能有用的情况。
另一个例外是，使用 here-document 允许您将特殊字符（例如 '）放入输出中，而无需担心如何转义它们。然而，这也似乎更像是一种便利而不是基本功能。
这里还有什么地方文档如此重要，以至于 Unix 为它们保留了一个特殊的操作符？