Current mood:	annoyed
Current music:	Down by the Riverside - Raffi
Entry tags:	geeky, vmware

xterm and execv
The xterm application, which is distributed with most X11 implementations, sports a -e flag that accepts a command followed by a sequence of arguments, all of which are space-delimited. I'd been exploiting this feature to ensure that when I programatically executed console apps inside a Linux VM, the user could interact with them. All I had to do was run xterm with the -e flag and follow that with the location of the console app and its arguments (e.g. xterm -e "xeyes -center red"). Everything had been working fine when I tried this on modern Linux distros but today one of the QA people tried it on Redhat 8, which was released in 2002, and saw a nasty error message complaining that the execvp syscall could not find the specified file.

Curious about the cause of this problem, I tried manually running xterm under strace with the same arguments. This revealed that the xterm binary in XFree86 4.2 that was part of Redhat 8 simply tries to call execvp with the entire quoted string as the first argument. Since that string contained space-delimited arguments appended to the binary's name, it couldn't be resolved as a valid pathname by execvp. That made sense but it didn't explain why it worked in newer releases of xterm. Trying the same thing with the xterm binary on my Ubuntu 6.10 system revealed that xterm now falls back on passing the entire quoted string to the shell for execution if the call to execve fails. Since bash knows to deal with the space-delimited arguments, that works fine.

I was trivially able to solve the problem by removing the quotes.