The namespace 'y' doesn't exist on CPAN, and it is very unlikely that it will ever show up there. Likewise, it is very improbable that a pragma 'y.pm' will be included into the perl core. This means - unless something very insane happens sometime in the future - that this namespace 'y' is YOUR VERY OWN NAMESPACE, and you can set it up in any way you want it to be. Whatever appears in it, even functions/things that should never happen, is up to you.
This module doesn't exist. You have to write it. Fortunately, all of it (98%) has already been written, according to Salomon (bible) - see CPAN.
The perl inclusion methods apply, you must write your own y.pm and either point to it via the PERL5LIB environment variable (best) or lump it into the standard perl module installation paths (worst), or something else (depends).
This module is meant to be a container of your own inventions, idiomatic expressions and code snippets you use on a daily basis, which don't merit - or don't fit into - a separate Module.
Up to this day, not only sysadmin's work comprises a lot of random hackery, file parsing and data munging, quick makeshifts and saving coworkers from a fix, e.g. defeating the Agile Imposition.
Lots of those oneliners are one-shots. Others, even quite complex ones, are typed over and over again. Modern shells have a history and means to query that, but even the history has limits. This module can be used to save those snippets in a well defined place.
You could use this module for aliases to trivial perl tasks that require a lot of typing. Consider:
perl -le 'print scalar localtime pop' 1468404921
perl -My -le 'plt pop' 1468404921
So your y.pm could have a plt function, and perhaps a slt one to be used e.g. inside regular expressions.
Tired of invoking perl (these four letters are so much bound together - can't remember how many times I've corrected myself after typing "as perl invoice" and such) with other switches than those matching /[lane]+/, namely including modules on the command line with several -MModule statements, I decided to claim the y namespace for my very own, just for being male. Ladies might want to name it x. Transgender people might name it _ (* would be nice, but that's illegal as a module name)(thanks, tinita). Blackhats would prefer naming it I6 prolly.
You may export anything you want. Perhaps you want to use export tags, too.
A handy way to load other modules into the caller's namespace:
package y;
use strict;
use warnings;
my $callpack = caller;
eval <<"EOH";
package $callpack;
use Data::Dumper;
use B::Deparse;
use Devel::Peek;
# other modules...
EOH
This could be wrapped into a BEGIN block.
Of course, maintainance is up to you. To add code snippets to it, my version of y.pm sports the following CHECK and import routines:
{
my $append = 0;
my (@lines,$line,$saveout);
CHECK {
if ($append) {
print STDOUT"}\n\n",@lines;
open STDOUT, '>&', $saveout or die "Can't restore STDOUT:
+$!\n";
exec "vi +$line ". __FILE__;
}
}
sub import{
shift;
if (@_ && $_[0] eq 'append'){
$append = shift;
my $func = shift || die "need function name to append.\n";
open $saveout, '>&', STDOUT or die "Can't dup STDOUT: $!\n
+";
open STDOUT, '+<', __FILE__;
seek DATA,0,0;
while(<DATA>) { last if /^"foo";$/}
$line = $.;
my $pos = tell(DATA) -7;
@lines = ($_,<DATA>);
seek STDOUT, $pos, 0;
print "sub $func {\n";
require O;
O->import('Deparse');
}else{
no strict 'refs';
my $caller = caller;
for(@_?@_: keys %y::){
next if /__ANON__/;
*{$caller."::$_"}=\&$_;
}
}
}
}
This lets me say
perl -My=append,stime -e 'my$t=localtime(shift||time);$t'
and have this snippet inserted as sub stime just before the line containing "foo"; which is my y's way to say 1;, and have vi opened at the beginning of the sub (which has been milled through B::Deparse) to do any tidings and completions (localizing variables, handling @_, return values etc):
sub stime {
my $t = localtime(shift @ARGV || time);
$t;
}
My y.pm of course contains a __DATA__ token; the import if block would not work without it. The rest (in the else block) is just exporting without Exporter.
For the curious: the CHECK block is necessary since B::Deparse doesn't emit it's output before the import completes, and it does not run the script. It does, however, run CHECK blocks, which is used here to complete the file update.
This is perhaps insane and brittle, but TIMTOWTDI. Of course you are free to mess around otherwise. For instance, you could set up a module directory proper, complete with Makefile.PL lib CHANGES etc and have the import routine add test files to t/ for the sub added, patch lib/y.pm, run make test && make install and whatnot. Or else.