I don’t think it’s just a matter of patching, though. On my system the shebang line for the biber built from the latest Nixpkgs master is almost 50 KB (while the maximum macOS will tolerate is 512 bytes). I’m not sure how we’d get around this without introducing a wrapper. Can you be more specific about how we could just patch biber to fix it on macOS? patchShebangs doesn’t do anything to improve the length of the shebang line.

(The shebang line for exiftool contains a lot of redundant -I options, so it could be manipulated via sed to be less than 512 characters. But this approach is brittle and it wouldn’t work for biber anyway.)

Builds ok for me macos 10.13 FWIW

Although the build works, the same error is present - the error is now just in the resulting .biber-wrapped script. The wrapper script does correctly set the environment though.

@volth I still don’t understand why creating an ad-hoc solution for each different program is preferable to creating a single wrapper that can be invoked when needed. Is there some concern with the closure size?

@gpampara Are you having that issue with the code from the PR, or one of the versions from the comments here?

The PR version of Biber works for me on macOS 10.13, at least to the extent that biber --help and biber --version work fine. The shebang lines for both scripts are nice and short:

$ head -n 1 result/bin/biber result/bin/.biber-wrapped 
==> result/bin/biber <==
#! /nix/store/5frlp3yii9vhxx6sc4daw3vzs7r3w7k5-bash-4.4-p23/bin/bash -e

==> result/bin/.biber-wrapped <==
#!/nix/store/3mxzksvycp6sk730zqqzch3qwla3hfhd-perl-5.28.2/bin/perl

@volth It seems like ack has the same problem on Darwin too—see #47302—and this comment implies that the youtube-viewer package is affected as well. There doesn’t seem to be a ticket for youtube-viewer but I went ahead and updated this PR to include a fix for ack too.

I’m not opposed to taking the ad-hoc approach if it really is only two packages that are affected, but if every Perl-based program has the potential to trigger this problem on Darwin then it seems like the fix should be part of the Nix Perl infrastructure, not something for each program to solve on its own. I understand that you don’t want to include a near-duplicate wrapper if it’s not necessary, but isn’t it going to be more total lines of code to fix the same problem in every single affected package?

@bdesham the patch listings from the comments. I was hoping that they would provide a quick solution, but I'll apply your patches on a pinned version of nixpkgs locally :)

That seems reasonable to me. Just to be clear, you’re okay with adding a builder_darwin.sh script or something like that? Or should I try to put the logic (and OS checking) inline in the existing builder.sh?

I guess creating a new builder for Darwin would prevent a whole bunch of rebuilding on other platforms.

OK, I’ll work on a new Bash script we can call for these kinds of programs.

I rewrote this PR to introduce a shell function called shortenPerlShebang. This function is invoked in the postInstall phase for ack, biber, exiftool, and youtube-viewer when building for Darwin. If this approach looks good then I will

• mention this function in the manual,
• add some inline documentation of the function,
• add a check to ensure that the file being operated on actually does have a Perl shebang line, and
• print a warning message if the resulting shebang line is still longer than 512 characters.

I’ve made the additional improvements I mentioned, so this should be good to go.

This could be also useful for latexindent: #59537 (comment)

@veprbl I did test the execution of the scripts at some point, but apparently I made other changes in the meantime that broke the files’ modes. Sorry about that! The issue should be fixed now.

Also should use nativeBuildInputs instead of buildInputs.

Thanks @bdesham @boronine @volth and others for tackling this bug!