develooper Front page | perl.perl5.porters | Postings from December 2019

Re: updating POSIX module for newer functions

Thread Previous | Thread Next
Eric Wong
December 17, 2019 07:18
Re: updating POSIX module for newer functions
Message ID:
> On Mon, Dec 16, 2019 at 2:51 PM Eric Wong <> wrote:
> > Hello all, I noticed POSIX.pod states it's for IEEE Std 1003.1,
> > but I figure it'll be useful to support new functionality...

Hi Mark, Dan; thanks for the responses so far.

Some background here: most users of my software get Perl from
their GNU/Linux distros or BSD ports.  And a big reason why I
choose Perl is that it's widely available out-of-the-box and
users typically don't need to install extra dependencies.

CPAN modules which aren't packaged by the distro are extra
overhead for them to learn, download and install; and they
already complain about dependencies.  Most of them are not Perl
hackers.  Even getting them to consider using software written
in Perl these days is a challenge :<

Mark Overmeer <> wrote:
> There are about 1800 functions in the 2008 release.
> and CORE together support about 100 (but also not really strict) 
> There are some modules on CPAN which implement some additional
> functions.  A few dozen.

Right, some are abandoned and most of those are not available
from distros.

> I started POSIX::1003 which tries to provide all functions... as
> pure as feasible.  But... I need to rework it into a more flexible
> installation structure using Config::AutoConf.  Help welcome ;-)
> When I get help, I will increase its priority.

Any reason you choose to work on a new module rather than
improving the existing POSIX one?  I certainly don't see the
need for all functions in POSIX, especially the ones which
are made redundant by CORE functions.

Dan Book <> wrote:
> If it's at all helpful, it's trivial to write a FFI::Platypus wrapper of
> POSIX functions available on the system, such as I did in Unix::Groups::FFI.

Yup.  I favor Inline(::C) since it's more widely-packaged
(for example, perl-Inline is in CentOS/RHEL 7.x and AFAIK
Platypus is not).

I may even favor syscall() for popular platforms since there's
no extra .so loading and no need to have a compiler installed.

But I consider those dependencies interim solutions because of
the extra installation burden it places on users (and distro
maintainers).  And this probably a big reason why AOT-compiled
languages like Go with giant binaries are gaining favor

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About