Slackware This Forum is for the discussion of Slackware Linux.
|
Notices |
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
Are you new to LinuxQuestions.org? Visit the following links:
Site Howto |
Site FAQ |
Sitemap |
Register Now
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
|
 |
11-13-2013, 10:27 AM
|
#1
|
Member
Registered: Aug 2007
Location: Melbourne
Posts: 111
Rep:
|
Slack 14.1 bash different in KDE
I have my 14.0 Slackware set to boot to a console so I can then startx manually. The bash shell at boot has username@hostname on the left hand side and includes the changes I make to bsd-games-login-fortune-sh. When I startx and run Konsole the console looks the same. When I test Slack 14.1 the initial boot console is ok but the KDE console has Bash 4.2 on the LHS and my changes to bsd---.sh have not been applied. Any ideas why bash is different in KDE?
|
|
|
11-13-2013, 10:45 AM
|
#2
|
LQ Veteran
Registered: May 2008
Posts: 7,116
|
Sounds like kde/konsole is no longer starting the shell as a 'login shell' (which IMO is exactly the right thing to do). non-login shells don't run .profile.
Read the INVOCATION section of man bash for full details.
|
|
|
11-13-2013, 11:55 AM
|
#3
|
Member
Registered: Jun 2002
Location: South Africa
Distribution: Custom slackware64-current
Posts: 308
Rep:
|
alt-f2->konsole->Settings->Manage Profiles->Edit Profile->Change command /bin/bash to /bin/bash -l
|
|
|
11-15-2013, 01:19 AM
|
#4
|
Member
Registered: Aug 2007
Location: Melbourne
Posts: 111
Original Poster
Rep:
|
Thanks guys
Gazl:- Yes I agree it is not an actual login shell however any console that does not let me apply, at least, alias rm="rm -i" to it is of no use to me.
fskmh:- that worked thanks. first time in years (10?) that I have had this issue with Slackware.
|
|
|
11-15-2013, 03:25 AM
|
#5
|
Member
Registered: Jun 2007
Location: Farmington, CT
Distribution: Slackware64
Posts: 208
Rep:
|
This was already the case in 14.0
|
|
|
11-15-2013, 04:39 AM
|
#6
|
LQ Veteran
Registered: May 2008
Posts: 7,116
|
Quote:
Originally Posted by nyloc
Thanks guys
Gazl:- Yes I agree it is not an actual login shell however any console that does not let me apply, at least, alias rm="rm -i" to it is of no use to me.
fskmh:- that worked thanks. first time in years (10?) that I have had this issue with Slackware.
|
The best place for your aliases are in a bashrc file. Slackware's default shell plumbing isn't ideal and it relies on you starting every shell as a login shell in order to get aliases and suchlike working.
This is what I do on my machines to clean it up a little: http://www.linuxquestions.org/questi...ts-4175472234/
|
|
|
11-15-2013, 06:46 PM
|
#7
|
Member
Registered: Aug 2007
Location: Melbourne
Posts: 111
Original Poster
Rep:
|
metageek:- NO it was NOT at least not in the version I have installed !
|
|
|
11-15-2013, 06:49 PM
|
#8
|
Senior Member
Registered: Dec 2012
Location: Washington DC area
Distribution: Fedora, CentOS, Slackware
Posts: 4,908
|
Quote:
Originally Posted by GazL
The best place for your aliases are in a bashrc file. Slackware's default shell plumbing isn't ideal and it relies on you starting every shell as a login shell in order to get aliases and suchlike working.
This is what I do on my machines to clean it up a little: http://www.linuxquestions.org/questi...ts-4175472234/
|
Thats the ONLY valid place for it...
If they aren't there, no shell process spawned from that shell (the login shell) will ever have the aliases.
|
|
|
11-15-2013, 07:10 PM
|
#9
|
Member
Registered: Aug 2007
Location: Melbourne
Posts: 111
Original Poster
Rep:
|
If I put the commands in .bashrc then I have to do that for every user, which is what I am trying to avoid (due to laziness - why create many files when one will do).
|
|
|
11-15-2013, 07:27 PM
|
#10
|
Senior Member
Registered: Dec 2012
Location: Washington DC area
Distribution: Fedora, CentOS, Slackware
Posts: 4,908
|
Quote:
Originally Posted by nyloc
If I put the commands in .bashrc then I have to do that for every user, which is what I am trying to avoid (due to laziness - why create many files when one will do).
|
mostly because it works that way.
In no case is the /etc/profile used after the login shell... so any shell script started by that shell will not get whatever is in it.
Now you CAN make a shared .bashrc... by putting it in the skeleton for account creation. That shared
file CAN include an /etc/profile (or any name you want to call it). In addition, the skeleton file itself gets copied when the users login is created... so again, you don't have to do it yourself.
The major weakness is that users can easily change their version. But that is up to them.
|
|
|
11-16-2013, 02:00 PM
|
#11
|
LQ Veteran
Registered: May 2008
Posts: 7,116
|
Quote:
Originally Posted by nyloc
If I put the commands in .bashrc then I have to do that for every user, which is what I am trying to avoid (due to laziness - why create many files when one will do).
|
Blame the bash developers. Not only did they not add a default system-wide /etc/bashrc file, they made it so that $BASH_ENV only applies to non-interactive shells (unlike $ENV in the traditional bourne familiy shells), so there's no way for the sysadmin to do what you want without putting a .bashrc in /etc/skel to do it and leaving it at the mercy of the idiot users in the hope of them not deleting or otherwise messing it up.
Last edited by GazL; 11-16-2013 at 02:07 PM.
|
|
|
11-16-2013, 02:06 PM
|
#12
|
LQ Veteran
Registered: May 2008
Posts: 7,116
|
Quote:
Originally Posted by jpollard
That's the ONLY valid place for it...
If they aren't there, no shell process spawned from that shell (the login shell) will ever have the aliases.
|
 Exactly my point... when it comes to bash at any rate. Other shells were better designed.
|
|
|
11-16-2013, 05:11 PM
|
#13
|
Senior Member
Registered: Dec 2012
Location: Washington DC area
Distribution: Fedora, CentOS, Slackware
Posts: 4,908
|
Not better. Just different.
The problem the other shells cause by such action is that it makes getting a standard environment much harder to do - you have to first disable everything that is in /etc/<whatever>, AND it makes
running standard scripts (problems due to the changes there) much harder. You don't know if an error
is due to the environment, or the command... (after having to chase through an installation cshell script because it failed due to some rather bogus definitions put in the environment by previous admins, that really didn't know what they were doing).
Personally, I prefer the bourne shell. Smaller executable.
But I do find bash better for simple shell scripting than any of the alternatives. for anything more complex, I much prefer Perl.
|
|
|
All times are GMT -5. The time now is 10:07 PM.
|
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
|
Latest Threads
LQ News
|
|