CUXIDUMDUM

#!/usr/bin/env perl
 
use v5.16;
use Modern::Perl;
use Carp;
use Data::Dump qw(dump);
 
no strict 'subs';
no strict 'refs';
 

CUXIDUMDUM

#!/usr/bin/env perl

use Test::MockModule;
use Test::More qw/no_plan/;
use Test::Exception;
use Modern::Perl;
use Data::Dump qw(dump);
use Test::MockCommand record => 'commands.db';
use Foo;
use Bar;

CUXIDUMDUM

 Howto execute system commands in Perl and possible danger
There are various ways to run system subproces in Perl. I will mention only 7 - few native (exec(), system, qx{}/``) and few which use additional libraries (Open("|"), IPC::Open2, IPC::Open3, IPC::Cmd) which are in fact in standard Perl distribution so they can be used without worries.
Introduction
Most people think that running system command from Perl is only done by system() or exec(), but there are many ways to achieve this task - some are better some are worse. Each of them has different performance, even specific usage of function could increase/decrease performance. This post is written only to help programmer choose right solution for task (solution secure, flexible and with best performance).

Note: I am using in this article some (quite much) text which is copied from PerlDoc - it will be in tag: <cite>.
Executing system command - possible ways

    exec() - PerlDoc Page
    system() - PerlDoc Page

CUXIDUMDUM

#!/usr/bin/env perl
use strict;
use warnings;
use 5.016;
use FindBin;
use File::Spec;
use lib File::Spec->catfile($FindBin::Bin, '..', 'lib');
use lib File::Spec->catfile($FindBin::Bin, '..', 't', 'lib');
use Data::Dump qw/dump/;
use English qw( -no_match_vars );

CUXIDUMDUM

Start gearmand
gearmand &

start worker in background

    use Gearman::Worker;
    use Storable qw( thaw );
    use List::Util qw( sum );
    my $worker = Gearman::Worker->new;
    $worker->job_servers('127.0.0.1');

CUXIDUMDUM

#
# File: test-ssh2.pl
# By  : Kevin L. Esteb
# Date: 26-Dec-2013
#
# Prototype code for a SSH RPC client. This code uses the shell subsystem
# instead of the exec subsystem. Not all servers have implemented exec.
#
# Tested against
#

CUXIDUMDUM

# "Understanding Python's closures".
#
# Tested in Python 3.1.2
#
# General points:
#
#    1. Closured lexical environments are stored
#       in the property __closure__ of a function
#
#    2. If a function does not use free variables

CUXIDUMDUM

#!/usr/bin/env perl
use strict;
use warnings;
use 5.016;
use Data::Dump qw(dump);

use MCE;

my $mapper = {
    1 => sub { say join " ", $$, 1; },

CUXIDUMDUM

http://www.electricmonk.nl/log/2008/08/07/dependency-resolving-algorithm/

Here's a little explanation of a possible dependency resolution algorithm. I've made this as basic as possible, so it's easy to understand. If you're at home in (graph) algorithms, this post is probably not of much interest to you.

Premise

Suppose we have five objects which all depend on some of the other objects. The objects could be anything, but in this case let's say they're very simple software packages (no minimal versions, etc) that depend on other packages which must be installed first. How does one find the right order of installing the packages?


Take, for instance, the following scenario: Software package 'a' depends on 'b' and 'd'. 'b' depends on 'c' and 'e'. 'c' depends on 'd' and 'e'. 'd' depends on nothing, nor does 'e'. When we visualize this, we get something like this:

CUXIDUMDUM

def wrap(*args, **kwargs):
    print "wrap"
    def wrap_this_func(func):
        print "wrap_this_func"
        def this_func_args(*wargs, **wkwargs):
            print "this_func_args"
            print "before"
            print "after"
            return func(*wargs, **wkwargs)
        return this_func_args