你还停留在只能解决自我能力范围之内的问题吗？

为什么要写这样一篇博客?

我在 linux 中改变运行程序的 stdout 中描述了使用 gdb 改变运行程序 stdout 输出的一种方法。一开始没有想到能够实现这种功能，但是最终搜索了下发现使用 gdb 就能够简单的做到。

很多时候我们在解决一些问题的时候都是通过这种方式来搞定的，但是解决了之后想想难道我们自己真的不能解决吗？搜索引擎确实非常方便，这是搜索引擎的核心竞争力，并不是我们的核心竞争力。

为什么我想不到用 gdb 来解决这个问题？

gdb 我也经常使用，对于一些基本的命令与功能我也是清楚的，但是在这个问题里面使用 call 命令来调用系统调用这个功能我确实不清楚，可是这个是关键问题吗？

仔细想想这并不是关键的问题，关键的问题应当是怎样将 gdb 与这个问题关联起来。

进一步的思考

首先应当分析的是要改变的是运行程序的 stdout 输出，根据以往的知识经验，找不到一个解决方案，那这个问题就这样放弃了么？

很多时候对于超出我们认知范围的事物，我们常常很容易得出不可能的结论。这个不可能的结论是最大的障碍，这个障碍是我们自己制造出来的，针对这个问题来说并不存在。

扯到我们认知心理的特征上

这里体现了我们认知的特点，当面对难题时，我们往往会对相对简单的问题进行回答，却忽略了自己已经置换了原始问题这个事实。（摘自《思考 快与慢》）

在这个问题中也存类似的认知过程。我们的目标是解决问题，然后快思考让我们得出了一个直觉的结论，这个问题不能解决。

这个结论严格的描述应该是以我们自己当前的知识水平不容易解决，到此这个问题就能够抛在一旁，不至于让我们苦思冥想，不至于让我们陷入焦灼状态。

再扯回这个问题

扯到认知心理的特征并不是突发奇想，只是为了说明在解决这个问题时我们面对的最大的障碍并不是技术上的问题，而是我们认知心理上的障碍。如果不能克服这一点，那么我们将一直在舒适区内，只能解决自我知识水平内的问题。

用慢思考来分析这个问题

当我们认识到快思考让我们过早的凭直觉得出一个结论的问题后，我们可以用慢思考来仔细分析一下这个问题。

首先确认的是我们要改变的是运行中程序的 stdout，我们肯定要执行某些针对该程序的操作。

既然要针对该程序进行操作，那么我们继续思考在系统中我们能够通过怎样的接口、工具来控制程序的状态呢？

这次根据直觉判断，我指向 /proc 目录与 gdb 命令，我基于如下认知判断可能能够通过这两个方面来解决这个问题：

1. 每个程序在运行时，/proc 目录中都会创建一些与程序运行相关的文件，proc 文件一些是可以动态修改的，那么是否能够通过写入 proc 目录中的某个文件来动态修改程序的 stdout?
2. 以前有使用过 gdb 修改过程序中的变量，这是一种改变程序执行环境的操作，那么可不可能 gdb 还有其它命令来完成修改 stdout 的操作？

第一个判断可以执行 man proc 来阅读帮助手册，查看是否有类似的功能。
第二个判断可以通过通读 gdb 命令的手册来确定。

gdb 手册非常长，我们可以先看目录，在目录中寻找相关的内容，找到的目录内容如下：

17 Altering Execution

    17.1 Assignment to Variables
    17.2 Continuing at a Different Address
    17.3 Giving your Program a Signal
    17.4 Returning from a Function
    17.5 Calling Program Functions
        17.5.1 Calling functions with no debug info
    17.6 Patching Programs
    17.7 Compiling and injecting code in GDB
        17.7.1 Compilation options for the compile command
        17.7.2 Caveats when using the compile command
        17.7.3 Compiler search for the compile command

这一个章节讲的用 gdb 修改程序的执行过程，我们这个问题应该要从这里找答案。

确定了大的章节后，确定小的章节，看上去应该是 Calling Program Functions 这个，阅读手册后发现可以通过 call 命令、print 命令调用函数，我们可以利用这个功能调用系统调用来完成这个功能。

只有我遇到过这个问题吗？

很多问题并不是只有你才能遇到，也许已经有人遇到过类似的问题并且提供了解决方案，这样我们就可以直接利用别人的成果。

搜索引擎搜索下这个问题，果然有人已经解决过了，并且具体的操作示例也有，依葫芦画瓢操作一下果然能够解决问题。

问题必须自己解决吗?

在这个问题中我们可以通过搜索引擎解决这个问题，相较自己去解决，利用别人现有的成果搞起来非常快，对于工作来说这才是应当优先尝试的解决方案。

我们解决问题的思路要拓宽，可以按照解决问题的成本来排列不同的解决方案，优先尝试低成本的解决方案，当失败后再尝试相对较高成本的解决方案。

同时需要注意的是这里面向的是工作的环境，对于自己研究学习的环境最好尝试自己去解决。这并不是说每个问题都要自己解决，而是评估重要程度，优先尝试自己解决那些自己认为重要的问题。

使用其它途径解决问题的核心竞争力

诚然，使用搜索引擎等工具在解决一些问题时能够取得非常快的进展，但是这里的核心竞争力不在于问题本身，而在于能够利用其它途径解决问题的思路，这并不是不可复制的。从这点来说，似乎微不足道，可每个人都能做到吗？如果大家都能做到，这篇文章就失去了其存在的价值。