Slack and .bashrc

Tinkster · 12-28-2002, 02:56 PM

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

Tinkster · 12-28-2002, 03:05 PM

Nope, it's not odd!

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

Cheers

Aussie · 12-29-2002, 03:05 AM

.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.

MasterC · 12-29-2002, 04:56 AM

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

NSKL · 12-30-2002, 09:15 AM

/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

fskmh · 01-04-2003, 07:43 AM

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.

GATTACA · 12-03-2003, 06:12 PM

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.

itsjustme · 12-28-2003, 11:52 AM

Quote:

Originally posted by MasterC
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.

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!!!

)

synaptical · 12-28-2003, 12:21 PM

Quote:

Originally posted by MasterC
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.

you shouldn't have to source .bashrc every time, only once.

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.

itsjustme · 12-28-2003, 12:24 PM

Quote:

Originally posted by synaptical
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!

(oops, sorry about that...

)

synaptical · 12-28-2003, 12:35 PM

Quote:

Originally posted by itsjustme
Well, aren't you special!

well, yes i am

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'

itsjustme · 12-28-2003, 12:50 PM

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...

synaptical · 12-28-2003, 01:04 PM

Quote:

Originally posted by itsjustme
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?

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."

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.

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.

core · 12-28-2003, 06:26 PM

Code:

me@core:~$ ll .bash*
-rw-------    1 me  users        8,9K 2003-12-28 23:37 .bash_history
lrwxrwxrwx    1 me  users           7 2003-12-12 12:30 .bash_login -> .bashrc
-rw-------    1 me  users         565 2003-12-28 08:55 .bashrc
me@core:~$ cat .bashrc 

alias pico=nano
alias ll='ls -lh'
alias la='ls -Alh'
alias links='links -driver fb'

eval `dircolors`
VISUAL=/usr/local/bin/nano

case $TERM in
  xterm*)
        PROMPT_COMMAND='echo -ne "\033]0;${USER}:${PWD}\007"'
        PS1="[\033[0;37m\]\u\[\033[0;32m\]@\[\033[0;37m\]\h\[\033[0;32m\]:\[\033[1;33m\]\w\[\033[0;32m\]\$\[\033[0;37m\] "
        ;;
  screen*)
        PS1="\[\033[0;37m\]\u\[\033[0;32m\]@\[\033[0;37m\]\h\[\033[0;32m\]:\[\033[1;33m\]\w\[\033[0;32m\]\$\[\033[0;37m\] "
        ;;
  *)
        PROMPT_COMMAND=''
        PS1="\u@\h:\w\$ "
  ;;
esac

export VISUAL PROMPT_COMMAND

This just works like a charm

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

kiko · 12-28-2003, 07:38 PM

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