Strangly even using -f option, it still asks for whether or not to overwrite the file. This shouldn't happen?
I wouldn't think so, but that's a WAG.
What do you mean by .bashrc.bak file. Is it automatically generated on Mac? I don't see it in my Home folder. Or do you simply suggest the name of file to be .bashrc.bak?
Normally there is no .bashrc file on Mac by default, but you can create and put some commands in .bash_profile to source the .bashrc file. .bashrc fie is more prevelent on Linux.
Mac OS isn't Linux and .bashrc isn't needed, IMO.
Definitely create yourself a second administrative login, and either use that to mess around with, or use that as a path to log in. This available should there be problems local to your experimental login environment.
As for the errors you're reporting, please post the command used, the full text of the error, and an ls ale@ of the source and target files.
While cron or periodic can make hourly copies, Time Machine should already be configured and running here and will automatically capture copies of these files. Having backups is particularly useful when you're learning how to use the shell, as mistakes can and do happen, particularly as you start working with sudo and related commands.
If you're making lots of copies to that particular file, use a script with something like the following commands:
cp .bashrc $bashrcsavename
to create a backup copy with some history.
You forgot to show permissions. I doubt the command syntax is at fault. It's something in the environment. You should copy complete script. Add ls commands before copy of source & target.
is this the actual path?
Unix is very unforgiving. Need to see exactly what you did.
# Verify that we have permissions and correct commnad.
ls -ale@ .bashrc
ls -ale@ /pathtofolder/bashrc_backup.txt
ls -aled@ /pathtofolder
# for debugging i'd add the v
# for sanity check i'd try
cp -fv .bashrc bashrc_backup.txt
echo "copy to folder"
cp -fv .bashrc /pathtofolder/bashrc_backup.txt
OK if you are trying to learn or are experimenting with bash and the startup file then backing up the file is a good idea. However doing the backup out of the .bashrc file is wrong. Think about it you make a change to the .bashrc file and then you source it or log out and log in again and what happens? This new version back's itself up over the previous version and if this new version has an error then that's all you have the previous version is gone.
So for backup purpose s you'll be better off using and editor that has versions or at least keeps the previous file around.
Second you should not need the -f flag for this cp. cp will happily overwrite any destination file you have rw access to. It doesn't care if the destination exists as long as you have rw access. In this case that shouldn't be a problem. The first time you ran the command the destination file didn't exist and cp should have created it with rw access for the owner (you). On subsequent runs cp should be overwriting the file.
That this isn't indicates something else going on. You need to troubleshoot the problem, break it down to individual steps. Start with running the cp command from the command line and get that to work before trying to put it inot a script. Follow the advice of the other posters, they have given you lots o good advice.
Normally, bash ONLY reads .bashrc when creating a subshell.
On a new login, bash looks for .bash_profile, .bash_login, or .profile (in that order and stops after the first one it finds).
On Mac OS X if you want .bashrc processed when starting a new Terminal session, you should have a
in a .bash_profile, .bash_login, or .profile otherwise .bashrc would be ignored until a subprocess running bash is started.
So basically, I'm wondering how your .bashrc commands normally get executed? Unless you have a .bash_profile, .bash_login, or .profile with a 'source' for your .bashrc