Create mimeapps.list if not already present

[Kabouik]

I was excited to see that cargo didn't complain about the architecture of my arm device when trying cargo install handlr, but unfortunately it doesn't work on it. The binary available on Github doesn't work either. Would it be relevant to add somewhere in the README or in the release names that handlr requires x86_64?

[chmln]

Hi @Kabouik are there any errors? What's not working?

[Kabouik]

Hey, here's the error I get from the binary installed with cargo:

Error: Io(Os { code: 2, kind: NotFound, message: "No such file or directory" })

And this is what I get with the release binary downloaded off Github:

bash: ./handlr: cannot execute binary file: Exec format error

I thought they both look like architecture errors. This is in a LXC container running Debian Sid (arm64).

[chmln]

@Kabouik the first one definitely looks like it could be solved. Could you try doing this:

touch ~/.config/mimeapps.list

and running handlr again?

[Kabouik]

Oh, that was it! Now I can show handlr --help and probably use the core features too.

Shouldn't handlr create the file if it doesn't exist already? Note that I don't really know why that file was not here in the first place, I thought it was standard (but I don't understand anything about mime standards to be honest, that's why handlr really makes my life easier).

On 2020-07-12 23:27 Gregory notifications@github.com wrote:

@Kabouik the first one definitely looks like it could be solved. Could you try doing this:

touch ~/.config/mimeapps.list

and running handlr again?

--
You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: https://github.com/chmln/handlr/issues/14#issuecomment-657277771

[chmln]

Shouldn't handlr create the file if it doesn't exist already? Note that I don't really know why that file was not here in the first place, I thought it was standard

Yes, it definitely should. I guess I never thought about a case when it doesn't exist :laughing:

[Kabouik]

It's a LXC container, maybe that's the reason? Though I don't really see why it wouldn't have file associations set there by default.

I found a non-empty /usr/share/applications/mimeinfo.cache, would it make sense to copy its content inside the newly created ~/.config/mimeapps.list? handlr currently sees no default association at all since the file is empty.

On 2020-07-12 23:45 Gregory notifications@github.com wrote:

Shouldn't handlr create the file if it doesn't exist already? Note that I don't really know why that file was not here in the first place, I thought it was standard

Yes, it definitely should. I guess I never thought about a case when it doesn't exist :laughing:

--
You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: https://github.com/chmln/handlr/issues/14#issuecomment-657280049

[siesing]

Yes, it definitely should. I guess I never thought about a case when it doesn't exist

Vanilla Arch is such an example, @chmln :+1:

[chmln]

Fixed in v0.5