On Tue, 16 Jan 2001, Bruce Ingalls wrote:
> tramp.el is missing a
>(require 'advice)
Okay, I've added this.
> I see Compiling ~tramp/lisp/tramp.el...done Warning: The following
> functions are not known to be defined: coding-system-p,
> process-coding-system, set-buffer-process-coding-syste
I noticed this odd sequence of tests for perl in my tramp debug buffer:
$ test -x /bin/perl5 ; echo tramp_exit_status $?
tramp_exit_status 1
$ test -x /usr/bin/perl5 ; echo tramp_exit_status $?
tramp_exit_status 1
$ test -x /usr/sbin/perl5 ; echo tramp_exit_status $?
tramp
[EMAIL PROTECTED] (Kai Großjohann) writes:
> then issuing this command is quite fragile already.) In the
> beginning, I assumed that every Unix host had a /bin/sh and that "exec
> /bin/sh" would be a good way to start a known shell from the
> beginning.
Would it be possible to have ( or perhaps
Kai Großjohann wrote:
>
> The only reason that tramp-remote-sh exists is that "exec /bin/sh" is
> the very first command that's issued by Tramp, so that it at least
> knows how to set the prompt and stuff like this.
Isn't $SHELL set at remote login?
You can usually look at /etc/shells to see wh
Perhaps certain commands should be setq()ed.
You do not need to unalias ls, if you call
\ls
which invokes the original ls. I tested this command on solaris's
/bin/sh, which is _not_ xpg4 compliant. It still works.
ls --color=auto only works for gnu ls, and probably only gnu ls that
is less tha
Bruce Ingalls <[EMAIL PROTECTED]> writes:
> Perhaps certain commands should be setq()ed.
> You do not need to unalias ls, if you call
>\ls
Didn't know this factoid - thanks you've saved me from having to type
/bin/ls everytime I mean it.
> which invokes the original ls. I tested this comman
On Wed, 17 Jan 2001, Skip Montanaro wrote:
> Why is /usr/bin/perl checked last? Seems to me to be the most
> likely place to find it. Why not use something akin to
> tramp-sh-program to allow users to specify odd locations for perl?
Tramp must check for perl5 first, since on those systems wher
--bug report follows this line--
I've tried tu, su, sudu, multiu/telnet/sudo and of all these
connection methods, only tu seems to work. This is a new (to me)
machine, so it is possible that I'm doing something wacky.
Here is the output after toggle-debug-on-error for one of the failing
metho
