As a result, a fair amount of bash scripts as well as habit, in fact *relies on the "improperly" configured sudo.

Is there? I don't see this myself, and can't really imagine why it would be a problem. The only thing that change is the environment, and the large majority of scripts don't pass much data though the environment.
And even if they did, all it takes is putting sudo at the start of the line instead of the command, sudo FOO=bar script instead of FOO=bar sudo script -- ok, that means user changing habits, and that's hard.

And apparently Debian changed sudo's default without too much issues, or at least I didn't hear about them, so it sounds very possible.

There is a ton of stuff in Linux (and BSD and Windows) where "improper" eventually became "standard", and tools & apps that consume their services either have to assume "improper" function, or at least be able not fail in the face of it. Like I said before, I've never seen a base of code yet, that consumes lower-level services as a significant portion of it's function, that doesn't have a significant if not majority share of code devoted to working around flaws. Nirvana would be stuff that works as expected. Whether or not stuff below it works as expected.

I could be wrong and it's just an opinion, but it feels like your response is one of dogmatic ideology, and does nothing to address the world as it is. That's just my reading. I know that's an attractive stance in the open-source world. (And to be fair, there is an important place at the table for hyper-rigid idealistic purity - but it can't be the only voice. We need the inflexible purists hashing things out with the end users. When those two don't talk, things get bad.)

Well, you're kind of right. I'm reluctant to make a change I don't feel good about in Geany for something I don't think is a Geany problem. If we "fix" Geany, there will be N-1 applications that suffers from the issue. If sudo is "fixed", there will be 0. If the platform layer we use is "fixed", there will be N - apps_using_glib (where apps_using_glib is guaranteed to be >= 1).

I get that you have the problem with Geany because you use Geany, but if GLib "fixes" it, Geany will be "fixed" as long with a long list of other apps. Plus a long list of apps will show a consistent behavior, instead of each using its own version of the hack with its own pros and cons.

And yeah, I'm really sad writing apps requires fixing bugs in the platform, so I generally try and fix the platform layer when I can.

So… yeah we could make a change to get you and few other users happy. I do like happy users. But I'm also reluctant to participate to the hack party without trying to improve the situation.

To answer your question, yes I do have dotfiles owned by root. Most people do if they use dbus or gvfs. I also have a couple of paths put there by installers, apparently incorrectly. ...But...I've broken things before by assuming nothing but me should have ownership in my own directory ;-). Nothing geany-related anyway. Why do you ask?

I don't, and I do use apps using DBUS and GVFS.

And I ask because actually, if you do have files not owned by your user in your dotfiles, there's a lot more problems than just Geany. If a file is owned by root, your user won't be able to touch it, resulting generally in not being able to save settings, state, history, etc., or worse fail to start because realizing something's fishy is going on.

I know several years ago I had that problem with the nano editor: it would not be able to write its history file after having been used by root, and would complain at each startup -- and using such a basic editor as root is a lot more common.
I don't know if they did something in nano itself or it just got fixed when Debian started to env_reset by default though.

Anyway, my points is that:

  1. every application writing user config/state files suffers from this "bug" unless they have specific handling for it. There however are many ways to avoid this without changing applications, addressing the root cause of the problem, and most have been suggested here:
  2. If really root user should be sepcial-cased, it should be done lower in the stack, like in the XDG specification, and then its implementations (like g_get_user_config_dir() and friends), so it's "fixed" for many people, and not just one application at a time. And it should still be possible to override it if a power-user really knows he wants to mess with its stuff, so the simple hard-coded logic of "if you're root, ignore the environment" seems flawed to me.

In the end, I'm not strictly against adding a workaround to Geany, given it's good enough in every case, and reasonably simple. It probably would involve getpwuid() and getting the home directory that way, and it might involve some extra trickiness to really be sure we never access $HOME/$XDG_CONFIG_HOME directly then, even through platform code.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.