Date: Sun, 20 Jan 2013 12:03:40 +0100 From: Polytropon <freebsd@edvax.de> To: "Ralf Mardorf" <ralf.mardorf@rocketmail.com> Cc: FreeBSD quest <freebsd-questions@freebsd.org> Subject: Re: Editors are broken after update Message-ID: <20130120120340.e29b1144.freebsd@edvax.de> In-Reply-To: <op.wq7gdrdiuwjkcr@freebsd> References: <op.wq7byyojuwjkcr@freebsd> <20130120103845.76c1a963.freebsd@edvax.de> <op.wq7gdrdiuwjkcr@freebsd>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 20 Jan 2013 11:21:17 +0100, Ralf Mardorf wrote: > On Sun, 20 Jan 2013 10:38:45 +0100, Polytropon <freebsd@edvax.de> wrote: > > # cd /root > > # mv .mc .mc.orig > > # mcedit > > $ mv .mc .mc.pre.update-01-Jan-2013 > $ su root -c "mv /root/.mc /root/.mc.pre.update-01-Jan-2013" > $ mcedit > > Error > "user/home/rocketmouse" is not a regular file [ Dismiss ] Also looks wrong, that doesn't seem to be a valid path. I assume /home/rocketmouse would be your home directory, so MC (or mcedit) would access a configuration structure within that directory (~/.mc). > > That should start the editor with the defaults. > > It doesn't do it for the user. Are you able to start the "normal" Midnight Commander instead? And if yes, PF4 on a file to invoke the editor? > > Of course, /root is not a regular file, it's a directory. :-) > > Yes and in this case it's true for the users home directory, but I only > run mcedit, without a file name. That shouldn't be a problem. If I start mcedit without a filename here, I _still_ get the editor launched with an empty file, with PF2 allowing me to enter a file name. (Version here: 4.7.5_1 on FreeBSD 8.2-STABLE i386). > > This editor requires X. If you're running the above su command > > in an xterm, use "su -m root" and try again. > > On Linux regarding to this, there is a difference between "su" and "su -", > I never had to run "su -m root". The -m option makes sure the environment is not touched, so $DISPLAY will be kept. If you do a full root login (su - and su -l simulate a full login, and omission of the name assumes root, so "su -" is like "su -l root", discarding your user's environment). > $ su -m root > # mcedit > > Error > "user/home/rocketmouse" is not a regular file [ Dismiss ] That was designed for running gedit as root (because of X). :-) Again, the path specification just looks wrong - there is no such thing (not absolute, not relative to ~). > # ls -l .config/mc > total 8 > -rw-r--r-- 1 rocketmouse rocketmouse 2931 Jan 20 10:55 ini > drwx------ 2 rocketmouse rocketmouse 512 Jan 20 09:28 mcedit > -rw-r--r-- 1 rocketmouse rocketmouse 1 Jan 20 10:51 panels.ini Okay, so this looks like it would be the new configuration location. For comparison: % ls .mc Tree bindings_1 filepos ini bindings cedit/ history panels.ini And cedit/ is now mcedit/. > # rm -r /root/.mc* /root/.config/mc /home/rocketmouse/.mc* > /home/rocketmouse/.config/.mc > rm: /home/rocketmouse/.config/.mc: No such file or directory > # rm -r /home/rocketmouse/.config/mc > > # mcedit > > Error > "user/home/rocketmouse" is not a regular file [ Dismiss ] Time for portdowngrade? :-) > # gedit > GConf Error: Failed to contact configuration server; some possible causes > are that you need to enable TCP/IP networking for ORBit, or you have stale > NFS locks due to a system crash. See http://projects.gnome.org/gconf/ for > information. (Details - 1: Failed to get connection to session: The > connection is closed) > GConf Error: Failed to contact configuration server; some possible causes > are that you need to enable TCP/IP > [snip] > networking for ORBit, or you have stale NFS locks due to a system crash. > See http://projects.gnome.org/gconf/ for information. (Details - 1: > Failed to get connection to session: The connection is closed) > g_dbus_connection_real_closed: Remote peer vanished with error: Underlying > GIOStream returned 0 bytes on an async read (g-io-error-quark, 0). Exiting. > Terminated What a scary error message. It seems that gedit relies a lot on Gtk / Gnome services running to access its own configuration, and that is not accessible from an instance running as root (in opposite to running as the user who started X and the services required). > On Linux it's a common issue for some distros, when using apps from > bloated DEs. So it seems that this "nice tradition" is also carried with programs ported to FreeBSD. Excellent. % gimp (gimp:3045): GLib-WARNING **: goption.c:2132: ignoring no-arg, optional-arg or filename flags (8) on option of type 0 > It usually needs gksu or similar. Programs being designed to be primarily used within specific desktop environments heavily rely on the mechanisms provided by those environments, even though one would consider them optional (as the program can be used "stand-alone"). Obviously it's not true to consider that. > At the end of the update I > got the information, that for K3b I have to set the suid flag for cdrecord > and cdrdao. That doesn't seem to be the default: % ll /usr/local/bin/cdr* -r-xr-xr-x 1 root wheel 564156 2011-08-22 03:01:50 /usr/local/bin/cdrdao* -r-xr-xr-x 1 root wheel 399044 2011-08-22 03:12:57 /usr/local/bin/cdrecord* % ll /dev/cd* /dev/pass* /dev/xpt* crw-rw-r-- 1 root operator 0, 110 2013-01-20 09:18:50 /dev/cd0 crw-rw-r-- 1 root operator 0, 111 2013-01-20 09:18:50 /dev/cd1 lrwxr-xr-x 1 root wheel 4 2013-01-20 09:18:58 /dev/cdrom@ -> acd0 crw-rw---- 1 root operator 0, 103 2013-01-20 09:18:50 /dev/pass0 crw-rw---- 1 root operator 0, 104 2013-01-20 09:18:50 /dev/pass1 crw-rw---- 1 root operator 0, 99 2013-01-20 09:18:50 /dev/xpt0 My local user is in the "operator" group, and I can access the devices for burning without requiring any su mechanism. Maybe this is also possible for a program (K3b) that calls other tools (cdrecord, cdrdao). > Wow, for FreeBSD the kit family is installed, so setting suid > IMO shouldn't be needed and should be avoided, perhaps there's the need to > use kdesu? That's possible. What about good old permissions in /etc/devfs.conf to allow regular users to access optical devices for burning? We've been doing this with chmod on /dev files decades ago! > # cd /usr/ports/sysutils/gksu ; make install clean > [...] > > $ gksu gedit > > Yes, it does work. I suspect for K3b it's not needed to set suid, but to > install kdesu or perhaps gksu does work too. That's worth trying, but also consider file permissions so they can be accessed by cdredord or cdrdao as a user. You can do this by group permissions (e. g. root:operator 0664) for the cd, xpt and pass device(s). > However, there's still this issue for mcedit :(. That's really an issue. Can you use truss to check what mcedit is acually trying to access? As I said, the error message looks totally wrong. > It would be nice if not so many Linux distros and FreeBSD won't follow > upstream for some odd policies :(. It's not about those recommendations to standardize the plethora of deviations among the many Linusi: It's about transitioning them to FreeBSD which definitely isn't a Linux distribution, and is not centered around one desktop environment. To me, the Midnight Commander (and therefor mcedit) do not have any relation to FreeDesktop, as the MC is a very nice tool for use on a server. A server is not a desktop. Why force a concept that is not stupid per se (in fact, having ~/.config doesn't sound that wrong!) to apply to a software that is not related to that concept? Maybe I'm too old to understand that motivation. :-) > When I read the name Lennart Poettering my blood pressure does rise ;). This is because BSD isn't relevant anymore. ;-) -- Polytropon Magdeburg, Germany Happy FreeBSD user since 4.0 Andra moi ennepe, Mousa, ...
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20130120120340.e29b1144.freebsd>