3

First of all a bit of background. I apologise in advance for the misuse of terminology. Please correct me where necessary.

For my work I am going to be running simulations remotely via ssh on several ubuntu machines. These machines are in a network and my account is linked across all of them, ie. $HOME is /home/links/Ogaday and is mirrored across each machine. So I make a directory on one machine in that folder, and it appears in another machine (this is a case where I don't know how to use the correct terms). There is also local memory on each machine, accessible by each user on that machine, called /scratch/. I will make a directory in /scratch/ to do my actual work in, because I don't think I have enough memory on my account to run the simulations in $HOME, and it will be faster because it's all local, I assume.

Now, there is software installed on those machines that I need to use, and it is installed in directories that I have no write access to (/usr/local/software/). However, that software has a bash script that sets environment variables. I'm supposed to append the bash script (source /usr/local/software/etc/bashrc) to $HOME/.bashrc in order to set the necessary environment variables. Pretty standard so far, this sets everything up for this software to run when I log in, correct? Now, I think that the software on these computers hasn't been configured properly, because the .../etc/bashrc is supposed to set a variable called $SOFTWARE_INST_DIR, the install directory. By default, this is $HOME/software, and it is necessary to change that bashrc file so that it instead sets it to /usr/local/software. Of course, I don't have write access to to .../etc/bashrc. There are other similar issues, this is just the thing that fails first.

As a fix, I copied that file into $HOME/software-etc/bashrc and appended source $HOME/software-etc/bashrc to $HOME/.bashrc instead of appending source /usr/local/software/etc/bashrc, so that I can edit the variables it assigns. Is there anything fundamentally wrong with this? I thought another solution would be to, instead of copying the bashrc file from the software install location, appending export $HOME=/scratch/ogaday to .bashrc, which I assume would reassign my home directory to scratch. Am I correct? Is this dangerous? I wouldn't really be using these machines for anything else except running long simulations on them.

ps: The final solution would be to ask the IT guys to look into it I guess! I'd rather do a quick fix though if it's possible.

Ogaday
  • 133
  • 1
  • 1
  • 7

1 Answers1

4

No, there is nothing wrong with copying the rc file somewhere else. That said, while you can indeed change your $HOME by adding HOME=/foo to one of the files read on startup (~/.profile, for example), that is really not a good idea. HOME is used by many things, not just your scripts and there's no reason to change it since that can have unintended consequences.

For example, the default configuration files for a variety of programs, including your shell, are stored in $HOME. If you change that, your settings will be lost.

Now, if I understand correctly, your main objective here is to have $HOME/software point to /usr/local/software. Instead of copying files around, the simplest solution would be to make $HOME/software a link pointing to /usr/local/software.

  1. Rename $HOME/software (if it already exists):

    mv $HOME/software $HOME/software.old

  2. Make a link called $HOME/software that points to /usr/local/software:

    ln -s /usr/local/software $HOME/software

Now, anything looking for $HOME/software will actually find /usr/local/software instead.

Similarly, in order to do your work locally on each machine, create the directory in /scratch and then link it to your $HOME:

mkdir /scratch/ogaday
ln -s /scratch/ogaday $HOME/work

Now, everything you do in $HOME/work will actually happen in /scratch/ogaday.

Finally, bear in mind that there are different types of shell. When you log in via ssh, you are running an interactive login shell and, on many systems, $HOME/.bashrc is ignored by those shells. While Ubuntu specifically does also read $HOME/.bashrc, for such shells, many other distributions don't. Therefore, it is safer to use $HOME/.profile and not $HOME/.bashrc to set environment variables. See here for an explanation of what files are read when.

Community
  • 1
terdon
  • 100,812
  • This looks great. I didn't redefine $HOME in the end, because I thought it might be fishy. One question though, the work I do in $HOME/work which is actually happening on scratch, will that be visible on other machines on the network? Because $HOME is synced across all these computers (I don't actually know where the data there is hosted, on a central sever?), so would that link be local? Synced as well? Copying the bashrc file locally has worked for now, but I think your solution is definitely the proper way to do it. – Ogaday Oct 05 '15 at 12:36
  • @Ogaday the link will appear on all computers but it will point to each computers respective /scratch/ogaday directory (if present). So, if you work on machine2, machine2 won't see it. By the way, if this answer solved your issue, please take a moment and accept it by clicking on the check mark to the left. That will mark the question as answered and is the way thanks are expressed on the Stack Exchange sites. – terdon Oct 05 '15 at 12:39
  • I definitely will, that sounds perfect, thanks for your help. – Ogaday Oct 05 '15 at 12:54
  • Ugh, last comment should read "if you work on machine1, machine2 won't see it", of course. – terdon Oct 05 '15 at 12:56
  • That's how I read it anyway hah. – Ogaday Oct 05 '15 at 12:57