On Wed, 23 Oct 2002, Alistair Crooks wrote:

# And I will jump in and say that it is really pax's problem.  This is
# because (a) a lot of the distfiles that we use in pkgsrc come with
# symbolic links with ".." in them, so that we can't even extract the
# contents properly now - this has nothing to do with pkg_create - and
# (b) because we go to great lengths in pkg_create to make symbolic
# links relative to ${PREFIX} for binary packages.  You are now
# seriously suggesting that we can't make archives relative to a certain
# directory because tar or pax might extract over a file that's above
# ${PREFIX}?  I'd say that was a bug in pax and tar - they should be
# able to calculate the depth of directories, and handle it accordingly.
#
# I realise this has nothing to do with pax itself - we'd be seeing the
# same problems right now with GNU tar.
#

Why not just have an '--allow-dot-dot' flag or something similarly
(in)sane added to pax?  That way you have to explicitly say that
'yes, I *know* there are ../ entries in here.  Do It Anyway.'

rm has '-f' for a reason.  It also has '-i' for a reason.  Many
other utilities follow suit, especially in the fact that they are
*options* (flags), almost none of which are active by default
(in the long run, almost none, anyway).  The '-f', as I'm sure
most of us are familiar, means 'shut up and try anyway, I don't care
about EROFS etc.'

We are thus responsible for the consequences of our actions.

				--*greywolf;
--
NetBSD: Microsoft ask you where you want to go.  BSD gets you there.