A system deletes my .bashrc file

It deletes my .bashrc file rarely but predictability after some unknown count of Mac's restarts. Has someone ever faced such behavior?

How do I prevent OS X from modifying .bashrc? What ownership/permission should I set up to not let it happen?

OS X Lion.

I assume you meant predictably instead of predictability... What happens that enables you to predict that your .bashrc file will be deleted the next time you reboot OS X? Is it that if you perform some specific action, the file will disappear the next time you reboot? If so, what actions do you perform before the reboot that makes your .bashrc disappear?

Are you sure it is the reboot that causes the file to disappear? It could easily be that something you are doing removes your .bashrc file while you are actively running bash and you just won't notice that it is gone until the next time you reboot (or log out and log in again). Try running the command:

ls -l $HOME/.bashrc

just before you log out or reboot your system every time you log out or reboot your system.

Hi Don Dragun,
Thank you for such a prompt reply

By predictably I'm saying that in all of the cases when it disappears it usually tends to be gone after some unknown crossed line of reboot counts (in the sense that you can bet it will happen sooner or later), never during login session, because I use commands from my .bashrc on a frequent basis and nothing signals about it not being there. But, as I said, after some reboots it will simply erase that file.

What this command lists?

Can I prevent the system from modifying it by setting up a "backstone" on its way?

Thanks

So you say that .bashrc IS executed during login but then disappears during your interactive session?
The command that Don proposed should just make sure the file is still present at the moment when you log out or reboot. I'd propose to run it frequently to be able to tell about when it disappears.

Not quite. To represent the situation schematically the issue looks smth like this:

.bashrc 

normally is executed every time I open new Terminal window or start a new Terminal session (by typing the command

./.bashrc

in Terminal Preferences where you can customize what command for Terminal to execute on starting a session). I can't tell the exact moment it disappears but MOST of the time (except when it's being deleted) during my interactive session I'm able to use commands put in there successfully.

  1. It also sits in its location immutably undergoing numerous shutdowns, reboots and so on.

  2. At some point coinciding with some reboot (or with turning my Mac on) on Terminal trying to execute

./.bashrc

it fails because it tells

MacBook-Pro-ILJA:~ iljashebalin$ . ./.bashrc
-bash: ./.bashrc: No such file or directory

when I start Terminal session/open a new Terminal window. Executing the command

ls -lahG

reveals it's gone forever.

BTW, it was the second time I detected such misbehavior. The first time I had manually recreate the file together with all configurations I laboriously put into it.

We understand that. But, when you start a new terminal session, you don't need to type the command ./.bashrc if bash is the shell running in that terminal session. When bash is invoked as a login shell, it runs .bashrc in your home directory as part of its initialization steps.

We understand that.

You are assuming at least two things here, neither of which are backed up by what you have told us:

  1. The file $HOME/.bashrc is removed during a reboot. Nothing you have shown us tells us that $HOME/.bashrc was not removed 1 second after the last terminal session you started. It could have been removed any time after you started the last terminal session up until the next time you rebooted; not just as a side effect of rebooting.
  2. The files ./.bashrc and $HOME/.bashrc are the same file. If, at any point after you start a terminal session you issue a cd directory command, the command . ./bashrc would then be expected to fail in that terminal session unless you have issued another cd command that moves you back to your home directory.

OK. So, first you told us the file disappears predictability (sic) after an unknown number of reboots. I asked what happens that allows you to predict when it will disappear. You have not answered that question. And, now you tell us, that instead of the file disappearing predictably after some number of reboots, it has happened two times.

That file does not disappear as a side effect of rebooting unless you have modified a system or personal file that is executed when your system reboots that causes that file to be removed. It is MUCH MORE likely that you are doing something while you are logged in that is removing that file and you just don't notice it until you reboot after you have removed it. That is why it is important to know how you can predict when the file will disappear. If you can predict that the file won't be there the next time you reboot, it is probably because you have just done something that removed the file.

If you have issued a command to remove your own file, we can make it a little more likely that a warning will be printed before it is removed; but there is nothing we can do to keep you from removing your own file if you tell your shell to remove your file. You make it more difficult in some cases by making the file read-only after you recreate the file with the contents you want. The command:

chmod 400 $HOME/.bashrc

will do that. If you then try to remove the file using:

rm $HOME/.bashrc

it will ask for confirmation before removing your file. But, if you use the command:

rm -f $HOME/.bashrc

that command will happily remove your file exactly as you requested with no warning.

Of course, you would not have to actually type in one of the above commands literally to remove your file. It could also be done with an unlink command or library call, a rename command or library call, or a mv command (but, note that with rename or mv , the file's contents may still be present in a file with a different name instead of actually gone).

If you run the command:

ls -l $HOME/.bashrc

frequently, it will eventually report that the file is not found. And, if you can identify what you were doing before it disappeared, we'll have a better chance of tracking down what you are doing that is removing the file.

OK, so to set it up I'd like to admit I'm neither computer not programming, let alone UNIX, geek. I'm a dummy, hence all this confusion with used terminology etc. It's possibly that I may've misled myself and others, participating in this discussion, due to this reason, not just because I intended to, bear that in mind, please.

You wrote too much. Let me clear out some points:

  1. I don't know exactly why and when did .bashrc disappear. Considering "deletion-reboot" connection it's just my guess based on my subject observations. Maybe the connection is not the case, maybe it's really a coincidence that I misinterpreted as a cause.

Further on
2.

Really? Didn't have a clue of it. However I may misinterpret that statement once again but from "Learning UNIX for Mac OS X users" by Kevin Scoglund (by Lynda.com) I got impression that for commands from .bashrc to take effect you have to execute this file by running

source .bashrc

when in home directory (or

. ./.bashrc
  • I think I foozled with the syntax in my last post considering this command, so stand corrected in this one). So, instead of running it multiple times when I launch Terminal or open its new window I just set it in Terminal Preferences to run it on bash shell's startup (see the screenshot - are we talking about the same thing?). It used to work - until it has gone.
  1. I didn't execute in all my consciousness and right state of mind neither
rm -f

nor

rm

towards .bashrc file, that's for sure.

  1. The main thing is that due to some unknown reasons the file got erased. I don't have a slightest explanation of this fact, I do however recall that some time ago I had a similar issue of unexpected deliberate erase (though I DON'T REMEMBER if it was the first occurrence of something deleting .bashrc or another file) because I copied and wrote down a Console's log referring to some pbs process.

The message was:

pbs[4781]: While watching paths {("/Users/iljashebalin/Library/")}, we got a change in path /Users/iljashebalin/Library/

Again, it's not my claim, rather my supposition that maybe something alike had hand in this case.