Ability to open a directory from within dua

[i2]

I was wonderig if it's possible to open a directory from within dua, with the default file browser? (thunar, nautilus, etc.)
This can also be extended to opening any file with the default application designated for that file within os.

[Byron]

If I remember correctly shift + O does the job. If not, shift + ? will list all keyboard shortcuts.

[i2]

Hi, thanks for the response. I tried Shift+o on a folder, a conf file, a txt file and a jpg/png file and none worked!

[Byron]

I just verified that shift + o, the letter, not the number, works as expected. It runs open::that on the currently selected item, directory or file alike.
If that doesn't work it might be related to the open crate not working as expected on the platform/OS it's running on - currently dua-cli squelches error messages so it would look like nothing happens. If you think this is the case here one could turn this into an issue to improve error reporting in this case.

[i2]

Apologies for my ignorance... Do I have to have rust-lang package installed for this open functionality to work? I'm assuming/hoping not!
I'm on Arch (without the by the way)

[Byron]

No additional program is needed. But in order to find out what's going on, you could indeed do the following:

git clone https://github.com/Byron/open-rs
cd open-rs
cargo run -- .

It will show errors if they occur.

[i2]

Well running that opens the folder in thunar no issues. Here's output:

 cargo run -- .
  Updating crates.io index
Downloaded pathdiff v0.2.1
Downloaded 1 crate (7.1 KB) in 0.61s
 Compiling pathdiff v0.2.1
 Compiling open v3.0.1 (/home/me/Downloads/tesssssssssssssssss/open-rs)
  Finished dev [unoptimized + debuginfo] target(s) in 1m 44s
   Running `target/debug/open .`
Opened '.' successfully.

Still no luck within dua itself!

[i2]

So if this is indeed an issue with dua-cli, please feel free to re-open this issue Byron/dua-cli#131.

[Byron]

Thanks for your help! Maybe you can help once more and see what happens if you run dua like this:

git clone --branch debug-open https://github.com/Byron/dua-cli
cd dua-cli
cargo run -- i

Then open something and see what's inside of the dua-open.dbg file it wrote into your current working dir.

[i2]

According to GitHub, I can't re-open that issue unfortunately until you do so (which I'd appreciate as it'll reduce clutter):
you cannot re-open your own issues if a repo collaborator closed them

dua-open.dbg is:
Ok(())Ok(())Ok(())

Initially, I thought my issue might be because I am using and older version of dua-cli (2.7.1), so I updated it to 2.7.7. This doesn't seem to be the issue. I have dua-cli standalone (d1) and dua-cli by above method (d2) run side-by-side browsing the same folder. Strangely, d2 functions normally whereas d1 still has same issue!

[i2]

I think I found what the issue is. I was running dua as sudo (I have an alias duai='sudo dua i'). Running without sudo acts as intended.

But still, I think even if you run dua as sudo, it should be able to Shift+open folders and files, no? There are times that I need to run as sudo.

[Byron]

Great detective work! Can you try open-rs with sudo to reproduce the issue? Probably you will. The problem then must be with the launcher programs that open-rs tries to run. You could run them by hand with sudo and see if there is anything special happening. In any case, this should be an issue in open-rs then, if my assumptions are correct.

[i2]

Here are the outputs for both running as normal and sudo:

└─ cargo run -- .
    Updating crates.io index
   Compiling pathdiff v0.2.1
   Compiling open v3.0.1 (/tmp/dua-debug/open-rs)
    Finished dev [unoptimized + debuginfo] target(s) in 17.94s
     Running `target/debug/open .`
Opened '.' successfully.
┌─(1)──(ray)──(me)──(04:37:59 PM)──(/tmp/dua-debug/open-rs)
└─ sudo cargo run -- .
[sudo] password for me:
    Updating crates.io index
  Downloaded pathdiff v0.2.1
  Downloaded 1 crate (7.1 KB) in 0.60s
   Compiling pathdiff v0.2.1
   Compiling open v3.0.1 (/tmp/dua-debug/open-rs)
    Finished dev [unoptimized + debuginfo] target(s) in 1m 51s
     Running `target/debug/open .`
Opened '.' successfully.

Note that, even though in both cases it says opened successfully, Thunar doesn't launch (if that's the desired behavior!).

Please let me know if more info is needed.

[Byron]

This sounds like neither in the sudo nor in the no-sudo case there is no observable effect despite it saying it opened successfully? Or does the no-sudo version bring up Thunar, but the sudo version doesn't?

I just tried this with debian 12 and fedora 34 and in both cases, sudo or not, it works as expected. In any case, open-rs just runs a set of standard 'open' programs and if one of these reports success, it assumes success. It looks like that's not reliable on all platforms.

If you want, you can try the open-programs in order yourself and see what happens. It's notable that I recently removed obtaining any stderr output and relying completely on the exit status. Maybe that's also an issue. As I am unable to easily virtualize Arch for ARM locally, I am unable to debug this further and would appreciate your support for a fix. Please feel free to open an issue in open-rs with your findings. Thank you.

[i2]

Similar behavior as expected. non-sudo opens Thunar but sudo doesn't, even though it reports as successful.

I will make a note to open an issue in open-rs. Thank you!