Re: $PATH and /etc/profile
Sam Halliday wrote: ... it IS differnet. if you start from the console, you should really do `startx ` to detach from the console and allow you to continue working on the console and X; hence 2 logins. No. That's not 2 logins. It's two things (a console shell and a whole X session) spawned from the same login: You logged in once. Your login-time settings were set once. You might have changed some environment variables from your login default before you started X (or when you started X, as in SOME_VAR=somevalue startx ). You don't necessarily want starting X to re-apply your login-time settings when you start X when you have already logged in. Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: $PATH and /etc/profile
Michael B Allen wrote: Bob Proulx said: That is clever and I like it. But unfortunately exec -l is a bash-ism and so that does not work if /bin/sh is not bash but a different POSIX compatible shell. Users with ash installed as /bin/sh will fail. Because 'exec -l' is not specified by POSIX /bin/sh is not required to implement it. So you can't in general make that change unless you have changed Xsession to use '#!/bin/bash'. Then it works. But many object to using nonstandard bash features like this. Is that really feasable? Is there even a way to do it without actually changing the /bin/sh link? Do you know of anyone that actually replaces bash with another shell for /bin/sh on a debian system? I think in practice that might prove to be a little daring. At least for a system with X. This has been discussed before but unfortunately I don't have pointers to the discussions. Look in debian-devel. But yes, people do actually run with /bin/sh pointing to ash. Debian Policy specifically allows /bin/sh to be any POSIX compatible shell. If scripts do not work with it then it is a bug. Many people use this as a standards compatibility test. It is a reasonably good one. If the #!/bin/sh script works with both bash and ash then the odds are very good that it is a portable script. Bob pgpO6buxI5ORc.pgp Description: PGP signature
Re: $PATH and /etc/profile
Simon L wrote: In my /etc/profile file, I wrote: PATH=/opt/j2sdk1.4.2_04/bin:/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/games:/usr/local/sbin:/usr/sbin:/sbin When I log in text mode, the entire PATH is there as I want, I can startx and when I open a terminal, the PATH is perfect. Now, if I start the computer with KDM and that I run a terminal, the PATH is only: /usr/local/bin:/usr/bin:/bin:/usr/X11R6/bin:/usr/games How can I fix that? By starting a login shell. Create ~/.xsession with the following: #!/bin/bash --login exec x-session-manager # or gnome-session or whatever. Make sure it is executable or it will have no effect. chmod a+x ~/.xsession Bob P.S. Does it seem like I answer this question about every other week? Probably only during weeks that I can find the time to read d-u. :-/ pgpv65FzVrM4j.pgp Description: PGP signature
Re: $PATH and /etc/profile
Bob Proulx wrote: Simon L wrote: When I log in text mode, the entire PATH is there as I want, I can startx and when I open a terminal, the PATH is perfect. Now, if I start the computer with KDM and that I run a terminal, the PATH is only: /usr/local/bin:/usr/bin:/bin:/usr/X11R6/bin:/usr/games By starting a login shell. Create ~/.xsession with the following: #!/bin/bash --login exec x-session-manager # or gnome-session or whatever. RG! you can't be serious!! .xsession as a LOGIN shell?? repeat after me... X windows is not your shell! Simon, the reason you do not get your PATH set correctly is that if you login at a console, /etc/profile will be read because it is a login shell. starting X from there will inherit all your settings. if however, you login via kdm/gdm/xdm, it is NOT a login shell, so /etc/profile is not read. there are good reasons for this. if you do not agree with these good reasons, then you can simply add the line . /etc/profile to your ~/.xsession file. doing as Bob suggests and changing your X login to a login shell is NOT the way to solve this problem. the only reason his solution works is because in the process of making X a login shell, /etc/profile will be sourced. in his solution you will be seen to be logged in twice. P.S. Does it seem like I answer this question about every other week? i hope you aren't giving this advise to everyone! cheers, Sam -- Free High School Science Texts http://www.nongnu.org/fhsst/ Sam's Homepages http://fommil.homeunix.org/~samuel/ http://www.ma.hw.ac.uk/~samuel/ pgpaneds0gRvr.pgp Description: PGP signature
Re: $PATH and /etc/profile
Sam Halliday wrote: Bob Proulx wrote: By starting a login shell. Create ~/.xsession with the following: #!/bin/bash --login exec x-session-manager # or gnome-session or whatever. RG! you can't be serious!! .xsession as a LOGIN shell?? repeat after me... X windows is not your shell! Yes, I am very serious. Please tell me why you are so adamantly opposed to this. (Other than it being poorly documented and confusing. I completely agree there.) This is by the design of the KDE folks upstream. Please see this KDE FAQ entry. http://www.kde.org/documentation/faq/configure.html#id2913380 9.7. KDE (kdm) does not read my .bash_profile!. The login managers xdm and kdm do not run a login shell, so .profile, .bash_profile, etc. are not sourced. When the user logs in, xdm runs Xstartup as root and then Xsession as user. So the normal practice is to add statements in Xsession to source the user profile. Please edit your Xsession and .xsession files. I don't particularly like the way KDM/KDE is set up in this regard. But changes should happen upstream in order to change and improve this situation. Simon, the reason you do not get your PATH set correctly is that if you login at a console, /etc/profile will be read because it is a login shell. starting X from there will inherit all your settings. Agreed. Also don't forget that bash will read ~/.bash_profile (or ~/.profile) and commands there normally source ~/.bashrc. if however, you login via kdm/gdm/xdm, it is NOT a login shell, so /etc/profile is not read. there are good reasons for this. if you do not agree with these good reasons, then you can simply add the line . /etc/profile to your ~/.xsession file. Negative. That won't get your ~/.bash_profile, or .login with csh, sourced. You will not be getting the user's customizations from the profile or bashrc or $ENV. You will not have the same effect as if you logged into the text console and then started X11. Your solution of loading the /etc/profile in a .xsession script is only half functional. Also your vehemence at opposing the .xsession as a login shell, and then proposing that it simply source the /etc/profile, seems completely inconsistent to me. Why do you oppose sourcing the file and then propose sourcing the file! My turn for an, RG! :-) [Darn, I really wish you had suggested sourcing the ~/.bash_profile or ~/.bashrc files in the /etc/Xsession* script. Because that is definitely wrong and I would have a serious rebuttal. :-) Those scripts run as /bin/sh, the POSIX shell, and a users's ~/.bash* files can have non-POSIX, bash specific syntax. (I am really just adding this for other folks reading along in the discussion.) You can't source them in the system scripts. It is more clear that does not work when you think about ~/.login and ~/.cshrc files.] doing as Bob suggests and changing your X login to a login shell is NOT the way to solve this problem. the only reason his solution works is because in the process of making X a login shell, /etc/profile will be sourced. You have not said anything here that indicates any problems or issues. You have only just ranted. And you have left out that using an xsession as a login shell also sources the user's environment files, such as ~/.bash_profile and ~/.bashrc, correctly. Your solution does not do that and leaves the user environment less than fully configured. in his solution you will be seen to be logged in twice. What are you talking about here? Logged in twice? Please explain. Because I think you are the one way off base here. I think you are confused about what it means to be a login shell. The user is not logged in twice. (What does that even mean in this context?) The /etc/profile and ~/.bashrc files are not even sourced twice. The environment files are sourced exactly once by the shell in this configuration. Please be specific. What is your complaint? Here is the process flow using KDM. init spawns kdm kdm spawns bash --login ~/.xsession bash acts upon --login, reads /etc/profile, ~/.bash_profile and others as appropriate for a login shell. At this time the environment is configured exactly as if you had logged into the text console. bash executes the ~/.xsession script which starts the window manager The window manager inherits the environment. window manager continues All graphical terminal windows started by the window manager inherit the environment. Constrast that to the process when you log into the text console and start X with 'xinit or 'startx. init spawns getty getty reads username, exec's /bin/login /bin/login reads password, exec's user as login shell (leading '-') '-bash' acts upon - in name and reads /etc/profile, ~/.bash_profile and others as appropriate for a login shell. bash from command line runs xinit (or
Re: $PATH and /etc/profile
On Sun, 27 Jun 2004 17:20:21 +0100 Sam Halliday [EMAIL PROTECTED] wrote: Bob Proulx wrote: Simon L wrote: When I log in text mode, the entire PATH is there as I want, I can startx and when I open a terminal, the PATH is perfect. Now, if I start the computer with KDM and that I run a terminal, the PATH is only: /usr/local/bin:/usr/bin:/bin:/usr/X11R6/bin:/usr/games By starting a login shell. Create ~/.xsession with the following: #!/bin/bash --login exec x-session-manager # or gnome-session or whatever. RG! you can't be serious!! .xsession as a LOGIN shell?? repeat after me... X windows is not your shell! Right. That's why the correct method is to change: /etc/X11/Xsession.d/99xfree86-common_start to read: exec -l $SHELL -c $STARTUP This will exec the session manager though a login shell. This permits the shell to contibute to the environment (in the case of bash this includes sourcing /etc/profile). Simon, the reason you do not get your PATH set correctly is that if you login at a console, /etc/profile will be read because it is a login shell. starting X from there will inherit all your settings. Why is this different from what is happening above? If you run startx you're starting X from a login shell. if however, you login via kdm/gdm/xdm, it is NOT a login shell, True, I suppose it's not a shell but if you're using *dm conceptually it is a login. so /etc/profile is not read. there are good reasons for this. if you do not agree with these good reasons, then you can simply add the line . /etc/profile to your ~/.xsession file. No. 1) this is an arcane hack that the average user should not have to put up with and 2) ~./xsession is not executed unless you choose Default System Session -- if you select KDE or WindowMaker etc the xsession.d scripts bail out before ~/.xsession is reached. doing as Bob suggests and changing your X login to a login shell is NOT the way to solve this problem. Well besides Debian I only have access to a RedHat machine but from looking at their X scripts the xsession is exec'd through a login shell precisely as I described. So it's not too far fetched. In fact it makes perfect sense to me. the only reason his solution works is because in the process of making X a login shell, /etc/profile will be sourced. in his solution you will be seen to be logged in twice. No. This is false. If you're talking about running /usr/bin/who to see who's actively logged in then you will not be show as logged in twice if you use *dm and if you run startx on the console then you *are* logged in twice -- do Ctrl-Alt-F1 and do Ctrl-z then bg and you still have access to that console. If you're talking about /usr/bin/last to see who has logged in then you are not shown as having logged in twice if you're using *dm. If you run startx on the console yes you may be logged has having logged in twice, I'm not sure. In that case you could create an ~/.xsession to override the method posted above but we could argue about what the majority would would want for default bahavior. Personally I think I would rather appear as having logged in an extra time (like Ctrl-Alt-F2 and login) than be required to hack some obscure X session control file that newbies are clueless about and ask about every two weeks. P.S. Does it seem like I answer this question about every other week? i hope you aren't giving this advise to everyone! He's not. But I *am* and I will continue to because 1) there is a significant amount of ignorance and disinformation flying around on this list about this topic and 2) it is the most appropriate solution for everybody. If you don't agree with that then you will have to point out to me were there is *any* negative to using the method posted above for *any* configuration. If you can successfully do that I will include your point in my advice and leave it to the user to decide. Mike -- Greedo shoots first? Not in my Star Wars. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: $PATH and /etc/profile
On Sun, 27 Jun 2004 12:23:56 -0600 [EMAIL PROTECTED] (Bob Proulx) wrote: Here is the process flow using KDM. init spawns kdm kdm spawns bash --login ~/.xsession I think we're on the same page here Bob but I want to point out that running /usr/bin/bash --login is specific to bash. Another method that uses the user's default shell is to change: /etc/X11/Xsession.d/99xfree86-common_start to read: exec -l $SHELL -c $STARTUP Also, you may or may not have noticed ~/.xsession is not executed unless the user selects Default System Session. Otherwise I believe the xsession.d scripts bail out before reachine that step. Mike bash acts upon --login, reads /etc/profile, ~/.bash_profile and others as appropriate for a login shell. At this time the environment is configured exactly as if you had logged into the text console. bash executes the ~/.xsession script which starts the window manager The window manager inherits the environment. window manager continues All graphical terminal windows started by the window manager inherit the environment. -- Greedo shoots first? Not in my Star Wars. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: $PATH and /etc/profile
Michael B Allen wrote: Sam Halliday wrote: Bob Proulx wrote: Simon L wrote: When I log in text mode, the entire PATH is there as I want, I can startx and when I open a terminal, the PATH is perfect. Now, if I start the computer with KDM and that I run a terminal, the PATH is only: /usr/local/bin:/usr/bin:/bin:/usr/X11R6/bin:/usr/games By starting a login shell. Create ~/.xsession with the following: #!/bin/bash --login exec x-session-manager # or gnome-session or whatever. RG! you can't be serious!! .xsession as a LOGIN shell?? repeat after me... X windows is not your shell! Right. That's why the correct method is to change: /etc/X11/Xsession.d/99xfree86-common_start to read: exec -l $SHELL -c $STARTUP who said this was the correct way? if it was the correct way, do you not think the debian maintainers would have done this a long time ago? This will exec the session manager though a login shell. This permits the shell to contibute to the environment (in the case of bash this includes sourcing /etc/profile). Simon, the reason you do not get your PATH set correctly is that if you login at a console, /etc/profile will be read because it is a login shell. starting X from there will inherit all your settings. Why is this different from what is happening above? If you run startx you're starting X from a login shell. it IS differnet. if you start from the console, you should really do `startx ` to detach from the console and allow you to continue working on the console and X; hence 2 logins. try `startx`, lock your screen, do a Ctrl-Alt-F1 and realise that C-c will kill the X session and give whoever is at the machine your console login. using startx is an arcane way of starting up X. use a login manager. if however, you login via kdm/gdm/xdm, it is NOT a login shell, True, I suppose it's not a shell but if you're using *dm conceptually it is a login. yes... it IS a login, and sessreg will register it. so /etc/profile is not read. there are good reasons for this. if you do not agree with these good reasons, then you can simply add the line . /etc/profile to your ~/.xsession file. No. 1) this is an arcane hack that the average user should not have to put up with why? .xsession is there for users to set up their system. perhaps i don't want the login files to be sourced during my X login? what do i do then? come on... its one line! 2) ~./xsession is not executed unless you choose Default System Session -- if you select KDE or WindowMaker etc the xsession.d scripts bail out before ~/.xsession is reached. exactly. and why should it be reached? it is up to debian to set up the PATH for each of these window managers, not the user. doing as Bob suggests and changing your X login to a login shell is NOT the way to solve this problem. Well besides Debian I only have access to a RedHat machine but from looking at their X scripts the xsession is exec'd through a login shell precisely as I described. So it's not too far fetched. In fact it makes perfect sense to me. do you also have access to a SUN machine? a *BSD machine? all of these systems have been using this method for years... it is standard. it is the way it is done. X is NOT a login shell. the only reason his solution works is because in the process of making X a login shell, /etc/profile will be sourced. in his solution you will be seen to be logged in twice. No. This is false. hmm, you are correct about not being logged in twice. i could have sworn on my LFS system last year this counted as 2 logins... if you run startx on the console then you *are* logged in twice this is true. but that is becuase you ARE logged in twice. once in the console, and once in X. Personally I think I would rather appear as having logged in an extra time (like Ctrl-Alt-F2 and login) than be required to hack some obscure X session control file that newbies are clueless about and ask about every two weeks. newbies generally don't use .xsession, they use the drop down window to choose a desktop. curious users use .xsession, and they should be given the correct answer, which can be solved in userspace... not sysadmin space. X is not a login shell. besides, how is change: /etc/X11/Xsession.d/99xfree86-common_start to read: exec -l $SHELL -c $STARTUP in any way less cryptic than add . /etc/profile . $HOME/.profile (if you use a POSIX shell) to the top of your ~/.xsession file P.S. Does it seem like I answer this question about every other week? i hope you aren't giving this advise to everyone! He's not. But I *am* and I will continue to because 1) there is a significant amount of ignorance and disinformation flying around on this list about this topic i agree 2) it is the most appropriate solution for everybody. If you don't agree with that then you will have to point out to me were there is
Re: $PATH and /etc/profile
Bob Proulx wrote: Sam Halliday wrote: Bob Proulx wrote: By starting a login shell. Create ~/.xsession with the following: #!/bin/bash --login exec x-session-manager # or gnome-session or whatever. RG! you can't be serious!! .xsession as a LOGIN shell?? repeat after me... X windows is not your shell! Yes, I am very serious. Please tell me why you are so adamantly opposed to this. (Other than it being poorly documented and confusing. I completely agree there.) 9.7. KDE (kdm) does not read my .bash_profile!. The login managers xdm and kdm do not run a login shell, so .profile, .bash_profile, etc. are not sourced. When the user logs in, xdm runs Xstartup as root and then Xsession as user. So the normal practice is to add statements in Xsession to source the user profile. Please edit your Xsession and .xsession files. this says exactly what i said. if however, you login via kdm/gdm/xdm, it is NOT a login shell, so /etc/profile is not read. there are good reasons for this. if you do not agree with these good reasons, then you can simply add the line . /etc/profile to your ~/.xsession file. Negative. That won't get your ~/.bash_profile, or .login with csh, sourced. so source all the files you want sourced. you should not source bashrc as it should contain bash interactive shell specific stuff (like functions and aliases which do not get inherited anyway). you should only source POSIX compliant shell stuff if you are using a POSIX shell. you could change your .xsession's shell however and source csh files. i have never done that. non-POSIX shells are the devil. Also your vehemence at opposing the .xsession as a login shell, and then proposing that it simply source the /etc/profile, seems completely inconsistent to me. Why do you oppose sourcing the file and then propose sourcing the file! My turn for an, RG! :-) sourcing /etc/profile is not equivalent to logging in. logging in will do more than that. [Darn, I really wish you had suggested sourcing the ~/.bash_profile or ~/.bashrc files in the /etc/Xsession* script. Because that is definitely wrong and I would have a serious rebuttal. :-) :-) yes, it is... for the reasons i said above. sourcing ~/.profile would be a good idea though, and i do that. in his solution you will be seen to be logged in twice. What are you talking about here? Logged in twice? Please explain. Because I think you are the one way off base here. I think you are confused about what it means to be a login shell. i was wrong here... debian must do something as on my LFS system last year (standard X scripts) this would count as a double login. probably a workaround because they seen so many people were doing this kind of thing. in fact... do a `grep -R sessreg /etc` to see what debian do. they exec any sessreg calls, so that stamps out any double logins. thats that puzzle sorted out! however, on most systems (eg SunOS, *BSD, other GNU/Linux) having .xsession be a login shell would count as a double login. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: $PATH and /etc/profile
Michael B Allen wrote: [EMAIL PROTECTED] (Bob Proulx) wrote: kdm spawns bash --login ~/.xsession I think we're on the same page here Bob but I want to point out that running /usr/bin/bash --login is specific to bash. Yes, but if you were a csh/tcsh user you would use the following ~/.xsession instead. I know I did not say it but left it implied. The examples get very complicated if every possibility is explored in detail. #!/bin/tcsh -l exec x-session-manager The user knows what shell they are using and can match the syntax correctly for it. In this case it would read /etc/csh.cshrc, /etc/csh.login, ~/.cshrc and ~/.login in that order, IIRC. Another method that uses the user's default shell is to change: /etc/X11/Xsession.d/99xfree86-common_start to read: exec -l $SHELL -c $STARTUP That is clever and I like it. But unfortunately exec -l is a bash-ism and so that does not work if /bin/sh is not bash but a different POSIX compatible shell. Users with ash installed as /bin/sh will fail. Because 'exec -l' is not specified by POSIX /bin/sh is not required to implement it. So you can't in general make that change unless you have changed Xsession to use '#!/bin/bash'. Then it works. But many object to using nonstandard bash features like this. Also, you may or may not have noticed ~/.xsession is not executed unless the user selects Default System Session. Yes. See my recent posting[1] with some more description. I just did not expand upon that here. But let me tip my hat to you as an astute and critical reader. Otherwise I believe the xsession.d scripts bail out before reachine that step. It won't bail out. In 50xfree86-common_determine-startup if .xsession is not executable it will mark it for execution with the POSIX shell '/bin/sh $STARTUPFILE' and that means the '#!/bin/bash --login' will be a comment and ignored. This has been a source of frustration and confusion to new users because it partially seems to do what they asked it to do. See 'man 5 Xsession' for some documentation on this process. Bob [1] http://lists.debian.org/debian-user/2004/05/msg00142.html pgpyfD9qQftYv.pgp Description: PGP signature
Re: $PATH and /etc/profile
Sam Halliday said: Why is this different from what is happening above? If you run startx you're starting X from a login shell. it IS differnet. if you start from the console, you should really do `startx ` to detach from the console and allow you to continue working on the console and X; hence 2 logins. try `startx`, lock your screen, do a Ctrl-Alt-F1 and realise that C-c will kill the X session and give whoever is at the machine your console login. using startx is an arcane way of starting up X. use a login manager. You could do Ctrl-z and then bg to background the X session. But you're reasoning is flawed anyway. It's not two logins. You never enter credentials running X from the console. With *dm you do so it should be like a login. The whole point is that starting X from the console is no different from the exec -l $SHELL -c $STARTUP method I describe. It just eliminates the startx part. No. 1) this is an arcane hack that the average user should not have to put up with why? Because it's totally unnecessary for newbies to suffer through discovering how to propery setup their shell environment. Ever heard of the Principal of Least Surprise? .xsession is there for users to set up their system. perhaps i don't want the login files to be sourced during my X login? what do i do then? Then create a ~/.xsession exec $STARTUP to dump the env. But I think most people do wish to normalize their shell environment so spare me the contrived examples. come on... its one line! Pointer? 2) ~./xsession is not executed unless you choose Default System Session -- if you select KDE or WindowMaker etc the xsession.d scripts bail out before ~/.xsession is reached. exactly. and why should it be reached? it is up to debian to set up the PATH for each of these window managers, not the user. I'm confused now. You suggest using ~/.xsession to source the user's profile but if you select KDE from the *dm screen causing ~/.xsession to be ignored how does one setup their shell environment? newbies generally don't use .xsession, they use the drop down window to choose a desktop. If you do not use ~/.xsession (and select Default System Session) or use the technique I've described /etc/profile and the shells home directory profile will not be sourced. Is this correct in your mind? besides, how is change: /etc/X11/Xsession.d/99xfree86-common_start to read: exec -l $SHELL -c $STARTUP in any way less cryptic than add . /etc/profile . $HOME/.profile (if you use a POSIX shell) to the top of your ~/.xsession file Because changing the file in the xfree86-common package works for everybody without requiring cryptic commands at all. You're method *requires* manual intervention and is specific to a certain shell which means if you change shells you may also need to change your ~/.xsession file. Also, again, ~/.xsession does not work with *dm managers. Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: $PATH and /etc/profile
Bob Proulx said: Another method that uses the user's default shell is to change: /etc/X11/Xsession.d/99xfree86-common_start to read: exec -l $SHELL -c $STARTUP That is clever and I like it. But unfortunately exec -l is a bash-ism and so that does not work if /bin/sh is not bash but a different POSIX compatible shell. Users with ash installed as /bin/sh will fail. Because 'exec -l' is not specified by POSIX /bin/sh is not required to implement it. So you can't in general make that change unless you have changed Xsession to use '#!/bin/bash'. Then it works. But many object to using nonstandard bash features like this. Is that really feasable? Is there even a way to do it without actually changing the /bin/sh link? Do you know of anyone that actually replaces bash with another shell for /bin/sh on a debian system? I think in practice that might prove to be a little daring. At least for a system with X. Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: $PATH and /etc/profile
Carl Fink wrote: On Tue, Jun 08, 2004 at 10:41:08PM +, Simon L wrote: I wonder if you could find the line in your startup script that says kdm and just change it to read /bin/bash kdm. I HAVE NOT TRIED THIS and make no claim that it will work, but it would explain why startx works and kdm does not. There are no kdm line in this file ... Which file? If you mean /etc/init.d/kdm, I suspect you just aren't skilled at reading shell scripts (as I am not). Look for a lines that start with start-stop-daemon. It is true that I am not :P but I suspected that it was the start-stop-daemon. The only thing is that I don't know where to add the /bin/bash in this line. I checked a bit more this file and I found the line DAEMON= so I added the /bin/bash here, but it did nothing (yes I rebooted :P ) -- E-mail: [EMAIL PROTECTED] Page Web: http://www.PVworld.ca -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: $PATH and /etc/profile
On Wed, Jun 09, 2004 at 07:36:14AM +, Simon L wrote: I checked a bit more this file and I found the line DAEMON= so I added the /bin/bash here, but it did nothing (yes I rebooted :P ) Did you put it in quotes, like this? DAEMON=/bin/bash /usr/bin/kdm? I have (I must say) no expertise with shell scripts, I'm just throwing out ideas. Why reboot? You can stop and restart any (compliant) Debian daemon by typing (as root) /etc/init.d/name-of-daemon restart -- Carl Fink [EMAIL PROTECTED] Manager, Dueling Modems Computer Forum http://dm.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: $PATH and /etc/profile
Carl Fink wrote: On Wed, Jun 09, 2004 at 07:36:14AM +, Simon L wrote: I checked a bit more this file and I found the line DAEMON= so I added the /bin/bash here, but it did nothing (yes I rebooted :P ) Did you put it in quotes, like this? DAEMON=/bin/bash /usr/bin/kdm? Yes, because it was already like in quote I have (I must say) no expertise with shell scripts, I'm just throwing out ideas. Why reboot? You can stop and restart any (compliant) Debian daemon by typing (as root) /etc/init.d/name-of-daemon restart I know, but I wanted to be sure :) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: $PATH and /etc/profile
Incoming from Simon L: In my /etc/profile file, I wrote: PATH=/opt/j2sdk1.4.2_04/bin:/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/games:/usr/local/sbin:/usr/sbin:/sbin When I log in text mode, the entire PATH is there as I want, I can startx and when I open a terminal, the PATH is perfect. Now, if I start the computer with KDM and that I run a terminal, the Define terminal. What are you actually running? XTerm, KTerm, Gnome-terminal? Are you clicking on an icon or entering a command? One way or another, you need to tell that thing to run a _login_ session, and all of them do it differently. PATH is only: /usr/local/bin:/usr/bin:/bin:/usr/X11R6/bin:/usr/games -- Any technology distinguishable from magic is insufficiently advanced. (*) http://www.spots.ab.ca/~keeling - - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: $PATH and /etc/profile
s. keeling wrote: Incoming from Simon L: In my /etc/profile file, I wrote: PATH=/opt/j2sdk1.4.2_04/bin:/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/games:/usr/local/sbin:/usr/sbin:/sbin When I log in text mode, the entire PATH is there as I want, I can startx and when I open a terminal, the PATH is perfect. Now, if I start the computer with KDM and that I run a terminal, the Define terminal. What are you actually running? XTerm, KTerm, Gnome-terminal? Are you clicking on an icon or entering a command? One way or another, you need to tell that thing to run a _login_ session, and all of them do it differently. PATH is only: /usr/local/bin:/usr/bin:/bin:/usr/X11R6/bin:/usr/games I use kterm, but my problem is the same when I use an icon of a program that use java. So I want the PATH to be always there for any use. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: $PATH and /etc/profile
Incoming from Simon L: s. keeling wrote: Incoming from Simon L: In my /etc/profile file, I wrote: PATH=/opt/j2sdk1.4.2_04/bin:/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/games:/usr/local/sbin:/usr/sbin:/sbin First, you should append /opt/j2sdk1.4.2_04/bin to the _end_ of your PATH variable, not the beginning. When I log in text mode, the entire PATH is there as I want, I can startx and when I open a terminal, the PATH is perfect. Now, if I start the computer with KDM and that I run a terminal, the Define terminal. What are you actually running? XTerm, KTerm, PATH is only: /usr/local/bin:/usr/bin:/bin:/usr/X11R6/bin:/usr/games I use kterm, but my problem is the same when I use an icon of a program that use java. So I want the PATH to be always there for any use. I gave up trying to figure out how kde works. If you have that in /etc/profile, it ought to be right. -- Any technology distinguishable from magic is insufficiently advanced. (*) http://www.spots.ab.ca/~keeling - - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: $PATH and /etc/profile
s. keeling wrote: Incoming from Simon L: s. keeling wrote: Incoming from Simon L: In my /etc/profile file, I wrote: PATH=/opt/j2sdk1.4.2_04/bin:/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/games:/usr/local/sbin:/usr/sbin:/sbin First, you should append /opt/j2sdk1.4.2_04/bin to the _end_ of your PATH variable, not the beginning. When I log in text mode, the entire PATH is there as I want, I can startx and when I open a terminal, the PATH is perfect. Now, if I start the computer with KDM and that I run a terminal, the Define terminal. What are you actually running? XTerm, KTerm, PATH is only: /usr/local/bin:/usr/bin:/bin:/usr/X11R6/bin:/usr/games I use kterm, but my problem is the same when I use an icon of a program that use java. So I want the PATH to be always there for any use. I gave up trying to figure out how kde works. If you have that in /etc/profile, it ought to be right. Just for the pleasure, I tried a Gnome session. So I opened gnome-terminal and it gives me the same thing (not working) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: $PATH and /etc/profile
Note: I'm far from an expert. On Tue, Jun 08, 2004 at 09:12:05PM +, Simon L wrote: When I log in text mode, the entire PATH is there as I want, I can startx and when I open a terminal, the PATH is perfect. Now, if I start the computer with KDM and that I run a terminal, the PATH is only: /usr/local/bin:/usr/bin:/bin:/usr/X11R6/bin:/usr/games Presumably KDM is being started by one of the /etc/init.d scripts, without first running Bash. Thus the profile file isn't being read (because why should anything but a login shell read it?). I wonder if you could find the line in your startup script that says kdm and just change it to read /bin/bash kdm. I HAVE NOT TRIED THIS and make no claim that it will work, but it would explain why startx works and kdm does not. -- Carl Fink [EMAIL PROTECTED] Jabootu's Minister of Proofreading http://www.jabootu.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: $PATH and /etc/profile
On Tue, Jun 08, 2004 at 09:12:05PM +, Simon L wrote: In my /etc/profile file, I wrote: PATH=/opt/j2sdk1.4.2_04/bin:/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/games:/usr/local/sbin:/usr/sbin:/sbin When I log in text mode, the entire PATH is there as I want, I can startx and when I open a terminal, the PATH is perfect. Now, if I start the computer with KDM and that I run a terminal, the PATH is only: /usr/local/bin:/usr/bin:/bin:/usr/X11R6/bin:/usr/games How can I fix that? Try setting the UserPath in kdmrc and restart kdm. My kdmrc is located in /etc/kde3/kdm. -- Jerome signature.asc Description: Digital signature
Re: $PATH and /etc/profile
Carl Fink wrote: Note: I'm far from an expert. On Tue, Jun 08, 2004 at 09:12:05PM +, Simon L wrote: When I log in text mode, the entire PATH is there as I want, I can startx and when I open a terminal, the PATH is perfect. Now, if I start the computer with KDM and that I run a terminal, the PATH is only: /usr/local/bin:/usr/bin:/bin:/usr/X11R6/bin:/usr/games Presumably KDM is being started by one of the /etc/init.d scripts, without first running Bash. Thus the profile file isn't being read (because why should anything but a login shell read it?). I wonder if you could find the line in your startup script that says kdm and just change it to read /bin/bash kdm. I HAVE NOT TRIED THIS and make no claim that it will work, but it would explain why startx works and kdm does not. There are no kdm line in this file :( , but I found a PATH= line so I tried it and it doesn't work :( . I also searched for UserPath in the kdmrc file, but it is not in the file. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: $PATH and /etc/profile
On Tue, Jun 08, 2004 at 10:41:08PM +, Simon L wrote: I wonder if you could find the line in your startup script that says kdm and just change it to read /bin/bash kdm. I HAVE NOT TRIED THIS and make no claim that it will work, but it would explain why startx works and kdm does not. There are no kdm line in this file ... Which file? If you mean /etc/init.d/kdm, I suspect you just aren't skilled at reading shell scripts (as I am not). Look for a lines that start with start-stop-daemon. -- Carl Fink [EMAIL PROTECTED] Jabootu's Minister of Proofreading http://www.jabootu.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
