RT 103157 - t/oo-api.t failures under Mac OS #7
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The problem here is that libmagic is not very forthcoming on what the default magic file is, so the test looks in the usual place. Apple has for reasons of their own modified the file command and the underlying magic file, which lives in the usual place. So we need a way to find the default magic file for the copy of libmagic that is actually being linked into File::LibMagic.
This pull request attempts to address this issue. The approach used is two-fold.
The first commit adds Apple's description of a C source file to the test, and under macOS 10.13 High Sierra is sufficient to get the test to pass. The offset errors appearing in earlier versions of macOS (as they style it now) appear to have gone away, and I think were cosmetic anyway.
The second commit scrapes the output of 'file -v' (after deleting $ENV{MAGIC}) to try to get a better idea of what the default magic file is. This is not ideal, and assumes the file command we are running goes with the libmagic we are linking against. But the API that would otherwise be more desirable for this is undocumented, which makes me nervous about using it in production code. The third commit simply tweaks the second in response to some perltidy errors.