Re: [tlug] "How to"

[Travis Cardwell <travis.cardwell@example.com>]

I am short on time, but I am going to make one quick comment, in fear that
the thread will be old when I eventually get to it! ;)

On 2014年05月12日 01:02, Bruno Raoult wrote:
> Following our discussions, and different solutions to one problem.
> 
> 1- You have 10,000 files, and you want to find duplicates. Sometimes, 1
> file changes, or you add/remove one, so you want to find the changes
> quickly (let say daily). How?
> 2- These files have "meta-information" inside (let say date/time), that you
> can extract. how would you do?
> 3- How would you *copy* your mp3 (real files) playlists from an m3u file to
> another place, with no subtree in destination? Example: src/a/b/c/d.mp3 =>
> dst/a-b-c-d.mp3. m3u is a common file format for music playing lists.
> 4- If you consider the final target being /a/b/c/d, how would you create
> the new m3u file from the original one? Example: you answered question 3,
> but the target is for another device/machine, therefore different path.
> 
> This is just a practical usage, and maybe a bad example :)

I really like practical examples!  They often have more meaning than
abstract questions, and they often provide a context for evaluation of
answers as well.

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.  Personally, I tend to
write scripts even sooner (based on the complexity of the commands, not so
much the number of characters).  Similarly, I switch to a programming
language once the script starts to get complex enough to need non-trivial
control flow, error management, or data structures.  In the past, I have
had scripts go well over 1,000 lines before I realized I should just
rewrite in a programming language.  These days, I tend to switch *much*
more quickly, as it saves time in the long run.

The above problem is one that I would write a program for.  It is complex
enough that I would not even start with a shell script.  The reason is
that it requires persistence (a "database") in order to be implemented
efficiently.  My solution would have little to do with Linux; it would be
more of a programming exercise.

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.

Steve's git suggestion is awesome!  Git indeed implements all of the data
structures and algorithms that are required, using the repository for
persistence.

Cheers,

Travis