.bashrc backup

Based on the permissions shown, the cp -f should have replaced the file without asking any questions.

Instead of "whereis cp", what is

type cp

which will tell us if cp is an alias that maybe includes hidden cp option switches. We would normally expect to see

type cp
cp is /bin/cp

Another approach might be to blindly remove the old backup copy, then make a new backup

/bin/rm -f /path/to/your/backup.bashrc
/bin/cp -fp $HOME/.bashrc /path/to/your/backup.bashrc

Yet another approach is to create dated copies, but that can also lead to lots of copies, especially since .bashrc is run every time a bash subshell is started :-)

/bin/cp -fp $HOME/.bashrc /path/to/your/backup.bashrc.$(date +%Y%m%d%H%M)

The addition of the -p is to preserve the original file's attributes (permissions, timestamps, etc...).

just run /bin/cp and you won't need the -f As I wrote cp doesn;t care if the file exists if you have rw permission on it (except of course if you envoke it with -i)

But once again doing the backup of the file this way is wrong and not accomplishing what you think it will.

First thank rrcharles for asking the right questions. He got to the heart of the matter.

/bin/cp

as in

/bin/cp -fp $HOME/.bashrc /path/to/your/backup.bashrc

Or put the copy in .bash_profile

One of the reasons for .bash_profile vs .bashrc is scope.

.bash_profile gets invoked once during a new session, and it an idea place to put actions that only need to be done once, such as environment variable setups, copying .bashrc to a backup, checking the state of your environment (if there is anything you need to check), etc...

.bashrc is invoked every time you start a new shell (this includes sub-shells), so it is idea for things that are not inherited, such as aliases, your command prompt if you need it to be dynamic based on where and under what conditions the sub-shell is invoked, establishing in-line shell functions that behave like shell scripts but are executed out of the shell's memory, etc...

So if you did your backup in .bash_profile, and at the end of .bash_profile sourced .bashrc, then your cp alias would not occur until after your cp was completed.

But if your shell initializations are simple, and you rarely create subshells, then having a single .bashrc is fine. Just use /bin/cp for the copy and you should be fine.

Message was edited by: BobHarris

I thought the command options overrid the alias options?

--------------------------

I have this function in one of my profiles. Types out all the info that I could think of.

# Define a new command called settings to list various options.

function settings ()

{

( echo "---------- env"; \

env; \

echo "--------- set"; \

set; \

echo "--------- export"; \

export; \

echo "--------- export -f"; \

export -f; \

echo "--------- alias"; \

alias; \

echo "--------- set -o"; \

set -o; \

echo "--------- shopt"; \

shopt; \

echo "--------- enable -a"; \

enable -a; ) | less

}

I thought the command options overrid the alias options?

man bash

"Aliases allow a string to be substituted for a word when it is used as the first word of a simple command..."

so Tissot11's "cp -fv" turns into "cp -i -fv". It is a simple substition. The shell does not involve itself with command argument processing. It does not know what the argument rules are for a command. It just substitutes the command name with the alias contents, then sees if the newly formed command name is an internal command or a program in PATH. It then passes the arguments on the substituted command line to the program which has the knowledge to interpret the command line options.

Which goes a long way to explaining why Unix commands have such a diverse behavior with respect to options and what they mean, what they look like, etc...

I thought the orginal poster was running the cp command from a script.

I get my alias command aa as undefined. Hence, he should have not seen the cp -i

mac $ bash -version

GNU bash, version 2.05b.0(1)-release (powerpc-apple-darwin8.4.0)

Copyright (C) 2002 Free Software Foundation, Inc.

mac $ cat new.sh

#!/bin/sh

# debug info

export PS4='+(${BASH_SOURCE}:${LINENO}):'

set -o xtrace

aa

mac $ alias aa

alias aa='ls'

mac $ ./new.sh

+(:7):aa

./new.sh: line 7: aa: command not found

mac $

----------------------------------

The leading backslash skips aliasing

\ls

the /bin/ skips function calls, I was just reading. As well as avoiding bath problems.

/bin/\ls

>I thought the orginal poster was running the cp command from a script.

The OP was doing the copy in .bashrc AFTER after issuing the alias command.

So the cp alias was defined in the same environment as it was executed.

Interesting. Its been some time since I mucked with this but Bob's explanation sounded reasonable and then I tested it out.

Seems there is a difference between how sh and bash handle this (now I know that the binary for sh and bash are identical on OS X but the behavior of the shell does change depending on if argv[0] is sh or bash)

If the script starts with /bin/bash no aliases are expanded, it it starts with /bin/sh aliases defined in the script are expanded.

Very Interesting. [ Unix ! ]

fyi

This make sense actually. It's to give the alias "cp=cp -i" precidence.

man cp

-f For each existing destination pathname, remove it and create a new

file, without prompting for confirmation regardless of its permis-

sions. (The -f option overrides any previous -n option, but not -i

option. See also the legacy section.)

LEGACY DESCRIPTION

When invoked in legacy mode, both -n, -i options are overridden by the -f

option.

------------------------------------

PS. I've have put the copy very near the top of the script. Seems like it would be good coding style to do a rm the copy if you expect to delete something.