I wrote this module in order for me automate my personal Video library rip and import work flow.

The idea being that dvds would be ripped into a staging folder. The files would be named according to Season and Episode format. The resulting file would then be moved into the correct show/season folder automatically. This is done as a cron job.

The module's role is to allow someone to create their own programs to to carry out these actions. Taking care of details such as matching show name to destination folder, create the required season folder if it does not exist and calling rsync to migrate the video file to its new home.

This module is a wrapper around the standalone Perl script "psjoin.pl" by Tom Sato. All I did was the minimal set of changes to allow Tom's script to work as a Perl subroutine.

I just realized that the synopsis and description don't explain the handful of options; I'll add those.

Text::Parser is a bare-bones text parsing class. It is ignorant of the text format, and cannot recognize any grammars, but derived classes that inherit from it can specify this. They can do this usually by overriding just one of the methods in this class.

Future versions are expected to include progress-bar support, parsing text from sockets, or a chunk of memory. All these software features are text-format independent and can be re-used in parsing any text format. Derived classes of Text::Parser will be able to take advantage of these features.

Simple wrappers for core print-like methods (print, say, printf). The goal is to avoid using "print or die" since autodie does not work with print.

The "die" action can be configured by importing use_"action". Where "action" can be croak (default), die, carp, cluck, and confess.

Every method has three wrappers (with o/e/at at the end of the names)

The "o" method writes on STDOUT, the "e" method writes to STDERR and the "at" writes to file handle. The "at" methods will require a block, which is anyways the recommended way (according to Perl Best Practices) of passing filehandles when using print-like methods.

Example:

use Print::OrDie qw(use_confess sayo saye sayat);

# It will 'confess' if there's some error.  
sayo 'FOOBAR'; # writes "FOOBAR\n" at STDOUT
saye 'FOOBAR'; # writes "FOOBAR\n" at STDERR
sayat {*STDERR} 'FOOBAR'; # same as before
sayat {$my_file_handle} 'FOOBAR'; # writes "FOOBAR\n" at given file handle

Example:

use Print::OrDie qw(use_confess sayat printfat);
use autodie;

# It will 'confess' if there's some error.  
open my $fh, '>', 'foobar.txt';
sayat {$fh} 'FOO';
close $fh;
$fh = undef;
printfat {$fh // *STDOUT} 'FOO %s', 'BAR';

Will write "FOO\n" on the 'foobar.txt' file and 'FOO BAR' on the console (STDOUT)

Example

use autodie;
use File::Temp qw( tempfile );
use Print::OrDie qw( use_confess sayat sayo );

my ( $fh, $filename ) = tempfile();
close $fh;

print {$fh} q(); # It will not fail

sayat {$fh} q(); # It will fail

sayo 'finished'; # Will never execute

When implements concurrent non-blocking I/O using select(2) or others (without AnyEvent/IO::AIO), it makes many complex procedural codes. This framework makes easy to write it by scenarios. AnyEvent and IO::AIO are great tools, but I think these are too much for this case. IMO, this case is not needed async I/O or/and event loops.

The module offers two ways of bakup: the, default, simplest one will copy all files to one folder, named as the name of the backup (the mandatory name parameter used while creating the object). All successive invocation of the backup will write into the same destination folder.

If you instead specify the history parameter as true during construction, then inside the main destination folder ( always named using the name ) there will be one folder for each run of the backup named using a timestamp like 2022-04-12T09-02-36

A wrapper around the 'optimised for field sales' crm ForceManager - specifically the JSON API used to maintain the background data.

Structurally I plan to make it one base class (ForceManager.pm) and currently 13 ForceManager:: child classes due to the facility to set custom fields and requirement parameters which would be better served as a class definition than monolithic configuration.

I've already got a working version of this developed with assistance of ForceManager themselves, but it used something of a questionable approach.

I hope to use this as an easy on ramp to CPAN contributions as it's more a case of procedure and optimisation than hard coding problems.

Insights greatly appreciated!

Test::Skipper treats testing like a make target depending on no changes to the test.t script or the Module::To::Test since all significant tests passed.

passing() saves state indicating success when $aok is true.

skipper() runs one succeeding test to report the skipping and exits cleanly.

$aok is the only communication that "all" tests have passed, so peripheral tests may be included for information.

Is there an older wheel, that I missed?

I'm trying to determine if something like this already exists. If not, I'll create a module for this function. See https://perlmonks.org/?node_id=1222269 for background and to see what this code outputs.

The module will help developers quickly assess json (or any other data structure) responses. It will print out a "merge" of each element in the data structure, without the actual data, so the developer can see all the fields at a glance to see the structure of the response.

SMS::Send::UK::BTSmartMessaging is a SMS::Send driver that provides SMS message sending via the BT Smart Messaging Tailored powered by Soprano HTTP API

Many thanks to the authors of the following modules that served as inspiration for this one:

• SMS::Send::US::TMobile
• SMS::Send::US::Ipipi
• SMS::Send::UK::Kapow