On Fri, 17 Nov 2000, Pete Forman wrote:
> I thought that we'd been over this ground before. In /bin/sh on
> Solaris 2.5 to 8 (at least) and on ISC, if the builtin test fails
> for a syntactic reason the rest of the line, including semicolons,
> is discarded.
Damn. I now remember that we indeed covered this. But I failed to
learn this lesson from it. Thanks for pounding that lesson into my
head once again.
> An "echo $?" on a fresh line after "test -e /" does still result in
> "1". So were you to split the check into two commands the behaviour
> of "test -e" would be assessed correctly.
Good. Is somebody willing to see what happens when tramp-run-test is
changed to send `test' and `echo $?' on separate lines?
> BTW, if you insert "/usr/xpg4/bin" before "/bin" in
> tramp-remote-path then you've a better chance of finding a decent sh
> on Solaris.
Well, Tramp does "exec /bin/sh" to be fairly certain about getting a
Bourne-ish shell. I didn't expect vagarities like this in the /bin/sh
behavior; I thought as long as I don't do strange things, any
Bourne-ish shell will do. I'm not sure that it is a good idea to
change the "exec /bin/sh" to something else, because at that time, no
shell environment is set up, really.
One possible approach to the whole thing would be to search for a
decent shell first, then look for a working `file exists' command.
But then we'd have to look real close that the shell-searching
machinery doesn't use the `file exists' command. But I think that it
is possible; we can use a `file executable' command instead.
kai
--
The arms should be held in a natural and unaffected way and never
be conspicuous. -- Revised Technique of Latin American Dancing
