Showing results for 
Search instead for 
Did you mean: 

why Tru64 sshd can't work with ${PATH:-/usr/bin:.}

Go to solution
Frequent Advisor

why Tru64 sshd can't work with ${PATH:-/usr/bin:.}


Does anyone know why the above path substitution does not work with Tru64 sshd??

The . or current directory does not appears in the env path after login. I have to move the . outside the curly bracket for it to appears in the env path.

Anyway to define the path in sshd_config???
Al Licause
Trusted Contributor

Re: why Tru64 sshd can't work with ${PATH:-/usr/bin:.}

YL.....can you please supply a bit more information:

What version of the OS ?
What version of ssh ?
What shell are you using ?

I've asked several different people and no one seems to understand the syntax you've used, so we're not quite sure
what end result your attempting to achieve.

I did take your line as entered and placed it in a sh script. Just prior to this line I null'd the PATH variable then after your statement was executed, I echo'd the results.

In my case on v5.1b Tru64unix
with the v3.2 ssh that comes with the OS, I saw the same results as that from a straight telnet session.
And in both cases, the "." was in the path.

Don Ritchey
Frequent Advisor

Re: why Tru64 sshd can't work with ${PATH:-/usr/bin:.}

[[ By the way: This should be found in the user's profile and only applies to /bin/sh and /bin/ksh. ]]

The string shown will set the PATH variable to the user's home directory's bin followed by the contents of the existing PATH variable, or, if that is not set, then to "/usr/bin:.".

If PATH has a value going in, then this will pre-pend the $HOME/bin to it. If PATH is not set, then the PATH will be "${HOME}/bin:/usr/bin:."

I suspect the reason you are not seeing the "." in the path is that PATH is probably always being set to some sane value going into the initialization logic of the user's profile. Most login programs set a default path (usually something like "/usr/bin:/usr/bin/X11:/usr/dt/bin") before spawning the user's shell.

Also, for the functionally paranoid, the practice of including the current working directory (".") in a PATH is discouraged, since this is a common vector for worms and Trojan Horses. Naive users may be permitted this practice, but experienced users should be discouraged, and administrators should be forbidden to use this. One can always run a commend off the PATH by specifying "./command" to run a command in the current directory, or a relative path to the executable.