Open apjanke opened 4 years ago
I threw a placeholder error message in at https://github.com/cowsay-org/cowsay/commit/3496ec869665f5563246527fe456ca49caccd2e0.
Just a note: After PR https://github.com/cowsay-org/cowsay/pull/26 has been merged, when you implement support for *.pm
, you will need to change Makefile
from
# If you implement support for *.pm cows, add share/cows/*.pm here.
#
# Note that this is a list of shell globs to be evaluated by the
# shell, not a list of files to be evaluated by make.
COW_FILES = share/cows/*.cow
to about
# Note that this is a list of shell globs to be evaluated by the
# shell, not a list of files to be evaluated by make.
COW_FILES = share/cows/*.cow share/cows/*.pm
Oh, I think I get it now... something like this: I think the Acme::Cow code does work, and that's what's on CPAN. But it didn't make it in to the cowsay 3.03 release tarball, or the rank-amateur-cowsay source code repo upload to GitHub. It was in a separate Acme-Cow module distribution. The Acme-Cow-1.0.tar.gz was a separate download on the original Cowsay web page, and an Acme-Cow package got uploaded to CPAN and is now up to version 0.2.1. The Acme::Cow module and Acme-Cow CPAN package are numbered version 0.2.1, but the package doesn't contain just library modules; it also has the cowsay/cowthink command scripts. Those scripts are numbered as version 4.x (in doco and internal version numbers), so the Acme-Cow package is Cowsay 4.x, though the package itself is versioned as 0.2.1. Doesn't look like the CPAN uploads were done by Tony himself. So, the 0.1.0 and 0.2.1 here are actually newer than the 3.0x releases.
And this new version and format isn't designed to run directly from the repo; you need to install it as a Perl module, with perl Makefile.PL; make; make install
before the code will run. The make
command will build a local blib/
tree, and you can run it locally if you tweak the Perl path, like export PERL5LIB=./blib/lib; ./blib/script/cowsay moo
. When installed, modules going in to site_perl/<perlver>
under your Perl installation, and I think the scripts and mans going in to regular bin and share dirs under $prefix. (Or maybe it's all under the Perl installation, in bin/ and lib/ subdirs?) At that point, you can also run the cowsay
script from within the repo (in original spot instead of blib), with it picking up the Acme::Cow module from the Perl site_perl library, as does the installed cowsay
command. It uses Perl's MakeMaker for the build & installation stuff.
I'm guessing the .pm format cowfiles made it in to cowsay 3.04 (in the posted GitHub repo) because they were in-progress stuff heading to Cowsay 4, and the Acme::Cow module and newer cowsay were working if you installed them (from a different repo or source), but the corresponding code support didn't make it in to that 3.x series repo.
Looks like OpenBSD is shipping this Acme-Cow 0.2.1 as its Cowsay (package source here in GitHub), so one could use that as an example of what this version of Cowsay looks like as packaged in a distro.
Based on the CPAN package's Changes file and recent releases RSS feed, I don't think that Acme-Cow was uploaded to CPAN until 2019, with the 0.1 release I linked above.
<item rdf:about="https://metacpan.org/release/HADFL/Acme-Cow-0.2">
<title>Acme-Cow-0.2</title>
<link>https://metacpan.org/release/HADFL/Acme-Cow-0.2</link>
<dc:creator>HADFL</dc:creator>
<dc:date>2021-09-02T21:36:45</dc:date>
<description></description>
</item>
<item rdf:about="https://metacpan.org/release/ELIZABETH/Acme-Cow-0.1">
<title>Acme-Cow-0.1</title>
<link>https://metacpan.org/release/ELIZABETH/Acme-Cow-0.1</link>
<dc:creator>ELIZABETH</dc:creator>
<dc:date>2019-03-28T12:01:21</dc:date>
<description></description>
</item>
</rdf:RDF>
So we could pull in the Acme::Cow module and related code from the Acme-Cow-0.x package distribution, add a build step (or rearrange its place in the repo to run without a build step), and have working .pm format cowfile support, using the code intended by the original author, I think. Don't think we'd need to convert to MakeMaker and installing modules in the main lib/site_perl; think they could just be vendored instead. Or maybe I'm misreading how MakeMaker works, and they end up under a site_perl under a cowsay-specific dir or sub-prefix; but a make -n install
on macOS looks like they go under the main Perl installation.
"/usr/local/Cellar/perl/5.38.2_1/bin/perl" -MExtUtils::Install -e 'install([ from_to => {@ARGV}, verbose => '\''0'\'', uninstall_shadows => '\''0'\'', dir_mode => '\''755'\'' ]);' -- \
read "/usr/local/opt/perl/lib/perl5/site_perl/5.38/darwin-thread-multi-2level/auto/Acme/Cow/.packlist" \
write "/usr/local/Cellar/perl/5.38.2_1/lib/perl5/site_perl/5.38/darwin-thread-multi-2level/auto/Acme/Cow/.packlist" \
"blib/lib" "/usr/local/Cellar/perl/5.38.2_1/lib/perl5/site_perl/5.38" \
"blib/arch" "/usr/local/Cellar/perl/5.38.2_1/lib/perl5/site_perl/5.38/darwin-thread-multi-2level" \
"blib/bin" "/usr/local/Cellar/perl/5.38.2_1/bin" \
"blib/script" "/usr/local/Cellar/perl/5.38.2_1/bin" \
"blib/man1" "/usr/local/Cellar/perl/5.38.2_1/share/man/man1" \
"blib/man3" "/usr/local/Cellar/perl/5.38.2_1/share/man/man3"
[...]
"/usr/local/Cellar/perl/5.38.2_1/bin/perl" -MExtUtils::Command::MM -e 'perllocal_install' -- \
"Module" "Acme::Cow" \
"installed into" "/usr/local/Cellar/perl/5.38.2_1/lib/perl5/site_perl/5.38" \
LINKTYPE "dynamic" \
VERSION "0.2.1" \
EXE_FILES "cowpm cowsay cowthink" \
>> "/usr/local/Cellar/perl/5.38.2_1/lib/perl5/5.38/darwin-thread-multi-2level/perllocal.pod"
Not sure how inclined I am to do that, since it was a late change that didn't seem to make it out in the wild much.
And maybe only the 0.2 series is still up on CPAN? Maybe that's what the "re-publish" comment was about, with it changing maintainers or something?
That Acme-Cow-Interpreter I believe is unrelated to Cowsay; instead it's an interpreter for the COW programming language. Noted here to avoid me getting confused later.
Looks like a *.pm class-based cow format was designed at one point, involving an Acme::Cow Perl module, but the
cowsay
code doesn't have actual implementation code for it. Add this.