[RFC] File::TVShow::Parse

--0000000000004470c105841a0876
Content-Type: text/plain; charset="UTF-8"

Hello Everyone,

I am considering a module to supplement Video::Filename written by
Behan Webster. I have tried reaching out to him in the past couple of
weeks. Submitting a patch to provide support for show
name.yyyy.mm.dd.ext


In the mean time I have been considering if a specific module for TV
Shows only might also be worth while, of course with additional
features and support.

See attached podtotext file.

I have a few questions.

1)
Would it be better to go with Parse, Meta, or Info since we are
attempting to get meta data from from the file naming. There is
already a Video::Info which does the deep dive into the file contents
from what I have read. I have not used the module itself.

2)
Should I keep support for perl below version 5.10 as versions below
this do not support named groups in regex. I have seen on PerlMonks
that there are still questions being asked by people using perl
versions less than 5.10


Looking forward to hearing back.

Best,
Adam Spann

--0000000000004470c105841a0876
Content-Type: text/plain; charset="US-ASCII"; name="Parse.txt"
Content-Disposition: attachment; filename="Parse.txt"
Content-Transfer-Encoding: base64
Content-ID: <f_jt9j59nx0>
X-Attachment-Id: f_jt9j59nx0

TkFNRQogICAgRmlsZTo6VFZTaG93OjpQYXJzZQoKVkVSU0lPTgogICAgVmVyc2lvbiAwLjAxCgpT
WU5PUFNJUwogICAgVGhpcyBtb2R1bGUgaXMgaW50ZW5kZWQgdG8gcGFyc2UgYW5kIGlkZW50aWZ5
IGluZm9ybWF0aW9uIGluIHRoZSBmaWxlCiAgICBuYW1lIG9mIGEgVFYgc2hvdy4gVGhlc2UgZGV0
YWlscyBjYW4gdGhlbiBiZSBhY2Nlc3NlZCBieSBjYWxsaW5nIHRoZQogICAgcmVsZXZhbnQgbWV0
aG9kcy4gSXQgZG9lcyBOT1QgYXR0ZW1wdCB0byByZWFkIHRoZSBjb250ZW50cyBvZiB0aGUgZmls
ZS4KCiAgICBOb3RlOiBUaGlzIG1vZHVsZSB3aWxsIG1vZGVsbGVkIG9mZiBWaWRlbzo6RmlsZW5h
bWUgY3JlYXRlZCBieSBCZWhhbgogICAgV2Vic3RlciwgYnV0IHdpbGwgZm9jdXMgb24gVFYgU2hv
d3Mgb25seSBhbmQgd2l0aCBhZGRpdGlvbmFsIGZlYXR1cmVzLgoKICAgIElmIHRoZSBmaWxlIG5h
bWUgaXMgcGFyc2VkIGFuZCBjYW4gbm90IGJlIGlkZW50aWZpZWQgYXMgYSBUViBzaG93IHRoZW4K
ICAgICJpc190dl9zaG93IiB3aWxsIHJldHVybiAwLgoKICAgICAgICB1c2UgRmlsZTo6VFZTaG93
OjpQYXJzZTsKCiAgICAgICAgbXkgJHNob3cgPSBGaWxlOjpUVlNob3c6OlBhcnNlLT5uZXcoJ2Zp
bGUnKTsKCk1ldGhvZHMKICBuZXcKICAgIENyZWF0ZSBhIFBhcnNlIG9iamVjdCB0byBleHRyYWN0
IG1ldGEgaW5mb3JtYXRpb24gZnJvbSB0aGUgZmlsZSBuYW1lLgoKICAgICAgICBteSAkc2hvdyA9
IEZpbGU6OlRWU2hvdzo6UGFyc2UtPm5ldygnZmlsZScpOwoKICAgRGF0YSBoZWxkIGluIHRoZSBv
YmplY3QuCiAgICAqICAgc2hvd19uYW1lOiBOYW1lIG9mIHRoZSBzaG93LgoKICAgICogICBvcmln
aW5hbF9zaG93X25hbWU6IFRoaXMgd2lsbCBjb250YWluIHRoZSBzaG93IG5hbWUgZm91bmQgaW4g
dGhlCiAgICAgICAgZmlsZSBuYW1lIHdpdGhvdXQgYW55IG1vZGlmaWNhdGlvbnMgVGhpcyB3aWxs
IG9ubHkgYmUgZGVmaW5lZCBpZgogICAgICAgIF9pc29sYXRlX25hbWVfeWVhciBoYXMgZm91bmQg
YSB5ZWFyIHN0cmluZyB3aXRoaW4gdGhlIGZpbGUgbmFtZSBzdWNoCiAgICAgICAgdGVzdC4yMDE5
LCB0ZXN0LigyMDE5KSwgdGVzdCAyMDE4LCB0ZXN0ICgyMDE4KQoKICAgICogICBzZWFzb246IFNo
b3cgc2Vhc29uCgogICAgKiAgIGVwaXNvZGU6IFNob3cgZXBpc29kZQoKICAgICogICBlbmRlcDog
KE5hbWluZyB1bmRlciBjb25zaWRlcmF0aW9uKSBsYXN0IEVwaXNvZGUgbnVtYmVyIGZvdW5kIHdo
ZW4KICAgICAgICBmaWxlIG5hbWUgY29udGFpbnMgU1hYRVhYRVhYCgogICAgKiAgIHllYXIsIG1v
bnRoLCBkYXRlOiBTaG93IGRhdGUgZS5nIDIwMTkuMDMuMDMgVGhpcyBjYW4gYmUgYWNjZXNzZWQK
ICAgICAgICB1c2luZyB0aGUgbWV0aG9kICJ5bWQiIE5vdGU6IHllYXIgd2lsbCBiZSBkZWZpbmVk
IGluIHR3byBjYXNlcy4gT25lOgogICAgICAgIHNob3cgbmFtZSBjb250YWlucyB5ZWFyIFR3bzog
RmlsZSBuYW1lIGNvbnRhaW5zIFlZWVkuTU0uREQgdGhhdCBhcmUKICAgICAgICBpZGVudGlmaWVk
IGJ5IGRhdGUuCgogICAgKiAgIHJlc29sdXRpb246IFNob3cgcmVzb2x1dGlvbiA0ODBwLzcyMHAg
YW5kIHNvIG9uLiBUaGlzIHdpbGwgYmUgJycgaWYKICAgICAgICBub3QgZm91bmQuCgogICAgKiAg
IGV4dDogRmlsZSBleHRlbnNpb24KCiAgc2hvd19uYW1lCiAgICBSZXR1cm4gdGhlIHNob3cgbmFt
ZSBmb3VuZCBpbiB0aGUgZmlsZSBuYW1lLgoKICBvcmlnaW5hbF9zaG93X25hbWUKICAgIFJldHVy
biB0aGUgb3JpZ2luYWwgc2hvdyBuYW1lLiBUaGlzIG1ldGhvZCB3aWxsIHJldHVybiB0aGUgb3Jn
aW5hbCBzaG93CiAgICBuYW1lIGlmIGRlZmluZWQgb3JpZ2luYWxfc2hvd19uYW1lIHdpbGwgYmUg
ZGVmaW5lZCBpZiBzaG93IG5hbWUKICAgIGNvbnRhaW5lZCBhIHllYXIgc3RyaW5nIChZWVlZKSBv
ciBZWVlZIElmIG5vdCBkZWZpbmVkIGl0IHdpbGwgcmV0dXJuCiAgICB7c2hvd19uYW1lfQoKICBz
ZWFzb24KICAgIFJldHVybiB0aGUgc2Vhc29uIGZvdW5kIGluIHRoZSBmaWxlIG5hbWUuIFJldHVy
biAnJyBpZiBubyBzZWFzb24gaXMKICAgIGZvdW5kLgoKICBlcGlzb2RlCiAgICBSZXR1cm4gdGhl
IGVwaXNvZGUgZm91bmQgaW4gdGhlIGZpbGUgbmFtZS4gUmV0dXJuICcnIGlmIG5vIGVwaXNvZGUK
ICAgIGZvdW5kLgoKICBpc19tdWx0aV9lcGlzb2RlCiAgICBSZXR1cm4gMSBpZiB0aGlzIGlzIGEg
bXVsdGktZXBpc29kZSBmaWxlIFNYWEVYWEVYWC4gUmV0dXJuIDAgaWYgZmFsc2UKCiAgc2Vhc29u
X2VwaXNvZGUKICAgIFJldHVybiBTWFhFWFggb3IgU1hYRVhYRVhYIGZvciBzaW5nbGUgb3IgbXVs
dGkgZXBpc29kZSBmaWxlcy4gUmV0dXJuICcnCiAgICBpZiBub3QgY3JlYXRlZAoKICBoYXNfeWVh
cgogICAgUmV0dXJucyAxIGlmICRzZWxmLT57eWVhcn0gaXMgZGVmaW5lZCBlbHNlIHJldHVybiAw
CgogIHllYXIKICAgIFJldHVybiB0aGUgeWVhciBmb3VuZCBpbiB0aGUgZmlsZSBuYW1lLiBSZXR1
cm4gJycgaXMgbm8geWVhciBmb3VuZC4KCiAgbW9udGgKICAgIFJldHVybiB0aGUgbW9udGggZm91
bmQgaW4gdGhlIGZpbGUgbmFtZS4gUmV0dXJuICcnIGlmIG5vIG1vbnRoIGZvdW5kLgoKICBkYXRl
CiAgICBSZXR1cm4gdGhlIGRhdGUgZm91bmQgaW4gdGhlIGZpbGUgbmFtZS4gUmV0dXJuICcnIGlm
IG5vIGRhdGUgZm91bmQuCgogIHltZAogICAgUmV0dXJuIHRoZSBjb21wbGV0ZSBkYXRlIHN0cmlu
ZyBhcyAnWVlZWS5NTS5ERCcgUnV0dXJuICcnIGlmIG5vCiAgICBhdHRyaWJ1dGVzIHllYXIsIG1v
bnRoLCBvciBkYXRlLgoKICByZXNvbHV0aW9uCiAgICBSZXR1cm4gcmVzb2x1dGlvbiBmb3VuZCBp
biB0aGUgZmlsZSBuYW1lLiBSZXR1cm4gJycgaWYgbm8gcmVzb2x1dGlvbgogICAgZm91bmQuCgog
IGVwaXNvZGVfbmFtZSAoVW5kZXIgY29uc2lkZXJhdGlvbiwgZGlmZmljdWx0IHRvIGlzb2xhdGUg
YW5kIG9mdGVuIG9tbWl0ZWQpCiAgZXh0CiAgICBSZXR1cm4gZmlsZSBleHRlbnNpb24uCgogIGlz
X3R2X3Nob3cKICAgIFJldHVybiAxIGlmIGlkZW50aWZpZWQgYXMgYSBUViBTaG93LiBEZWZhdWx0
IGlzIDAKCiAgaXNfYnlfZGF0ZQogICAgUmV0dXJuIDEgaWYgYnkgZGF0ZS4gRGVmYXVsdCBpcyAw
CgogIGlzX2J5X3NlYXNvbgogICAgUmV0dXJuIDEgaWYgYnkgc2Vhc29uLiBEZWZhdWx0IGlzIDAK
CiAgX2lzb2xhdGVfbmFtZV95ZWFyCkFVVEhPUgogICAgQWRhbSBTcGFubiwgIjxiYXNwYW5uIGF0
IGdtYWlsLmNvbT4iCgpCVUdTCiAgICBQbGVhc2UgcmVwb3J0IGFueSBidWdzIG9yIGZlYXR1cmUg
cmVxdWVzdHMgdG8gImJ1Zy1maWxlLXR2c2hvdy1wYXJzZSBhdAogICAgcnQuY3Bhbi5vcmciLCBv
ciB0aHJvdWdoIHRoZSB3ZWIgaW50ZXJmYWNlIGF0CiAgICA8aHR0cHM6Ly9ydC5jcGFuLm9yZy9O
b0F1dGgvUmVwb3J0QnVnLmh0bWw/UXVldWU9RmlsZS1UVlNob3ctUGFyc2U+LiBJCiAgICB3aWxs
IGJlIG5vdGlmaWVkLCBhbmQgdGhlbiB5b3UnbGwgYXV0b21hdGljYWxseSBiZSBub3RpZmllZCBv
ZiBwcm9ncmVzcwogICAgb24geW91ciBidWcgYXMgSSBtYWtlIGNoYW5nZXMuCgpTVVBQT1JUCiAg
ICBZb3UgY2FuIGZpbmQgZG9jdW1lbnRhdGlvbiBmb3IgdGhpcyBtb2R1bGUgd2l0aCB0aGUgcGVy
bGRvYyBjb21tYW5kLgoKICAgICAgICBwZXJsZG9jIEZpbGU6OlRWU2hvdzo6UGFyc2UKCiAgICBZ
b3UgY2FuIGFsc28gbG9vayBmb3IgaW5mb3JtYXRpb24gYXQ6CgogICAgKiAgIFJUOiBDUEFOJ3Mg
cmVxdWVzdCB0cmFja2VyIChyZXBvcnQgYnVncyBoZXJlKQoKICAgICAgICA8aHR0cHM6Ly9ydC5j
cGFuLm9yZy9Ob0F1dGgvQnVncy5odG1sP0Rpc3Q9RmlsZS1UVlNob3ctUGFyc2U+CgogICAgKiAg
IEFubm9DUEFOOiBBbm5vdGF0ZWQgQ1BBTiBkb2N1bWVudGF0aW9uCgogICAgICAgIDxodHRwOi8v
YW5ub2NwYW4ub3JnL2Rpc3QvRmlsZS1UVlNob3ctUGFyc2U+CgogICAgKiAgIENQQU4gUmF0aW5n
cwoKICAgICAgICA8aHR0cHM6Ly9jcGFucmF0aW5ncy5wZXJsLm9yZy9kL0ZpbGUtVFZTaG93LVBh
cnNlPgoKICAgICogICBTZWFyY2ggQ1BBTgoKICAgICAgICA8aHR0cHM6Ly9tZXRhY3Bhbi5vcmcv
cmVsZWFzZS9GaWxlLVRWU2hvdy1QYXJzZT4KCkFDS05PV0xFREdFTUVOVFMKTElDRU5TRSBBTkQg
Q09QWVJJR0hUCiAgICBDb3B5cmlnaHQgMjAxOSBBZGFtIFNwYW5uLgoKICAgIFRoaXMgcHJvZ3Jh
bSBpcyBmcmVlIHNvZnR3YXJlOyB5b3UgY2FuIHJlZGlzdHJpYnV0ZSBpdCBhbmQvb3IgbW9kaWZ5
IGl0CiAgICB1bmRlciB0aGUgdGVybXMgb2YgZWl0aGVyOiB0aGUgR05VIEdlbmVyYWwgUHVibGlj
IExpY2Vuc2UgYXMgcHVibGlzaGVkCiAgICBieSB0aGUgRnJlZSBTb2Z0d2FyZSBGb3VuZGF0aW9u
OyBvciB0aGUgQXJ0aXN0aWMgTGljZW5zZS4KCiAgICBTZWUgPGh0dHA6Ly9kZXYucGVybC5vcmcv
bGljZW5zZXMvPiBmb3IgbW9yZSBpbmZvcm1hdGlvbi4KCg==
--0000000000004470c105841a0876--
0
baspann
3/15/2019 3:56:55 AM
perl.module-authors 1584 articles. 0 followers. Follow

9 Replies
40 Views

Similar Articles

[PageSpeed] 48

I would tend toward Info myself. The existence of Video::Info is
irrelevant except for highlighting that Info is a valid choice. But I also
admit that's just me, and I tend to view Parse in a language context.

Don't bother trying to support Perl versions less that 5.10. Last I
checked the (admittedly unscientific) surveys, 5.10 was the lowest version
that had a sizeable usage percentage, and on a personal level, I just
don't want to support Perls with flawed security.

My current modules either have a minimum required versions of 5.10.1, or
5.16.1, depending on whether I might have to deal with Unicode. I've never
had a complaint (I don't write pragmas or system-oriented code, so it's
never been anything I've need to worry about).

     -john

On Thu, March 14, 2019 10:56 pm, Adam Spann wrote:
> Hello Everyone,
>
> I am considering a module to supplement Video::Filename written by
> Behan Webster. I have tried reaching out to him in the past couple of
> weeks. Submitting a patch to provide support for show
> name.yyyy.mm.dd.ext
>
>
> In the mean time I have been considering if a specific module for TV
> Shows only might also be worth while, of course with additional
> features and support.
>
> See attached podtotext file.
>
> I have a few questions.
>
> 1)
> Would it be better to go with Parse, Meta, or Info since we are
> attempting to get meta data from from the file naming. There is
> already a Video::Info which does the deep dive into the file contents
> from what I have read. I have not used the module itself.
>
> 2)
> Should I keep support for perl below version 5.10 as versions below
> this do not support named groups in regex. I have seen on PerlMonks
> that there are still questions being asked by people using perl
> versions less than 5.10
>
>
> Looking forward to hearing back.
>
> Best,
> Adam Spann
>
0
jgamble
3/16/2019 7:09:05 PM
--0000000000000f2e9b05848810af
Content-Type: text/plain; charset="UTF-8"

Thanks for the suggestions. I have decided to go with Info.

At this point support legacy regex appears pretty straight forward. But I
agree. It will be removed.
I run my code on an old mac mini, late 2009 which has perl 5.14

Thanks again for the feedback.

Adam

On Sun, 17 Mar 2019 at 04:09, John M. Gamble <jgamble@ripco.com> wrote:

> I would tend toward Info myself. The existence of Video::Info is
> irrelevant except for highlighting that Info is a valid choice. But I also
> admit that's just me, and I tend to view Parse in a language context.
>
> Don't bother trying to support Perl versions less that 5.10. Last I
> checked the (admittedly unscientific) surveys, 5.10 was the lowest version
> that had a sizeable usage percentage, and on a personal level, I just
> don't want to support Perls with flawed security.
>
> My current modules either have a minimum required versions of 5.10.1, or
> 5.16.1, depending on whether I might have to deal with Unicode. I've never
> had a complaint (I don't write pragmas or system-oriented code, so it's
> never been anything I've need to worry about).
>
>      -john
>
> On Thu, March 14, 2019 10:56 pm, Adam Spann wrote:
> > Hello Everyone,
> >
> > I am considering a module to supplement Video::Filename written by
> > Behan Webster. I have tried reaching out to him in the past couple of
> > weeks. Submitting a patch to provide support for show
> > name.yyyy.mm.dd.ext
> >
> >
> > In the mean time I have been considering if a specific module for TV
> > Shows only might also be worth while, of course with additional
> > features and support.
> >
> > See attached podtotext file.
> >
> > I have a few questions.
> >
> > 1)
> > Would it be better to go with Parse, Meta, or Info since we are
> > attempting to get meta data from from the file naming. There is
> > already a Video::Info which does the deep dive into the file contents
> > from what I have read. I have not used the module itself.
> >
> > 2)
> > Should I keep support for perl below version 5.10 as versions below
> > this do not support named groups in regex. I have seen on PerlMonks
> > that there are still questions being asked by people using perl
> > versions less than 5.10
> >
> >
> > Looking forward to hearing back.
> >
> > Best,
> > Adam Spann
> >
>
>
>

--0000000000000f2e9b05848810af
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Thanks for the suggestions. I have decided to go with Info=
..<div><br></div><div>At this point support legacy regex appears pretty stra=
ight forward. But I agree. It will be removed.</div><div>I run my code on a=
n old mac mini, late 2009 which has perl 5.14</div><div><br></div><div>Than=
ks again for the feedback.</div><div><br></div><div>Adam</div></div><br><di=
v class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Sun, 17 Ma=
r 2019 at 04:09, John M. Gamble &lt;<a href=3D"mailto:jgamble@ripco.com">jg=
amble@ripco.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:so=
lid;border-left-color:rgb(204,204,204);padding-left:1ex">I would tend towar=
d Info myself. The existence of Video::Info is<br>
irrelevant except for highlighting that Info is a valid choice. But I also<=
br>
admit that&#39;s just me, and I tend to view Parse in a language context.<b=
r>
<br>
Don&#39;t bother trying to support Perl versions less that 5.10. Last I<br>
checked the (admittedly unscientific) surveys, 5.10 was the lowest version<=
br>
that had a sizeable usage percentage, and on a personal level, I just<br>
don&#39;t want to support Perls with flawed security.<br>
<br>
My current modules either have a minimum required versions of 5.10.1, or<br=
>
5.16.1, depending on whether I might have to deal with Unicode. I&#39;ve ne=
ver<br>
had a complaint (I don&#39;t write pragmas or system-oriented code, so it&#=
39;s<br>
never been anything I&#39;ve need to worry about).<br>
<br>
=C2=A0 =C2=A0 =C2=A0-john<br>
<br>
On Thu, March 14, 2019 10:56 pm, Adam Spann wrote:<br>
&gt; Hello Everyone,<br>
&gt;<br>
&gt; I am considering a module to supplement Video::Filename written by<br>
&gt; Behan Webster. I have tried reaching out to him in the past couple of<=
br>
&gt; weeks. Submitting a patch to provide support for show<br>
&gt; name.yyyy.mm.dd.ext<br>
&gt;<br>
&gt;<br>
&gt; In the mean time I have been considering if a specific module for TV<b=
r>
&gt; Shows only might also be worth while, of course with additional<br>
&gt; features and support.<br>
&gt;<br>
&gt; See attached podtotext file.<br>
&gt;<br>
&gt; I have a few questions.<br>
&gt;<br>
&gt; 1)<br>
&gt; Would it be better to go with Parse, Meta, or Info since we are<br>
&gt; attempting to get meta data from from the file naming. There is<br>
&gt; already a Video::Info which does the deep dive into the file contents<=
br>
&gt; from what I have read. I have not used the module itself.<br>
&gt;<br>
&gt; 2)<br>
&gt; Should I keep support for perl below version 5.10 as versions below<br=
>
&gt; this do not support named groups in regex. I have seen on PerlMonks<br=
>
&gt; that there are still questions being asked by people using perl<br>
&gt; versions less than 5.10<br>
&gt;<br>
&gt;<br>
&gt; Looking forward to hearing back.<br>
&gt;<br>
&gt; Best,<br>
&gt; Adam Spann<br>
&gt;<br>
<br>
<br>
</blockquote></div>

--0000000000000f2e9b05848810af--
0
baspann
3/20/2019 3:13:12 PM
I have completed the majority of the code for this module. Renamed it
File::TVShow::Info as well.

There are still a few things to do. But its main function of
extracting key identifying information is complete.

I am including the current README from the pod documentation.

One question however:

1) I have separted some data and arrays containing regex patterns into
seperate files
    E.G File:TVShow::EpisodeName.pm
    Do I need to VERSION this pm file. The expectation would be that
this file would be updated and this would then
   require a minor version update to the File::TVShow::Info Note that
VERSION is 0.01.0.0 so if EpsiodeName is updated
   Info would become 0.01.0.1 and a minor update to Info would make
the version 0.01.1.0 with a major code change resulting in 0.02.0.0


I look forward to hearing some feedback.

Kind Regards,
Adam Spann

NAME

    File::TVShow::Info - Perl meta data extractor from file name for TV
    Show file.

VERSION

    Version 0.01.0.0

SYNOPSIS

    This module is intended to identify and extract nformation in the file
    name of a TV show. These details can then be accessed by calling the
    relevant methods. It does NOT attempt to read the contents of the file.

    Note: This module will be modelled off
    https://metacpan.org/pod/Video::Filename created by Behan Webster, but
    will focus on TV Shows only and with additional features.

    If the file name is parsed and can not be identified as a TV show then
    "is_tv_show" will return 0.

        use File::TVShow::Info;
        my $show = File::TVShow::Info->new('file');

Methods

 new

    Create a Info object to extract meta information from the file name.

        my $show = File::TVShow::Info->new('file');

  Object attributes.

    Attributes may be accessed through $show->{attribute_name} however
    methods do exist for all required operations.

      * show_name: Name of the show.

      * original_show_name: This will contain the show name found in the
      file name without any modifications. This will only be defined if
      _isolate_name_year has found a year string within the file name such
      as name.2019, name.(2019), name 2018, name (2018)

      * season: Show season

      * episode: Show episode

      * episode_name

      * country

      * endep: (Naming under consideration) last Episode number found when
      file name contains SXXEXXEXX

      * year, month, date: Show date e.g 2019.03.03 This can be accessed
      using the method "ymd" Note: year will be defined in two cases. One:
      show name contains year. show_name.yyyy or Two: File name contains
      YYYY.MM.DD that are identified by date. These are mutually exclusive
      and no conflict is expected.

      * source

      * resolution: Show resolution 480p/720p and so on. This will be '' if
      not found.

      * release_group

      * is_subtitle

      * subtitle_lang

      * ext: File extension

 show_name

    Return the show name found in the file name.

 strip_show_name

    Return show_name after removing string delimiters

 original_show_name

    Return the original show name.

    This method will return the orginal show name if original_show_name is
    defined. This will be defined if show_name contains a year string
    (YYYY) or YYYY

    If not defined it will return {show_name}

 season

    Return the season found in the file name. Return '' if {season} is not
    defined.

 season_to_int

    Return season as an integer

 episode

    Return the episode found in the file name. Return '' if {episode} is
    not defined.

 episode_to_int

    Return episode as an integer

 source

    Return the source of tv show. Return '' if not defined. Yet to be
    coded.

 is_multi_episode

    Return 1 if this is a multi-episode file SXXEXXEXX. Return 0 if false

    This is true if {endep} is defined.

 season_episode

    Return SXXEXX or SXXEXXEXX for single or multi episode files. Return ''
    if not created

    This would only return an empty string if the show_name is not formated
    as show_name.SXX.*

 has_year

    Return 1 if year is defined else return 0

 year

    Return the year found in the file name. Return '' if {year} is not
    defined.

 month

    Return the month found in the file name. Return '' if {month} is not
    defined.

 date

    Return the date found in the file name. Return '' if {date} is not
    defined.

 ymd

    Return the complete date string as 'YYYY.MM.DD' Ruturn '' if attributes
    {year}, {month}, and {date} are not defined.

 resolution

    Return resolution found in the file name. Return '' if {resolution} is
    not defined.

 release_group

    Return release_group found in the file name. Return '' if
    {release_group} is not defined.

 episode_name

    Return episode_name. Return '' if {extra_meta} is not defined or can
    not determine episode name.

    Note: episode name MUST directly follow SXXEXX or it can not be found.

 strip_episode_name

    Return episode name without delimiters.

 country

    Return country found in {show_name}. Return '' if not defined

 ext

    Return file extension. {ext}

 is_tv_show

    Return 1 if identified as a TV Show. Default is 0

 is_tv_subtitle

    Return 1 if the file is a subtitle file, 0 if {is_subtitle} is not
    defined.

    The file must also return true for is_tv_show() or the result is 0

 has_subtitle_lang

    Return 1 if subtitle language was found, Return 0 if {subtitle_lang} is
    not defined.

    Must also return 1 for is_tv_subtitle()

 subtitle_lang

    Return the language of the subtitle file: eng or en. Return '' if
    {subtitle_lang} is not defined.

 has_country

    Return 1 if country was found, Return 0 if {country} is not defined.

    Must also return 1 for is_tv_subtitle()

 is_by_date

    Return 1 if by date. Default is 0

    This will be true where year, month and date are all defined.
    show_name.yyyy.mm.dd.ext

 is_by_season

    Return 1 if by season. Default is 0

    Requires {season} and {episode} to be defined.

AUTHOR

    Adam Spann, <baspann at gmail.com>

On Thu, 21 Mar 2019 at 00:13, Adam Spann <baspann@gmail.com> wrote:
>
> Thanks for the suggestions. I have decided to go with Info.
>
> At this point support legacy regex appears pretty straight forward. But I agree. It will be removed.
> I run my code on an old mac mini, late 2009 which has perl 5.14
>
> Thanks again for the feedback.
>
> Adam
>
> On Sun, 17 Mar 2019 at 04:09, John M. Gamble <jgamble@ripco.com> wrote:
>>
>> I would tend toward Info myself. The existence of Video::Info is
>> irrelevant except for highlighting that Info is a valid choice. But I also
>> admit that's just me, and I tend to view Parse in a language context.
>>
>> Don't bother trying to support Perl versions less that 5.10. Last I
>> checked the (admittedly unscientific) surveys, 5.10 was the lowest version
>> that had a sizeable usage percentage, and on a personal level, I just
>> don't want to support Perls with flawed security.
>>
>> My current modules either have a minimum required versions of 5.10.1, or
>> 5.16.1, depending on whether I might have to deal with Unicode. I've never
>> had a complaint (I don't write pragmas or system-oriented code, so it's
>> never been anything I've need to worry about).
>>
>>      -john
>>
>> On Thu, March 14, 2019 10:56 pm, Adam Spann wrote:
>> > Hello Everyone,
>> >
>> > I am considering a module to supplement Video::Filename written by
>> > Behan Webster. I have tried reaching out to him in the past couple of
>> > weeks. Submitting a patch to provide support for show
>> > name.yyyy.mm.dd.ext
>> >
>> >
>> > In the mean time I have been considering if a specific module for TV
>> > Shows only might also be worth while, of course with additional
>> > features and support.
>> >
>> > See attached podtotext file.
>> >
>> > I have a few questions.
>> >
>> > 1)
>> > Would it be better to go with Parse, Meta, or Info since we are
>> > attempting to get meta data from from the file naming. There is
>> > already a Video::Info which does the deep dive into the file contents
>> > from what I have read. I have not used the module itself.
>> >
>> > 2)
>> > Should I keep support for perl below version 5.10 as versions below
>> > this do not support named groups in regex. I have seen on PerlMonks
>> > that there are still questions being asked by people using perl
>> > versions less than 5.10
>> >
>> >
>> > Looking forward to hearing back.
>> >
>> > Best,
>> > Adam Spann
>> >
>>
>>
0
baspann
4/15/2019 1:34:49 PM
--00000000000015e6e7058693cff9
Content-Type: text/plain; charset="UTF-8"

Best practice is to $VERSION all modules in your distribution, because then
other distributions can depend on a certain version of any module they are
using rather than only the main module. You can bump versions in modules
separately based on when each is updated, but generally it ends up being
simpler in the long run if you keep all versions the same, thus matching
the distribution version, and bump all of them each release. Authoring
tools like Dist::Zilla/Milla/Minilla can manage these versions for you (see
the Starter bundle's managed_versions option for Dist::Zilla), and
otherwise I wrote a tool that may be helpful:
https://metacpan.org/pod/perl-bump-version

As a side note, remember that the X.Y.Z form of versions (with more than
one decimal point) is a sequence of integers, thus leading zeroes in any
section are insignificant. Make sure not to accidentally use the X.Y form,
which in Perl is treated as a decimal number that isn't directly
compatible. Further reading:
http://blogs.perl.org/users/grinnz/2018/04/a-guide-to-versions-in-perl.html

-Dan

On Mon, Apr 15, 2019 at 9:35 AM Adam Spann <baspann@gmail.com> wrote:

> I have completed the majority of the code for this module. Renamed it
> File::TVShow::Info as well.
>
> There are still a few things to do. But its main function of
> extracting key identifying information is complete.
>
> I am including the current README from the pod documentation.
>
> One question however:
>
> 1) I have separted some data and arrays containing regex patterns into
> seperate files
>     E.G File:TVShow::EpisodeName.pm
>     Do I need to VERSION this pm file. The expectation would be that
> this file would be updated and this would then
>    require a minor version update to the File::TVShow::Info Note that
> VERSION is 0.01.0.0 so if EpsiodeName is updated
>    Info would become 0.01.0.1 and a minor update to Info would make
> the version 0.01.1.0 with a major code change resulting in 0.02.0.0
>
>
> I look forward to hearing some feedback.
>
> Kind Regards,
> Adam Spann
>
> NAME
>
>     File::TVShow::Info - Perl meta data extractor from file name for TV
>     Show file.
>
> VERSION
>
>     Version 0.01.0.0
>
> SYNOPSIS
>
>     This module is intended to identify and extract nformation in the file
>     name of a TV show. These details can then be accessed by calling the
>     relevant methods. It does NOT attempt to read the contents of the file.
>
>     Note: This module will be modelled off
>     https://metacpan.org/pod/Video::Filename created by Behan Webster, but
>     will focus on TV Shows only and with additional features.
>
>     If the file name is parsed and can not be identified as a TV show then
>     "is_tv_show" will return 0.
>
>         use File::TVShow::Info;
>         my $show = File::TVShow::Info->new('file');
>
> Methods
>
>  new
>
>     Create a Info object to extract meta information from the file name.
>
>         my $show = File::TVShow::Info->new('file');
>
>   Object attributes.
>
>     Attributes may be accessed through $show->{attribute_name} however
>     methods do exist for all required operations.
>
>       * show_name: Name of the show.
>
>       * original_show_name: This will contain the show name found in the
>       file name without any modifications. This will only be defined if
>       _isolate_name_year has found a year string within the file name such
>       as name.2019, name.(2019), name 2018, name (2018)
>
>       * season: Show season
>
>       * episode: Show episode
>
>       * episode_name
>
>       * country
>
>       * endep: (Naming under consideration) last Episode number found when
>       file name contains SXXEXXEXX
>
>       * year, month, date: Show date e.g 2019.03.03 This can be accessed
>       using the method "ymd" Note: year will be defined in two cases. One:
>       show name contains year. show_name.yyyy or Two: File name contains
>       YYYY.MM.DD that are identified by date. These are mutually exclusive
>       and no conflict is expected.
>
>       * source
>
>       * resolution: Show resolution 480p/720p and so on. This will be '' if
>       not found.
>
>       * release_group
>
>       * is_subtitle
>
>       * subtitle_lang
>
>       * ext: File extension
>
>  show_name
>
>     Return the show name found in the file name.
>
>  strip_show_name
>
>     Return show_name after removing string delimiters
>
>  original_show_name
>
>     Return the original show name.
>
>     This method will return the orginal show name if original_show_name is
>     defined. This will be defined if show_name contains a year string
>     (YYYY) or YYYY
>
>     If not defined it will return {show_name}
>
>  season
>
>     Return the season found in the file name. Return '' if {season} is not
>     defined.
>
>  season_to_int
>
>     Return season as an integer
>
>  episode
>
>     Return the episode found in the file name. Return '' if {episode} is
>     not defined.
>
>  episode_to_int
>
>     Return episode as an integer
>
>  source
>
>     Return the source of tv show. Return '' if not defined. Yet to be
>     coded.
>
>  is_multi_episode
>
>     Return 1 if this is a multi-episode file SXXEXXEXX. Return 0 if false
>
>     This is true if {endep} is defined.
>
>  season_episode
>
>     Return SXXEXX or SXXEXXEXX for single or multi episode files. Return ''
>     if not created
>
>     This would only return an empty string if the show_name is not formated
>     as show_name.SXX.*
>
>  has_year
>
>     Return 1 if year is defined else return 0
>
>  year
>
>     Return the year found in the file name. Return '' if {year} is not
>     defined.
>
>  month
>
>     Return the month found in the file name. Return '' if {month} is not
>     defined.
>
>  date
>
>     Return the date found in the file name. Return '' if {date} is not
>     defined.
>
>  ymd
>
>     Return the complete date string as 'YYYY.MM.DD' Ruturn '' if attributes
>     {year}, {month}, and {date} are not defined.
>
>  resolution
>
>     Return resolution found in the file name. Return '' if {resolution} is
>     not defined.
>
>  release_group
>
>     Return release_group found in the file name. Return '' if
>     {release_group} is not defined.
>
>  episode_name
>
>     Return episode_name. Return '' if {extra_meta} is not defined or can
>     not determine episode name.
>
>     Note: episode name MUST directly follow SXXEXX or it can not be found.
>
>  strip_episode_name
>
>     Return episode name without delimiters.
>
>  country
>
>     Return country found in {show_name}. Return '' if not defined
>
>  ext
>
>     Return file extension. {ext}
>
>  is_tv_show
>
>     Return 1 if identified as a TV Show. Default is 0
>
>  is_tv_subtitle
>
>     Return 1 if the file is a subtitle file, 0 if {is_subtitle} is not
>     defined.
>
>     The file must also return true for is_tv_show() or the result is 0
>
>  has_subtitle_lang
>
>     Return 1 if subtitle language was found, Return 0 if {subtitle_lang} is
>     not defined.
>
>     Must also return 1 for is_tv_subtitle()
>
>  subtitle_lang
>
>     Return the language of the subtitle file: eng or en. Return '' if
>     {subtitle_lang} is not defined.
>
>  has_country
>
>     Return 1 if country was found, Return 0 if {country} is not defined.
>
>     Must also return 1 for is_tv_subtitle()
>
>  is_by_date
>
>     Return 1 if by date. Default is 0
>
>     This will be true where year, month and date are all defined.
>     show_name.yyyy.mm.dd.ext
>
>  is_by_season
>
>     Return 1 if by season. Default is 0
>
>     Requires {season} and {episode} to be defined.
>
> AUTHOR
>
>     Adam Spann, <baspann at gmail.com>
>
> On Thu, 21 Mar 2019 at 00:13, Adam Spann <baspann@gmail.com> wrote:
> >
> > Thanks for the suggestions. I have decided to go with Info.
> >
> > At this point support legacy regex appears pretty straight forward. But
> I agree. It will be removed.
> > I run my code on an old mac mini, late 2009 which has perl 5.14
> >
> > Thanks again for the feedback.
> >
> > Adam
> >
> > On Sun, 17 Mar 2019 at 04:09, John M. Gamble <jgamble@ripco.com> wrote:
> >>
> >> I would tend toward Info myself. The existence of Video::Info is
> >> irrelevant except for highlighting that Info is a valid choice. But I
> also
> >> admit that's just me, and I tend to view Parse in a language context.
> >>
> >> Don't bother trying to support Perl versions less that 5.10. Last I
> >> checked the (admittedly unscientific) surveys, 5.10 was the lowest
> version
> >> that had a sizeable usage percentage, and on a personal level, I just
> >> don't want to support Perls with flawed security.
> >>
> >> My current modules either have a minimum required versions of 5.10.1, or
> >> 5.16.1, depending on whether I might have to deal with Unicode. I've
> never
> >> had a complaint (I don't write pragmas or system-oriented code, so it's
> >> never been anything I've need to worry about).
> >>
> >>      -john
> >>
> >> On Thu, March 14, 2019 10:56 pm, Adam Spann wrote:
> >> > Hello Everyone,
> >> >
> >> > I am considering a module to supplement Video::Filename written by
> >> > Behan Webster. I have tried reaching out to him in the past couple of
> >> > weeks. Submitting a patch to provide support for show
> >> > name.yyyy.mm.dd.ext
> >> >
> >> >
> >> > In the mean time I have been considering if a specific module for TV
> >> > Shows only might also be worth while, of course with additional
> >> > features and support.
> >> >
> >> > See attached podtotext file.
> >> >
> >> > I have a few questions.
> >> >
> >> > 1)
> >> > Would it be better to go with Parse, Meta, or Info since we are
> >> > attempting to get meta data from from the file naming. There is
> >> > already a Video::Info which does the deep dive into the file contents
> >> > from what I have read. I have not used the module itself.
> >> >
> >> > 2)
> >> > Should I keep support for perl below version 5.10 as versions below
> >> > this do not support named groups in regex. I have seen on PerlMonks
> >> > that there are still questions being asked by people using perl
> >> > versions less than 5.10
> >> >
> >> >
> >> > Looking forward to hearing back.
> >> >
> >> > Best,
> >> > Adam Spann
> >> >
> >>
> >>
>

--00000000000015e6e7058693cff9
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Best practice is to $VERSION all modules in your distribut=
ion, because then other distributions can depend on a certain version of an=
y module they are using rather than only the main module. You can bump vers=
ions in modules separately based on when each is updated, but generally it =
ends up being simpler in the long run if you keep all versions the same, th=
us matching the distribution version, and bump all of them each release. Au=
thoring tools like Dist::Zilla/Milla/Minilla can manage these versions for =
you (see the Starter bundle&#39;s managed_versions option for Dist::Zilla),=
 and otherwise I wrote a tool that may be helpful:=C2=A0<a href=3D"https://=
metacpan.org/pod/perl-bump-version">https://metacpan.org/pod/perl-bump-vers=
ion</a><div><br></div><div>As a side note, remember that the X.Y.Z form of =
versions (with more than one decimal point) is a sequence of integers, thus=
 leading zeroes in any section are insignificant. Make sure not to accident=
ally use the X.Y form, which in Perl is treated as a decimal number that is=
n&#39;t directly compatible. Further reading:=C2=A0<a href=3D"http://blogs.=
perl.org/users/grinnz/2018/04/a-guide-to-versions-in-perl.html">http://blog=
s.perl.org/users/grinnz/2018/04/a-guide-to-versions-in-perl.html</a><br><di=
v><br></div><div>-Dan</div></div></div><br><div class=3D"gmail_quote"><div =
dir=3D"ltr" class=3D"gmail_attr">On Mon, Apr 15, 2019 at 9:35 AM Adam Spann=
 &lt;<a href=3D"mailto:baspann@gmail.com">baspann@gmail.com</a>&gt; wrote:<=
br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8e=
x;border-left:1px solid rgb(204,204,204);padding-left:1ex">I have completed=
 the majority of the code for this module. Renamed it<br>
File::TVShow::Info as well.<br>
<br>
There are still a few things to do. But its main function of<br>
extracting key identifying information is complete.<br>
<br>
I am including the current README from the pod documentation.<br>
<br>
One question however:<br>
<br>
1) I have separted some data and arrays containing regex patterns into<br>
seperate files<br>
=C2=A0 =C2=A0 E.G File:TVShow::EpisodeName.pm<br>
=C2=A0 =C2=A0 Do I need to VERSION this pm file. The expectation would be t=
hat<br>
this file would be updated and this would then<br>
=C2=A0 =C2=A0require a minor version update to the File::TVShow::Info Note =
that<br>
VERSION is 0.01.0.0 so if EpsiodeName is updated<br>
=C2=A0 =C2=A0Info would become 0.01.0.1 and a minor update to Info would ma=
ke<br>
the version 0.01.1.0 with a major code change resulting in 0.02.0.0<br>
<br>
<br>
I look forward to hearing some feedback.<br>
<br>
Kind Regards,<br>
Adam Spann<br>
<br>
NAME<br>
<br>
=C2=A0 =C2=A0 File::TVShow::Info - Perl meta data extractor from file name =
for TV<br>
=C2=A0 =C2=A0 Show file.<br>
<br>
VERSION<br>
<br>
=C2=A0 =C2=A0 Version 0.01.0.0<br>
<br>
SYNOPSIS<br>
<br>
=C2=A0 =C2=A0 This module is intended to identify and extract nformation in=
 the file<br>
=C2=A0 =C2=A0 name of a TV show. These details can then be accessed by call=
ing the<br>
=C2=A0 =C2=A0 relevant methods. It does NOT attempt to read the contents of=
 the file.<br>
<br>
=C2=A0 =C2=A0 Note: This module will be modelled off<br>
=C2=A0 =C2=A0 <a href=3D"https://metacpan.org/pod/Video::Filename" rel=3D"n=
oreferrer" target=3D"_blank">https://metacpan.org/pod/Video::Filename</a> c=
reated by Behan Webster, but<br>
=C2=A0 =C2=A0 will focus on TV Shows only and with additional features.<br>
<br>
=C2=A0 =C2=A0 If the file name is parsed and can not be identified as a TV =
show then<br>
=C2=A0 =C2=A0 &quot;is_tv_show&quot; will return 0.<br>
<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 use File::TVShow::Info;<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 my $show =3D File::TVShow::Info-&gt;new(&#39;fi=
le&#39;);<br>
<br>
Methods<br>
<br>
=C2=A0new<br>
<br>
=C2=A0 =C2=A0 Create a Info object to extract meta information from the fil=
e name.<br>
<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 my $show =3D File::TVShow::Info-&gt;new(&#39;fi=
le&#39;);<br>
<br>
=C2=A0 Object attributes.<br>
<br>
=C2=A0 =C2=A0 Attributes may be accessed through $show-&gt;{attribute_name}=
 however<br>
=C2=A0 =C2=A0 methods do exist for all required operations.<br>
<br>
=C2=A0 =C2=A0 =C2=A0 * show_name: Name of the show.<br>
<br>
=C2=A0 =C2=A0 =C2=A0 * original_show_name: This will contain the show name =
found in the<br>
=C2=A0 =C2=A0 =C2=A0 file name without any modifications. This will only be=
 defined if<br>
=C2=A0 =C2=A0 =C2=A0 _isolate_name_year has found a year string within the =
file name such<br>
=C2=A0 =C2=A0 =C2=A0 as name.2019, name.(2019), name 2018, name (2018)<br>
<br>
=C2=A0 =C2=A0 =C2=A0 * season: Show season<br>
<br>
=C2=A0 =C2=A0 =C2=A0 * episode: Show episode<br>
<br>
=C2=A0 =C2=A0 =C2=A0 * episode_name<br>
<br>
=C2=A0 =C2=A0 =C2=A0 * country<br>
<br>
=C2=A0 =C2=A0 =C2=A0 * endep: (Naming under consideration) last Episode num=
ber found when<br>
=C2=A0 =C2=A0 =C2=A0 file name contains SXXEXXEXX<br>
<br>
=C2=A0 =C2=A0 =C2=A0 * year, month, date: Show date e.g 2019.03.03 This can=
 be accessed<br>
=C2=A0 =C2=A0 =C2=A0 using the method &quot;ymd&quot; Note: year will be de=
fined in two cases. One:<br>
=C2=A0 =C2=A0 =C2=A0 show name contains year. show_name.yyyy or Two: File n=
ame contains<br>
=C2=A0 =C2=A0 =C2=A0 YYYY.MM.DD that are identified by date. These are mutu=
ally exclusive<br>
=C2=A0 =C2=A0 =C2=A0 and no conflict is expected.<br>
<br>
=C2=A0 =C2=A0 =C2=A0 * source<br>
<br>
=C2=A0 =C2=A0 =C2=A0 * resolution: Show resolution 480p/720p and so on. Thi=
s will be &#39;&#39; if<br>
=C2=A0 =C2=A0 =C2=A0 not found.<br>
<br>
=C2=A0 =C2=A0 =C2=A0 * release_group<br>
<br>
=C2=A0 =C2=A0 =C2=A0 * is_subtitle<br>
<br>
=C2=A0 =C2=A0 =C2=A0 * subtitle_lang<br>
<br>
=C2=A0 =C2=A0 =C2=A0 * ext: File extension<br>
<br>
=C2=A0show_name<br>
<br>
=C2=A0 =C2=A0 Return the show name found in the file name.<br>
<br>
=C2=A0strip_show_name<br>
<br>
=C2=A0 =C2=A0 Return show_name after removing string delimiters<br>
<br>
=C2=A0original_show_name<br>
<br>
=C2=A0 =C2=A0 Return the original show name.<br>
<br>
=C2=A0 =C2=A0 This method will return the orginal show name if original_sho=
w_name is<br>
=C2=A0 =C2=A0 defined. This will be defined if show_name contains a year st=
ring<br>
=C2=A0 =C2=A0 (YYYY) or YYYY<br>
<br>
=C2=A0 =C2=A0 If not defined it will return {show_name}<br>
<br>
=C2=A0season<br>
<br>
=C2=A0 =C2=A0 Return the season found in the file name. Return &#39;&#39; i=
f {season} is not<br>
=C2=A0 =C2=A0 defined.<br>
<br>
=C2=A0season_to_int<br>
<br>
=C2=A0 =C2=A0 Return season as an integer<br>
<br>
=C2=A0episode<br>
<br>
=C2=A0 =C2=A0 Return the episode found in the file name. Return &#39;&#39; =
if {episode} is<br>
=C2=A0 =C2=A0 not defined.<br>
<br>
=C2=A0episode_to_int<br>
<br>
=C2=A0 =C2=A0 Return episode as an integer<br>
<br>
=C2=A0source<br>
<br>
=C2=A0 =C2=A0 Return the source of tv show. Return &#39;&#39; if not define=
d. Yet to be<br>
=C2=A0 =C2=A0 coded.<br>
<br>
=C2=A0is_multi_episode<br>
<br>
=C2=A0 =C2=A0 Return 1 if this is a multi-episode file SXXEXXEXX. Return 0 =
if false<br>
<br>
=C2=A0 =C2=A0 This is true if {endep} is defined.<br>
<br>
=C2=A0season_episode<br>
<br>
=C2=A0 =C2=A0 Return SXXEXX or SXXEXXEXX for single or multi episode files.=
 Return &#39;&#39;<br>
=C2=A0 =C2=A0 if not created<br>
<br>
=C2=A0 =C2=A0 This would only return an empty string if the show_name is no=
t formated<br>
=C2=A0 =C2=A0 as show_name.SXX.*<br>
<br>
=C2=A0has_year<br>
<br>
=C2=A0 =C2=A0 Return 1 if year is defined else return 0<br>
<br>
=C2=A0year<br>
<br>
=C2=A0 =C2=A0 Return the year found in the file name. Return &#39;&#39; if =
{year} is not<br>
=C2=A0 =C2=A0 defined.<br>
<br>
=C2=A0month<br>
<br>
=C2=A0 =C2=A0 Return the month found in the file name. Return &#39;&#39; if=
 {month} is not<br>
=C2=A0 =C2=A0 defined.<br>
<br>
=C2=A0date<br>
<br>
=C2=A0 =C2=A0 Return the date found in the file name. Return &#39;&#39; if =
{date} is not<br>
=C2=A0 =C2=A0 defined.<br>
<br>
=C2=A0ymd<br>
<br>
=C2=A0 =C2=A0 Return the complete date string as &#39;YYYY.MM.DD&#39; Rutur=
n &#39;&#39; if attributes<br>
=C2=A0 =C2=A0 {year}, {month}, and {date} are not defined.<br>
<br>
=C2=A0resolution<br>
<br>
=C2=A0 =C2=A0 Return resolution found in the file name. Return &#39;&#39; i=
f {resolution} is<br>
=C2=A0 =C2=A0 not defined.<br>
<br>
=C2=A0release_group<br>
<br>
=C2=A0 =C2=A0 Return release_group found in the file name. Return &#39;&#39=
; if<br>
=C2=A0 =C2=A0 {release_group} is not defined.<br>
<br>
=C2=A0episode_name<br>
<br>
=C2=A0 =C2=A0 Return episode_name. Return &#39;&#39; if {extra_meta} is not=
 defined or can<br>
=C2=A0 =C2=A0 not determine episode name.<br>
<br>
=C2=A0 =C2=A0 Note: episode name MUST directly follow SXXEXX or it can not =
be found.<br>
<br>
=C2=A0strip_episode_name<br>
<br>
=C2=A0 =C2=A0 Return episode name without delimiters.<br>
<br>
=C2=A0country<br>
<br>
=C2=A0 =C2=A0 Return country found in {show_name}. Return &#39;&#39; if not=
 defined<br>
<br>
=C2=A0ext<br>
<br>
=C2=A0 =C2=A0 Return file extension. {ext}<br>
<br>
=C2=A0is_tv_show<br>
<br>
=C2=A0 =C2=A0 Return 1 if identified as a TV Show. Default is 0<br>
<br>
=C2=A0is_tv_subtitle<br>
<br>
=C2=A0 =C2=A0 Return 1 if the file is a subtitle file, 0 if {is_subtitle} i=
s not<br>
=C2=A0 =C2=A0 defined.<br>
<br>
=C2=A0 =C2=A0 The file must also return true for is_tv_show() or the result=
 is 0<br>
<br>
=C2=A0has_subtitle_lang<br>
<br>
=C2=A0 =C2=A0 Return 1 if subtitle language was found, Return 0 if {subtitl=
e_lang} is<br>
=C2=A0 =C2=A0 not defined.<br>
<br>
=C2=A0 =C2=A0 Must also return 1 for is_tv_subtitle()<br>
<br>
=C2=A0subtitle_lang<br>
<br>
=C2=A0 =C2=A0 Return the language of the subtitle file: eng or en. Return &=
#39;&#39; if<br>
=C2=A0 =C2=A0 {subtitle_lang} is not defined.<br>
<br>
=C2=A0has_country<br>
<br>
=C2=A0 =C2=A0 Return 1 if country was found, Return 0 if {country} is not d=
efined.<br>
<br>
=C2=A0 =C2=A0 Must also return 1 for is_tv_subtitle()<br>
<br>
=C2=A0is_by_date<br>
<br>
=C2=A0 =C2=A0 Return 1 if by date. Default is 0<br>
<br>
=C2=A0 =C2=A0 This will be true where year, month and date are all defined.=
<br>
=C2=A0 =C2=A0 show_name.yyyy.mm.dd.ext<br>
<br>
=C2=A0is_by_season<br>
<br>
=C2=A0 =C2=A0 Return 1 if by season. Default is 0<br>
<br>
=C2=A0 =C2=A0 Requires {season} and {episode} to be defined.<br>
<br>
AUTHOR<br>
<br>
=C2=A0 =C2=A0 Adam Spann, &lt;baspann at <a href=3D"http://gmail.com" rel=
=3D"noreferrer" target=3D"_blank">gmail.com</a>&gt;<br>
<br>
On Thu, 21 Mar 2019 at 00:13, Adam Spann &lt;<a href=3D"mailto:baspann@gmai=
l.com" target=3D"_blank">baspann@gmail.com</a>&gt; wrote:<br>
&gt;<br>
&gt; Thanks for the suggestions. I have decided to go with Info.<br>
&gt;<br>
&gt; At this point support legacy regex appears pretty straight forward. Bu=
t I agree. It will be removed.<br>
&gt; I run my code on an old mac mini, late 2009 which has perl 5.14<br>
&gt;<br>
&gt; Thanks again for the feedback.<br>
&gt;<br>
&gt; Adam<br>
&gt;<br>
&gt; On Sun, 17 Mar 2019 at 04:09, John M. Gamble &lt;<a href=3D"mailto:jga=
mble@ripco.com" target=3D"_blank">jgamble@ripco.com</a>&gt; wrote:<br>
&gt;&gt;<br>
&gt;&gt; I would tend toward Info myself. The existence of Video::Info is<b=
r>
&gt;&gt; irrelevant except for highlighting that Info is a valid choice. Bu=
t I also<br>
&gt;&gt; admit that&#39;s just me, and I tend to view Parse in a language c=
ontext.<br>
&gt;&gt;<br>
&gt;&gt; Don&#39;t bother trying to support Perl versions less that 5.10. L=
ast I<br>
&gt;&gt; checked the (admittedly unscientific) surveys, 5.10 was the lowest=
 version<br>
&gt;&gt; that had a sizeable usage percentage, and on a personal level, I j=
ust<br>
&gt;&gt; don&#39;t want to support Perls with flawed security.<br>
&gt;&gt;<br>
&gt;&gt; My current modules either have a minimum required versions of 5.10=
..1, or<br>
&gt;&gt; 5.16.1, depending on whether I might have to deal with Unicode. I&=
#39;ve never<br>
&gt;&gt; had a complaint (I don&#39;t write pragmas or system-oriented code=
, so it&#39;s<br>
&gt;&gt; never been anything I&#39;ve need to worry about).<br>
&gt;&gt;<br>
&gt;&gt;=C2=A0 =C2=A0 =C2=A0 -john<br>
&gt;&gt;<br>
&gt;&gt; On Thu, March 14, 2019 10:56 pm, Adam Spann wrote:<br>
&gt;&gt; &gt; Hello Everyone,<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; I am considering a module to supplement Video::Filename writt=
en by<br>
&gt;&gt; &gt; Behan Webster. I have tried reaching out to him in the past c=
ouple of<br>
&gt;&gt; &gt; weeks. Submitting a patch to provide support for show<br>
&gt;&gt; &gt; name.yyyy.mm.dd.ext<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; In the mean time I have been considering if a specific module=
 for TV<br>
&gt;&gt; &gt; Shows only might also be worth while, of course with addition=
al<br>
&gt;&gt; &gt; features and support.<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; See attached podtotext file.<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; I have a few questions.<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; 1)<br>
&gt;&gt; &gt; Would it be better to go with Parse, Meta, or Info since we a=
re<br>
&gt;&gt; &gt; attempting to get meta data from from the file naming. There =
is<br>
&gt;&gt; &gt; already a Video::Info which does the deep dive into the file =
contents<br>
&gt;&gt; &gt; from what I have read. I have not used the module itself.<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; 2)<br>
&gt;&gt; &gt; Should I keep support for perl below version 5.10 as versions=
 below<br>
&gt;&gt; &gt; this do not support named groups in regex. I have seen on Per=
lMonks<br>
&gt;&gt; &gt; that there are still questions being asked by people using pe=
rl<br>
&gt;&gt; &gt; versions less than 5.10<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; Looking forward to hearing back.<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; Best,<br>
&gt;&gt; &gt; Adam Spann<br>
&gt;&gt; &gt;<br>
&gt;&gt;<br>
&gt;&gt;<br>
</blockquote></div>

--00000000000015e6e7058693cff9--
0
grinnz
4/15/2019 4:04:24 PM
On Mon, Apr 15, 2019 at 12:04:24PM -0400, Dan Book wrote:

> As a side note, remember that the X.Y.Z form of versions (with more than
> one decimal point) is a sequence of integers ...

Sadly it's worse than that.

There exists popular software management software out there written by
idiots who think that 3.0014 > 3.1, so that rule applies even when
you're using numbers in the form X.Y with a single decimal point. Those
people did a lot of hard work to break numeric comparisons, one of the
few things that computers are any good at.

To work around their deliberate bug you need to keep the non-integer
part of your version numbers the same length, always. So use the strings
"3.0014" and "3.1000" instead of the numbers 3.0014 and 3.1 if you want
to use non-integers.

Or just use integers.

-- 
David Cantrell | Minister for Arbitrary Justice

   The voices said it's a good day to clean my weapons
0
david
4/15/2019 5:46:01 PM
On Mon, April 15, 2019 12:46 pm, David Cantrell wrote:
> On Mon, Apr 15, 2019 at 12:04:24PM -0400, Dan Book wrote:
>
>> As a side note, remember that the X.Y.Z form of versions (with more than
>> one decimal point) is a sequence of integers ...
>
> Sadly it's worse than that.
>
> There exists popular software management software out there written by
> idiots who think that 3.0014 > 3.1, so that rule applies even when
> you're using numbers in the form X.Y with a single decimal point. Those
> people did a lot of hard work to break numeric comparisons, one of the
> few things that computers are any good at.

Are we at the point where there is no reason to not use X.Y.Z? I recall (I
think) the historical reasons for using the 5.00y00z format, but given
that minimum Perl versions are now specified in META.* files, surely
there's no real reason to keep doing that anymore?

I say this while looking at all my modules, which still use the fraction
format.

     -john
0
jgamble
4/16/2019 7:54:13 PM
--0000000000005155250586ab35de
Content-Type: text/plain; charset="UTF-8"

It depends entirely what Perls you want to support. If you only want to
support Perl 5.10 or newer, module versions in the dotted-decimal form are
fine as long as you always declare them as strings and don't use
underscores. If you want to support older than that, you have to jump
through some hoops or risk users getting the wrong behavior.

For the 'use X' statement itself for declaring a minimum perl version of a
file, the '5.XXXYYY' format is still (always?) recommended, because it will
make sure that running it on older Perls will result in a sensible error
message.

-Dan

On Tue, Apr 16, 2019 at 3:54 PM John M. Gamble <jgamble@ripco.com> wrote:

> On Mon, April 15, 2019 12:46 pm, David Cantrell wrote:
> > On Mon, Apr 15, 2019 at 12:04:24PM -0400, Dan Book wrote:
> >
> >> As a side note, remember that the X.Y.Z form of versions (with more than
> >> one decimal point) is a sequence of integers ...
> >
> > Sadly it's worse than that.
> >
> > There exists popular software management software out there written by
> > idiots who think that 3.0014 > 3.1, so that rule applies even when
> > you're using numbers in the form X.Y with a single decimal point. Those
> > people did a lot of hard work to break numeric comparisons, one of the
> > few things that computers are any good at.
>
> Are we at the point where there is no reason to not use X.Y.Z? I recall (I
> think) the historical reasons for using the 5.00y00z format, but given
> that minimum Perl versions are now specified in META.* files, surely
> there's no real reason to keep doing that anymore?
>
> I say this while looking at all my modules, which still use the fraction
> format.
>
>      -john
>

--0000000000005155250586ab35de
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">It depends entirely what Perls you want to support. If you=
 only want to support Perl 5.10 or newer, module versions in the dotted-dec=
imal form are fine as long as you always declare them as strings and don&#3=
9;t use underscores. If you want to support older than that, you have to ju=
mp through some hoops or risk users getting the wrong behavior.<div><br></d=
iv><div>For the &#39;use X&#39; statement itself for declaring a minimum pe=
rl version of a file, the &#39;5.XXXYYY&#39; format is still (always?) reco=
mmended, because it will make sure that running it on older Perls will resu=
lt in a sensible error message.</div><div><br></div><div>-Dan</div></div><b=
r><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Tue, =
Apr 16, 2019 at 3:54 PM John M. Gamble &lt;<a href=3D"mailto:jgamble@ripco.=
com">jgamble@ripco.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_q=
uote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,2=
04);padding-left:1ex">On Mon, April 15, 2019 12:46 pm, David Cantrell wrote=
:<br>
&gt; On Mon, Apr 15, 2019 at 12:04:24PM -0400, Dan Book wrote:<br>
&gt;<br>
&gt;&gt; As a side note, remember that the X.Y.Z form of versions (with mor=
e than<br>
&gt;&gt; one decimal point) is a sequence of integers ...<br>
&gt;<br>
&gt; Sadly it&#39;s worse than that.<br>
&gt;<br>
&gt; There exists popular software management software out there written by=
<br>
&gt; idiots who think that 3.0014 &gt; 3.1, so that rule applies even when<=
br>
&gt; you&#39;re using numbers in the form X.Y with a single decimal point. =
Those<br>
&gt; people did a lot of hard work to break numeric comparisons, one of the=
<br>
&gt; few things that computers are any good at.<br>
<br>
Are we at the point where there is no reason to not use X.Y.Z? I recall (I<=
br>
think) the historical reasons for using the 5.00y00z format, but given<br>
that minimum Perl versions are now specified in META.* files, surely<br>
there&#39;s no real reason to keep doing that anymore?<br>
<br>
I say this while looking at all my modules, which still use the fraction<br=
>
format.<br>
<br>
=C2=A0 =C2=A0 =C2=A0-john<br>
</blockquote></div>

--0000000000005155250586ab35de--
0
grinnz
4/16/2019 7:59:24 PM
I'm already on record on not supporting anything older than 5.10.1*. But
the reason I mentioned the META.* files is because I would think (well,
hope) that that in itself should be enough to prevent older Perls from
even looking at the package**.

Therefore, if the package isn't ever downloaded by these older Perls, the
'use' statement can use the all-integer format without problem. In theory.

     -john

---
* In two or three years I'll be changing that to 5.16.1.

** People who deliberately override that restriction aren't part of this
conversation.

On Tue, April 16, 2019 2:59 pm, Dan Book wrote:
> It depends entirely what Perls you want to support. If you only want to
> support Perl 5.10 or newer, module versions in the dotted-decimal form are
> fine as long as you always declare them as strings and don't use
> underscores. If you want to support older than that, you have to jump
> through some hoops or risk users getting the wrong behavior.
>
> For the 'use X' statement itself for declaring a minimum perl version of a
> file, the '5.XXXYYY' format is still (always?) recommended, because it
> will
> make sure that running it on older Perls will result in a sensible error
> message.
>
> -Dan
>
> On Tue, Apr 16, 2019 at 3:54 PM John M. Gamble <jgamble@ripco.com> wrote:
>
>> On Mon, April 15, 2019 12:46 pm, David Cantrell wrote:
>> > On Mon, Apr 15, 2019 at 12:04:24PM -0400, Dan Book wrote:
>> >
>> >> As a side note, remember that the X.Y.Z form of versions (with more
>> than
>> >> one decimal point) is a sequence of integers ...
>> >
>> > Sadly it's worse than that.
>> >
>> > There exists popular software management software out there written by
>> > idiots who think that 3.0014 > 3.1, so that rule applies even when
>> > you're using numbers in the form X.Y with a single decimal point.
>> Those
>> > people did a lot of hard work to break numeric comparisons, one of the
>> > few things that computers are any good at.
>>
>> Are we at the point where there is no reason to not use X.Y.Z? I recall
>> (I
>> think) the historical reasons for using the 5.00y00z format, but given
>> that minimum Perl versions are now specified in META.* files, surely
>> there's no real reason to keep doing that anymore?
>>
>> I say this while looking at all my modules, which still use the fraction
>> format.
>>
>>      -john
>>
>
0
jgamble
4/16/2019 9:09:07 PM
--00000000000018381c0586ac44ce
Content-Type: text/plain; charset="UTF-8"

It would be either the job of the install script or static install process
to determine that the Perl is too old, yes. In the former case, it's
commonly hard-blocked by a "use 5.XXX" statement in the Makefile.PL or
Build.PL, in the legacy format, as META.json is only used for configure
phase prereqs in this case. In the latter case it would be via the perl
runtime prereq in META.json - and only by an installer new enough to
understand all of this anyway.

This is all just for what version of Perl you support, though; for your
module version, as long as you have a declared Perl minimum version in one
of these ways, either version format is fine.

-Dan

On Tue, Apr 16, 2019 at 5:09 PM John M. Gamble <jgamble@ripco.com> wrote:

> I'm already on record on not supporting anything older than 5.10.1*. But
> the reason I mentioned the META.* files is because I would think (well,
> hope) that that in itself should be enough to prevent older Perls from
> even looking at the package**.
>
> Therefore, if the package isn't ever downloaded by these older Perls, the
> 'use' statement can use the all-integer format without problem. In theory.
>
>      -john
>
> ---
> * In two or three years I'll be changing that to 5.16.1.
>
> ** People who deliberately override that restriction aren't part of this
> conversation.
>
> On Tue, April 16, 2019 2:59 pm, Dan Book wrote:
> > It depends entirely what Perls you want to support. If you only want to
> > support Perl 5.10 or newer, module versions in the dotted-decimal form
> are
> > fine as long as you always declare them as strings and don't use
> > underscores. If you want to support older than that, you have to jump
> > through some hoops or risk users getting the wrong behavior.
> >
> > For the 'use X' statement itself for declaring a minimum perl version of
> a
> > file, the '5.XXXYYY' format is still (always?) recommended, because it
> > will
> > make sure that running it on older Perls will result in a sensible error
> > message.
> >
> > -Dan
> >
> > On Tue, Apr 16, 2019 at 3:54 PM John M. Gamble <jgamble@ripco.com>
> wrote:
> >
> >> On Mon, April 15, 2019 12:46 pm, David Cantrell wrote:
> >> > On Mon, Apr 15, 2019 at 12:04:24PM -0400, Dan Book wrote:
> >> >
> >> >> As a side note, remember that the X.Y.Z form of versions (with more
> >> than
> >> >> one decimal point) is a sequence of integers ...
> >> >
> >> > Sadly it's worse than that.
> >> >
> >> > There exists popular software management software out there written by
> >> > idiots who think that 3.0014 > 3.1, so that rule applies even when
> >> > you're using numbers in the form X.Y with a single decimal point.
> >> Those
> >> > people did a lot of hard work to break numeric comparisons, one of the
> >> > few things that computers are any good at.
> >>
> >> Are we at the point where there is no reason to not use X.Y.Z? I recall
> >> (I
> >> think) the historical reasons for using the 5.00y00z format, but given
> >> that minimum Perl versions are now specified in META.* files, surely
> >> there's no real reason to keep doing that anymore?
> >>
> >> I say this while looking at all my modules, which still use the fraction
> >> format.
> >>
> >>      -john
> >>
> >
>

--00000000000018381c0586ac44ce
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">It would be either the job of the install script or static=
 install process to determine that the Perl is too old, yes. In the former =
case, it&#39;s commonly hard-blocked by a &quot;use 5.XXX&quot; statement i=
n the Makefile.PL or Build.PL, in the legacy format, as META.json is only u=
sed for configure phase prereqs in this case. In the latter case it would b=
e via the perl runtime prereq in META.json - and only by an installer new e=
nough to understand all of this anyway.<div><br></div><div>This is all just=
 for what version of Perl you support, though; for your module version, as =
long as you have a declared Perl minimum version in one of these ways, eith=
er version format is fine.<br><div><br></div><div>-Dan</div></div></div><br=
><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Tue, A=
pr 16, 2019 at 5:09 PM John M. Gamble &lt;<a href=3D"mailto:jgamble@ripco.c=
om">jgamble@ripco.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,20=
4);padding-left:1ex">I&#39;m already on record on not supporting anything o=
lder than 5.10.1*. But<br>
the reason I mentioned the META.* files is because I would think (well,<br>
hope) that that in itself should be enough to prevent older Perls from<br>
even looking at the package**.<br>
<br>
Therefore, if the package isn&#39;t ever downloaded by these older Perls, t=
he<br>
&#39;use&#39; statement can use the all-integer format without problem. In =
theory.<br>
<br>
=C2=A0 =C2=A0 =C2=A0-john<br>
<br>
---<br>
* In two or three years I&#39;ll be changing that to 5.16.1.<br>
<br>
** People who deliberately override that restriction aren&#39;t part of thi=
s<br>
conversation.<br>
<br>
On Tue, April 16, 2019 2:59 pm, Dan Book wrote:<br>
&gt; It depends entirely what Perls you want to support. If you only want t=
o<br>
&gt; support Perl 5.10 or newer, module versions in the dotted-decimal form=
 are<br>
&gt; fine as long as you always declare them as strings and don&#39;t use<b=
r>
&gt; underscores. If you want to support older than that, you have to jump<=
br>
&gt; through some hoops or risk users getting the wrong behavior.<br>
&gt;<br>
&gt; For the &#39;use X&#39; statement itself for declaring a minimum perl =
version of a<br>
&gt; file, the &#39;5.XXXYYY&#39; format is still (always?) recommended, be=
cause it<br>
&gt; will<br>
&gt; make sure that running it on older Perls will result in a sensible err=
or<br>
&gt; message.<br>
&gt;<br>
&gt; -Dan<br>
&gt;<br>
&gt; On Tue, Apr 16, 2019 at 3:54 PM John M. Gamble &lt;<a href=3D"mailto:j=
gamble@ripco.com" target=3D"_blank">jgamble@ripco.com</a>&gt; wrote:<br>
&gt;<br>
&gt;&gt; On Mon, April 15, 2019 12:46 pm, David Cantrell wrote:<br>
&gt;&gt; &gt; On Mon, Apr 15, 2019 at 12:04:24PM -0400, Dan Book wrote:<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt;&gt; As a side note, remember that the X.Y.Z form of versions =
(with more<br>
&gt;&gt; than<br>
&gt;&gt; &gt;&gt; one decimal point) is a sequence of integers ...<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; Sadly it&#39;s worse than that.<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; There exists popular software management software out there w=
ritten by<br>
&gt;&gt; &gt; idiots who think that 3.0014 &gt; 3.1, so that rule applies e=
ven when<br>
&gt;&gt; &gt; you&#39;re using numbers in the form X.Y with a single decima=
l point.<br>
&gt;&gt; Those<br>
&gt;&gt; &gt; people did a lot of hard work to break numeric comparisons, o=
ne of the<br>
&gt;&gt; &gt; few things that computers are any good at.<br>
&gt;&gt;<br>
&gt;&gt; Are we at the point where there is no reason to not use X.Y.Z? I r=
ecall<br>
&gt;&gt; (I<br>
&gt;&gt; think) the historical reasons for using the 5.00y00z format, but g=
iven<br>
&gt;&gt; that minimum Perl versions are now specified in META.* files, sure=
ly<br>
&gt;&gt; there&#39;s no real reason to keep doing that anymore?<br>
&gt;&gt;<br>
&gt;&gt; I say this while looking at all my modules, which still use the fr=
action<br>
&gt;&gt; format.<br>
&gt;&gt;<br>
&gt;&gt;=C2=A0 =C2=A0 =C2=A0 -john<br>
&gt;&gt;<br>
&gt;<br>
</blockquote></div>

--00000000000018381c0586ac44ce--
0
grinnz
4/16/2019 9:15:07 PM
Reply: