3 ms·
execve(2) on my machine defines ELOOP lie this: Too many symbolic links were encountered in translating the pathname. Refer to sys/kern/imgact_shell.c and ^do_
by gkya 10y ago
execve(2) on my machine defines ELOOP lie this: Too many symbolic links were encountered in translating the pathname.
Refer to sys/kern/imgact_shell.c and ^do_execve in sys/kern/kern_exec.c, I skimmed but could not find why it ran.
- cyphar 10y agoPresumably then, whatever shell you're using decides to just execute the code as a subshell rather than use execve(2). Can you dtrace it to figure out whether it actually calls execve(2)?
- gkya 10y agoAfter running dtrace as $ sudo dtrace -n 'syscall::execve*:entry { printf("%s %s", execname, copyinstr(arg0)); }' I had this output 0 51617 execve:entry sh ./quine 1 51617 execve:entry sh /bin/sh 1 51617 execve:entry sh /bin/cat Altho this is the first time I use dtrace. I can try to run another command you can ask me to. My login shell is the Bourne shell. However I tried bash, csh and tcsh too, it works, so it's probably the system level code that substitutes /bin/sh (maybe because it's my login shell?) to the interpreter.
- cyphar 10y agoI think shells are doing that. Otherwise you wouldn't see the execve("/bin/sh") syscall entry (it would get silently translated inside the kernel).