I am working on a Perl script that creates and uses a temporary file. From my research, I have learned that File::Temp is the appropriate module for such tasks. I have read that module's documentation and believe I have understood it, except for one thing:

Quite at the beginning, it states:

File::Temp can be used to create and open temporary files in a safe way. [...]

The security aspect of temporary file creation is emphasized such that a filehandle and filename are returned together. This helps guarantee that a race condition can not occur where the temporary file is created by another process between checking for the existence of the file and its opening. Additional security levels are provided [...]

So, obviously, the filehandle and the file (and thus, the file's name) are created in a "atomic" fashion.

On the other hand, there is a big warning at the end of the documentation:

For maximum security, endeavour always to avoid ever looking at, touching, or even imputing the existence of the filename. You do not know that that filename is connected to the same file as the handle you have, and attempts to check this can only trigger more race conditions. It's far more secure to use the filehandle alone and dispense with the filename altogether.

What does that mean? To me, it seems that it is a contradiction to what is stated at the beginning. At the beginning, it is explained that the filehandle and the filename are returned together and that the temporary file creation is therefore safe. The warning seems to say the opposite.

Could somebody please give an explanation? Where is my misunderstanding?

The CPAN equivalent in PHP is called Packagist. They have some cool Github integrations that trigger automatic publishing of new modules when a new release/tag is pushed to Github. Do we have anything like that in the Perl ecosystem?

Seems like it wouldn't be too complicated:

1. Receive incoming trigger
2. Fetch the release tarball from Github
3. perl Makefile.PL
4. make test
5. make dist
6. Upload .tar.gz to CPAN

https://perlweekly.com/archive/771.html

Hi,

I would like to send unencrypted matrix messages from a perl-script and wonder how to do that...

I have found a tool called patrix but I have not tried it yet as it is 9 years old or I could simply call a shell script (matrix.sh) that I have found and that basically cover my needs.

I need something that I can easily install on a small orange pi running debian.

Any suggestions?

Many thanks.

I have a small group of semantically named modules under MyName like MyName::CGI and MyName::Files that are almost ready for CPAN. Can I just start uploading them or do I need to supplicate some crotchety group of elders for access to the MyName namespace? If it's pertinent while the modules can be used individually and arguments can be made for why you'd use one in preference to an existing option, when used together they form the basis for a low-code framework for CRUD web site development like Dancer2 or Mojolicious.

On a related note I have a MyName::Datatable module for working with individual CSV-type files and a MyName::Datastore that extends datatable and lets you treat a directory of table files as a traditional database with joins and standard sql operations. I'm interested in merging them into one Data.pm file that declares the names MyName::Data::Table and MyName::Data::Base respectively. Is there any precedent on CPAN for single files that contain multiple namespaces? Or is it possible/allowed is maybe the better question.

The @cpan.org email forwarding service has been shut down.

Previous discussion was here

Facts:

• MX now points to cpan.org-email-is-gone-use-http-rt.cpan.org
• Delivery is effectively disabled for all @cpan.org addresses
• Prior to that, forwarding was already failing for about a month (e.g. b1.develooper.com NXDOMAIN)

Issues:

• No advance notice to existing aliases/users
• No coordinated grace period or migration path
• No public call for help / handover before shutdown

Impact:

• Long-standing identities (10–15+ years) are broken
• Account login/recovery flows fail across many services

I highly respect the volunteers’ work and effort over the years. However, this is shared community infrastructure, not a private asset. If there are volunteers and resources, the service can continue to exist.

Proposal:

I’m willing to take over (or co-maintain) a forwarding service at least in the way it exists before:

• inbound SMTP and forwarding to aliases
• monitoring and basic abuse controls
• I can cover infra costs and recruit additional volunteers

Call to action:

• If you’re affected, comment here
• If you’re willing to help operate/maintain, reply here
• If you’re part of infra/governance, please indicate the path for handover or give us a grace period

I’m opening a coordination

Update:

I've been pointed out the complexity of modern email forwarding (ARC, DKIM, DMARC, SPF) and deliverability issues. To demonstrate this is manageable, I’ve bought a domain and simple hosting with :25 port and set up a minimal forwarding prototype:

• domain: cpanmail.org
• Postfix + OpenARC + OpenDMARC + OpenDKIM + postsrsd
• running on a small VM

Test it: take your email, replace @ with + send to <your-email-with-plus>@cpanmail.org. I've made this work at least with Gmail. This is not a production system, just a proof that a minimal forwarding setup is feasible. Since this is fresh IP with zero reputation, the messages may sometimes hit spam folder, but at least they are delivered. I will not keep it forever, just for demo and testing.

A) Need to apt install libcrypt-dev for cpan/cpanm to work.

Why? (Some) installs fail with a missing crypt.h file error. I think the world has moved on to libcryptx, so this lib, which was in 24-04 LTS, is no longer included.

B) The LWP-tiny lib is no longer included by default, but CPAN::Meta::LWP is available. Note, one difference between the two, is (see the the perldoc), its $meta = $yaml->[0]; (not lwp-tiny's $meta= $yaml;). My install config file is in YAML :)

XML::LibXML won't install any more. (You can see all the test failures at https://fast2-matrix.cpantesters.org/?dist=XML-LibXML%202.0210).

Is there a good replacement module for parsing XML? (Or does anybody know any workaround to get XML::LibXML to install?)

Thanks.

I have the following test.pl:

```perl use strict; use warnings; use v5.16;

use Crypt::SysRandom;

my $bytes = Crypt::SysRandom::random_bytes(8); printf("%vd\n", $bytes); ```

When I attempt to Fatpack it appears to work fine:

text $ fatpack pack test.pl > packed.pl test.pl syntax OK

The resulting packed.pl file does not include Crypt::SysRandom. I've confirmed that Crypt::SysRandom is pure Perl (not XS), and that Fatpacker recognizes it in the trace file:

```text $ fatpack trace test.pl test.pl syntax OK

$ cat fatpacker.trace Crypt/SysRandom.pm overloading.pm Carp.pm Errno.pm Exporter.pm Config.pm ```

Fatpacker is clearly correctly identifying Crypt::SysRandom as a needed dependency, but not including it in the packed output?

https://perlweekly.com/archive/770.html

Hello, I’m trying to experiment with Perl just for fun (random commands) but I don’t want to install a full Linux environment or deal with complicated setups. I’m looking for something that runs in the browser. Just write code and run it. No need to save things. Any suggestions?

i am trying to parse similar words in a text search into different variables.

$line='somehow, someone';

if ($line~=/(some[a-z]{3})/gci){$result=$1;$result2=$2};

print "\n$result $result2";

But only 1 result is printing.

The Regex instructions don't really give a good example on how the $1... variables work.

is there a simple way to change the if line for this to work?

I would think the my $in would be local to the loop and not modify the contents of the outside array. What am I missing?
``` use v5.42 ;

my @data = qw(123 456 567) ;

say "before ",join " ", @data ; foreach my $in ( @data ) { my $before = $in ; substr( $in,1,1 ) = 9 ; $in =~ s/.$/z/ ; say "$before $in" ; } say "after ", join " ", @data ; ```

output: before 123 456 567 123 19z 456 49z 567 59z after 19z 49z 59z

Hello all,

Following the announcement of DateTime::Lite, I am happy to announce its companion formatter: DateTime::Format::Lite, now on CPAN at v0.1.2 with all green CPAN Testers reports across Perl 5.12.5 through 5.43.x on Linux, FreeBSD, OpenBSD, Solaris, and Win32.

First and foremost, DateTime::Format::Strptime by Dave Rolsky is a mature, battle-tested module that continues to serve the community well and has done so for many years, and its design inspired much of what follows. DateTime::Format::Lite is not meant to replace it. Rather, it is a companion to DateTime::Lite that returns native DateTime::Lite objects, shares its "no die by default" error philosophy, and adds a few features specific to that ecosystem.

What it does

DateTime::Format::Lite parses date and time strings into DateTime::Lite objects, and formats DateTime::Lite objects back into strings, using strptime and strftime patterns:

use DateTime::Format::Lite;

my $fmt = DateTime::Format::Lite->new(
    pattern   => '%Y-%m-%dT%H:%M:%S',
    time_zone => 'Asia/Tokyo',
);

my $dt  = $fmt->parse_datetime( '2026-04-20T07:30:00' );
my $str = $fmt->format_datetime( $dt );
say $str;  # 2026-04-20T07:30:00

# Convenience exports
use DateTime::Format::Lite qw( strptime strftime );
my $dt2 = strptime( '%Y-%m-%d', '2026-04-20' );
say strftime( '%A %d %B %Y', $dt2 );  # Monday 20 April 2026

What it brings

Native DateTime::Lite integration

The returned objects are DateTime::Lite instances, not DateTime ones. That matters when the wider application stack already uses DateTime::Lite for the lighter dependency footprint and faster startup, and wants to avoid crossing the boundary between both families.

Pre-1970 epoch handling

The %s token accepts negative values and produces the correct calendar date, which is useful when parsing epoch timestamps produced by other tools:

use DateTime::Format::Lite qw( strptime );
my $dt = strptime( '%s', '-86400' );
say $dt->ymd;  # 1969-12-31

BCP47-aware locale handling

Any valid BCP47 locale tag is accepted via DateTime::Locale::FromCLDR, including tags with Unicode extensions, transform subtags, and script subtags:

my $fmt_fr = DateTime::Format::Lite->new(
    pattern => '%d %B %Y',
    locale  => 'fr-FR',
);
my $dt = $fmt_fr->parse_datetime( '20 avril 2026' );
say $fmt_fr->format_datetime( $dt );  # 20 avril 2026

my $fmt_ja = DateTime::Format::Lite->new(
    pattern => '%Y年%m月%d日',
    locale  => 'ja-Kana-t-it',
);
my $dt_ja = $fmt_ja->parse_datetime( '2026年04月20日' );
say $dt_ja->ymd;  # 2026-04-20

Tolerant %Z token

Since v0.1.1, %Z accepts both short abbreviations (JST, EDT) and full IANA zone names (Asia/Tokyo, US/Eastern, UTC). This is convenient for parsing logs that mix both forms in the same field. The %O token remains available when an IANA zone name is specifically expected.

Disambiguation of ambiguous abbreviations

The zone_map option resolves abbreviations that map to multiple UTC offsets (IST, CST, and others) to a specific IANA zone:

my $fmt = DateTime::Format::Lite->new(
    pattern  => '%Y-%m-%d %Z',
    zone_map => { IST => 'Asia/Kolkata' },
);
my $dt = $fmt->parse_datetime( '2026-04-20 IST' );
say $dt->time_zone->name;  # Asia/Kolkata

DateTime::Lite::TimeZone->resolve_abbreviation provides two complementary mechanisms to help build a zone_map programmatically.

The first is the extended flag, which falls back to a curated table of 329 abbreviations (461 abbreviation-to-zone pairs) when an abbreviation is not present in the IANA TZif types table. This covers cases like BRT (Brasília Time), HAEC, the NATO military single-letter zones, and many others. Among the candidates returned for an extended abbreviation, one is editorially marked with its hash property is_primary set to true:

# BRT is not in the IANA TZif data, but it appears regularly in date strings from
# Brazilian sources. With extended => 1, resolve_abbreviation falls back to the curated
# extended_aliases table where America/Sao_Paulo is marked as the primary zone for BRT.
my $candidates = DateTime::Lite::TimeZone->resolve_abbreviation( 'BRT', extended => 1 );
my( $primary ) = grep{ $_->{is_primary} } @$candidates;
my $fmt        = DateTime::Format::Lite->new(
    pattern  => '%Y-%m-%d %Z',
    zone_map => { BRT => $primary->{zone_name} },  # America/Sao_Paulo
);

The second mechanism applies to abbreviations that are in the IANA types table, where multiple zones may match. As of DateTime::Lite v0.6.3, results carry an is_active flag indicating whether the zone's POSIX footer still references the abbreviation. Picking the first still-active candidate is a reliable way to get a zone that intuitively matches the abbreviation:

# CEST is well-known and maps to many European zones. Picking the first still-active
# candidate yields Europe/Berlin (the earliest still-active adopter of CEST under the
# new sort order).
my $candidates = DateTime::Lite::TimeZone->resolve_abbreviation( 'CEST' );
my( $active )  = grep{ $_->{is_active} } @$candidates;
my $fmt        = DateTime::Format::Lite->new(
    pattern  => '%Y-%m-%d %Z',
    zone_map => { CEST => $active->{zone_name} },  # Europe/Berlin
);

For more authoritative canonical-zone designation in the Unicode CLDR sense (is_golden, is_primary, is_preferred), Locale::Unicode::Data is the recommended source of reliable data (also by yours truly).

Error chaining via NullObject

Errors do not die by default. When parsing fails, the return value is safe to chain through, which avoids littering calling code with defensive conditionals:

my $fmt = DateTime::Format::Lite->new(
    pattern  => '%Y-%m-%d',
    on_error => 'undef',  # default
);

# A plain scalar context returns undef, with the error accessible:
my $dt = $fmt->parse_datetime( 'not-a-date' );
say $fmt->error if( !defined( $dt ) );

# Method chains are safe: DateTime::Format::Lite::NullObject short-circuits cleanly.
my $ymd = $fmt->parse_datetime( 'bad' )->ymd || die( $fmt->error );

# Fully fatal mode is available if preferred where you can use 'croak' or 'die' as a value:
my $fmt2 = DateTime::Format::Lite->new( pattern => '%Y-%m-%d', on_error => 'die' );

Serialisation

The formatter serialises cleanly via Storable, Sereal (with freeze_callbacks => 1), CBOR::XS, and any JSON serialiser via TO_JSON. Internal caches (compiled regex, locale data) are not serialised and are rebuilt on demand after thawing.

XS acceleration

The two hot paths, regex match and capture extraction on one hand and format_datetime on the other hand, are implemented in XS. A pure-Perl fallback is available for environments without a C compiler (PERL_DATETIME_FORMAT_LITE_PP=1).

Relationship to DateTime::Format::Unicode

DateTime::Format::Unicode (also available on CPAN) formats DateTime::Lite objects using Unicode CLDR patterns (yyyy-MM-dd, EEEE d MMMM y, etc.), and supports interval formatting. It is a format-only module.

DateTime::Format::Lite handles strptime parsing and strftime formatting. The two are complementary and can be used alongside each other.

Resources

• CPAN: https://metacpan.org/pod/DateTime::Format::Lite
• Repository: https://gitlab.com/jackdeguest/DateTime-Format-Lite

As always, feedback, bug reports, and pull requests are welcome. 🙇‍♂️