findProgram can't handle empty entries in PATH

[DanGrayson]

+ PATH=:/Applications/Macaulay2-1.17/bin:/Users/dan/src/ProofChecking/agda/.cabal-sandbox/bin:/usr/local/texlive/2018/bin/x86_64-darwin:/Users/dan/src/M2/qesource/bin:/Users/dan/.opamroot/default/bin:/usr/local/opt/libxml2/bin:/Users/dan/bin:/Users/dan/local/bin:/Applications/DjView.app/Contents/bin:/usr/local/brew-root/sbin:/usr/local/brew-root/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/./sbin:/./bin:/opt/X11/bin:/nowhere:/Users/dan/.rvm/bin:/Applications/Emacs-27.1-1.app/Contents/MacOS/bin-x86_64-10_14:/Applications/Emacs-27.1-1.app/Contents/MacOS/libexec-x86_64-10_14
+ /Users/dan/src/M2/M2.git/M2/BUILD/dan/builds.tmp/gallium-development/M2 --no-readline --print-width 197
Macaulay2, version 1.17.1.1
with packages: ConwayPolynomials, Elimination, IntegralClosure, InverseSystems, LLLBases, MinimalPrimes, PrimaryDecomposition, ReesAlgebra, Saturation, TangentCone
Macaulay2/Core/startup.m2.in:121:19:(0):[26]: error: string index out of bounds
Macaulay2/Core/startup.m2.in:121:19:(0):[26]: --entering debugger (type help to see debugger commands)
Macaulay2/Core/startup.m2.in:121:18-121:21: --source code:
     last = x -> x#-1;

i1 : 

An empty entry indicates that the current directory should be searched.

[d-torrance]

An empty entry indicates that the current directory should be searched.

Is that true?

From https://pubs.opengroup.org/onlinepubs/000095399/basedefs/xbd_chap08.html#tag_08_03:

A strictly conforming application shall use an actual pathname (such as .) to represent the current working directory in PATH .

And from https://en.wikipedia.org/wiki/PATH_(variable):

System administrators as a rule do not include it in $PATH in order to prevent the accidental execution of scripts residing in the current directory, such as may be placed there by a malicious tarbomb.

[DanGrayson]

An empty entry indicates that the current directory should be searched.

Is that true?

Yes. I wasn't sure, so I did an experiment.

[d-torrance]

Yeah, it seems to be the case in Ubuntu, too:

dtorrance@nimmie:~/tmp$ echo echo Hello world > foo
dtorrance@nimmie:~/tmp$ chmod +x foo
dtorrance@nimmie:~/tmp$ PATH=:/usr/bin foo
Hello world

I'll try to fix it soon. (It's the first day of the semester, so I have some last-minute prep to get to first!)

[DanGrayson]

Well, they have an easy work-around. If we do release 1.7.2, as Mike suggested, then we would do that after the fix for this gets in.

[d-torrance]

I found a few minutes to fix it. :)

Do we know approximately when 1.17.2 might be released? I may need to have Macaulay2 re-uploaded to Debian anyway -- depending on which doc I read, it looks like #1834 might block it from migrating to testing -- and it would be nice to upload 1.17.2 if it's ready. We just have a few more weeks before the freeze, though, when no new packages can enter.

[DanGrayson]

We could tag 1.7.2 any time and work on releases after that. I think the bugs Mike was worried about have been fixed.

@mikestillman -- should we make a new distribution of binaries (involving work for me)? Or just tag a new release as 1.17.2 so Doug can use it?

Doug, is there hope that what we have fixes #1834 ?

[d-torrance]

Doug, is there hope that what we have fixes #1834 ?

Switching away from capture for the Core tests fixes it, but that's not really a solution (see #1834 (comment)). For the time being in the latest draft of the Debian package, I'm doing this only on 32-bit architectures -- see https://salsa.debian.org/science-team/macaulay2/-/blob/debian/master/debian/patches/dont-capture-check-core-32-bit.patch.

[mahrud]

I'm going to use the upstream bottle of Flint 2.7.1 for brew, so someone should fix #1292 (and hence #1830) before making a new release. Otherwise the brew bottle and the other distributed binaries will be out of sync.

[DanGrayson]

How is #1292 relevant for you? Doesn't your brew build with cmake?

[mahrud]

How is #1292 relevant for you? Doesn't your brew build with cmake?

Do you not mind if different binary distributions are built with different versions of flint and factory?

[DanGrayson]

How is #1292 relevant for you? Doesn't your brew build with cmake?

Do you not mind if different binary distributions are built with different versions of flint and factory?

I don't see how it can be avoided, in general, because we build on various operating systems, using, if possible, the flint libraries found there, which will be of various versions. That's why we have version, so the user can report the version to us.

[mahrud]

Okay then.

[DanGrayson]

On the other hand, Bill Hart said flint 2.7.0 has bugs, so I should certainly upgrade the autotools build to that version.

[DanGrayson]

... and I've done that in commit 721e350