考虑到逗号或制表符分隔的输入，我想向标准输出显示一系列适当填充的列，以便我可以轻松扫描列式信息，否则这些信息会显示得相当混乱。
我尝试过troff基于 - 的解决方案，虽然简单的演示已经奏效，但提供命令的实际输入会导致奇怪的错误。我目前求助于使用一个相当慢的sed基于方法的hack......
编辑：column是一个非常有用的工具，但是如果我的列之间有一个管道字符 ( |) 这样它们就不会在空间中“漂浮”，我可以轻松区分每个列的开始位置，那就太棒了。
附注。这篇文章的标题用于阅读“ASCII“表格”，而不是“ASCII艺术表格”。编辑以尝试消除混淆。
几年来（~2012-2020），在多台计算机（不同年份的 AMD/Intel、S3/AMD/Intel 显卡）上，我观察到了 X11 中一个奇怪的、与 DDX 无关的错误。
有时，经过几次睡眠 ( echo mem > /sys/power/state) 和唤醒周期后，X11 会“忘记”显示器的 DPMS 设置，并无限期地保持屏幕打开。
在这种状态下，xset dpms force suspend(或 - standby) 可以正常工作；我想知道该错误是否存在于活动检测或超时管理中。
有时问题需要数周时间才会浮出水面；有时它发生得非常快。我前几天碰巧需要重新启动，问题就出现了。在此之前，我想我在这台机器（我已经使用了大约一年）上只遇到过一次这个问题。
嗯，也许这实际上是一个竞争条件。耶耶耶。
作为严格测试，我将所有可以设置的值从默认的 600（10 分钟）更改为 5 秒。现在，xset q正在向我展示：
Screen Saver:
...
timeout: 5 cycle: 5
...
DPMS (Energy Star):
Standby: 5 Suspend: 5 Off: 5
DPMS is Enabled
Monitor is On
我的屏幕既没有被 X 屏幕保护程序清空，也没有进入 DPMS 待机/挂起状态。
我猜我需要构建自己的 X 副本，添加尽可能多的printfs，并尝试记住始终使用我的 X 而不是系统 X...但在我去那里之前，我想知道是否有人有任何有趣、有见地的花絮供我先尝试。
谢谢 ：） …
我最初想将其发布到 StackOverflow，因为我的兴趣主要来自于编程焦点，但在阅读了历史标签（以及它链接到的问题）后，我将其发布到 softwareengineering.se以深入了解实际/当前-日《软件工程》方面。然而，我的问题的根本历史性质是不可避免的，所以现在就到这里了。
\n我目前正在了解 Linux 上的日志记录如何工作，并且对RFC 5424或RFC 3164似乎未涵盖的实现细节有点困惑：用于将数据写入/dev/log.
TL;DR：我正在尝试确定 a）“/dev/log格式”的名称，以及 b）其语义的正式指定位置。我无法识别任何 RFC 或其他可引用的参考文献 - 仅代码实现特定规则，没有押韵或理由。
syslog()虽然我最初对这个主题感兴趣，同时评估与其他日志记录策略（写入 stdout/stderr 和/或文件；发送到其他类型的日志服务器等）的优缺点，但有一次我意识到我完全无法确定“/dev/log格式”如何/在何处适应更大的情况。关于 syslog 格式或协议的每个问题都讨论了 RFC，并且完全忽略了控制数据如何离开syslog()并发送到 syslog 服务器的规则。
几乎就像 UNIX 的这个特定角落已经完全消失在木制品中一样，就像不再存在一样……而每天都有数万亿条日志消息使用这种“格式”（？）写入。
\n因此，这个问题是试图消除这个特定细节的歧义，只是为了这样做，描述格式，并确定可引用的参考文献。
\n日志行似乎需要以非常特定的方式进行格式化才能被接受（在我的例子中是 systemd-journald - 首先是优先级/设施信息（包含在 中<>），然后是一个非常特定格式的时间戳，这似乎是通常提到的to 作为标签，然后是消息：
\n# logger -s hi\n<13>3 月 5 日 14:04:11 i336: hi\n\n#journalctl -qn1 -o Short-iso-precise\n2021-03-05T14:04:11.430504+1100 h0nk …
我是 Linux 休眠支持的忠实粉丝，它在我尝试过的所有（不可否认的稍旧）硬件上都运行得非常好。我非常喜欢它完全关机和开机。
不过，关于休眠的一件事让我困扰了一段时间：休眠的系统在恢复后总是缓慢且无响应。通电后不会立即活泼。旧硬件会加剧这种情况，但在较新的系统上也会发生稍微显着的程度。
这似乎是因为内核只将 [内核级] 操作所必需的页面交换回工作内存，恢复内核的基本工作状态，并让用户空间在各种进程交换他们需要的页面时只搅动一段时间。 RAM 下他们自己的蒸汽。
这在实践中效果不佳，因为系统最初运行时好像某个大型进程已强制所有内容完全交换到磁盘。屏幕上的任何内容都会很快换回，但切换到另一个进程，您将等待几秒钟，因为它也会换回内存。在较旧的硬件上——我的例子是 Core 2 ThinkPad T60——“几秒钟”甚至可以结束几分钟。
我最近意识到这个问题有一个令人惊讶的简单解决方案，在考虑了一下之后：记下标记磁盘和 RAM 中哪些页面的标签，然后在恢复时恢复这个确切的状态。当然，恢复过程可能需要大约 10 秒以上，但我不在乎 - 我有一个活泼的系统。
我想知道是否有任何晦涩的内核编译选项可以启用此类功能，或者我可以设置一些近似于这种行为的配置？
注意：我不认为swapoff -a; swapon -a可行的解决方案；当挂起的用户空间被重新激活时，所有加载的进程都在尝试执行代码并努力将自己交换回 RAM，从而导致大量的磁盘 I/O。试图破坏交换区只会加剧飓风，实际上比内核在重新激活用户空间之前恢复所有RAM需要更长的时间才能完成。
一段时间以来，我一直在遇到 NFS 的一个奇怪问题，其中一个看似随机的目录子集（总是相同的）在/NFS 挂载后立即显示为陈旧的文件句柄。
我已经能够通过显式导出看似随机的问题目录集来纠正问题，但我想看看我是否可以更彻底地修复问题，这样我就不必偶尔向导出表添加随机目录.
下面，我挂载了一个文件系统，显示没有打开的文件句柄 runls和 rerun lsof。为清晰起见，在命令之间添加了空行：
# mount -t nfs -o vers=4,noac,hard,intr 192.168.0.2:/ /nfs -vvv
mount.nfs: trying text-based options 'vers=4,noac,hard,intr,addr=192.168.0.2,clientaddr=192.168.0.4'
192.168.0.2:/ on /nfs type nfs (rw,vers=4,noac,hard,intr)
# lsof | grep /nfs
# ls -lh /nfs
ls: cannot access /nfs/usr: Stale file handle
ls: cannot access /nfs/root: Stale file handle
ls: cannot access /nfs/etc: Stale file handle
ls: cannot access /nfs/home: Stale file handle
lrwxrwxrwx 1 root root 7 Mar 27 2017 bin …我有大量的文件（数以万计）需要grep通过特定的字符串。少数文件中有空格。文件太多，进程创建开销-n1实际上比文件搜索本身还要大。
这有效，但速度慢得无法使用：
cat filelist | xargs -I{} grep mystring '{}'
所以，我想向每个grep实例传递 1000 个参数，如下所示：
cat filelist | xargs -n1000 -I{} grep mystring '{}'
但这不起作用。似乎{}只有当-n= 1时才有效？！
例子：
进程太多，正确输出：
$ seq 1 10 | xargs -I{} -n1 echo "<{}>"
<1>
<2>
<3>
<4>
<5>
<6>
<7>
<8>
<9>
<10>
大量的进程，还有……什么？
$ seq 1 10 | xargs -I{} -n2 echo "<{}>"
<{}> 1 2
<{}> 3 4
<{}> 5 6
<{}> 7 8 … 在无数次查找如何使用gettimeofday()时，我决定这次快速深入了解一下 vDSO，因为我对它只有一个模糊的认识，并且想知道是否有任何我应该注意的使用陷阱。
根据/sf/ask/2983569921/，如果 vDSO 正在使用，则strace不应显示或。gettimeofdayclock_gettime
嗯，看起来我的 ThinkPad T400 已经坏了一段时间了：从我记事起，我就一直看到“大量”这样的电话。strace（特别是来自 QEMU。）
如果我尝试testgtod.c（运行gettimeofday()1000 次）上述问题：
$ strace ./testgtod 2>&1 | grep clock_gettime | wc -l
1000
目前，我能发现的 ThinkPad 和 i3 台式机之间的唯一区别是 i3 使用 TSC，而 ThinkPad 使用 HPET，因为tsc: Marking TSC unstable due to TSC halts in idle. （想知道这是否是一个暂停/恢复的事情，但后来注意到了时间戳 - 这是启动后的 1.53 秒。）T400（当前......）运行 Arch，而 i3 盒子运行 Debian 9。
上述问题也参考了dump-vdso.c。T400 上的 vDSO 对我来说看起来相当不错：
$ …