[Discuss] rsync v. cp in data migration

[Derek Martin]

On Sun, May 26, 2013 at 07:36:14AM -0400, Jerry Feldman wrote:
> >Generally the convention is to use upper case names for environment
> >variables (i.e. things you want to have persistence across
> >sessions/processes/etc.), and shell scripts should use lower case
> >names for their variables to avoid unintended conflicts like this.
>
> Yes, using upper case for environment variables and lower case for
> local variables is the long-time Unix/Linux convention. Shell
> scripts can use both local as well as environment variables. I think
> your definition of persistence is incorrect.
> Environment variables persist within the process where they were
> created, and any child process. 

I never actually gave you my definition of persistence, and I've been
posting here long enough that I think you know that I know how
environment variables work. I was vague for the sake of brevity, but
being vague is not the same as being wrong. ;-)

It's perhaps interesting to note that if you do change an environment
variable in your shell, but it is one that is set in your login files,
then when you start a new shell from that one, the changed value will
"revert" to the value it had when you log in, on account of it having
been re-read from your login files (or rather it MAY, whether or not
this happens depends upon how the new shell was invoked, as described
in the INVOCATION section of the bash man page).

And since you bring it up, and it's tangentially related to Greg's
script, I'll mention that when you pipe the output of a loop in a
script, as I did in the example that I gave, that loop is run in a
subshell.  This is important to know because it means that when you do
this, if, inside that loop, you change a variable that exists outside
the loop, its value will revert to the value it had before the start
of the loop.  For example, take the following script:

$ cat x.sh
#!/bin/sh

x=hello
for i in 1 2 3; do
    x="$x$i"
    echo $x
done 
echo $x 

When you run this, you get the output you would intutively expect:

$ sh x.sh
hello1
hello12
hello123
hello123

But if we make a small modification:

$ cat y.sh
#!/bin/sh

x=hello
for i in 1 2 3; do
    x="$x$i"
    echo $x
done | tee /dev/null
echo $x 

Your output becomes:

$ sh y.sh
hello1
hello12
hello123
hello


This behavior catches a lot of people who shell script casually
unawares.  Shell scripting is a virtual mine field...  I used to be a
big fan of it, but these days I'll prefer Python for almost
everything, save really short scripts that mostly just run a few
commands, or the occasional very short Perl script that does very
little other than process some regexes.


-- 
Derek D. Martin    http://www.pizzashack.org/   GPG Key ID: 0xDFBEAD02
-=-=-=-=-
This message is posted from an invalid address.  Replying to it will result in
undeliverable mail due to spam prevention.  Sorry for the inconvenience.