From mojca@macports.org

According to one of our users the platform version detection on Darwin
is not reliable.

The log
  https://trac.macports.org/attachment/ticket/58572/main.log
seems to report
  Operating system version? [pro]
which is likely due to some space in "uname -a" which usually reads
something like
  darwin mynames-macbook-pro.local 17.7.0 darwin kernel version
17.7.0​: wed feb 27 00​:43​:23 pst 2019;
root​:xnu-4570.71.35~1release_x86_64 x86_64

In addition to that the version detection further on is strange. I
don't believe that
  1[5-9]*|[2-9]*)
works as originally intended, but it does work on darwin9, for example.

Probably related commit​:
https://github.com/Perl/perl5/commit/191f8909fa4eca1db16a91ada42dd4a065c04890.patch

Mojca

From @tonycoz

On Tue, 02 Jul 2019 16​:40​:36 -0700, mojca@​macports.org wrote​:

According to one of our users the platform version detection on Darwin
is not reliable.

The log
https://trac.macports.org/attachment/ticket/58572/main.log
seems to report
Operating system version? [pro]
which is likely due to some space in "uname -a" which usually reads
something like
darwin mynames-macbook-pro.local 17.7.0 darwin kernel version
17.7.0​: wed feb 27 00​:43​:23 pst 2019;
root​:xnu-4570.71.35~1release_x86_64 x86_64

A space in the host name seems kind of broken. The code that extracts the version starts with​:

  if $test -f $uname; then
  set X $myuname
  shift

The value of $uname is from uname -a lowercased by tr. The set X ... and shift set $1 etc to the space separated values from that (shift removed the "X")

The code that I think ends up extracting the version on darwin is this fallback code​:

  *) case "$osname" in
  '') : Still unknown. Probably a generic BSD.
  osname="$1"
  osvers="$3"
  ;;
  esac
  ;;

For my system uname -a | tr 'A-Z' 'a-z' is​:

darwin pallas.tony.develop-help.com 17.7.0 darwin kernel version 17.7.0​: wed apr 24 21​:17​:24 pdt 2019; root​:xnu-4570.71.45~1/release_x86_64 x86_64

so $1 is "darwin" and $3 is 17.7.0

Maybe we'll need to add an extra guess to the list starting at

  : Half the following guesses are probably wrong... If you have better

though I'm not sure what filename we'd check.

Tony

The RT System itself - Status changed from 'new' to 'open'

From mojca@macports.org

On Wed, 3 Jul 2019 at 07​:54, Tony Cook via RT wrote​:

On Tue, 02 Jul 2019 16​:40​:36 -0700, mojca@​macports.org wrote​:

According to one of our users the platform version detection on Darwin
is not reliable.

The log
https://trac.macports.org/attachment/ticket/58572/main.log
seems to report
Operating system version? [pro]
which is likely due to some space in "uname -a" which usually reads
something like
darwin mynames-macbook-pro.local 17.7.0 darwin kernel version
17.7.0​: wed feb 27 00​:43​:23 pst 2019;
root​:xnu-4570.71.35~1release_x86_64 x86_64

A space in the host name seems kind of broken.

To clarify​: I'm not claiming there is a space, just guessing that this
could have caused faulty parsing.
Maybe we should also wait for that user to respond and confirm what's going on.

Maybe we'll need to add an extra guess to the list starting at

    : Half the following guesses are probably wrong\.\.\. If you have better

though I'm not sure what filename we'd check.

Why do you need to check for any filenames? What's wrong with "uname
-s" to check for Darwin, and then using "uname -r" for the version?

Mojca