Bug#333765: xterm -e no longer works with relative paths
Package: xterm
Version: 6.8.2.dfsg.1-7
Part of my session arrangements include running this command:
xterm -e .configs/rxprofile
from in my home directory (/u/ian in this case).
/u/ian/.configs/rxprofile exists and is an executable shell script.
This no longer works (!)
In
strace -Ffot xterm -e .configs/rxprofile
I see this:
17686 execve("/usr/bin/X11/xterm", ["xterm", "-e", ".configs/rxprofile"], [/* 38 vars */]) = 0
...
17686 fork() = 17687
...
17687 rt_sigaction(SIGHUP, {SIG_DFL}, {SIG_IGN}, 8) = 0
17687 access("/u/ian/personal/linux/bin/.configs/rxprofile", X_OK) = -1 ENOENT (No such file or directory)
17687 access("/usr/local/bin/.configs/rxprofile", X_OK) = -1 ENOENT (No such file or directory)
17687 access("/bin/.configs/rxprofile", X_OK) = -1 ENOENT (No such file or directory)
17687 access("/usr/bin/.configs/rxprofile", X_OK) = -1 ENOENT (No such file or directory)
17687 access("/usr/local/sbin/.configs/rxprofile", X_OK) = -1 ENOENT (No such file or directory)
17687 access("/sbin/.configs/rxprofile", X_OK) = -1 ENOENT (No such file or directory)
17687 access("/usr/sbin/.configs/rxprofile", X_OK) = -1 ENOENT (No such file or directory)
17687 access("/usr/bin/X11/.configs/rxprofile", X_OK) = -1 ENOENT (No such file or directory)
17687 access("/usr/games/.configs/rxprofile", X_OK) = -1 ENOENT (No such file or directory)
17687 access("/bin/.configs/rxprofile", X_OK) = -1 ENOENT (No such file or directory)
17687 write(2, "No absolute path found for shell"..., 53) = 53
Which is quite insane enough, but it is followed by:
17687 --- SIGSEGV (Segmentation fault) @ 0 (0) ---
Just as icing on the cake, another deficiency in xterm means that I
don't see this message - the window just disappears again.
On woody's xterm I see this:
9915 execve("/usr/bin/X11/xterm", ["xterm", "-e", ".configs/rxprofile"], [/* 43 vars */]) = 0
...
9915 fork() = 9916
...
9916 rt_sigaction(SIGHUP, {SIG_DFL}, {SIG_IGN}, 8) = 0
9916 execve(".configs/rxprofile", [".configs/rxprofile"], [/* 43 vars */]) = 0
which is exactly as it should be.
Can we have the old sane behaviour back please ?
Ian.
Reply to: