"sudo -E" breaks things #257
Comments
|
Can you check the permissions on |
|
Aaaah, I think it was my use of |
|
Oh, I bet that would do it. At a bare minimum we can make the error a little more self-explanatory but it would be nice for |
mxmilkiib
changed the title
Result::unwrap() ... "Permission denied"
|
Thanks for reporting the issue and helping us dig into it 😃 That error message indeed was bad. I've made a PR that cleans up that unwrap and generally improves error handling (#258). With that pr, the error would be: That improves one part of this. There could be something to do for avoiding this specific cause of wrong permissions in the first place though. The options that come to mind are:
For a little more context on what I mean by 3, pazi updates I think 2 isn't really an option. 1 and 3 both have their points to them, but 3 seems easy enough and like it would have avoided the problem described in this issue quite neatly. I think I've talked myself into 3 being the right option actually, so if that makes sense, I think we can implement that change to fix this |
|
I agree that 3 sounds like what you'd expect to happen anyway, not terribly difficult to implement, and unlikely to do the wrong thing unless you have some very unusual circumstances. |
258: *: improve error messages r=euank a=euank
This switches things over to anyhow for many (but not all) of our
errors, and removes the use of unwrap from database loading.
Here's the before and after for an error opening the frecency database:
Before:
```
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Os { code: 13, kind: PermissionDenied, message: "Permission denied" }', src/frecent_paths.rs:43:29
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
```
After:
```
could not open pazi frecency file: "/home/user/.config/pazi/pazi_dirs.msgpack"
Caused by:
Permission denied (os error 13)
```
I think it looks much nicer with this :)
The main things that weren't switched over are the things that are using specific error variants. For those, we'll probably want to have a thiserror layer that gets wrapped in any anyhow error, and then downcast at callsites.
I want to deal with that separately.
This improves #257 in that it significantly improves the error message.
Co-authored-by: Euan Kemp <euank@euank.com>
258: *: improve error messages r=euank a=euank
This switches things over to anyhow for many (but not all) of our
errors, and removes the use of unwrap from database loading.
Here's the before and after for an error opening the frecency database:
Before:
```
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Os { code: 13, kind: PermissionDenied, message: "Permission denied" }', src/frecent_paths.rs:43:29
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
```
After:
```
could not open pazi frecency file: "/home/user/.config/pazi/pazi_dirs.msgpack"
Caused by:
Permission denied (os error 13)
```
I think it looks much nicer with this :)
The main things that weren't switched over are the things that are using specific error variants. For those, we'll probably want to have a thiserror layer that gets wrapped in any anyhow error, and then downcast at callsites.
I want to deal with that separately.
This improves #257 in that it significantly improves the error message.
Co-authored-by: Euan Kemp <euank@euank.com>
258: *: improve error messages r=euank a=euank
This switches things over to anyhow for many (but not all) of our
errors, and removes the use of unwrap from database loading.
Here's the before and after for an error opening the frecency database:
Before:
```
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Os { code: 13, kind: PermissionDenied, message: "Permission denied" }', src/frecent_paths.rs:43:29
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
```
After:
```
could not open pazi frecency file: "/home/user/.config/pazi/pazi_dirs.msgpack"
Caused by:
Permission denied (os error 13)
```
I think it looks much nicer with this :)
The main things that weren't switched over are the things that are using specific error variants. For those, we'll probably want to have a thiserror layer that gets wrapped in any anyhow error, and then downcast at callsites.
I want to deal with that separately.
This improves #257 in that it significantly improves the error message.
Co-authored-by: Euan Kemp <euank@euank.com>
Not sure what I've maybe done or what has changed, but I'm getting this message when pazi runs;
The text was updated successfully, but these errors were encountered: