再谈CSHELL对C程序员的价值

几个礼拜前，介绍了CSHELL。/article/5558634.html 今天再试着介绍下，希望能有更多C程序员留意到它，从中获益。

很多年前，我在调试程序或是排查系统故障的时候，就希望有个SHELL。理想中，它应该是这个样子：

从exe文件读取elf符号，在内存中生成符号表表；
开启一个SHELL交互界面，接受修改变量或是函数的命令行；
要能够允许用户使用复杂的C语法，做到C程序编程一样；
用户回车后，自动从符号表找到相关函数，或是变量对应地址，然后执行；
函数的参数列表会被正确解析；
所有的非静态或内联的函数，变量，只要是代码里有的，都应该能在这个界面使用；
最好，能支持脚本，批量执行函数。

那些年，哥苦苦研究，但限于技术面的不足，始终未能找到入手方法。最接近的，也就是让在编码时，hardcode一组函数；而SHELL界面，则是如一般SHELL技术那样，要求按照严格的格式输入，依赖strcmp等字符处理技术判断如何调用函数。其中的限制和无奈，在此不赘述。

再后来，哥开始做VxWorks开发。做过vxWorks的人都应该知道WindShell，那东西真心好，让无数程序员爱不释手。哥也很喜欢啊，它就是理想中的那个SHELL，写上几个函数，编译一下，就能在SHELL下直接运行测试，真的方便的很；甚至有时候，要计算点东西，也会用WindShell，特别是编程过程中查16进制和10进制数的转换，或是某个字符的ascii值。

但哥终究是不那么容易被满足的程序员，很快就研究明白windshell的原理。涉及几个主要知识：
1，编译技术，比如LEX 词法分析、YACC 语法生成等；
2，ELF文件格式，以及GCC编译过程和链接技术；
3，某个脚本语言，处理文本必需要。
当然，C语言知识和Makefile知识是必须的，当然，C语言或是Makefile不过关的也没做SHELL的需求。

这三块技术，只有ELF格式和编译链接技术略有研究，另外两项都需要潜心研究。

脚本语言，哥选择了Perl入手，最开始的时候，是考虑Java和Python来着，因为算是有点基础；但很快改变了想法，对于复杂的文本处理来说，Perl可能才是王道。这期间，断断续续经历了好几个月，才算学成Perl，虽然不能说随心所欲的用Perl和正则表达式，但终于不再磕磕碰碰了。下次给大家介绍个自己用Perl做的Lex，Yacc，证明下哥没撒谎。

编译技术就没么容易了，首先要学理论。惭愧，工作后发现大学错过了两样东西：数学和编译原理。高等数序和离散数学没学好，让前些年做系统分析时缺了支柱；幸好编译原理要容易点，自学了一段时间后，终于有所领悟。说到这，倒是提醒玩正则表达式的同学们，记得学点编译原理的词法技术，否则写正则表达式很难摆脱花拳绣腿的尴尬。

接下来，是研究LEX和YACC的运用。这个挺难，网上有很多很多介绍的，十有八九是抄来抄去的一样的东西，偶尔不一样的，也只是谈及皮毛，根本没什么参考价值，跟小编写出来骗大爷大妈的医学养生文章一个水平。当然也就牛叉的，讲的云里雾里，可就是没个实例，全是理论介绍，再仔细一瞧，丫的所谓原创竟然是把LEX和YACC的技术文档摘录翻译出来。就这样，大概挣扎了几个月，一步步积累后，哥终于明白LEX和YACC怎么用了。

接下来的过程就比较自然了，用了一两个周末和晚间休息时间，哥终于做出了CSHELL。最开始规划的时候，还预留了if，while这些逻辑控制，以及cshell下的宏操作支持；但后来发现，价值不是很大，实现需要的时间也蛮多的，就暂时放弃了。或许将来会做吧！

为了方便cshell移植，又花了一个周末将其模块化，整合到项目makefile里。然后，又花了个把钟头，把p_readelf.pl从perl版的zlib中独立出来，以便于大家更容易的移植cshell到自己的项目中。

哥前两天写的trace文章，阅读量破千，但CSHELL却没几个。其实，如果trace是一屌丝，那CSHELL绝非一般高富帅，它们所能带来的价值也是天上地下！

献上cshell的词法文件，供有志于研究lex的同学参考：
http://files.cnblogs.com/files/hhao020/cshell.l.rar

欢迎lex学习者留言探讨。