Please be aware that I'm currently using DSL version 3.2 due to a recent harddrive failure that caused me to have to install from the most recent CD I'd burned (and I've been too lazy to upgrade back to 4.x), so this might not be an issue with the newer versions.
In order for user dsl to use subshells in the midnight commander mydsl extension, dsl must have write access to /dev/ptmx, so I modify it from bootlocal. I did this again after reinstalling DSL, but found that neither dsl nor root could use subshells in mc, which meant the file permissions are not the issue (file permissions generally do not affect root). After pounding my head for an hour or so I realized that I wasn't using the "legacy" boot option as I had previously, and after rebooting with unionfs disabled the subshells worked as expected.
I noticed that with unionfs there is a /ramdisk/dev/ptmx, but the file permissions on that file were the same as those of /dev/ptmx, so I guess the permissions still had nothing to do with it in that case.
I'm wondering if anyone could explain, or at least give me some clue, what might be the issue with mc's subshells when using unionfs? I haven't yet had a use for unionfs, but probably will sometime in the future. If the subshells don't work, though, it won't be worth it for me...I use mc as much as any other application, and the subshells are invaluable to me.I don't use mc so cannot be specific to your question. However, unionfs that is in DSL, and the last supporting the 2.4 kernel, is quite old and therfeore buggy when used in its full capacity, ie., many write/updates. My intent was to basically use unionfs as a read-only layer to expand the concept that I introduced with uci. Doing this provides easy access to many additional program layered like uci but not having to re-compile to be completely self-contained.I don't know what to say, for that is the mechanism xterms use. And they worked in 3.2..Since this is 3.x, are you sure it is not due to mc vs mc.bin, with mc.bin intercepting what you want to do?I updated to 4.1 (haven't downloaded anything newer yet), and still get the same result. The mc/mc.bin isn't an issue. I run mc through a wrapper script that's located at the top of my PATH:
Code Sample
if [ -x "/opt/mc/bin/mc" ]; then exec /opt/mc/bin/mc -b "$@" else exec mc.bin -b "$@" fi
Regardless of whether or not mc.uci is loaded, the original mc wrapper isn't touched.
I suppose it's possible that it is a bug in unionfs, although I don't understand why there is a /ramdisk/dev/ptmx when /dev/ptmx is already writeable by default. Maybe it was created automatically when I modified the original? As I've said before, I don't understand how unionfs works, so this is a mystery to me.
In any case, I'm going to continue using legacy, possibly until it is no longer supported. The only thing I'd really like to try with it is xfree/xorg, but even that is in a very distant plan to be made into uci.Next Page...
original here.