4

If I run

biber --cache

it says:

No cache - you are not running the PAR::Packer executable version of biber

what does that mean? Is it an error? Should I do something about it?

Note: I'm running GNU/Linux Mint 18.3, which uses TeXLive 2015.20160320-1, and the biber version is reported as 2.4

  • 1
    It's a reference to the perl module of that name. Note that your version of Biber is rather old. Current is 2.10. – cfr Jan 31 '18 at 3:01
6

It means that your version of biber is not packaged as a standalone binary, the way biber is packaged in TeX distributions and for binary downloads from upstream. You presumably instead have a simple perl programme, which depends on your also having a suitable version of perl and the various modules required by biber. Normally, you don't need these to run biber because the PAR:Packer module allows a completely self-sufficient version to be distributed. Basically, this unpacks itself into a stand-alone perl tree when biber is run. On your system, that won't happen: biber will be just the biber bit and the other bits will be elsewhere.

From Biber's manual (p. 49):

Biber is a Perl application which relies heavily on quite a few modules. It is packaged as a stand-alone binary using the excellent PAR::Packer module which can pack an entire Perl tree plus dependencies into one file which acts as a stand-alone binary and is indistinguishable from such to the end user. You can also simply download the Perl source and run it as a normal Perl program which requires you to have a working Perl 5.24+ installation and the ability to install the pre-requisite modules. You would typically only do this if you wanted to keep up with all the bleeding- edge git commits before they had been packaged as a binary. Almost all users will not want to do this and should use the binaries from their TEX distribution or downloaded directly from SourceForge in case they need to use a more recent binary than is included in their TEX distribution.

When a binary biber is run it normally unpacks all the bits it needs into a temporary directory somewhere on your system. This unpacked tree is then reused on later runs, unless the directory is deleted (e.g. rebooting deletes it if it is stored in RAM).

biber --cache

tells you where this is, because it depends on the local configuration. This enables you to remove the directory yourself if necessary (e.g. if the cached files get corrupted).

On my system the command returns

/tmp/par-636672656573/cache-c69eefcf7af45c44dec592684a863c8f49910910

which tells me, among other things, that biber will take longer to run after a reboot, because this location is in RAM rather than in persistent storage (e.g. a HDD or SSD).

  • So I should just never run biber --cache, essentially? – einpoklum Jan 31 '18 at 8:52
  • 1
    @einpoklum You don't need to. That option is only there to let you find out about the location of your PAR::Packer cache, because it can be necessary to delete the cache if it is corrupted. Since you don't have that cache, it can't get corrupted. Why did you want to run biber --cache anyway? – moewe Jan 31 '18 at 9:11
  • @einpoklum You can run it as much as you like, but it will always tell you you don't have a cached version. So it will get rather boring, but there's no reason you shouldn't run it, if you like doing so ;). – cfr Feb 1 '18 at 0:34

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.