Slack and .bashrc
 

Hi guys,

not that it's a big deal, but I
keep wondering ...

My bash won't evaluate .bashrc, but
if I copy the file to .bash_login it works
fine ... this is a bit odd? :)

Cheers,
Tink

Nope, it's not odd!

Since all your terminals are login-shells .bashrc
is never going to be evaluated for you :}

Cheers

.bashrc will come into play (so to speak) when you open a terminal emulator such as konsole, eterm or aterm when logged in to a user account in X, if you want to have some system wide variables or aliases you can put them in /etc/profile.

Recently I started messing with aliases. I've always read to put these into a .bashrc file. Since my slack didn't have one, I just created it and added my 2 aliases in it. In order for it to work I have to first:
source .bashrc

Then it works. I am wondering where I should put these files (or entries) to make then work without having to source my bashrc each time I login.

Cool

/etc/profile or /etc/profile.d/yourscript.sh but make sure its executable and invoked by /etc/profile. For simplicity sake you can just stick your aliases at the ned of /etc/profile and they will be made global.
If you want it for only one use put it in ~/.bash_login or create a script in /etc/profile.d/script.sh that will check for UID and if UID is that of your user it will use the aliases, otherwise it will ignore them. I use something similar to check if UID is 0, and in case it is it will color the prompt RED to make it evident i'm root right away and that i shouldn't do anything stupid. :)
If you are interested in my script (very basic, as im unable to create anything usefult yet) e-mail me.
And BTW, merry christmas and a happy new year to everyone.
-NSKL

The global profile (/etc/profile) should only have evironment variables that make sense for all users to have. If a specific user has specialised needs it is better to put these into .profile in the user's home dir. Additionally, ~/.profile is read during a console login, so things like coloured prompts should really go in there.

Here's my work around on my Slackware 9.1 system:

1) Create your own global aliases in a new file called: /etc/bashrc
2) cd /etc/profile.d
3) Create this script (I call it bashrc.sh)
#!/bin/sh
source /etc/bashrc
4) Save it, and then make it executable: chmod 755 /etc/profile.d/bashrc.sh

Next time you open a terminal your global aliases in /etc/bashrc will be read.

HTH.

Did you decide on a solution for this?

I put { alias ls='ls --color' } in .bashrc, in .profile, and at the end of /etc/profile. (without the curly braces.)

Edit: Oh, and I also tried putting { source ~/.bashrc } in .bash_profile .

The color works when I first log in just from having it in the .bashrc, but once I startx and open xterm or gnome-terminal, the color is gone.

Shouldn't this be doable without having to write some script?

Thanks...

(hey.. I thought Tinkster and MasterC had all the answers!!! :eek: )

;)

you shouldn't have to source .bashrc every time, only once. :confused: all my user specific settings and aliases are in their respective ~/.bashrc (including root's in /root), and once i source them once, they work everytime i log in to that account, whether in X or at a non-X tty terminal, or even if ssh-ing into the system. :)

Well, aren't you special! :p


(oops, sorry about that... ;) )

well, yes i am :D but aside from that, i was only trying to show how it worked on one system for comparison. i have no idea why it works, but the fact that it does means that it can. come to think of it, you might need "source ~/.bashrc" in ~/.bash_profile for it to "take" every time you login. :)

---------------------------
this might be helpful:

Setting the PS? Strings Permanently

Various people and distributions set their PS? strings in different places. The most common places are /etc/profile, /etc/bashrc, ~/.bash_profile, and ~/.bashrc . Johan Kullstam (johan19@idt.net) writes:

the PS1 string should be set in .bashrc. this is because non-interactive bashes go out of their way to unset PS1. the bash man page tells how the presence or absence of PS1 is a good way of knowing whether one is in an interactive vs non-interactive (ie script) bash session.

The way i realized this is that startx is a bash script. what this means is, startx will wipe out your prompt. when you set PS1 in .profile (or .bash_profile), login at console, fire up X via startx, your PS1 gets nuked in the process leaving you with the default prompt.

One workaround is to launch xterms and rxvts with the -ls option to force them to read .profile. but any time a shell is called via a non-interactive shell-script middleman PS1 is lost. system(3) uses sh -c which if sh is bash will kill PS1. a better way is to place the PS1 definition in .bashrc. this is read every time bash starts and is where interactive things - eg PS1 should go.

Therefore it should be stressed that PS1=..blah.. should be in .bashrc and not .profile.
http://www.dreaming.org/~giles/bashp...wto/setps.html

so maybe it's the same thing for aliases getting nuked?

pps., adding -F to the ls alias is a cool little feature also. it gives you a symbol next to the file when it's of a certain kind, e.g., * for executable, @ for a symlink, etc.
alias ls='ls -F --color'

Yeah, I edited my post to indicate that I did put { source ~/.bashrc } in .bash_profile, but it had no effect in either xterm on gnome-terminal after logging out and in and then once I had x started.

I am running WindowMaker on that machine. What do you run when you startx ? Maybe you could grep out an { ls --color } on your system to see where it's set?

Thanks...

well it gets a bit complicated at this point, because i not only don't startx, i startxfce4, and actually i don't even startxfce4 anymore, i have a ~/.bashrc alias for startxfce4 called "gui." :p but i just tried it and my aliases work if i startx into gnome or fluxbox.

so your guess as to what is going on is as good as mine. :D

grep ls --color didn't give anything, maybe because i use the -F option (?). but i have all aliases like that in the ~/.bashrc for each user, and it seems to be working.

This just works like a charm :)

Edit: note that the forum breaked the PS1 lines.. actially it's just one line.

Below is an excerpt of "bash.SlackBuild":

CFLAGS="-O2 -march=i486 -mcpu=i686" \
./configure --prefix=/usr i486-slackware-linux
make
make install DESTDIR=$PKG

It seemed it is clean, I used to modify my .bash_profile, .bashrc for use in slackware as well as in redhat. I've only 1 root subdir shared among diverse distros or releases of slackware.

Redhat seemed not only have the "--prefix=.." on its configure arguments. So thing get something choastic after I merged redhat's (~/.bash*,/etc/{profile,bashrc}) with my config for slackware, but after sometime I forgot wut is specific for redhat n wut for slack. But now I use almost EXCLUSIVELY slack, so I don't wonna spend $TIME for other distro ..

"man bash" should give good advice on bash* config, redhat might need extra attention on the place/order for reading the resource files (check the argument of ./configure).

Actually I heard sh/bash is not that excellent regarding their semantic/syntax compared to tcsh or ksh, wonder why so much ppl use it excusively ..

-------
Booster for Ka+pumper between nerits n dendrites ?
cafein, glutamat acid but not ectaxi