Re: odd search order looking for perl?
On Sun, 18 Feb 2001, Francesco Potorti` wrote: Yes. The correct way is: -f $dir/perl -a -x $dir/perl Now I'm confused. What if /usr/bin/perl is a symlink to /usr/bin/perl5.005 or something? It works with a file (or simlink) and with a directory (or simlink), both with bash's bilt-in test and the stand-alone test. Committed. Thanks. kai -- Be indiscrete. Do it continuously.
Re: odd search order looking for perl?
On Sat, 17 Feb 2001, Francesco Potorti` wrote: Yes. The correct way is: -f $dir/perl -a -x $dir/perl Now I'm confused. What if /usr/bin/perl is a symlink to /usr/bin/perl5.005 or something? Is it better to say "-f $d/perl -a -x $d/perl", or "-x $d/perl -a \! -d $d/perl"? kai -- Be indiscrete. Do it continuously.
Re: odd search order looking for perl?
I was afraid that this which-like command might be known by various names on various systems, and the output might vary. I tried this, and I think it should work on any bourne shell: echo $PATH | tr : \\n | while read dir; do if [ -x $dir/perl ]; then echo $dir/perl; break; fi; done Nifty. I have now changed the implementation of tramp-find-executable to use something like this. There's a problem with this if you have a directory named "perl" inside a directory in your path. I'm not all that familiar with Bourne shell syntax, so the following may not be syntactically correct, but you need to do something like this: do if [ -x $dir/perl ! -d $dir/perl ] instead of just do if [ -x $dir/perl ] Later, Ed
Re: odd search order looking for perl?
do if [ -x $dir/perl ! -d $dir/perl ] instead of just do if [ -x $dir/perl ] Yes. The correct way is: -f $dir/perl -a -x $dir/perl
Re: odd search order looking for perl?
On Wed, 24 Jan 2001, Francesco Potorti` wrote: I was afraid that this which-like command might be known by various names on various systems, and the output might vary. I tried this, and I think it should work on any bourne shell: echo $PATH | tr : \\n | while read dir; do if [ -x $dir/perl ]; then echo $dir/perl; break; fi; done Nifty. I have now changed the implementation of tramp-find-executable to use something like this. Any other functions which should be optimized in this way? kai -- Be indiscrete. Do it continuously.
Re: odd search order looking for perl?
Any other functions which should be optimized in this way? Maybe. Proposals?
Re: odd search order looking for perl?
Francesco Potorti` writes: I was afraid that this which-like command might be known by various names on various systems, and the output might vary. I tried this, and I think it should work on any bourne shell: Yes but not for any tr. Try this change echo $PATH | tr : \\n | tr : \\012 | while read dir; do if [ -x $dir/perl ]; then echo $dir/perl; break; fi; done -- Pete Forman -./\.- Disclaimer: This post is originated WesternGeco -./\.- by myself and does not represent [EMAIL PROTECTED] -./\.- opinion of Schlumberger, Baker http://www.crosswinds.net/~petef -./\.- Hughes or their divisions.
Re: odd search order looking for perl?
Pete Forman [EMAIL PROTECTED] writes: Francesco Potorti` writes: I was afraid that this which-like command might be known by various names on various systems, and the output might vary. I tried this, and I think it should work on any bourne shell: Yes but not for any tr. Try this change [...] Unless anyone raises serious objections to this, I intend to make this change tonight, test it a little, then commit. That's in about eight hours, tops. This is, like, official notice that you might break if you update tomorrow. :) Daniel -- Never express yourself more clearly than you are able to think. -- Niels Bohr
Re: odd search order looking for perl?
I was afraid that this which-like command might be known by various names on various systems, and the output might vary. I tried this, and I think it should work on any bourne shell: echo $PATH | tr : \\n | while read dir; do if [ -x $dir/perl ]; then echo $dir/perl; break; fi; done
Re: odd search order looking for perl?
Kai, # Bourne shell if [ "$SHELL" = "/bin/sh" ] ; then echo bourne, bourne fi # Csh if ( "$SHELL" == "/bin/csh" ) then echo c, c endif As you can see, even the `if' command is quite different. Perhaps you were aiming at something entirely different, but if you were just looking to check the value of $SHELL: test "$SHELL" = "/bin/sh" echo bourne test "$SHELL" = "/bin/csh" echo c As far as MacOS X and /bin/sh: from the accounts I've read, the Apple engineers have been pretty savvy in their design, so I've no doubt that /bin/sh exists, either as a link to /bin/zsh or as an executable. After all, I recall configure scripts working and they start with the line: #!/bin/sh Mark. -- New signature coming soon!
Re: odd search order looking for perl?
[EMAIL PROTECTED] (Kai Grojohann) writes: I think people should init their shell like this: case "$TERM" in linux|xterm) alias ls=... ;; esac After all, printing color sequences on if $TERM=dumb does not make sense. I've done basically the same thing for $TERM=emacs in shell mode Alas, Tramp does not set $TERM correctly. Whee. I think Emacs should do that, but in the meantime, I intend to frob Emacs to do that. I was hoping to get a basic Bourne shell after "exec /bin/sh". Therefore, the aliases should be off after this. Are they? Yes they are. alias ls='ls --color=auto' is in .bashrc escape sequences when I manually "exec /bin/sh". Perhaps I've misdiagnosed this prolblem. /r:sprout@helium: the "*tramp/scp sprout@helium*" buffer pops up with bash$ / When I comment out the ls alias, dired properly loads on my homedir. /bin/sh is bash 1.14.7 -- Chris Green [EMAIL PROTECTED] A good pun is its own reword.
Re: odd search order looking for perl?
On Thu, 18 Jan 2001, Bruce Ingalls wrote: I use which.el, myself, which is fast. However, I recall that there is some which()-like emacs function. Err. I need to do this on the remote host, not on the local host. And the point of Tramp is that I don't need Emacs on the remote host. And if I use which.el to check files on the remote host, that will result in doing file-executable-p for a couple of remote files. Presumably the ones in tramp-remote-path. And that's what I'm doing right now... You are probably right; most modern unixes should have at least ksh-88 (original old Korn Shell) installed. Except Mac OS-X. However, zsh is pretty much ksh-88 compliant. You could probably do /bin/ksh || /bin/zsh and hope that these are the correct directories. Okay, I will wait for MacOS X users to tell me what's the state of affairs on that system. Too bad that I have to leave out the "exec", though. Oh, well. Hm. Let's just hope that "/bin/sh || /bin/zsh" works on all shells that people might be using as login shells... OTOH, installing a symlink isn't asking too much of the Apple guys, is it. I'd suppose that quite a number of existing tools expect a program /bin/sh on every Unix machine, which should behave vaguely Bourne-ish. GNU autoconf produced configure scripts would break I guess... kai -- Be indiscrete. Do it continuously.
Re: odd search order looking for perl?
On 18 Jan 2001, Chris Green wrote: [EMAIL PROTECTED] (Kai Grojohann) writes: I was hoping to get a basic Bourne shell after "exec /bin/sh". Therefore, the aliases should be off after this. Are they? Yes they are. Good. According to the docs, bash called as sh isn't supposed to read ~/.bashrc. alias ls='ls --color=auto' is in .bashrc escape sequences when I manually "exec /bin/sh". Perhaps I've misdiagnosed this prolblem. /r:sprout@helium: the "*tramp/scp sprout@helium*" buffer pops up with bash$ / When I comment out the ls alias, dired properly loads on my homedir. /bin/sh is bash 1.14.7 Well. Hm. I confess that I've also got a strange prompt and I had to frob shell-prompt-pattern to recognize optional color escape sequences. Not pretty at all. Okay. There is a new version of Tramp now which locally sets the env var TERM to "dumb" when opening the connection. Does this work? kai -- Be indiscrete. Do it continuously.
Re: odd search order looking for perl?
[EMAIL PROTECTED] (Kai Grojohann) writes: I confess that I've also got a strange prompt and I had to frob shell-prompt-pattern to recognize optional color escape sequences. Not pretty at all. Okay. There is a new version of Tramp now which locally sets the env var TERM to "dumb" when opening the connection. Does this work? Yes works perfectly with both scp and rsync backends. Thanks very much. I'm a very happy camper right now. Cheers, Chris -- Chris Green [EMAIL PROTECTED] Fame may be fleeting but obscurity is forever.
odd search order looking for perl?
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_exit_status 1 $ test -x /usr/local/bin/perl5 ; echo tramp_exit_status $? tramp_exit_status 1 $ test -x /usr/ccs/bin/perl5 ; echo tramp_exit_status $? tramp_exit_status 1 $ test -x /local/bin/perl5 ; echo tramp_exit_status $? tramp_exit_status 1 $ test -x /local/freeware/bin/perl5 ; echo tramp_exit_status $? tramp_exit_status 1 $ test -x /local/gnu/bin/perl5 ; echo tramp_exit_status $? tramp_exit_status 1 $ test -x /usr/freeware/bin/perl5 ; echo tramp_exit_status $? tramp_exit_status 1 $ test -x /usr/pkg/bin/perl5 ; echo tramp_exit_status $? tramp_exit_status 1 $ test -x /bin/perl ; echo tramp_exit_status $? tramp_exit_status 1 $ test -x /usr/bin/perl ; echo tramp_exit_status $? tramp_exit_status 0 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? Skip
Re: odd search order looking for perl?
[EMAIL PROTECTED] (Kai Grojohann) 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 there already is ) a list of commands that get executed on the remote host to ``prep'' sh for tramp? The main one that comes to mind for me is unalias ls instead of getting ls --color=auto commented out. Of course, ls --color=auto | cat also does the right thing as does ls --color=auto --color=none -- Chris Green [EMAIL PROTECTED] This is my signature. There are many like it but this one is mine.
Re: odd search order looking for perl?
Kai Grojohann 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 what is available, if you don't like what you have. Does it make sense to do a which()-like command, and use that version of perl? I'm not sure which perl5 features that tramp exploits. Finally, I'm not sure if Mac OS-X will have any shell available, other than /bin/zsh. The traditional solution is to have a sh and a csh solution, and decide which to use.
Re: odd search order looking for perl?
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 than 4 years old. Chris Green wrote: [EMAIL PROTECTED] (Kai Grojohann) 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 there already is ) a list of commands that get executed on the remote host to ``prep'' sh for tramp? The main one that comes to mind for me is unalias ls instead of getting ls --color=auto commented out. Of course, ls --color=auto | cat also does the right thing as does ls --color=auto --color=none
Re: odd search order looking for perl?
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 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 than 4 years old. thats why I was thinking of post setup commands rather than proposing it as a default. Your idea is much better :) Cheers, Chris -- Chris Green [EMAIL PROTECTED] You now have 14 minutes to reach minimum safe distance.
Re: odd search order looking for perl?
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 where perl5 exists, perl might be version 4, and Tramp does not work with Perl 4. Tramp checks directories in the sequence mentioned in tramp-remote-path. You can fiddle with that variable if you like. (It is safe to include directories in this variable which do not exist on all hosts, since Tramp first goes through this list of directories and for each host discards the ones that don't exist.) I'm trying to write Tramp in such a way that it figures out as many things as possible about the remote environment on its own. Maybe this was a wrong decision. I'm open to arguments. My thinking was that people probably don't know much about the remote hosts, so asking them a lot of questions about each host beforehand is not a good idea. 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. Before running "exec /bin/sh" on the remote host, it is nearly impossible to find out anything about that host at all. (Waiting for the shell prompt and 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. Some people put forth some arguments which kind of convinced me that some people might like "exec /bin/ksh" at that point or whatever. I'm sure you will be able to find the discussion at www.mailarchive.com (or www.mail-archives.com?). Refresh my memory :-) kai -- Be indiscrete. Do it continuously.
