newline problem with genVersionHeader.pl

PS: The bug in git show can be reproduced even without checking out the commit:
git show -s --format=%ci e63184e
The extra newline does not depend on the format. Even plain 'git show COMMIT' shows one newline too many whenever the COMMIT is a merge.

The genVersionHeader.pl script already has
    chomp $cv;
on line 139 to remove one trailing newline, does adding another copy after line 98 (the "$cv = `git show -s …" line) resolve this?

> chomp $cv;
> $RevDate=$vcs . ': ' . $cv;
...
> #define ${opt_N}_DATE \"$RevDate\"

I'm not sure I would even describe this as a bug with Git. And I'm puzzled why "chomp" doesn't remove both newlines.

https://perldoc.perl.org/functions/chomp

> ... When in paragraph mode ($/ = ''), it removes all trailing newlines from the string. ...

> does adding another copy after line 98 (the "$cv = `git show -s …" line) resolve this?
Yes.

With no 'chomp' in neither line 98 nor 139, I get both newlines in the output.
So it seems that 'chomp' removes only one newline.
My perl version is v5.16.3, in case it may be relevant.

If I set $/='' as the doc suggests, it removes both newlines.

$/ is newline by default
https://perldoc.perl.org/perlvar#%24%2F
That makes chomp remove only one newline.

> I'm puzzled why "chomp" doesn't remove both newlines.

Because Perl's $INPUT_RECORD_SEPARATOR = $/ defaults to a newline (line mode). "perldoc perlvar" and search for INPUT_RECORD_SEPARATOR to learn all about it.

Setting $/ to '' should be okay, but I would probably localize it like this (or at least don't do it before the chomp) in case changing it globally has any negative effects on input parsing elsewhere in the code:

{
  local $/; # Temporarily set to ''
  chomp $cv; # Remove all newlines
}

I had just started to read about "$/". How... complicated.

https://perldoc.perl.org/perlvar#%24%2F

https://en.wikipedia.org/wiki/Waterbed_theory

I have added $/=''; at the beginning, directly after use strict;
No problem found. The file looks good. All command line options work as before. Can create new files and update existing ones.

Created PR https://github.com/epics-base/epics-base/pull/371

> No problem found

What about testing the code sections that run for the other version control systems?

This script was designed to work with EPICS applications (not just Base itself) that are stored in Darcs, Mercurial, Git, Subversion or Bazaar, and each of those has a separate section of the script for obtaining version information from the VCS which could be affected by that change. The Darcs code at least appears to handle multi-line results. I'm not saying that there _is_ a problem, but this kind of change could very easily break one of the others unless you localize the $/ variable as I showed above. If you don't do that, they ought to be tested too.

Someone should add tests for those things. ;-)

Tested with CVS, Mercurial, Subversion and Bazaar on existing repositories I have access to. There is no difference in behavior with or without $/=''. The generated file looks the same.
Unfortunately, I have no Darcs repository to test with and I am not sure if generating a trivial one is enough for the test.

One interesting observation though: If the tool for the repository type is not installed, the VCSVERSION_DATE string simply looks like this:
  #define VCSVERSION_DATE ": "

I can test with Darcs if I know what to test...

My test was to generate a version header file with an unmodified version of genVersionHeader.pl and compare it with a header file generated with a version of genVersionHeader.pl which has $/=''; at the beginning and to check that the two files are identical.

I did something like this:
cd <some repo>
$EPICS_BASE/bin/$EPICS_HOST_ARCH/genVersionHeader.pl -t . v1.h

This generates a file 'v1.h'. Then I do the modification and generate a file v2.h and compare the two. I did this for several repositories of each type.