Journald access c-style. Provides structured logging via sendv, log opening, seeking + retrieval.

This module is currently included in Text::VisualPrintf distribution as Text::VisualPrintf::Transform, and I'm planning to release it as an individual module.

Library using Text::VisualPrintf::Transform

• Text::VisualPrintf
• Text::ANSI::Printf

Application using Text::VisualPrintf::Transform

• App::optex::xform

Application using Text::ANSI::Printf intensively

• App::ansicolumn

DESCRIPTION

This is a general interface to transform text data into desirable form, and recover the result after the process.

For example, Text::Tabs does not take care of Asian wide characters to calculate string width. So the next program does not work as we wish.

use Text::Tabs;
print expand <>;

In this case, make transform object with length function which understand wide-character width, and the pattern of string to be replaced.

use Text::VisualPrintf::Transform;
use Text::VisualWidth::PP;
my $xform = Text::VisualPrintf::Transform->new(
    length => \&Text::VisualWidth::PP::width,
    match => qr/\P{ASCII}+/,
);

Then next program encode data, call expand() function, and recover the result into the original text.

my @lines = <>;
$xform->encode(@lines);
my @expanded = expand @lines;
$xform->decode(@expanded);
print @expanded;

(The module has been renamed, url updated.)

NAME

Fancy::Open opens a file and creates an array with an optional prefix string, suffix string, or both to the lines in the file. You can also add an optional string to join the prefix, line, and suffix. You can specify how to handle empty lines. The array is returned in your preferred encoding.

VERSION

This document describes Fancy::Open version 1.0.

DESCRIPTION

fancy_open can be exported and returns a list of values. These values can be modified if the optional parameters prefix, suffix, or both are used. You can also add a joiner string to join the prefix, line, and suffix. If your file could have empty lines, the empty option can be used to specify how to handle them. There is the additional option to choose your encoding, the default is utf-8.

If the open fails, fancy_open will die.

perl my @fancy_array = fancy_open( 'file_path', { 'prefix' => 'prefix_string', 'suffix' => 'suffix_string', 'joiner' => 'joiner_string', 'empty' => 'empty_option', # fill, blank, or undefined 'encoding' => 'encoding_option' # any valid encoding } );

The file is also closed by fancy_open.

Fancy::Open requires Perl version 5.6 or better.

Parameters

fancy_open has two parameters.

Note: all sample returned arrays are the results from Data::Dump.

Sample file contents.

red orange yellow spring green teal cyan azure blue violet magenta pink white black gray

file

perl my @plain_array = fancy_open('file_path');

The first parameter is the file to be opened. If this is the only parameter specified, the file will be opened, encoded to utf-8, and returned as a list.

Options

The second parameter are the options: prefix, suffix, joiner, empty, and encoding.

prefix

perl my @prefix_array = fancy_open('file_path', { 'prefix' => 'solid' });

The prefix option is the string you want prepended to each item in the list. Using the example, all items on the list will be returned with solid prepended to them.

perl ( "solidred", "solidorange", "solidyellow", "solidspring", "solidgreen", "solidteal", "solidcyan", "solidazure", "solidblue", "solidviolet", "solidmagenta", "solidpink", "solidwhite", "solidblack", "solidgray", )

suffix

perl my @suffix_array = fancy_open('file_path', { 'suffix' => 'bead; });

The suffix option is the string you want to appear appended to each item in the list. Using the example, all items on the list will be returned with bead appended to them.

perl ( "redbead", "orangebead", "yellowbead", "springbead", "greenbead", "tealbead", "cyanbead", "azurebead", "bluebead", "violetbead", "magentabead", "pinkbead", "whitebead", "blackbead", "graybead", )

prefix and suffix

perl my @both_array = fancy_open('file_path', { 'prefix' => 'solid', 'suffix' => 'bead' });

Using both the prefix and suffix options together will prepend and append the associated strings to the items in the list.

perl ( "solidredbead", "solidorangebead", "solidyellowbead", "solidspringbead", "solidgreenbead", "solidtealbead", "solidcyanbead", "solidazurebead", "solidbluebead", "solidvioletbead", "solidmagentabead", "solidpinkbead", "solidwhitebead", "solidblackbead", "solidgraybead", )

joiner

perl my @joiner_array = fancy_open('file_path', { 'prefix' => 'solid', 'suffix' => 'bead', 'joiner' => ' ' });

The joiner option will add a string between the prefix, the line from the file, and the suffix. In this case, a single space.

perl ( "solid red bead", "solid orange bead", "solid yellow bead", "solid spring bead", "solid green bead", "solid teal bead", "solid cyan bead", "solid azure bead", "solid blue bead", "solid violet bead", "solid magenta bead", "solid pink bead", "solid white bead", "solid black bead", "solid gray bead", )

empty

perl my @empty_line = fancy_open('file_path', { 'empty' => 'fill' });

The empty option has three possible values for what to do with empty lines in the file: fill, blank, or undefined. If empty is not used or is any value than the three listed, the empty line will be ignored.

Sample file contents with an empty line.

``` red orange yellow spring green teal cyan azure

blue violet magenta pink white black gray ```

• fill will prefix and suffix the value as it does with all other lines.

  perl my @empty_line = fancy_open('file_path', { 'prefix' => 'solid', 'empty' => 'fill' });

  The array returned will be:

  perl ( "solidred", "solidorange", "solidyellow", "solidspring", "solidgreen", "solidteal", "solidcyan", "solidazure", "solid", "solidblue", "solidviolet", "solidmagenta", "solidpink", "solidwhite", "solidblack", "solidgray", )

• blank will return a zero length but defined value.

  perl my @empty_line = fancy_open('file_path', { 'prefix' => 'solid', 'empty' => 'blank' }); The array returned will be:

  perl ( "solidred", "solidorange", "solidyellow", "solidspring", "solidgreen", "solidteal", "solidcyan", "solidazure", "", "solidblue", "solidviolet", "solidmagenta", "solidpink", "solidwhite", "solidblack", "solidgray", )

• undefined will return an undefined value.

  perl @empty_line = fancy_open('file_path', { 'prefix' => 'solid', 'empty' => 'undefined' });

  The array returned will be:

  perl ( "solidred", "solidorange", "solidyellow", "solidspring", "solidgreen", "solidteal", "solidcyan", "solidazure", undef, "solidblue", "solidviolet", "solidmagenta", "solidpink", "solidwhite", "solidblack", "solidgray", )

encoding

perl my @encoded_array = fancy_open('file_path', { 'encoding' => 'ascii' });

The encoding option is the encoding you want to use to open the file. The above file will be opened ascii encoded.

I made this command to demonstrate Text::ANSI::Printf module, but it is getting to be more interesting tool.

IMAGES

https://github.com/kaz-utashiro/App-ansicolumn/tree/master/images

EXAMPLE

column(1) compatible usage

$ ls -1 --color=always /usr/bin | ansicolumn

$ (printf "PERM LINKS OWNER GROUP SIZE MONTH DAY HH:MM/YEAR NAME\n" ; ls --color=always -l | sed 1d) | ansicolumn -t

Show DOCX document in 3up format

$ cpanm App::optex::textconv
$ optex -Mtextconv ansicolumn -DPC3 foo.docx | less

Show highlighted source code in 2up format

$ source-highlight -f esc -i lib/App/ansicolumn.pm | ansicolumn -PC2 | less

INSTALL

$ cpanm https://github.com/kaz-utashiro/App-ansicolumn.git

Text::ANSI::Printf is a almost-printf-compatible library with a capability of handling string with ANSI terminal sequences, as well as multi-byte wide characters.

This is just a quick hack using existing modules, Text::VisualPrintf and Text::ANSI::Fold::Util. Not tuned for performance. Most of complicated work is done in Text::ANSI::Fold module.

INSTALL: cpanm https://github.com/kaz-utashiro/Text-ANSI-Printf.git

List::GroupBy provides functions to group a list of hashrefs in to a hash of hashrefs of arrayrefs.

FUNCTIONS

• groupBy( [ 'primary key', 'secondary key', ... ], LIST )

  If called with and array ref as the first parameter then groupBy will group the list by the keys provided in the array ref.

  Note: undefined values for a key will be defaulted to the empty string.

  Returns a hash of hashrefs of arrayrefs

• groupBy( { keys => [ 'key', ... ], defaults => { 'key' => 'default', ... }, operations => { 'key' => sub, ... }, LIST )

  More advanced options are available by calling groupBy with a hash ref of options as the first parameter. Available options are:

  • keys (Required)

    An array ref of the keys to use for grouping. The order of the keys dictates the order of the grouping. So the first key is the primary grouping, the second key is used for the secondary grouping under the primary grouping an so on.

  • defaults (Optional)

    A hash ref of defaults to use one or more keys. If a key for an item is undefined and there's an entry in the defaults option then that will be used. If no default value has been supplied for a key then the empty string will be used.

  • operations (Optional)

    A hash ref mapping keys to a function to use to normalise value's when grouping. If there's no entry for a key then the value is just used as is.

    Each funtion is passed the value as it's only parameter and it's return value is used for the key.

  Returns a hash of hashrefs of arrayrefs

Pretty self explanatory

A set of tools for testing paths.

Should also include:

• file_exists
• file_readable
• file_writable

same with dir:

• dir_exists
• dir_writable (has w)
• dir_accesible (has r and x) #?

And all of the above with '!'

This is a Test2 plugin that provides annotations for failed tests running in GitHub Actions workflow, using a workflow command. You can use it with use Test2::Plugin::GitHub::Actions::AnnotateFailedTest regardless of running in GitHub Actions workflow or not.

Questions

• Is the name appropriate?
• Can I publish it to CPAN from current master branch and install successfully? (Are the dependencies enough?)

This is a module for parsing /sys/class/input/input*/capabilities/* which is a Linux-specific interface. Linux exports all the events that the device can report, separated into several categories (some stretching belief in calling them input devices, like the PC speaker — but that's what Linux does). Linux unfortunately exports these as bit strings, encoded in hex, split in to words without leading zeros. And yes, word length does vary by architecture.

The modules already include POD. And some tests, too.

The …::Constants module is auto-generated from the Linux C headers by InputCapsFromHeader.pm. Which isn't a NIH re-implementation of h2xs, I'm pretty sure.

Modules in the neighborhood I'm aware of:

• Linux::Input, which I believe is mainly for getting the events from the devices and looks like it requires permission to actually open the devices. (I don't think I'm stepping on its namespace, as there are already multiple modules under Linux::Input:: by different authors).
• Linux::Input::Info — reads the easy files, does not do capabilities. Possibly my module could be merged into this, but last update of 2008 doesn't give me much hope. Also, this appears to be opening the device in /dev, not using /sys.

The synopsis, tested on a VM, spits out:

Input devices found (numbers): 0, 4, 2, 3, 5
Input device found: input0, AT Translated Set 2 keyboard
Input device found: input4, Power Button
Input device found: input2, ImExPS/2 Generic Explorer Mouse
Input device found: input3, QEMU QEMU USB Tablet
Input device found: input5, PC Speaker
Device AT Translated Set 2 keyboard answers questions

BTW: This is currently part of an application I'm writing, App::ABAN, and currently it lives in the same repository. I'm thinking I'll move it to its own, or at least build it separately, once its ready for CPAN. (My PAUSE ID hasn't be processed yet, so I've been working on other things).

The linked gist is the initial draft of a module that allows Rex to show diffs on the terminal upon file changes during task execution. I'm posting it here both for early availability and early feedback.

I think it is a good example of how to extend Rex without changing the core, and publishing on CPAN would be a great way to share.

Additional features could include colored output support, and pluggable diff backends (like Text::Diff::Unified::XS, or even using diff binary, if present).

The name is following this logic: it extends Rex via a Hook for File operations to show the Diff of changes. It could be more specific (e.g. Rex::Hook::File::Diff::Unified), but I feel it's already getting long, so I tried to find a good balance.

Some questions I am wondering about:

• is there a better fit for the name?
• would it be possible/easy to merge this into Rex core distribution later (which already has Rex::Hook)?
• is there a better approach to generate diffs?

Feedback welcome both here and on the gist.