POSIX is likely to specify the 's' flag (that we already have)
to the -s pathname substitution option of pax:
https://austingroupbugs.net/view.php?id=1618
But at least one implementation (with no 's' flag that I know of
anyway - pax is not my thing) makes that the default (ie: symlink
contents are never substituted).
That is, without the 's' flag, it isn't clear what will happen.
To avoid that, the current plan is to specify that 'S' (capital 's')
will mean "do substitute in symlink contents", 's' will mean don't
do that (all other pathnames are always substituted, including the
path name of the symlink itself). With neither 's' nor 'S' (or
with both) the behaviour will be unspecified.
Using capitals like this to reverse the sense of an option is a
fairly common POSIX technique.
If we were to take just our doc, all this would mean would be adding
an 'S' flag that does nothing.
But it turns out that we allow (but do not document) case independent
flag chars, so we have 'S'=='s' (and 'P'=='p' and 'G'=='g').
Will anything that anyone really cares about be affected if the sense
of that 'S' (capital) flag were to be altered (to become a do-nothing
flag in our case) ? Scripts using pax as we document it will not
need any alterations (at least to run using NetBSD pax).
If doing this is not desirable, now would be the time to speak up.
Perhaps even before Monday morning US time, when it is possible this
issue will be decided.
kre
