New answers tagged bashrc
You could check your .bashrc into some sort of version control system such as Git or SVN and have the file regularly pulled down from the repository to each server. If you then update the file on a single server you can push it back up to the main repository to be pulled down to each server from there. It would be best to create this is as a symlink to a ...
The best way is to use centralized log in servers and storage (via NFS or automounts) I'd recommend a mixture of OpenLDAP and Kerberos with NFSv4; however, there are several others such as Samba, just using OpenLDAP, NIS+, or manually syncing files. These all should be readily available in ports and in pkg. As a heads up, you'll need to adjust pam as well. ...
In the end, I sourced the .bashrc from the .profile. For me, this means the .profile must be empty except for running .bashrc to avoid circular references and other confusion. As I've read in the man page, sshd should have invoked the .bashrc, but, oh well, I have a workaround.
The ~/.bashrc file does not always get read: see Bash Startup Files in the manual. Does your ~/.bash_profile (or ~/.profile) invoke your .bashrc file? Often this appears in .profile files: # if running bash if [ -n "$BASH_VERSION" ]; then # include .bashrc if it exists if [ -f "$HOME/.bashrc" ]; then . "$HOME/.bashrc" fi fi
At the beginning you are recursively sourcing ~/.bashrc. You probably wanted to include /etc/bashrc instead. As a result bash terminates with stack overflow during parsing.
That is because a starting X session never reads your ~/.bashrc and ~/.profile. Usually, the desktop manager is started as root or its own user from an init script. The resulting process usually has the environment of the init process when it hits the desktop manager starting script. (I will not talk about less established init implementations at this ...
Top 50 recent answers are included