Re: [Bug-gnupod] Add --copy option to gnupod_search?

[Stuart McLaren]

Hi Henrik,

Please find a patch attached. 

Thanks for your helpful suggestions. I've tried to take
into account that a song may only have its title set (and
not artist or other parameters.) I also took account of
'/' and '\'. I decided to remove spaces too from song
names and target directories. This is more of a judgement
call -- sometimes for scripting etc spaces can cause
some IFS confusion.

I've cowardly ignored both podcast issues and artwork.
I'm more used to writing C rather than Perl, but I tried
to follow your coding conventions where they were
obvious to me.

Any feedback welcome.

-Stuart


--- On Wed, 3/16/11, H. Langos <address@hidden> wrote:

> From: H. Langos <address@hidden>
> Subject: Re: [Bug-gnupod] Add --copy option to gnupod_search?
> To: address@hidden
> Date: Wednesday, March 16, 2011, 10:36 AM
> Hi Richard and Stuart,
> 
> On Wed, Mar 16, 2011 at 05:12:50PM +0100, Richard van den
> Berg wrote:
> > On 16 mrt. 2011, at 16:44, Stuart McLaren <address@hidden>
> wrote:
> > 
> > > Ok. What I plan to do is have it work as
> follows:
> > >> 
> > > 
> > > 1) update gnupod_search --help --> Would
> include info on the --copy option
> > > 2) gnupod_search --copy --> Would backup whole
> ipod to current directory
> > > 3) gnupod_search --copy --directory=/tmp -->
> Would backup whole ipod to /tmp
> > > 4) gnupod_search --copy --directory=/tmp -a
> John_Doe -l Rock_On 
> > > --> Would backup artist John_Doe's Rock_On
> album to /tmp
> > > (ie the behaviour with matching would be exactly
> the same as delete)
> > > 
> > > Note that output would be in the form:
> > > 
> > > "John_Doe - Rock_On"/01_Song_One.m4a
> > > "John_Doe - Rock_On"/02_Song_Two.m4a
> > > 
> > > Does that work for you?
> > 
> > Sounds good to me, but let's hear Henrik's opinion as
> well (he is the main gnupod coder). 
> 
> Sounds very nice indeed.
> 
> I didn't put any work into gnupod_search recently but if
> the patch fits
> nicely into the existing code... no problem.
> I was missing features and flexibility in gnupod_search too
> but
> as people are used to it I have instead taken to writing
> smaller,
> single purpose tools that are (hopefully) easier to read
> and maintain.
> (gnupod_find, gnupod_delete and gnupod_modify)
> 
> 
> Some minor questions:
> 
> How do you select the target filename for podcasts?
> 
> How do you select a target directory if no artist or album
> is given? 
> (The only mandatory attribute for any song is the title.)
> 
> How do you handle character conversion? E.g. If the target
> filesystem
> doesn't handle unicode filenames, or if any of the
> attributes that you 
> use contains a "/" "\" or ":" ?
> 
> How about extracting artwork?
> 
> > > 
> > >> Interesting. Is this an iPod or OS
> limitation? What OS are
> > >> you using?
> > > 
> > > Debian 6.0, 2.6.32-5-amd64
> > > 
> > > Without this option there's a mismatch between
> the
> > > read ipod path for the file and the real mount
> point, ie
> > > gnupod looks for
> > > 
> > > /mnt/ipod/f19/file.mp3
> > > 
> > > but that doesn't exist, without the mount option
> its actually
> > > 
> > > /mnt/ipod/F1/file.mp3. With the mount option
> they
> > > match up.
> > 
> > According to Google shortname=lower is the default for
> linux vfat mounts. Will accessing a directory u6sing F19 not
> work when f19 exists on vfat? Silly case insensitive file
> systems..
> > 
> 
> My default mount options also contain shortname=lower. I
> guess we
> could call gnupod_INIT.pl guilty. It creates those folders
> with a
> capital F. But then again it probably only mimics what
> iTunes does.
> 
> 
> cheers
> -henrik
> 
> 
> 
> _______________________________________________
> Bug-gnupod mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/bug-gnupod
>

gnupod_search-copy.patch
Description: Text Data