Text 1078, 82 rader
Skriven 2004-09-11 18:48:06 av Pascal Schmidt (1:153/401.2)
   Kommentar till text 1077 av Paul Rogers (1:105/360.0)
Ärende: Is it safe to "merge"?
==============================
Hi Paul!

 PR> I think that may have been what I tried when I got logged off,
 PR> I forget.  Does quoting $1 in the if help?  Guess I need to study
 PR> more about when "$x" means x with all its special characters, and
 PR> when it means $x.
Just always use "$x" if the variable x is meant to contain a single filename.

There is a use for having the shell split up the contents of the variable, for
example you can do your verbose echo like this (this being the 3rd method
counting what you have now and the shell function idea):

if [ "$1" = "-v" ]; then
  ECHO="echo -e"
  shift
else
  ECHO=":"
fi

Then you can do

    $ECHO something

and the shell will correctly call "echo" with a first paramter of "-e", whereas
"$ECHO" in quotes would try to call a program called "echo -e". Note that ":"
is a builtin shell command that simply does nothing.

 PR> find gives me the parent directory node name, followed by all its
 PR> files/leaves.  If it doesn't exist in the destination tree, this 
 PR> gives
 PR> me the opportunity to create it.  Should I really consider that a 
 PR> "side
 PR> effect"?  I thought this was safer than depending on copy/move to
 PR> create the directory--still not exactly sure about that.
You didn't understand what I was trying to say. ;) It doesn't matter much. Note
that your script will also loop over special files (symlinks and such), but it
will not do anything with them, so there is no problem.

 PR> I need to study double quotes and single quotes, I guess.
Use double quotes if the content of the variable can contain whitespace and you
don't want the input split up on those boundaries. Use single quotes if you
don't want *any* shell expansion to happen. '$foo' will not expand to the value
of foo.

 PS>> Though I still would prefer a simple shell function to
 PS>> replace echo, makes the script much more readable.
 PR> I think so too, but looking at scripts in rc.d, et al, this
 PR> construct seems to be widely accepted.  I need to appear "with
 PR> it"!  ;-)
Just because the stuff in rc.d does it doesn't mean it's pretty. Most
initscripts look rather hacky.

 PR> Directory in the source, file in the destination?  Euww.  I don't
 PR> know what to do besides give up (exit 2).  Is there something else
 PR> I should do?  (This command OR construct is another one an old
 PR> FORTRAN progeammer has a hard time getting used to.)
I don't think there's something else you could do. As for the OR contruct, I
don't do that kind of error checking in most of my shell scripts. For critical
scripts, I put "#!/bin/bash -e" in the first line, which will make the script
exit as soon of one of the commands inside fails. Then I use 'trap "some
commands" ERR' where needed to install cleanup routines that need to run before
the script exits.

 PS>> If $d ends up being an existing directory, this will copy
 PS>> $f *into* the directory.
 PR> As long as $d isn't a newer file, that's just the sort of copy
 PR> I want.  I'm trying to build up my /pub directory, copying file
 PR> trees to the server, then merging them into one tree.
Assuming /src as the source and /dst as the destination, this situation can
mean that the file /src/a is copied to /dst/a/a if /dst/a/ already exists. Not
sure that is what you want.

 PR> The source trees are coming from downloads on my Windows box,
 PR> that's going to happen!  Perhaps a tr on d$ making " " into "_"?
 PR> Or quoting f$/d$?  I never anticipated this.
Quote them where needed, which is whenever you pass them to some command.

Ciao
Pascal

--- Msged/LNX 6.1.1
 * Origin: Linux FAQ - http://www.tzi.de/~pharao90/faq/ (1:153/401.2)