PATH not read on login

N

nvaz

Hi all,
I'm still new to freebsd (coming from linux), just finished installing everything and setting things up. I created a regular user account and built some basic apps from the ports (text editors, browser, etc).
Everything runs fine so far, but the regular user account seems to be unable to read the PATH variable. I.e., from the command line I have to enter the full path to every executable (/usr/local/bin/...), I cannot just call it as I would expect it should be, right?
Guess I'm missing something here but cannot figure out what.
Any ideas?
 
Hi,
I finally solved it. The PATH wasn't actually the issue, this problem happened only with those apps built from the ports ???. Have no idea why. But after switching my shell (I was using sh) to csh I'm able to run all commands just fine.
Thanks for the tip.
 
I suggest using tcsh(1) for a user's shell. It has all the features of csh(1) plus a few more. It's a good shell for interactive use. Use /bin/sh for scripting work.

(Technically csh and tcsh are the same, just started with a different feature set. Similar to sh and bash being the same on various Linux distributions)
 
nvaz said:
I finally solved it. The PATH wasn't actually the issue, this problem happened only with those apps built from the ports ???. Have no idea why.
Click to expand...
Still sounds like a possible PATH issue to me.

It's important to realize that FreeBSD basically consists of 2 "parts". On one hand you have your base system, this is a fully stand-alone OS which provides some utilities and minimal services on its own (services like Cron, Sendmail, the System logger (syslogd), Power management (powerd), and so on...). Key locations for normal system binaries are /usr/bin and /bin.

The Ports collection is basically "3rd party software", it's the 2nd theoretical part of FreeBSD. These programs get fully installed "on top" of your system. By default all in /usr/local. As such they never intermingle with your system itself as is the custom on Linux.

Now, by default /usr/local is included in your search path (specifically /usr/local/sbin and /usr/local/bin). But if some kind of shell overrules that then this will obviously no longer work. Another problem could be caused by a program installing its executables in another location (example being java/openjdk8 which installs itself in /usr/local/openjdk8, although it does create symlinks as well).

One thing though... Nothing wrong with using the CShell as an end user, but personally I always preferred to use a different shell between the root account and a regular user account. My personal favorite being the Korn shell (shells/pdksh) for myself.

Thing is... Root shouldn't be treated casually. And somewhat forcing yourself into another command set can help with that. If I'm logged on as Root then a simple for a in `ls *profile`; do echo $a; done won't work anymore because of the C shell, even though I'm pretty accustomed to using that.

So now I'd have to use # foreach a (`ls *profile`) and resolve the rest interactively. It somewhat forces me into this set up and I think that's a good difference to have between a root environment and that of a plain user.

Maybe food for thought?
 
ShelLuser said:
personally I always preferred to use a different shell between the root account and a regular user account
Click to expand...

Well, that sounds about right.

I've always used bash in my linux environments, but it wouldn't hurt to leave the comfort zone for once.
Guess I'll be building some shells tomorrow :D!!
 
You must log in or register to reply here.
Back
Top