The reason for passing av along in the execv call is that it is the
name of the program you are running. That's what av is for -- it isn't
the binary filename. For example, if you type in
ls -l /tmp
to your shell, it will call
execv("/bin/ls", ["ls" "-l" "/tmp"])
Here's another way of looking at it: I merely preserve scsh-tramp's client's
idea of what av should be, passing it along.
Unix doesn't really have a clearly stated policy on this, mind you, so
what I'm doing is just what I sort of managed to infer for myself. Just about
the only useful thing you can do with av, in any event, is use it to
construct error messages and useage messages. It's not very critical.
If things were the other way -- av is the filename of the binary
being executed, we wouldn't need the -o <binary> randomness.
I am completely baffled by your lossage, particularly the voodoo you described
in your second msg. I use scsh on a NeXTSTEP Intel box, and do not have these
problems. You might try writing the equivalent of scsh-tramp.c as a
Scheme procedure -- which is trivial in Scheme -- and forking that from
scsh to see if and how it loses. It's hard for me to debug this for you,
because I can't replicate your problem.
But I will say this: every time I've been screwed in NS, it has always been
their Posix support. Compiling with -posix breaks several parts of Unix; it's
really irritating that these jerks don't take the standard seriously.
(My favorite bit of lossage is that getpwnam(), when compiled with -posix,
reports that every user is uid 0, i.e., root. So if your Web server, say,
uses getpwnam() + setuid() to run as user nobody or user ftp, it will instead
quietly stay user root. Since my Web server allows people to upload Scheme
into the server from anywhere in the world, this made me a little nervous.
So you might look into trying it with and without -posix.