pub fn read() -> Result<ProxyConfig, Error>Expand description
Read the OS proxy configuration once, without starting a watcher.
The read ProxyWatcher::new performs during construction, on its own: no thread is
spawned and no change-notification route is registered. That is the difference worth
knowing — a machine where notifications cannot be armed makes ProxyWatcher::new fail
while its settings are still perfectly readable, and this call returns them.
Nothing here is watched, so nothing reports a later change; call it again.
Blocking, and not always briefly. Both non-Windows backends wait on a system service
that can be absent: on macOS a configd that is still coming up is retried for five
seconds before this gives up, and inside a Linux sandbox each portal Lookup is
bounded at five seconds too. That bound is per call, and a sandboxed read asks five
questions: one unanswered Lookup ends the read at five seconds, but five answers
that each arrive just inside the bound hold it for twenty-five. Neither is the ordinary
case, but this is not a call to put on a request path expecting syscall latency.
A Linux read consults both desktop stores, and an error from the one that is not
leading this session is softened to “absent” rather than failing the call — a
malformed kioslaverc should not break a GNOME session. So a success can be missing a
source that exists, and without the tracing feature nothing says so. The softening
holds only while the leading store is itself configured, which is what makes the
missing source one that could not have changed the answer. When the leading store is
unset, the store that failed was the effective one, and the error is returned rather
than reported as a Direct nothing measured.
let config = proxy_watch::read()?;
println!("effective: {:?}", config.effective);§Errors
Error::Unsupported, Error::Io, Error::Sandboxed (Linux, in a sandbox with
no dconf), or a parse error from malformed OS settings.