scp: command not found.

[Glenn S. Ramalho]

In message <Pine.LNX.4.10.10004110922460.826-100000 at 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