Linux Slickedit running under compat mode

[Anonymous]

Apologies if this isn't the right place -- there didn't seem to be a better one.

I've a copy of Slickedit v7 for Linux that I've installed to run in compat mode. But it doesn't seem to know how to edit, e.g., /etc/hosts. No matter how carefully I try to open /etc/hosts, what it opens is /usr/compat/linux/etc/hosts. Similarly, an attempt to open /usr/local/foo gets /usr/compat/linux/usr/local/foo, etc.

Presumably FreeBSD is intercepting and redirecting the filesystem requests "for free" under the table, since Slickedit would have no reason to know or care what it's opening. But I can't imagine why it's doing it, or how to tell it to stop.

Has anyone else seen something like this?

 

[fonz]

Presumably FreeBSD is intercepting and redirecting the filesystem requests "for free" under the table

I wonder whether it's FreeBSD's Linux compatibility in general or just this Slickedit thingy in particular. Do you have other programs in (/usr)/compat/linux and do they have the same problem?

For example, if I do % /compat/linux/bin/ls / it correctly lists the actual root directory, not /compat/linux/. I also run other native (i.e. not a FreeBSD port) Linux applications such as Maple and they are all perfectly aware of life beyond (/usr)/compat/linux.

Fonz

 

[Anonymous]

No, slick is the only Linux app I have, and the only reason I installed Linux compat.

I first installed it on my toy server under 7.3, and thought its bizarre behavior might go away when I upped to 8.3, but not so.

Unless the fact that it's an editor is triggering some bug in the compat code, such that when it tries to writelock a file the compat code revectors it, I simply can't imagine what might be going on.

I note that it doesn't mind editing ~/.tcshrc or other things in my home subtree. It gets those right.

 

[fonz]

I did some more fooling around using /compat/linux/bin/ls and truss(1). From what I can tell, it appears that if a path exists relative to compat, that takes precedence. In other words: if you do something like % /compat/linux/bin/ls [i]foo[/i] it will use /compat/linux/foo if that exists and just plain foo otherwise. Since /etc exists within compat but /home usually doesn't, /etc becomes /compat/linux/etc but /home remains /home.

I suggest you create a symlink in compat, pointing to the system root, e.g. # ln -s / /compat/linux/bsd
so that you can refer to either /etc (which resolves to /compat/linux/etc) or /bsd/etc (which resolves to /etc).

Hope this helps,

Fonz

 

[Anonymous]

From what I can tell, it appears that if a path exists relative to compat, that takes precedence.

AhhHHHhhh...thank you! When I read that sentence, everything suddenly fell into place. As I suspected, it is a bug: they didn't consider the case of someone running an editor in compat mode who will nevertheless want to be able to edit generally.

I'm sure there's a way to get around that in compat itself, but I'm too distracted to think about it right now. For the moment, I'll gratefully use your perfectly sensible kludge.

 

[fonz]

As I suspected, it is a bug: they didn't consider the case of someone running an editor in compat mode who will nevertheless want to be able to edit generally.

I found a section in the handbook about this (we probably both should have looked there first :r): http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/linuxemu-advanced.html Apparently it is a feature, albeit one that comes with a drawback.

I'm sure there's a way to get around that in compat itself, but I'm too distracted to think about it right now. For the moment, I'll gratefully use your perfectly sensible kludge.

A kludge it is indeed, but if you want to "fix" it I suspect you're going to have to get your hands dirty. As the handbook explains, there are reasons for this behaviour.

Fonz

 

[Anonymous]

Thanks again! Nice find in the handbook, and very explanatory. (I still wouldn't call that a "feature" exactly, since one rarely has to work around features to get expected behaviors )