dirs-dev / dirs-rs Goto Github PK
View Code? Open in Web Editor NEWa low-level library that provides config/cache/data paths, following the respective conventions on Linux, macOS and Windows
Home Page: https://dirs.dev
License: Apache License 2.0
a low-level library that provides config/cache/data paths, following the respective conventions on Linux, macOS and Windows
Home Page: https://dirs.dev
License: Apache License 2.0
I want to use the package with webassembly, unfortunately there is no support (I guess) for wasm-pack's compiler wasm32-unknown-unknown. Is there any plan to add support in the close future? Thanks
I am using:
Ubuntu 18.04.2 lts
rustc 1.32.0
wasm-pack 0.6.0
$ wasm-pack build
--> /home/regl/.cargo/registry/src/github.com-1ecc6299db9ec823/dirs-1.0.4/src/lin.rs:41:18
|
41 | use std::os::unix::ffi::OsStringExt;
| ^^^^ could not find unix
in os
error[E0432]: unresolved import unix
--> /home/regl/.cargo/registry/src/github.com-1ecc6299db9ec823/dirs-1.0.4/src/lin.rs:6:5
|
6 | use unix;
| ^^^^ no unix
in the root
Hi,
Various projects ported to Windows take $HOME value first (and XDG env), before looking up FOLDERID_Profile etc. This is the case for example with glib (on msys2 or not).
Would it make sense to add some "xdg" feature to follow this behaviour, even on Windows or other platforms?
Rust works very well on Cmder. Would you be open to supporting this environment?
Good morning, and thank you for maintaining a very useful Rust crate!
This isn't really a bug report—it's more of a "Hey, I noticed something interesting and thought I'd mention it."
When I updated to the latest dirs
, I received an interesting "heads up" from cargo deny
, which noticed that dirs-sys
uses option-ext
, which is licensed under the MPL license. The MPL license is a bit of an odd duck: It's a fairly complex file-level copyleft, and it's used infrequently for Rust crates. I'd normally only expect to see if for code extracted from Firefox.
This doesn't represent a serious problem—I can add an exception to our license checker for this and verify it with the right people, at least for the affected project. It isn't necessary to do anything here!
error[rejected]: failed to satisfy license requirements
┌─ option-ext 0.2.0 (registry+https://github.com/rust-lang/crates.io-index):4:12
│
4 │ license = "MPL-2.0"
│ ^^^^^^^
│ │
│ license expression retrieved via Cargo.toml `license`
│ rejected: license is considered copyleft
│
= option-ext v0.2.0
└── dirs-sys v0.4.1
└── dirs v5.0.1
On the other hand, option-ext
is a tiny library. So if you're interested, I'd be happy to submit a PR removing this dependency. But that's entirely up to you. This isn't really a bug report, or even really a request—it's more of a "heads up" that you can happily ignore. :-) Please feel free to close it.
Anyway, thank you once again for maintaining a very useful crate!
On macOS, the names of the various system-created directories like Library
, Music
, etc can vary based on the user's locale.
This crate simply hard-codes paths such as home_dir().map(|h| h.join("Music"))
, which won't always find the correct directory.
Instead, the NSSearchPathForDirectoriesInDomains
should be used to find the appropriate path to look for.
Correct me if i am wrong. The standard for an unset/not exported variable eg. $XDG_DOWNLOAD_DIR
should default to $HOME
. See: https://www.freedesktop.org/wiki/Software/xdg-user-dirs/.
Here is a shellscript example of how to find the desktop and the download directory:
test -f ${XDG_CONFIG_HOME:-~/.config}/user-dirs.dirs && source ${XDG_CONFIG_HOME:-~/.config}/user-dirs.dirs
echo ${XDG_DESKTOP_DIR:-$HOME/Desktop}
echo ${XDG_DOWNLOAD_DIR:-$HOME}
I suggest to implement this behavior as well.
cfg-if
0.1.10 requires a later rustc, so dirs-2.0 does not work with rustc 1.13 even though it is documented to work. I think cfg-if
0.1 is also a transitive dependency through for example the chain dir-sys
, redox_users
, failure
, backtrace
, cfg-if
.
Related discussion #32
Currently dirs-rs
returns always None for a font directory in Windows:
pub fn font_dir() -> Option<PathBuf> { None }
However, according to this , ever since Windows 1809, there has been support for a user font directory.
I have written a fork of dirs-sys-rs with support for the folder , basically it tries to find the directory %userprofile%\AppData\Local\Microsoft\Windows\Fonts
, if it doesn't exist, the function returns None. Is this a good approach for a merge request?
tl;dr: Please add a crates.io co-owner to improve the bus factor for this crate and dirs-ng.
Hi.
Relevantly, I'm the current maintainer of shellexpand
, which I inherited from its author when they weren't able to work on it any more. I was recently asked to swtich from dirs
to home
.
The principal motivation seems to have been to avoid the MPL. I strongly disagreed; I did some evaluation of both crates and concluded that I would like to stay with dirs
.
However, the biggest point against dirs
was the single ownership of the crate name on crates.io. I would respectfully request that you add a second crate owner. Single crate ownership can cause serious inconvenience if the owner can't work on the crate for any reason. (Indeed shellexpand
had to be forked for many months and dirs
seems to have had a temporary fork too.)
Your co-owner doesn't really have to do anything, other than approve (or not!) volunteers who come forward if you (for any reason) aren't available.
Obviously you'll want to pick someone you feel is ideologically aligned, and has similar engineering taste, and so on. Hopefully you'll have a friend or colleague you can prevail on. For the record: I am volunteering, but I don't want this request to be read as a request for you to grant co-ownership to me. I just want to avoid the risk iof having to rename the crate on crates.io; that would be seriously disruptive for your thousands of dependencies).
Thanks for your attention.
As mentioned in spacekookie/rfcs#1, it seems people have finally managed to add it to the spec.
When running with sudo
, dirs-rs
returns directories for the user calling sudo
and not the user that's running under sudo
.
On the surface this can seem like expected behavior but it becomes a real problem when a tool is run with sudo
, uses dirs::cache_dir
, and ends up creating that directory when it doesn't exist.
Unsetting $HOME
before using dirs-rs
causes dirs-sys-rs
's home_dir
to use getpwuid_r
in the "fallback" logic. This ends up returning the home dir for the user running under sudo
. But it's a really ugly workaround. Although sudo
has an -H
flag to replace $HOME
, you don't tend to expect a tool to end up creating a ~/.cache
owned by say root
when you don't use -H
.
I'm not sure if it's a good idea to never trust $HOME
, but would it be possible to offer another set of methods that use the "real home dir"?
Getting directories via shlobj::SHGetKnownFolderPath
works fine on Windows and Windows Server containers, but not in Nanoserver containers.
Simple program to output all dirs:
extern crate dirs;
fn main() {
println!("audio_dir: {}", dirs::audio_dir().unwrap_or_default().to_string_lossy());
println!("cache_dir: {}", dirs::cache_dir().unwrap_or_default().to_string_lossy());
println!("config_dir: {}", dirs::config_dir().unwrap_or_default().to_string_lossy());
println!("data_dir: {}", dirs::data_dir().unwrap_or_default().to_string_lossy());
println!("data_local_dir: {}", dirs::data_local_dir().unwrap_or_default().to_string_lossy());
println!("desktop_dir: {}", dirs::desktop_dir().unwrap_or_default().to_string_lossy());
println!("document_dir: {}", dirs::document_dir().unwrap_or_default().to_string_lossy());
println!("download_dir: {}", dirs::download_dir().unwrap_or_default().to_string_lossy());
println!("executable_dir: {}", dirs::executable_dir().unwrap_or_default().to_string_lossy());
println!("font_dir: {}", dirs::font_dir().unwrap_or_default().to_string_lossy());
println!("home_dir: {}", dirs::home_dir().unwrap_or_default().to_string_lossy());
println!("preference_dir: {}", dirs::preference_dir().unwrap_or_default().to_string_lossy());
println!("public_dir: {}", dirs::public_dir().unwrap_or_default().to_string_lossy());
println!("picture_dir: {}", dirs::picture_dir().unwrap_or_default().to_string_lossy());
println!("runtime_dir: {}", dirs::runtime_dir().unwrap_or_default().to_string_lossy());
println!("template_dir: {}", dirs::template_dir().unwrap_or_default().to_string_lossy());
println!("video_dir: {}", dirs::video_dir().unwrap_or_default().to_string_lossy());
}
Dockerfile:
ARG version=servercore:1809
FROM mcr.microsoft.com/windows/$version
COPY target/release/rust-test.exe .
ENTRYPOINT ["rust-test.exe"]
Outputs
Win 10 (no containers):
audio_dir: C:\Users\myuser\Music
cache_dir: C:\Users\myuser\AppData\Local
config_dir: C:\Users\myuser\AppData\Roaming
data_dir: C:\Users\myuser\AppData\Roaming
data_local_dir: C:\Users\myuser\AppData\Local
desktop_dir: C:\Users\myuser\Desktop
document_dir: C:\Users\myuser\Documents
download_dir: C:\Users\myuser\Downloads
executable_dir:
font_dir:
home_dir: C:\Users\myuser
preference_dir: C:\Users\myuser\AppData\Roaming
public_dir: C:\Users\Public
picture_dir: C:\Users\myuser\Pictures
runtime_dir:
template_dir: C:\Users\myuser\AppData\Roaming\Microsoft\Windows\Templates
video_dir: C:\Users\myuser\Videos
Windows ServerCore 1809 Container:
PS C:\dev\repos\rust-test> docker run --rm $(docker build --build-arg version=servercore:1809 -q .)
audio_dir: C:\Users\ContainerAdministrator\Music
cache_dir: C:\Users\ContainerAdministrator\AppData\Local
config_dir: C:\Users\ContainerAdministrator\AppData\Roaming
data_dir: C:\Users\ContainerAdministrator\AppData\Roaming
data_local_dir: C:\Users\ContainerAdministrator\AppData\Local
desktop_dir: C:\Users\ContainerAdministrator\Desktop
document_dir: C:\Users\ContainerAdministrator\Documents
download_dir: C:\Users\ContainerAdministrator\Downloads
executable_dir:
font_dir:
home_dir: C:\Users\ContainerAdministrator
preference_dir: C:\Users\ContainerAdministrator\AppData\Roaming
public_dir: C:\Users\Public
picture_dir: C:\Users\ContainerAdministrator\Pictures
runtime_dir:
template_dir: C:\Users\ContainerAdministrator\AppData\Roaming\Microsoft\Windows\Templates
video_dir: C:\Users\ContainerAdministrator\Videos
Windows Nanoserver 1809 Container:
PS C:\dev\repos\rust-test> docker run --rm $(docker build --build-arg version=nanoserver:1809 -q .)
audio_dir:
cache_dir:
config_dir:
data_dir:
data_local_dir:
desktop_dir:
document_dir:
download_dir:
executable_dir:
font_dir:
home_dir:
preference_dir:
public_dir:
picture_dir:
runtime_dir:
template_dir:
video_dir:
Windows Nanoserver 20H2 Container (newest version):
PS C:\dev\repos\rust-test> docker run --rm $(docker build --build-arg version=nanoserver:20H2 -q .)
audio_dir:
cache_dir:
config_dir:
data_dir:
data_local_dir:
desktop_dir:
document_dir:
download_dir:
executable_dir:
font_dir:
home_dir:
preference_dir:
public_dir:
picture_dir:
runtime_dir:
template_dir:
video_dir:
This is a known issue (or maybe even intended) in nanoserver according to dotnet/runtime#21430 (comment)
To work around this we could use environment variables on nanoserver, although only for some:
USERPROFILE for home_dir
APPDATA for data_dir
LOCALAPPDATA for data_local_dir
PUBLIC for public_dir
To find out if running on nanoserver, the easiest would be to check the registry:
C:\>reg query "HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Server\ServerLevels"
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Server\ServerLevels
NanoServer REG_DWORD 0x1
C:\>reg query "HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Server\ServerLevels"
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Server\ServerLevels
ServerCore REG_DWORD 0x1
C:\>reg query "HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Server\ServerLevels"
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Server\ServerLevels
Server-Gui-Mgmt REG_DWORD 0x1
Server-Gui-Shell REG_DWORD 0x1
ServerCore REG_DWORD 0x1
ServerCoreExtended REG_DWORD 0x1
The README states that rustc 1.20 is required on macOS, but it's building fine for me using 1.13. I think this is because libc 0.2.48 was not building on 1.13, but libc 0.2.49 has fixed that, presumably thanks to rust-lang/libc#1247.
systemd gives users the option in service units to create and point to various directories under paths like, /run/{app}, /var/lib/{app}, etc. Would It make sense to add these environment variables as possible returns if the XDG paths don't match? I guess I'm asking if I implement this, would you accept such a PR?
systemd.exec(5) has this table that seems to layout the variables set and roughly where they'd end up. I'm not sure why some of these paths would fall into the XDG_CONFIG_HOME paths if the service is a user service. I'd think XDG_DATA_HOME makes more sense.
Table 2. Automatic directory creation and environment variables
┌────────────────────────┬────────────────┬───────────────────────┬──────────────────────────┐
│Directory │ Below path for │ Below path for │ Environment │
│ │ system units │ user units │ variable set │
├────────────────────────┼────────────────┼───────────────────────┼──────────────────────────┤
│RuntimeDirectory= │ /run/ │ $XDG_RUNTIME_DIR │ $RUNTIME_DIRECTORY │
├────────────────────────┼────────────────┼───────────────────────┼──────────────────────────┤
│StateDirectory= │ /var/lib/ │ $XDG_CONFIG_HOME │ $STATE_DIRECTORY │
├────────────────────────┼────────────────┼───────────────────────┼──────────────────────────┤
│CacheDirectory= │ /var/cache/ │ $XDG_CACHE_HOME │ $CACHE_DIRECTORY │
├────────────────────────┼────────────────┼───────────────────────┼──────────────────────────┤
│LogsDirectory= │ /var/log/ │ $XDG_CONFIG_HOME/log/ │ $LOGS_DIRECTORY │
├────────────────────────┼────────────────┼───────────────────────┼──────────────────────────┤
│ConfigurationDirectory= │ /etc/ │ $XDG_CONFIG_HOME │ $CONFIGURATION_DIRECTORY │
└────────────────────────┴────────────────┴───────────────────────┴──────────────────────────┘
The
$XDG_STATE_HOME
contains state data that should persist between (application) restarts, but that is not important or portable enough to the user that it should be stored in$XDG_DATA_HOME
.
To me, this seems to indicate that non-portable files should be stored here. Of course, changing this would be a breaking change.
Currently the whole API assumes that home_dir
cannot realistically fail (which is currently the case, because env::home_dir
is broken and ignores errors).
If the implementation of home_dirs
is changed to not ignore errors and starts returning Option<PathBuf>
– what shall be done with all the other functions like config_dir() -> PathBuf
or data_dir() -> PathBuf
that rely on home_dir()
as a (not to unlikely) fallback?
Turning them all into Option
s would be pretty bad, because these function can't fail on MacOS or Windows.
Not sure if I'm doing something wrong or what, but I'm consistently getting "C:\" from config_dir()
when running on Windows 10. This happens both in develop builds and release builds.
I'd be happy to provide more info, but I'm not sure what info would be helpful.
Currently the documentation is vague about what causes None returns in functions. It would be very helpful to be able to not have to comb through the code to implement the api calls and know what is happening if None is returned.
This is a bug coming from the just
tool:
It seems that data_dir() returns some local folder such as /home/mini-me/.local/share
and not some system wide folder such as /usr/local/share
.
Maybe there is something that I don't quite get, but this seems to more or less be intended behaviour, when looking at the codebase of dirs-rs.
specifically, Termux
would you be open to including this?
Please use $XDG_*
directories on MacOS if they are set, at least.
Many users, including myself, do use them on MacOS, and it's annoying when they're not only not respected, but not respected in a sort of telling me I'm on MacOS not Linux and therefore doing it wrong and should be using some sort of ~/Application Support/Library/Resources/Content/MacOS/Content Library/Who Knows What/Nonsense
instead 🙂.
I found this directory under MacOS: /Library/User Template
open "/Library/User Template"
Does MacOS have a template directory like Windows?
I've just updated from version 4.x to 5.x. Is there any breaking changes in 5.x?
If not, could you, in the future, release such updates in a minor release (4.1 in this case).
Minor releases are meant for new features that are not-breaking. Most crates will depend on this crate only by the major version, so their projects will get the new minor version without any develop input. This is the great thing about semver.
My project expects the user to put their config in a subdirectory of dirs::config_dir()
. When testing my tool, I want to write a config file to a temporary directory and have the tool read that config. On Linux and Mac, I can do that by pointing $HOME
to a temporary directory, but what do I do for Windows? https://docs.rs/dirs/4.0.0/dirs/fn.config_dir.html says that the path on Windows is {FOLDERID_RoamingAppData}
. Is there a way to override that in my tests? I'm not asking for a change in the library.
I can of course define a custom environment variable (e.g. $JJ_CONFIG
) and make my tool prefer that over dirs::config_dir()
, and there are probably good reasons I'll want to have that functionality anyway (e.g. to let the user temporarily ignore their regular config).
Hi! I just saw you support XDG_BIN_HOME, which is a proposal, but not yet a standard. There’s some 2017 patches that haven’t been merged. I’d like to know why you decided to support it, because it would be cool to be able to rely on it.
Love the project but kinda of a pain to write tests around code that is leveraging this library. Have the team considered making a trait of the Public API's so they can be mocked or replaced with an in memory file system for testing code that uses this library.
Some MacOS users would like to use XDG configuration, especially for everything terminal related. Many tools out-there actually support it.
It would be great if dirs
could honor these environment variables on MacOS too. I'm only talking of honoring the environment variables, not the default locations, so that this remains strictly opt-in.
Another way to make this even safer is to check an additional XDG_FORCE_MACOS
environment variable. That way updating dirs
will not break workflow of users that are already using XDG
and ~/Library
.
Hey guys,
since windows 10 there is a user writable location for fonts: %localappdata%\Microsoft\Windows\Fonts
.
Might be worth adding it.
There is also a constant in the windows create for it:
windows::Win32::UI::Shell::FOLDERID_Fonts
Greetings
Resources:
Compiling dirs v2.0.1
error[E0425]: cannot find function `user_dir` in module `dirs_sys`
--> /Users/travis/.cargo/registry/src/github.com-1ecc6299db9ec823/dirs-2.0.1/src/lin.rs:17:56
|
17 | pub fn audio_dir() -> Option<PathBuf> { dirs_sys::user_dir("MUSIC") }
| ^^^^^^^^ not found in `dirs_sys`
error[E0425]: cannot find function `user_dir` in module `dirs_sys`
--> /Users/travis/.cargo/registry/src/github.com-1ecc6299db9ec823/dirs-2.0.1/src/lin.rs:18:56
|
18 | pub fn desktop_dir() -> Option<PathBuf> { dirs_sys::user_dir("DESKTOP") }
| ^^^^^^^^ not found in `dirs_sys`
error[E0425]: cannot find function `user_dir` in module `dirs_sys`
--> /Users/travis/.cargo/registry/src/github.com-1ecc6299db9ec823/dirs-2.0.1/src/lin.rs:19:56
|
19 | pub fn document_dir() -> Option<PathBuf> { dirs_sys::user_dir("DOCUMENTS") }
| ^^^^^^^^ not found in `dirs_sys`
error[E0425]: cannot find function `user_dir` in module `dirs_sys`
--> /Users/travis/.cargo/registry/src/github.com-1ecc6299db9ec823/dirs-2.0.1/src/lin.rs:20:56
|
20 | pub fn download_dir() -> Option<PathBuf> { dirs_sys::user_dir("DOWNLOAD") }
| ^^^^^^^^ not found in `dirs_sys`
error[E0425]: cannot find function `user_dir` in module `dirs_sys`
--> /Users/travis/.cargo/registry/src/github.com-1ecc6299db9ec823/dirs-2.0.1/src/lin.rs:22:56
|
22 | pub fn picture_dir() -> Option<PathBuf> { dirs_sys::user_dir("PICTURES") }
| ^^^^^^^^ not found in `dirs_sys`
error[E0425]: cannot find function `user_dir` in module `dirs_sys`
--> /Users/travis/.cargo/registry/src/github.com-1ecc6299db9ec823/dirs-2.0.1/src/lin.rs:23:56
|
23 | pub fn public_dir() -> Option<PathBuf> { dirs_sys::user_dir("PUBLICSHARE") }
| ^^^^^^^^ not found in `dirs_sys`
error[E0425]: cannot find function `user_dir` in module `dirs_sys`
--> /Users/travis/.cargo/registry/src/github.com-1ecc6299db9ec823/dirs-2.0.1/src/lin.rs:24:56
|
24 | pub fn template_dir() -> Option<PathBuf> { dirs_sys::user_dir("TEMPLATES") }
| ^^^^^^^^ not found in `dirs_sys`
error[E0425]: cannot find function `user_dir` in module `dirs_sys`
--> /Users/travis/.cargo/registry/src/github.com-1ecc6299db9ec823/dirs-2.0.1/src/lin.rs:25:56
|
25 | pub fn video_dir() -> Option<PathBuf> { dirs_sys::user_dir("VIDEOS") }
| ^^^^^^^^ not found in `dirs_sys`
I just noticed that there are a new major release dirs 2.0.0 but I cannot find how it differs from 1.0.0 (specifically looking for breaking changes). Any idea? Note that having 1.0
in lock file does not install 2.0
.
use error_chain::error_chain;
fn main() {
println!("Hello, world!");
let _path = dirs::home_dir();
}
When the crate is used with dirs and I try to run cargo test
, a gcc error occurs.
I don't know what went wrong.
error: linking with `gcc` failed: exit code: 1
|
= note: "gcc" "-fno-use-linker-plugin" "-Wl,--nxcompat" "-nostdlib" "-m64" "D:\\Rust\\Rustup\\toolchains\\stable-x86_
64-pc-windows-gnu\\lib\\rustlib\\x86_64-pc-windows-gnu\\lib\\crt2.o" "D:\\Rust\\Rustup\\toolchains\\stable-x86_64-pc-wi
ndows-gnu\\lib\\rustlib\\x86_64-pc-windows-gnu\\lib\\rsbegin.o" "-L" "D:\\Rust\\Rustup\\toolchains\\stable-x86_64-pc-wi
ndows-gnu\\lib\\rustlib\\x86_64-pc-windows-gnu\\lib" "E:\\Project\\ssr-sub-rust\\target\\debug\\deps\\ssr_sub-a3844f7e6
0f402c1.13lk4fuu55w47lwe.rcgu.o" "E:\\Project\\ssr-sub-rust\\target\\debug\\deps\\ssr_sub-a3844f7e60f402c1.169j9c5ha6hr
6uyk.rcgu.o" "E:\\Project\\ssr-sub-rust\\target\\debug\\deps\\ssr_sub-a3844f7e60f402c1.1brvr1sfvhor1mkh.rcgu.o" "E:\\Pr
oject\\ssr-sub-rust\\target\\debug\\deps\\ssr_sub-a3844f7e60f402c1.1cjjq73kguapbvjt.rcgu.o" "E:\\Project\\ssr-sub-rust\
\target\\debug\\deps\\ssr_sub-a3844f7e60f402c1.1eg4wfyckd9gffe3.rcgu.o" "E:\\Project\\ssr-sub-rust\\target\\debug\\deps
\\ssr_sub-a3844f7e60f402c1.1m572kadb7reutzb.rcgu.o" "E:\\Project\\ssr-sub-rust\\target\\debug\\deps\\ssr_sub-a3844f7e60
f402c1.1o3pkbij4voga1lp.rcgu.o" "E:\\Project\\ssr-sub-rust\\target\\debug\\deps\\ssr_sub-a3844f7e60f402c1.1s2q1p4cn25aw
jtg.rcgu.o" "E:\\Project\\ssr-sub-rust\\target\\debug\\deps\\ssr_sub-a3844f7e60f402c1.1w3aq7wnwhics2wv.rcgu.o" "E:\\Pro
ject\\ssr-sub-rust\\target\\debug\\deps\\ssr_sub-a3844f7e60f402c1.1xs29hx1mwagbm3o.rcgu.o" "E:\\Project\\ssr-sub-rust\\
target\\debug\\deps\\ssr_sub-a3844f7e60f402c1.20f28jgj01t7rt7f.rcgu.o" "E:\\Project\\ssr-sub-rust\\target\\debug\\deps\
\ssr_sub-a3844f7e60f402c1.20iym3seff83np6p.rcgu.o" "E:\\Project\\ssr-sub-rust\\target\\debug\\deps\\ssr_sub-a3844f7e60f
402c1.22n0dvwdidmgx15l.rcgu.o" "E:\\Project\\ssr-sub-rust\\target\\debug\\deps\\ssr_sub-a3844f7e60f402c1.247ysbwj2ha8ed
fn.rcgu.o" "E:\\Project\\ssr-sub-rust\\target\\debug\\deps\\ssr_sub-a3844f7e60f402c1.292imitdj7u5ai0t.rcgu.o" "E:\\Proj
ect\\ssr-sub-rust\\target\\debug\\deps\\ssr_sub-a3844f7e60f402c1.29oqjpaoyud5wc2i.rcgu.o" "E:\\Project\\ssr-sub-rust\\t
arget\\debug\\deps\\ssr_sub-a3844f7e60f402c1.29rvp9hfkc3ljayh.rcgu.o" "E:\\Project\\ssr-sub-rust\\target\\debug\\deps\\
ssr_sub-a3844f7e60f402c1.2cfrk3dk11y4awmi.rcgu.o" "E:\\Project\\ssr-sub-rust\\target\\debug\\deps\\ssr_sub-a3844f7e60f4
02c1.2fiwa1rzrnnz0he8.rcgu.o" "E:\\Project\\ssr-sub-rust\\target\\debug\\deps\\ssr_sub-a3844f7e60f402c1.2id7crdnkf11eyh
o.rcgu.o" "E:\\Project\\ssr-sub-rust\\target\\debug\\deps\\ssr_sub-a3844f7e60f402c1.2ieffgwanzamn4qq.rcgu.o" "E:\\Proje
ct\\ssr-sub-rust\\target\\debug\\deps\\ssr_sub-a3844f7e60f402c1.2oi57d4zas4oru5k.rcgu.o" "E:\\Project\\ssr-sub-rust\\ta
rget\\debug\\deps\\ssr_sub-a3844f7e60f402c1.2ppfbxobksus9gcr.rcgu.o" "E:\\Project\\ssr-sub-rust\\target\\debug\\deps\\s
sr_sub-a3844f7e60f402c1.2pwu2s179wb8x41c.rcgu.o" "E:\\Project\\ssr-sub-rust\\target\\debug\\deps\\ssr_sub-a3844f7e60f40
2c1.2uef3atwlail831k.rcgu.o" "E:\\Project\\ssr-sub-rust\\target\\debug\\deps\\ssr_sub-a3844f7e60f402c1.2wmikwuqzd1fctum
.rcgu.o" "E:\\Project\\ssr-sub-rust\\target\\debug\\deps\\ssr_sub-a3844f7e60f402c1.2zvf82f2wj2dtlsk.rcgu.o" "E:\\Projec
t\\ssr-sub-rust\\target\\debug\\deps\\ssr_sub-a3844f7e60f402c1.342qi39cohiq9869.rcgu.o" "E:\\Project\\ssr-sub-rust\\tar
get\\debug\\deps\\ssr_sub-a3844f7e60f402c1.34wqfhkolzk8keem.rcgu.o" "E:\\Project\\ssr-sub-rust\\target\\debug\\deps\\ss
r_sub-a3844f7e60f402c1.37rld56d7minhgpo.rcgu.o" "E:\\Project\\ssr-sub-rust\\target\\debug\\deps\\ssr_sub-a3844f7e60f402
c1.3ah8p37w3tnugvky.rcgu.o" "E:\\Project\\ssr-sub-rust\\target\\debug\\deps\\ssr_sub-a3844f7e60f402c1.3buovvj6idsv164y.
rcgu.o" "E:\\Project\\ssr-sub-rust\\target\\debug\\deps\\ssr_sub-a3844f7e60f402c1.45r36nbqgo0o1581.rcgu.o" "E:\\Project
\\ssr-sub-rust\\target\\debug\\deps\\ssr_sub-a3844f7e60f402c1.46px19d8i11g9dpu.rcgu.o" "E:\\Project\\ssr-sub-rust\\targ
et\\debug\\deps\\ssr_sub-a3844f7e60f402c1.4ei9le4kaqq27c72.rcgu.o" "E:\\Project\\ssr-sub-rust\\target\\debug\\deps\\ssr
_sub-a3844f7e60f402c1.4mn6k4lch65azhgz.rcgu.o" "E:\\Project\\ssr-sub-rust\\target\\debug\\deps\\ssr_sub-a3844f7e60f402c
1.52ttuv49s0wm1eti.rcgu.o" "E:\\Project\\ssr-sub-rust\\target\\debug\\deps\\ssr_sub-a3844f7e60f402c1.541t6qe55h1xqlmg.r
cgu.o" "E:\\Project\\ssr-sub-rust\\target\\debug\\deps\\ssr_sub-a3844f7e60f402c1.56hfhs7qpqkzr3hj.rcgu.o" "E:\\Project\
\ssr-sub-rust\\target\\debug\\deps\\ssr_sub-a3844f7e60f402c1.57dbxt7sknd8vrg4.rcgu.o" "E:\\Project\\ssr-sub-rust\\targe
t\\debug\\deps\\ssr_sub-a3844f7e60f402c1.59pijwsp4egpg02w.rcgu.o" "E:\\Project\\ssr-sub-rust\\target\\debug\\deps\\ssr_
sub-a3844f7e60f402c1.5b3vifhq4f7l3zqc.rcgu.o" "E:\\Project\\ssr-sub-rust\\target\\debug\\deps\\ssr_sub-a3844f7e60f402c1
.8zv0timj0896dqi.rcgu.o" "E:\\Project\\ssr-sub-rust\\target\\debug\\deps\\ssr_sub-a3844f7e60f402c1.9ole251ikol968n.rcgu
.o" "E:\\Project\\ssr-sub-rust\\target\\debug\\deps\\ssr_sub-a3844f7e60f402c1.bw46j6v7l0254o2.rcgu.o" "E:\\Project\\ssr
-sub-rust\\target\\debug\\deps\\ssr_sub-a3844f7e60f402c1.krbt87ev37rpsmo.rcgu.o" "E:\\Project\\ssr-sub-rust\\target\\de
bug\\deps\\ssr_sub-a3844f7e60f402c1.n9tsv2iyvxql737.rcgu.o" "E:\\Project\\ssr-sub-rust\\target\\debug\\deps\\ssr_sub-a3
844f7e60f402c1.slafqiivo4636dm.rcgu.o" "E:\\Project\\ssr-sub-rust\\target\\debug\\deps\\ssr_sub-a3844f7e60f402c1.vmh1jh
gzn2cq2ya.rcgu.o" "E:\\Project\\ssr-sub-rust\\target\\debug\\deps\\ssr_sub-a3844f7e60f402c1.z750xyh9hly7j9v.rcgu.o" "-o
" "E:\\Project\\ssr-sub-rust\\target\\debug\\deps\\ssr_sub-a3844f7e60f402c1.exe" "E:\\Project\\ssr-sub-rust\\target\\de
bug\\deps\\ssr_sub-a3844f7e60f402c1.2v3f77qnh0f6kj88.rcgu.o" "-Wl,--gc-sections" "-nodefaultlibs" "-L" "E:\\Project\\ss
r-sub-rust\\target\\debug\\deps" "-L" "D:\\Rust\\Cargo\\registry\\src\\mirrors.tuna.tsinghua.edu.cn-df7c3c540f42cdbd\\w
inapi-x86_64-pc-windows-gnu-0.4.0\\lib" "-L" "E:\\Project\\ssr-sub-rust\\target\\debug\\build\\backtrace-sys-a431b4f647
edf62f\\out" "-L" "D:\\Rust\\Rustup\\toolchains\\stable-x86_64-pc-windows-gnu\\lib\\rustlib\\x86_64-pc-windows-gnu\\lib
" "-Wl,-Bstatic" "E:\\Project\\ssr-sub-rust\\target\\debug\\deps\\libdirs-5823bc7f09291622.rlib" "E:\\Project\\ssr-sub-
rust\\target\\debug\\deps\\libdirs_sys-077ab72f8f57bcd0.rlib" "E:\\Project\\ssr-sub-rust\\target\\debug\\deps\\libwinap
i-cfdef71de770c40b.rlib" "E:\\Project\\ssr-sub-rust\\target\\debug\\deps\\libserde_json-aad127ddbde58f2e.rlib" "E:\\Pro
ject\\ssr-sub-rust\\target\\debug\\deps\\libryu-02e2226c4bace50c.rlib" "E:\\Project\\ssr-sub-rust\\target\\debug\\deps\
\libitoa-c2184fc85e8d4f08.rlib" "E:\\Project\\ssr-sub-rust\\target\\debug\\deps\\libbase64-e2471ed4aaa89351.rlib" "E:\\
Project\\ssr-sub-rust\\target\\debug\\deps\\libserde-13d17b410ea88c90.rlib" "E:\\Project\\ssr-sub-rust\\target\\debug\\
deps\\liberror_chain-31b6b1e011a65ccc.rlib" "E:\\Project\\ssr-sub-rust\\target\\debug\\deps\\libbacktrace-d91a6473b7cc9
e1d.rlib" "E:\\Project\\ssr-sub-rust\\target\\debug\\deps\\libbacktrace_sys-df64e9b190b4c447.rlib" "E:\\Project\\ssr-su
b-rust\\target\\debug\\deps\\liblibc-89997634662d0c87.rlib" "E:\\Project\\ssr-sub-rust\\target\\debug\\deps\\libcfg_if-
9aad1db24ad50a6d.rlib" "E:\\Project\\ssr-sub-rust\\target\\debug\\deps\\librustc_demangle-3f546688e87a2916.rlib" "-Wl,-
-start-group" "D:\\Rust\\Rustup\\toolchains\\stable-x86_64-pc-windows-gnu\\lib\\rustlib\\x86_64-pc-windows-gnu\\lib\\li
bstd-2709d4b440f1e31a.rlib" "D:\\Rust\\Rustup\\toolchains\\stable-x86_64-pc-windows-gnu\\lib\\rustlib\\x86_64-pc-window
s-gnu\\lib\\libpanic_unwind-a9004ff0947ef669.rlib" "D:\\Rust\\Rustup\\toolchains\\stable-x86_64-pc-windows-gnu\\lib\\ru
stlib\\x86_64-pc-windows-gnu\\lib\\libhashbrown-51ba26adca1c882c.rlib" "D:\\Rust\\Rustup\\toolchains\\stable-x86_64-pc-
windows-gnu\\lib\\rustlib\\x86_64-pc-windows-gnu\\lib\\librustc_std_workspace_alloc-845f51604911fcc4.rlib" "D:\\Rust\\R
ustup\\toolchains\\stable-x86_64-pc-windows-gnu\\lib\\rustlib\\x86_64-pc-windows-gnu\\lib\\libbacktrace-de041ab5ae3894b
3.rlib" "D:\\Rust\\Rustup\\toolchains\\stable-x86_64-pc-windows-gnu\\lib\\rustlib\\x86_64-pc-windows-gnu\\lib\\libbackt
race_sys-583b927240902ae3.rlib" "D:\\Rust\\Rustup\\toolchains\\stable-x86_64-pc-windows-gnu\\lib\\rustlib\\x86_64-pc-wi
ndows-gnu\\lib\\librustc_demangle-dc3974e5e5ee3f1e.rlib" "D:\\Rust\\Rustup\\toolchains\\stable-x86_64-pc-windows-gnu\\l
ib\\rustlib\\x86_64-pc-windows-gnu\\lib\\libunwind-93e1dea24f969698.rlib" "D:\\Rust\\Rustup\\toolchains\\stable-x86_64-
pc-windows-gnu\\lib\\rustlib\\x86_64-pc-windows-gnu\\lib\\libcfg_if-59c69470ac86444e.rlib" "D:\\Rust\\Rustup\\toolchain
s\\stable-x86_64-pc-windows-gnu\\lib\\rustlib\\x86_64-pc-windows-gnu\\lib\\liblibc-5fe3f715aad021c1.rlib" "D:\\Rust\\Ru
stup\\toolchains\\stable-x86_64-pc-windows-gnu\\lib\\rustlib\\x86_64-pc-windows-gnu\\lib\\liballoc-289552190fa6ddd0.rli
b" "D:\\Rust\\Rustup\\toolchains\\stable-x86_64-pc-windows-gnu\\lib\\rustlib\\x86_64-pc-windows-gnu\\lib\\librustc_std_
workspace_core-663fc4811d41d373.rlib" "D:\\Rust\\Rustup\\toolchains\\stable-x86_64-pc-windows-gnu\\lib\\rustlib\\x86_64
-pc-windows-gnu\\lib\\libcore-985f2d98a138c88e.rlib" "-Wl,--end-group" "D:\\Rust\\Rustup\\toolchains\\stable-x86_64-pc-
windows-gnu\\lib\\rustlib\\x86_64-pc-windows-gnu\\lib\\libcompiler_builtins-8d584b80572e52da.rlib" "-Wl,-Bdynamic" "-lw
inapi_advapi32" "-lwinapi_cfgmgr32" "-lwinapi_gdi32" "-lwinapi_kernel32" "-lwinapi_msimg32" "-lwinapi_ole32" "-lwinapi_
opengl32" "-lwinapi_shell32" "-lwinapi_user32" "-lwinapi_winspool" "-ladvapi32" "-lws2_32" "-luserenv" "-Wl,-Bstatic" "
-lgcc_eh" "-lpthread" "-Wl,-Bdynamic" "-lmingwex" "-lmingw32" "-lgcc" "-lmsvcrt" "-lmsvcrt" "-luser32" "-lkernel32" "D:
\\Rust\\Rustup\\toolchains\\stable-x86_64-pc-windows-gnu\\lib\\rustlib\\x86_64-pc-windows-gnu\\lib\\rsend.o"
= note: E:\Project\ssr-sub-rust\target\debug\deps\libbacktrace_sys-df64e9b190b4c447.rlib(alloc.o):alloc.c:(.text$__rb
t_backtrace_alloc+0x37): undefined reference to `__errno'
E:\Project\ssr-sub-rust\target\debug\deps\libbacktrace_sys-df64e9b190b4c447.rlib(alloc.o):alloc.c:(.text$__rb
t_backtrace_vector_grow+0xbf): undefined reference to `__errno'
E:\Project\ssr-sub-rust\target\debug\deps\libbacktrace_sys-df64e9b190b4c447.rlib(alloc.o):alloc.c:(.text$__rb
t_backtrace_vector_release+0x43): undefined reference to `__errno'
E:\Project\ssr-sub-rust\target\debug\deps\libbacktrace_sys-df64e9b190b4c447.rlib(posix.o):posix.c:(.text$__rb
t_backtrace_open+0x48): undefined reference to `__errno'
E:\Project\ssr-sub-rust\target\debug\deps\libbacktrace_sys-df64e9b190b4c447.rlib(posix.o):posix.c:(.text$__rb
t_backtrace_open+0x60): undefined reference to `__errno'
E:\Project\ssr-sub-rust\target\debug\deps\libbacktrace_sys-df64e9b190b4c447.rlib(posix.o):posix.c:(.text$__rb
t_backtrace_close+0x20): more undefined references to `__errno' follow
Hey,
What's your opinions on providing dummy implementation
(returning None) for platforms that are not Windows, Linux or OSX?
If you are positive to this I have a branch ready to do that and can create a PR!
Currently this crate doesn't build under WASI due to falling back to Linux for implementation, blocking WASI port of many popular crates.
How about stubbing out everything with None
or following the XDG spec for now?
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.