-
-
Notifications
You must be signed in to change notification settings - Fork 661
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Unable to determine time zone: Is a directory (os error 21) #712
Comments
Do you still have this error with exa 0.10.1? If yes, I would like to know more about how it works on Linux Bedrock. Also, you can try to use the TZ environment variable (see #725). Edit: I found these Configuration instructions but I don’t understand everything. |
TL;DR Bedrock will apparently set both |
Also... @ariasuni I should mention this: I'm on Exa 0.10.1 and still receive this error (on WSL + NixOS). My $TZ is set, although /etc/timezone does not exist (just Nix things). |
Please copy the content of your I looked at how exa is handling the |
I cannot vouch for Bedrock, as I do not own a Bedrock system and have only dabbled in contributing in the project, but here's some results from my side:
I should note the following:
|
The problem with NixOS is that they’re using In the meantime, I believe you can workaround this by setting
I just don’t understand how’s that supposed to happen. glibc and musl expects |
I can confirm that setting TZ=:/etc/localtime I am getting this error as well (with /etc/localtime being a symlink to /etc/zoneinfo/Europe/Copenhagen in my case). Even if I set TZ=Europe/Copenhagen or TZ=:/etc/zoneinfo/Europe/Copenhagen, I still get errors using |
I have the issue on both 0.10.1 and building from master. On my nixos system:
TZ is not set by default, this is a workaround for this firefox issue: NixOS/nixpkgs#238025. Unsetting TZ fixes the issue. Although from the glibc docs it should work, since it is equivalent to the default setting which points to /etc/localtime:
The current code at Line 342 in f039202
does not seem to handle the case where TZ starts with a ":" and is an absolute path. fn determine_time_zone() -> TZResult<TimeZone> {
if let Ok(file) = env::var("TZ") {
TimeZone::from_file({
if file.starts_with('/') {
file
} else {
format!("/usr/share/zoneinfo/{}", {
if file.starts_with(':') {
file.replacen(':', "", 1)
} else {
file
}
})
}
})
} else {
TimeZone::from_file("/etc/localtime")
}
}
I think that would only matter if TZ is a timezone string like "TZ=America/Sao_Paulo", if it is an absolute path to a file it shouldn't matter. https://docs.rs/datetime/0.5.2/datetime/fn.sys_timezone.html doesn't seem to handle the TZ env var. This seems to work for me, strip the ":" from the beginning, then use absolute paths as is or else use TZDIR if it there: diff --git a/src/output/table.rs b/src/output/table.rs
index 06e13b9..1221775 100644
--- a/src/output/table.rs
+++ b/src/output/table.rs
@@ -341,17 +341,17 @@ impl Environment {
#[cfg(unix)]
fn determine_time_zone() -> TZResult<TimeZone> {
if let Ok(file) = env::var("TZ") {
+ let file = if file.starts_with(':') {
+ file.replacen(':', "", 1)
+ } else { file };
TimeZone::from_file({
if file.starts_with('/') {
file
} else {
- format!("/usr/share/zoneinfo/{}", {
- if file.starts_with(':') {
- file.replacen(':', "", 1)
- } else {
- file
- }
- })
+ let mut str = env::var("TZDIR").unwrap_or_else(|_|String::from("/usr/share/zoneinfo"));
+ str.push('/');
+ str.push_str(&file);
+ str
}
})
} else { Or just merge #867, it's probably simpler than handling it here. |
Closing this, since exa is unmaintained (see #1243), and this has (finally 🎉) fixed in the active fork eza! |
My localtime is linked to directory... it is not a file.. this is as I am using a lnux called Bedrock.
Is there anyway I can define the timezone with a --command I can add to the alias... or something like that?
I can not seem to relink the file directly to the actual local file due to how bedrock works. So I was wondering if there was a way I can force exa to use a specified path to localtime?
The text was updated successfully, but these errors were encountered: