# Linux Slickedit running under compat mode



## Anonymous (Dec 12, 2012)

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 (Dec 12, 2012)

Auld_Besom said:
			
		

> 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 (Dec 13, 2012)

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 (Dec 13, 2012)

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 (Dec 13, 2012)

fonz said:
			
		

> 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 (Dec 13, 2012)

Auld_Besom said:
			
		

> 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.



			
				Auld_Besom said:
			
		

> 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 (Dec 13, 2012)

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 )


----------

