Re: [tlug] "How to"

["Stephen J. Turnbull" <stephen@example.com>]

Travis Cardwell writes:

 > During Kalin's presentation, he mentioned that he often composes commands
 > on the command line until they wrap to about five terminal lines, after
 > which it is easier to edit them in vim as a script.

Ctrl-V <RET> is a useful trick in bash, at least (bash treats it like a
 semicolon AFAICT).  Splitting lines with \ <RET> is also occasionally
useful (but I forget how it interacts with things like strings).
Strings themselves can be multiline in bash.  Ie

    $ echo "This is a
    > multiline string."
    This is a
    multiline string.
    $

DTRTs (where the "> " is bash's default line continuation prompt).

Another trick I use is to define a function.  Unfortunately bash
doesn't recognize open brace as a line continuation syntax, but that's
a minor thing.  The main advantage to this method is that you can then
wrap it in "cat >> .bashrc << EOT RET ... EOT <RET>" for future
reference.

 > I like Kalin's suggestion to use rsync.  Though it probably would not be a
 > viable solution for managing MP3 files, it illustrates a way to use a
 > standard utility to solve part of the problem.  Through maintenance of a
 > copy of a directory tree, rsync can indeed be used to alert you of changes
 > quickly.

Yeah, I liked it too.  rsync basically implements extremely efficient
binary comparison of file chunks to avoid expensive over-the-wire
copying at the sub-file level.  It should be possible to exploit that
in this application somehow.  I wonder if rsync has a feature to
maintain a list of checksums.  Or maybe xdelta (same comparison
algorith) would do it.

I just didn't understand how Kalin's suggestion really solves the
problem since it doesn't do "same file" detection (except for
hardlinks, which it will correctly create, but only on request -- but
hardlinks aren't the kind of duplicate Bruno is trying to detect).
Apparently it doesn't solve the problem after all!<wink/>