In message <20050901145324.GA19118@jodi.nimenees.com>, Eric Haszlakiewicz write
s:
>On Thu, Sep 01, 2005 at 11:17:48PM +1200, Mark Davies wrote:
>> On Thursday 01 September 2005 15:09, Steven M. Bellovin wrote:
>> > Ah -- excellent catch.  It turns out that it's the existence of
>> > /emul/linux/usr/pkg/bin that causes the problem.  Having just
>> > /emul/linux/usr/pkg doesn't cause any trouble.
>> >
>> > It's getting late; I'll do some ktraces tomorrow to understand exactly
>> > what the problem is before I file a PR.
>> 
>> Thats consistent with what I saw back in May.  If you had "/usr/pkg/bin/lpr"
> 
>> in acroread's dialog box it would try to to cd to "/usr/pkg/bin" which on 
>> your problem machine would take it to "/emul/linux/usr/pkg/bin" and on the 
>> other machine to "/usr/pkg/bin", do a getcwd() and append lpr to the result 
>> to get the path it actually tries to use.  Why it bothers I don't know.
>
>	That sort of makes sense.  I've done stuff like that in scripts I've
>written to do the equivalent of realpath(), so the path I store is absolute
>and doesn't have any /./ or /../ in it.  I'd be surprised if realpath() in
>a linux binary actually worked correctly.
>

Right, which raises questions about the linux emulation in the kernel.
It's using /emul/linux as a pseudo-root or a pseudo-overlay, but it's 
not doing the right thing.  Should it be changed to use more of the 
real overlay file systems?

It also raises the question of what, if anything, pkgsrc should do 
differently.  Newer versions don't seem to create /usr/pkg/bin, so 
maybe it's a non-issue for now.  If I'm wrong about that, should there 
be a warning message with acoread7?  A shell script 'lpr' that would 
just exec lpr, from the NetBSD environment instead?

		--Steven M. Bellovin, http://www.cs.columbia.edu/~smb