What I learned from porting my projects to FreeBSD

Introduction

I set up a local FreeBSD VirtualBox VM to test something, and it seems to work very well. Due to the novelty factor, I decided to get my software projects to build and pass the tests there.

The Projects

• https://github.com/shlomif/shlomif-computer-settings/ (my dotfiles).

• https://web-cpan.shlomifish.org/latemp/

• https://fc-solve.shlomifish.org/

• https://www.shlomifish.org/open-source/projects/black-hole-solitaire-solver/

• https://better-scm.shlomifish.org/source/

• http://perl-begin.org/source/

• https://www.shlomifish.org/meta/site-source/

• Written using a mix of C, Perl 5, Python, Ruby, GNU Bash, XML, CMake, XSLT, XHTML5, XHTML1.1, Website META Language, JavaScript and more.

• Work fine on several Linux distributions and have https://en.wikipedia.org/wiki/Travis_CI using Ubuntu 14.04 hosts

• Some pass builds and tests on AppVeyor/Win64

What I Learned:

FreeBSD on VBox has become very reliable

• Survived a host power interruption - https://twitter.com/shlomif/status/1048852791987527680 .

• I recall that some years back, rebooting with X running (because input was not enabled) has FUBARed the /etc directory prompting a reinstall, so FreeBSD on VirtualBox has come a long way.

Some executables on FreeBSD are in /usr/local/bin instead of /usr/bin

On Linux they are almost always in /usr/bin/ only:

• script to fix the perl shebang line

• /usr/bin/env is your friend.

• man hier(7) explains the difference.

make on FreeBSD is not GNU make

• One can call gmake

• No gmake on some older versions of Debian/Ubuntu/etc.

• Solution for Debian:

  mkdir -p "$HOME/bin"
  ln -sf /usr/bin/make "$HOME/bin/gmake"
  export PATH="$HOME/bin:$PATH"

• gmake alias under /usr/bin/ is present again in recent versions of Debian.

m4 on FreeBSD is not compatible with GNU m4

• Fixed in this commit by first checking for gm4 and then falling back on plain m4.

Some CPAN Modules fail to install using local-lib there

• No idea why.

• Sometimes cpanm -n (“no test”) helps.

• pkg install -y p5-Foo-Bar as root for other times.

DocBook/XSL Does Not Live Under /usr/share/sgml

• Fixed using a symlink on the FreeBSD system.

• Unhappy with this solution.

• On the “Hacker News” discussion, it was recommended to use xsltproc --nonet http://docbook.sourceforge.net/release/xsl/current/manpages/docbook.xsl foobar.xml ( Reference )

FreeBSD’s grep does not have a “-P” flag by default

• The “-P” flag is not in the POSIX’s grep specification

• Solution:

  -        ) | grep -vP '^<\?xml ver' \
  +        ) | perl -p -0777 -e 's%\A<\?xml ver[^>]*>%%' \

• Does not exactly do the same operation, but even more correct.

• Perl is portable shell

  — Guy Keren

FreeBSD has no "nproc" command

• https://unix.stackexchange.com/questions/108821/number-of-cores-on-freebsd

• nproc(1) is available in FreeBSD as of 13.2-RELEASE. ( Reference. )

• Added a small shell executable under ~/bin/nproc .

What still does not work:

• Valgrind tests fail - possibly due to this bug

• Spellchecking tests fail, like on Ubuntu, as it seems hunspell has system-dependent dictionaries. (Workaround: export SKIP_SPELL_CHECK=",en,".)

Conclusion:

It is easier to port a shell than a shell script.

— Larry Wall

• I ran into some cases where my scriptology was lacking and suboptimal, even for my own personal use, and fixed them.

Coverage:

• On the /r/freebsd subreddit - with some discussion.

• Hacker News comments - with a lot of discussion, including some with technical insights.

Continuations / sequels / updates:

• “What I learned from porting my projects to FreeBSD”

• “Why my projects cannot support NetBSD (yet)”

• “Why the BSDs should not blame the USL vs BSDi lawsuits for Linux’s dominance”