/opt/bin in root's PATHForum: DSL Ideas and Suggestions Topic: /opt/bin in root's PATH started by: WDef Posted by WDef on Oct. 07 2006,10:35
Could /opt/bin be added to the root user's path?This would be for the benefit of ucis that drop symlinks to their binaries into /opt/bin for command line use (like many of mine do eg the various tools in mplayer uci). User dsl has /opt/bin in PATH, so these are easily run from the command line. But user root has to cd to /opt/whatever Moreover some binaries expect to find other binaries in PATH, so won't work when they don't find them. I note that /etc/bashrc (I think it is) puts dirs into PATH that don't exist eg /opt/kde or something (I'm not on dsl). Posted by mikshaw on Oct. 07 2006,13:39
I honestly don't think /etc/bashrc is used in DSL, although I've never tried removing it. As far as I know, /etc/bash.bashrc and /etc/profile are used to set up the default environment.
Posted by WDef on Oct. 08 2006,10:28
Whichever. /etc/profile is the usual I know. It's not the point of the thread.. Posted by WDef on Oct. 27 2006,13:01
*BUMP*Mikshaw was on topic, my apologies. It seems . /etc/profile is commented out in /etc/bash.bashrc, which is why /opt/bin is not in root's PATH at present. Any information as to to why this is so? Is there some reason it shouldn't just be put in root's PATH in /etc/bash.bashrc? Posted by mikshaw on Oct. 27 2006,14:11
If I remember correctly, there was once an issue with PATH being reset each time a new shell was opened, because profile was not being used only at login. I can't recall what the solution was, but this might have been it. If so, I think it was appropriate for that particular issue. /etc/bash.bashrc is not a login script, so it should not run /etc/profile.I don't know why /opt/bin is not added to root's PATH...shouldn't /etc/profile run automatically for all users? Posted by roberts on Oct. 27 2006,16:13
dsl@box:~$ su - rootPassword: root@ttyp0[root]# echo $PATH /sbin:/bin:/usr/sbin:/usr/bin:/usr/X11R6/bin:/usr/local/sbin:/usr/local/bin:/usr/games:/opt/bin:. root@ttyp0[root]# Looks like /opt/bin is there to me. What root access/login procedure is being attempted? Posted by ^thehatsrule^ on Oct. 27 2006,16:25
PATH is set when a login shell happens - if it isn't a login shell, profile won't be sourced.I believe most distros have root's PATH set differently anyways. Posted by mikshaw on Oct. 27 2006,17:19
dsl@box:~$ sudo subash-2.05b# echo $PATH /sbin:/bin:/usr/sbin:/usr/bin:/usr/bin/X11:/usr/local/sbin:/usr/local/bin I see your point, hats....hadn't thought about that. another variation... dsl@box:~$ sudo echo $PATH /sbin:/bin:/usr/sbin:/usr/bin:/usr/X11R6/bin:/usr/local/sbin:/usr/local/bin:/usr/games:/opt/bin:.:. Posted by ^thehatsrule^ on Oct. 27 2006,17:34
Right, so you'd want to use sudo su -
Posted by WDef on Oct. 29 2006,13:40
Ah, helpful replies guys, thx. On most distros it's the ordinary user's PATH that's more restricted than root's. dsl has a non-login root shell, but it's still root.I noticed this because /opt/bin isn't in PATH when I open a root shell from the right-click menu (I only rarely type su - on dsl) and it might be useful if binaries linked into /opt/bin could be found from any type of root shell, just like binaries in /bin whatever, hence found by other apps running as root that look in PATH. Root should be able to find anything in PATH that user dsl can, yes? Posted by roberts on Oct. 29 2006,16:26
Correct. For liveCD/frugal it is not a login shell.I will adjust Root Shell from menu and Right Click Aterm Icon to give correct root PATHing in next RC. For fluxbox menu Root Shell lines change -e sudo /bin/bash to -e sudo su - For Aterm.lnk change MenuCommand1 from sudo aterm -cr red to aterm -cr red -e sudo su - Posted by ^thehatsrule^ on Oct. 29 2006,23:40
Actually that doesn't give you what you think it will. In this case.. $PATH would've been subbed in by the "dsl@box" parent shell before the line continues. Posted by mikshaw on Oct. 30 2006,02:10
yes, but you'd get the same result as if you used "sudo command" to run a command found in /opt/bin...it would still work even though /opt/bin is not in root's PATH because it uses dsl's environment.
Posted by ^thehatsrule^ on Oct. 30 2006,14:31
Ah, I see what you were trying to get at now.(I had thought you were trying to output root's PATH that way) Personally, I mostly use sudo <command> anyways, so that's probably why I never had this problem... Posted by WDef on Nov. 02 2006,11:24
I notice when using Robert's fix that these root shells now start using their home /root.A good thing anyway I think, that's more standard - root's bash history is in that dir. I like the blue prompt too - hard to ignore that you have a root shell open. Perhaps a line "root" will need to be added to filetool.lst so root's bash history gets backed up? Posted by mikshaw on Nov. 02 2006,13:02
Using root's environment also prevents problems that may occur if you use mc a lot. My system uses a persistent home and persistent root home, which is mounted from bootlocal.sh
Posted by WDef on Nov. 21 2006,15:28
Somewhat belated observation ..I notice apps lauched from these shells can't access the display, so no guis. (Instead I open a user dsl shell and use sudo). Posted by ^thehatsrule^ on Nov. 21 2006,15:57
I suppose that's because now all the env vars are overwritten when a login shell is invoked - you'd have to pass the X vars over somehow (see DISPLAY and XAUTHORITY)
Posted by WDef on Nov. 21 2006,16:13
No, the DISPLAY variable is still set in the environment. But the display can't be accessed, I'm guessing because it's not user dsl doing the accessing.
Posted by roberts on Nov. 21 2006,16:35
This issue has been addressed in 3.1RC series.
After trying the RC you still have an issue you should post in the RC section. Note: You must update your menu and Aterm.lnk files which may be overwritten from your backup. Posted by ^thehatsrule^ on Nov. 21 2006,17:50
wdef, are you sure? The login shell usually does not keep any env vars anyways, has to be explicitly set. As roberts suggested - are you on the latest RC? (I haven't checked it out yet).If you still have the problem, try `echo $DISPLAY and $XAUTHORITY` and see if they are set at all. sidenote to roberts: I suppose you meant /root/.bashrc |