> All the other replies aside, the package should also be fixed not to use a &
> in a pathname -- that's begging for trouble all around.

Point, umm, halfway taken.  This is, of course, a pkgsrcification of a
collection of files not intended for any specific OS, or even only for
POSIX OS's.  If you'd used a more neutral word than 'fixed' it probably
wouldn't get me started, but the fact that Andrew Mustun (the author of
qcad) used an & in a pathname for a directory named after brown&sharpe, and
when he wasn't specifically targeting UNIX, is not really quite something
to fault him for, or to describe as having to be 'fixed'.

Yes, there are probably other bugs in argument handling and quoting in
various random programs that will be brought to light by such a pathname,
and for end users that will be more annoying than beneficial, and the
easiest way to avoid dealing with it is to rename the directory.

And that's how every Tom, Dick, and Harry writing programs and scripts for
UNIX has been avoiding dealing with it for 30 yrs, and that's why we still
have these embarrassments.

Correct quoting is a solved problem.  We know that names can contain any
byte other than x00 and x2f, and we should be routinely testing against
hard examples as well as easy ones.  Yes, to add systematic testing for
this stuff even to the NetBSD base would surely create a horrible flood
of failures that would take years to work through, and that without even
touching the morass of add-on software.  But a little at a time, it's worth
doing, and it's *absolutely* worth trying to beat into *today's* programmers
to stop and think about their quoting invariants in new code.  If every now
and then somebody comes along and innocently names a directory brown&sharpe,
that's a good reminder.

At least it *was* innocent.  Every bug in quoting that's left around because
it's easier to tell the innocent user "just don't do that" is a standing
invitation to the less-innocent user.  brown&sharpe is a better example
to learn from than brown&rm -rf /.

-Chap