This is not a legitimate issue. It’s like complaining that wget reads proxy settings from /etc/wgetrc. It’s absolutely proper for programs to read system- or user-level configuration if the configuration is not specified via environment variables or command line options.

The typical setting hierarchy goes something like:

• command line options,
• environment variables,
• user-level configuration files and finally
• system-level configuration files.

I hear your frustration. It can be annoying. There’s a reason for it, and that’s because environment variables are limited in their use by scoping: they’re only inherited from the parent to children, and they’re pass-by-value. This means that, from a child process, you can’t influence the variables for any other sibling, or the parent. There’s no way to propagate environment variables to anyone except new children you fork.

This is a significant limitation. There is no work around using only environment variables. It’s a large part of why applications store scalar values in files: it’s (almost) the only environmentally agnostic way to propagate information to other processes.

Herbstluftwm has herbstclient getenv and setenv, because ostensibly every user process is a child of the window manager, and it’s a convenient way to communicate scalar changes between processes. tmux has similar commands; in both cases, the source of truth is the parent application, not the environment. gsettings is just Gnome’s version; KDE has it’s own version. I’d be surprised if Sway didn’t.

Environment variables are great, but they’re limited, and they are simply unsuitable for purposes. They’re also insecure: anyone with the right permissions can read them from /proc. The consequence is that it can be difficult to track down where settings are stored, especially if you’re still using some component of a desktop, which tend to manage all of their settings internally.

We do have a global solution for Linux: the kernel keyring. It’s secure, and global. It is not, however, automatically persisted, although desktops could easily persist and restore values from the keyring when they shut down or start up. Every desktop I know just keeps it’s own version of what’s essentially the Windows registry.

It’s a mess.

This is not a distro-specific thing, but a desktop-specific one. It was probably written for Gnome primarily.

Not sure how other software that reads this setting handles it, but imo doing it correctly it should only look at it if the current desktop is Gnome. Plasma has a setting like this too, which probably works similarly.

Before any commenter rushes to condemn the Chaos That Is Linux, please check out OP’s posting history to get a clearer picture of their credibility.

(and like they themselves stated, this is a rant and not a PSA)

It’s an issue but its a pretty niche one. Even software that works great on most distros might misbehave when you have multiple desktop environments installed. And http_proxy use doesn’t appear to be standardized by freedesktop, LSB, etc. Though it is pretty well adhered to: https://about.gitlab.com/blog/2021/01/27/we-need-to-talk-no-proxy/

So yeah, I agree with the spirit of this but its tough to follow the standard when there is no standard

Firstly, I agree with your main point.

Just an open thought: I wonder if zscalar are using settings in a heirarchy, ie if no env var is set, then check Gnome - just in case the user’s only making changes there…? Dunno…

Follow the guidelines as mentioned in freedesktop

Which guidelines are you talking about? Searching for “proxy” and “environment variables” didn’t pull up anything I saw that would be relevant in this case. I’ve been using linux for a couple of decades now and I’m not sure what rule is being broken here.

It sounds like you didn’t have a proxy set in your environment variables, but you did have one set through another means. It’s somewhat standard practice to have fall-through settings, where if settings aren’t set in one place, a program looks in another place, then maybe another, etc. Now admittedly it would be nice to have a way to disable functionality entirely, but usually that kind of thing happens with command line flags.

I get that it’s frustrating to deal with a problem like this, but ultimately your environment was misconfigured, and that’s going to break some software.

I am not sure whos advocate i am being here but theres class of vibe coding enthusiasts that get heavily demotivated by being told to do things a certain way.

The trade of for this chaos is. At least they how to code and participate in open source projects and once in a full moon some creative actually designs something nova and inspiring.

It’s very annoying that the community hasn’t standardized on an approach for proxy settings.