Hello, On Sat, 03 Oct 2009, Joachim Schrod wrote:

David Haller wrote:

...

$ strace bash -c './t.sh' ## shortened output, my comments after '###' [..]

Using the extra bash -c simulates the behaviour you'd get without strace.

Any questions? ;)

Yes -- why would one use strace to analyze that problem in the first place?

Why not? Routine?

A simple "bash -x", or at the max "bash -vx", would be better, wouldn't it?

Better? Nah. Sufficient? Maybe. With strace, you get to see what really gets done. Just to see what gets executed, esp. if your shell is not /bin/bash. Start e.g. a ksh and do a ./t.sh (or whatever) there, with -x and with strace -o t.strace -f -eprocess,open,read,write /bin/ksh -c './t.sh' (which emulates typing just './t.sh' running under strace) I'm too tired right know to check more details, but I think you'll find something interesting in the t.strace ;) E.g. that 't.sh' is actually executed by '/bin/sh'! 3190 execve("./t.sh", ["./t.sh"], [/* 103 vars */]) = -1 ENOEXEC (Exec format error) 3190 execve("/bin/sh", ["/bin/sh", "./t.sh"], [/* 103 vars */]) = 0 The kernel finds no valid executable, no valid #! line, and thus tries feeding it to /bin/sh ... You won't detect that difference with '-x' or '-vx'. Satisfied? (I'm too tired for more now, ask again, and I'll try ;) -dnh, considering strace and ltrace the swiss-knives of the first(-and-a-half)-step of debugging (i.e. before using gdb, reading source etc. ;) --

(void *)'\0' Didn't you see the sign? It said VOID WHERE PROHIBITED Don't tell me you can't C. -- the Internet Oracle [#1307-01] -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org