README.pod symlink to Perl module renders incorrectly

[kiwiroy]

Opening a new issue in an attempt to shine some light on my last comment in #1158 and the behaviour observed rendering the README.pod here. I have a mixture of private repositories using the same technique that have a mix of success and failure in displaying the expected result and a minimal example of success here

The symlinks are detected as POD as reported here.

Running locally github-markup, pod2html converts as expected:

$ git rev-parse --short HEAD
8f436ff
$ bundle show | grep linguist
  * github-linguist (7.1.3)
$ bundle exec bin/github-markup ../applify/README.pod | head
<h1 id="NAME">NAME</h1>

<p>Applify - Write object oriented scripts with ease</p>

<h1 id="VERSION">VERSION</h1>

<p>0.15</p>

<h1 id="DESCRIPTION">DESCRIPTION</h1>
$ perl -v | head -n2 | tail -n1
This is perl 5, version 26, subversion 2 (v5.26.2) built for darwin-thread-multi-2level

I did some sanity checking in linguist with additional tests, they all passed.

[kiwiroy]

I did some sanity checking in linguist with additional tests, they all passed.

Travis disagreed, but has since been convinced.

Investigating further in the simple repository listed above it is difficult to explain the results of the following three:

• rendering as POD
• not rendering POD, only unhighlighted file content.
• The minimal diff of header text

Could pod2html be failing occasionally, for some reason and consequently content is passed through in render:

markup/lib/github/markup/command_implementation.rb

Lines 25 to 29 in de903b8

	def render(filename, content, options: {})
	rendered = execute(command, content)
	rendered = rendered.to_s.empty? ? content : rendered
	call_block(rendered, content)
	end

[symkat]

I've also experienced this issue.

With no changes by me, my repos have gone from looking like this:

to looking like this:

[aarondcohen]

This is also affecting my repos. At first I thought it might be a result of the age of the code, but I ran it through github-markup and the results were fine. This is really frustrating...

[MCRayRay]

I've been trying to narrow this down to the smallest valid test case I can write and this is the best I've come up with so far.

This will render correctly:

=encoding UTF-8

=head1 NAME

=head1 FOO

This won't:

=encoding UTF-8

=head1 NAMD

=head1 FOO

I can't explain it.

[ANSI-C]

Having exact same issue with symlinks to PODs, it works in one case, it doesn't in another.

[Shelly1973]

Can we split it

…

On Mon, Jul 6, 2020, 5:43 PM Anselmo Canfora ***@***.***> wrote: Having exact same issue with symlinks to PODs, it works in one case, it doesn't in another. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#1253 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AQFURVOVKR3YVJNM6F6CPQ3R2JARDANCNFSM4GR25FVA> .

[Shelly1973]

Can we split it
…
On Mon, Jul 6, 2020, 5:43 PM Anselmo Canfora @.***> wrote: Having exact same issue with symlinks to PODs, it works in one case, it doesn't in another. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#1253 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AQFURVOVKR3YVJNM6F6CPQ3R2JARDANCNFSM4GR25FVA .
#1253 (comment)

[ap]

Here is a rather interesting data point: ap/Catalyst-View-Template@6318f66

I have a README.pod there which is failing to render… but this one doesn’t link to a .pm file. Instead I put the documentation in a separate .pod file and symlinked that – specifically to try and sidestep this bug. It seemed so obvious that this would work that I didn’t even do an experiment to verify before I used it. But it turns out that even this can fail.

Hopefully this is a new clue into the mystery of what is causing this bug… rather than an entirely separate second(ary) bug. Maybe it gives someone who has investigated this bug a lightbulb moment?

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[ap]

This bug continues to be present and it continues to be a problem. It has not magically gone away just because nobody fixed it in the meantime.

[ANSI-C]

This bug continues to be present and it continues to be a problem. It has not magically gone away just because nobody fixed it in the meantime.

Codeberg?

[ap]

Codeberg?

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[karenetheridge]

This is still a problem; please keep this open.

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[ap]

Here’s some further activity then.