dirs-dev / dirs-rs Goto Github PK

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

Rust 100.00%

xdg-basedir xdg-user-dirs knownfolders

dirs-rs's People

Contributors

Stargazers

Watchers

dirs-rs's Issues

(Not really a bug) option-ext used in dirs-sys adds an MPL license requirement

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!

Add support for `XDG_STATE_HOME`

As mentioned in spacekookie/rfcs#1, it seems people have finally managed to add it to the spec.

Fail to build on MacOS

   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`

does not work with rustc 1.13 as documented

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.

Windows/Cmder

Rust works very well on Cmder. Would you be open to supporting this environment?

template_dir() for MacOS

I found this directory under MacOS: /Library/User Template

open "/Library/User Template"

Does MacOS have a template directory like Windows?

Windows: Add fallback for nanoserver Windows containers

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:

Windows Nanoserver container:

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

Windows Server Core container:

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

Windows Server 2019 (without containers)

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

Windows 10 (without containrs): registry key doesn't exist

Redox

New major release?

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.

Honor XDG variables on MacOS

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.

gcc error while testing

Toolchian : stable-x86_64-pc-windows-gnu
OS: Windows 10
rust version: 1.42.0
dirs version: 2.0
error-chain version: 0.12.2

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

XDG_BIN_HOME isn’t a standard

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.

Add default values for `$XDG_DOWNLOAD_DIR` and such

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.

Add better descriptions as to what causes None to be returned.

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.

Thoughts on testing `dirs::config_dir()` on Windows?

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).

WASI support?

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?

API review: return types

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 Options would be pretty bad, because these function can't fail on MacOS or Windows.

Question/Feature `Return error instead of compiler-error on non-supported platforms`

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!

MacOS $XDG_*

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 🙂.

sudo and $HOME

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"?

Prefer $HOME (and XDG environment) even on Windows

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?

wasm-pack support missing.

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

Remove cfg-if

Related discussion #32

Please add a crates.io co-maintainer

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.

Mac dirs don't use correct APIs to look up names

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.

use XDG_STATE_HOME as data_local_dir

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.

data_dir return path in macos 14.3 is wrong

development evn：

macos 14.3
rustc 1.74.0 (79e9716c9 2023-11-13)

data_dir return the path is /Users/lixu/Library/Application Support， but the path is not exist. there is a dir named ~/Library/ApplicationSupport in my mac .

Builds fine on macOS with rustc 1.13

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.

Android

specifically, Termux

would you be open to including this?

Systemd Service Directories

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 │
           └────────────────────────┴────────────────┴───────────────────────┴──────────────────────────┘

Incorrect `config_dir` on Windows 10

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.

Windows font_dir

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?

Better Integration for Testing

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.

[Windows] Add user writeable fonts folder

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:

dirs-dev / dirs-rs Goto Github PK

dirs-rs's People

Contributors

Stargazers

Watchers

Forkers

dirs-rs's Issues

Recommend Projects

Recommend Topics

Recommend Org