Mailing List Archive

Where is scp on the remote machine? It has to be in sshd's path.
So set

--with-default-path to configure appropriately.

For some reason, openssh does not include exec prefix in the default
path.

Mate
On Tue, Apr 11, 2000 at 09:24:17AM -0700, Steve Mertz wrote:
>
> Hey.
>
> I found references to my problem 'scp: command not found' in the archives.
> But I could not find a solution to this problem. Could someone please
> help me out here?
>
> Info: OpenSSH 1.2.3, RedHat 6.1
>
> Thanks!
> -- Steve
>
>

--
---
Mate Wierdl | Dept. of Math. Sciences | University of Memphis

On Tue, 11 Apr 2000, Steve Mertz wrote:

>
> Hey.
>
> I found references to my problem 'scp: command not found' in the archives.
> But I could not find a solution to this problem. Could someone please
> help me out here?
>
> Info: OpenSSH 1.2.3, RedHat 6.1

Have you read the UPGRADING file? It contains some pretty explicit
instructions.

-d


--
| "Bombay is 250ms from New York in the new world order" - Alan Cox
| Damien Miller - http://www.mindrot.org/
| Email: djm@mindrot.org (home) -or- djm@ibs.com.au (work)

In message <Pine.LNX.4.10.10004110922460.826-100000@clunk.dii.local>,Steve Mert
z writes:
>
>Hey.
>
>I found references to my problem 'scp: command not found' in the archives.
>But I could not find a solution to this problem. Could someone please
>help me out here?

I could be wrong, but I think I got that exact error too. What happens is
when you run scp, the scp command runs an ssh connection to the other
system and then runs scp over there.

Let's say you type:

scp landreth:lei .

scp willconnect to landreth and run an scp to grab the file lei. That
file is then sent back to your host and stored locally by SSH. The problem
with this is when scp connects it needs to be able to find scp.

If you run:

remsh landreth ls
rsh landreth ls
ssh landreth ls

These commands do not load your .login. CSH and TCSH will run your
.cshrc/.tcshrc/whatever. That is it. Your path will then become whatever
the default on the system is. If scp is not on that default and you
are a KSH user or do not set your path in your .cshrc/.tcshrc then
you will not find scp.

% remsh dingdong echo \$PATH
/usr/bin:/usr/ccs/bin:/usr/bin/X11:/usr/contrib/bin:/usr/local/bin:
%

You should get your path on the other machine. I recommand you
change your default path on the system to include the
scp directory (like /usr/local/bin or /usr/local/ssh/bin or whatever it is).

Another solution is to add somwthing like this. I use this .tcshrc
on the systems I have tcsh. Not everyone allows me to use KSH. :)
I noticed this seemed to work for me on HP/UX. It might be different on
other systems. I hate setups in CSH/TCSH in which people put everything under
the sun in the .cshrc/.tcshrc. This makes every new window dog slow. Plus
if your path is set in it by appending stuff to the default path, you soon
explode the PATH size by reappending the same stuff. This one is quick and
fixes the problem. This is how it works:

- If the $DT variable is set, we are in CDE logging in on console. Do nothing.
CDE does not care about any of the things in the .cshrc/.tcshrc as it
influences CDE. Just aliases and TCSH parameters.

- If it is not set, check the $prompt variable. If it is set, this is an
interactive shell window like an xterm or a rlogin. Do not reset the PATH
or anything else as that stuff is loaded in the system wide startup files
that we are supposed to load. That file was already loaded. ssh without
a command will run this too.

- If the $prompt is not set, this could be a non interactive ssh/scp command
or a shell script:
- If $term is set, this command was ran from an
xterm/dtterm. Definitelly an interactive session. This
means that the path was already set.
- If you use ssh host command or scp, $term is not set. Set any thing
you might need like the path to scp.
- The third case is a little tricky. What if you type:

ssh host tcshelscript

Your .tcshrc is loaded twice. Once by ssh starting the shell and once
by the tcsh sctipt. To keep this double reading from happening I
set an environment variable flag __REMSH_check to 1. The fist
time will load the startup file and set the flag. The tcshell script
will then never reload the information as __REMSH_check is set.

an xterm, $term will be set but $prompt will not be set.

# $Header: tcshrc,v 1.3 98/12/15 17:33:29 ramalho Exp $

# Note: TCSH only sources the .cshrc if there is no .tcshrc. It is then
# wiser to name its startup file .tcshrc to not confuse CSH scripts.

if ( ! ${?DT} ) then
umask 022
if ( $?prompt ) then # shell is interactive.
set prompt = "%m %h: "
source $HOME/.aliases
bindkey -v
else # Either a shell script or remsh
if ( ! $?term && ! ${?__REMSH_check} ) then
setenv __REMSH_check 1
source /usr/local/public/startup/csh.cshrc # Definitelly remsh
set path=( /user/ramalho/bin $path )
endif
endif
endif

In message <20000411124851.A9056@moni.msci.memphis.edu>,Mate Wierdl writes:
>Where is scp on the remote machine? It has to be in sshd's path.
>So set
>
>--with-default-path to configure appropriately.
>
>For some reason, openssh does not include exec prefix in the default
>path.

It is a problem if SSH changes location from one machine to another. It
is not always easy to get everyone to put the tool in the same place.
Mainly between different companies. Some put it in /usr/local/bin
others put it in /usr/local/opt/openssh/bin, some go for /opt/openssh/bin
others prefer /usr/local/ssh. I have also seen /usr/local/lib/openssh
and /usr/local/gnu/bin to kinda gather all the free tools in one place.

Just too many possibilities. You best bet, in my suggestion is relly on
the paths or use the command line option to tell scp where ssh is on machines
where that is not possible.