问题说明 编写shell脚本辅助测试执行，考虑到可配置型和维护性，将一些变量常见的都写入配置文件。读取配置文件属性脚本如下，
filepath=`cat conf.ini|grep filepath|awk -F ‘=’ ‘{print $2}’`
之后会对给定参数的filepath目录下的文件进行遍历，for file in `ls $filepath` do done
在执行上面的遍历脚本时，报不存在该目录，并且打印出的目录和我输入的目录不一致(发生了截取，配置文件里面为 filepath=/home/XXX/XXX/exec/XXX/log/cur)。
如果将配置文件里面的路径配置直接在脚本中赋值给变量，脚本执行时Okay的。脚本如下：
filepath=/home/XXX/XXX/exec/XXX/log/cur。
for file in `ls $filepath` do done 在脚本中同时echo出配置文件和写入固定的，二者没有任何区别。
问题解决使用linux strace进行跟踪，strace –o log0402.log –f checkerror.sh对strace日志进行分析，2455 stat(“/home/XXX/XXX/exec/XXXX/log/cur\r”, 0x67a15e8) = -1 ENOENT (No such file or directory)系统报这个目录不存在，实际上这个目录肯定是存在的，注意到后面多了一个\r，linux和windows的换行符的差别。同时考虑到自己的配置文件是从windows做好后，上传到linux服务器。正好符合上面的说法。登陆到linxu服务器，使用vi命令，设置格式为unix（:set ff=unix）.重新执行脚本后成功。
Strace详细介绍
其他案例我们平时在使用其他linux软件，会遇到各种各样的怪异问题，根据提示的日志很难定位出问题的原因。下面列举了网上其他人使用strace进行问题分析的例子。案例一：运行clint出现Segment Fault错误操作系统：FreeBSD-5.2.1-releaseclint是一个C++静态源代码分析工具，通过Ports安装好之后，运行：# clint foo.cppSegmentation fault (core dumped)在Unix系统中遇见”Segmentation Fault”就像在MS Windows中弹出”非法操作”对话框一样令人讨厌。OK，我们用truss给clint”把把脉”：# truss -f -o clint.truss clintSegmentation fault (core dumped)# tail clint.truss739: read(0×6,0×806f000,0×1000) = 4096 (0×1000)739: fstat(6,0xbfbfe4d0) = 0 (0×0)739: fcntl(0×6,0×3,0×0) = 4 (0×4)739: fcntl(0×6,0×4,0×0) = 0 (0×0)739: close(6) = 0 (0×0)739: stat(”/root/.clint/plugins”,0xbfbfe680) ERR#2 ‘No such file or directory’SIGNAL 11SIGNAL 11Process stopped because of: 16process exit, rval = 139我们用truss跟踪clint的系统调用执行情况，并把结果输出到文件clint.truss，然后用tail查看最后几行。注意看clint执行的最后一条系统调用（倒数第五行）：stat(”/root/.clint/plugins”,0xbfbfe680) ERR#2 ‘No such file or directory’，问题就出在这里：clint找不到目录”/root/.clint/plugins”，从而引发了段错误。怎样解决？很简单： mkdir -p /root/.clint/plugins，不过这次运行clint还是会”Segmentation Fault”9。继续用truss跟踪，发现clint还需要这个目录”/root/.clint/plugins/python”，建好这个目录后 clint终于能够正常运行了。
案例三：用调试工具掌握软件的工作原理 操作系统：Red Hat Linux 9.0用调试工具实时跟踪软件的运行情况不仅是诊断软件”疑难杂症”的有效的手段，也可帮助我们理清软件的”脉络”，即快速掌握软件的运行流程和工作原理， 不失为一种学习源代码的辅助方法。下面这个案例展现了如何使用strace通过跟踪别的软件来”触发灵感”，从而解决软件开发中的难题的。大家都知道，在进程内打开一个文件，都有唯一一个文件描述符（fd：file descriptor）与这个文件对应。而本人在开发一个软件过程中遇到这样一个问题：已知一个fd，如何获取这个fd所对应文件的完整路径？不管是Linux、FreeBSD或是其它Unix系统都没有提供这样的API，怎么办呢？我 们换个角度思考：Unix下有没有什么软件可以获取进程打开了哪些文件？如果你经验足够丰富，很容易想到lsof，使用它既可以知道进程打开了哪些文件， 也可以了解一个文件被哪个进程打开。好，我们用一个小程序来试验一下lsof，看它是如何获取进程打开了哪些文件。lsof： 显示进程打开的文件。/* testlsof.c */#include #include #include #include #includeint main(void){open(”/tmp/foo”, O_CREAT|O_RDONLY); /* 打开文件/tmp/foo */sleep(1200); /* 睡眠1200秒，以便进行后续操作 */return 0;}将testlsof放入后台运行，其pid为3125。命令lsof -p 3125查看进程3125打开了哪些文件，我们用strace跟踪lsof的运行，输出结果保存在lsof.strace中：# gcc testlsof.c -o testlsof# ./testlsof &[1] 3125# strace -o lsof.strace lsof -p 3125我们以”/tmp/foo”为关键字搜索输出文件lsof.strace，结果只有一条：# grep ‘/tmp/foo’ lsof.stracereadlink(”/proc/3125/fd/3″, “/tmp/foo”, 4096) = 8原来lsof巧妙的利用了/proc/nnnn/fd/目录（nnnn为pid）：Linux内核会为每一个进程在/proc/建立一个以其pid为 名的目录用来保存进程的相关信息，而其子目录fd保存的是该进程打开的所有文件的fd。目标离我们很近了。好，我们到/proc/3125/fd/看个究 竟：# cd /proc/3125/fd/# ls -ltotal 0lrwx—— 1 root root 64 Nov 5 09:50 0 -> /dev/pts/0lrwx—— 1 root root 64 Nov 5 09:50 1 -> /dev/pts/0lrwx—— 1 root root 64 Nov 5 09:50 2 -> /dev/pts/0lr-x—— 1 root root 64 Nov 5 09:50 3 -> /tmp/foo# readlink /proc/3125/fd/3/tmp/foo答案已经很明显了：/proc/nnnn/fd/目录下的每一个fd文件都是符号链接，而此链接就指向被该进程打开的一个文件。我们只要用readlink()系统调用就可以获取某个fd对应的文件了，代码如下：#include #include #include #include #include #includeint get_pathname_from_fd(int fd, char pathname[], int n){char buf[1024];pid_t pid;bzero(buf, 1024);pid = getpid();snprintf(buf, 1024, “/proc/%i/fd/%i”, pid, fd);return readlink(buf, pathname, n);}int main(void){int fd;char pathname[4096];bzero(pathname, 4096);fd = open(”/tmp/foo”, O_CREAT|O_RDONLY);get_pathname_from_fd(fd, pathname, 4096);printf(”fd=%d; pathname=%sn”, fd, pathname);return 0;}
出于安全方面的考虑，在FreeBSD 5 之后系统默认已经不再自动装载proc文件系统，因此，要想使用truss或strace跟踪程序，你必须手工装载proc文件系统：mount -t procfs proc /proc；或者在/etc/fstab中加上一行：proc /proc procfs rw 0 0