'notes o' says it can't get a file descriptor on Linux

[rmNULL]

Issue Summary

notes o doesn't open a directory as expected to.

Steps to Reproduce

1. notes o

Couldn't get a file descriptor referring to the console

Apparently, open command gives the same error message, on the device I tried.
In another device, $ notes o reports "open: command not found"

Technical details:

• notes version: master

P.S:
If output of any relevant commands will help, let me know. I'll be glad to paste it here.

[primis]

Could you output the result of the EDITOR variable? echo $EDITOR should do the trick. I have a feeling that this is due to you having editor set to a GUI editor or some weird default on the raspi.
Also, is your notes configuration the default one? if not please include that in your reply

[rmNULL]

$EDITOR is set to nvim
btw notes n works fine , so the case when notes o is passed a filename.
e.g: notes o ca.sh open a file.
but notes o gives the error message shown above.

2. Yes I use the default configuration.

Relevant? https://unix.stackexchange.com/questions/253376/open-command-to-open-a-file-in-an-application

[pimterry]

Huh, interesting. That stackexchange answer is very useful. As far as I can tell this has never worked in linux, as it expects open to be the OSX command (which opens the file with the default handler), but open on most (all?) Linux OSs is a totally different thing.

We need to somehow fix that. A few options:

• Build a list of options (xdg-open, open), call the first one that exists
  • Works well for this basic case
  • I'm not sure xdg-open is guaranteed to exist though, so there'll still be some cases where this doesn't work
• Check the OS we're running in, and call the expected command
  • Open for OSX
  • xdg-open for Linux
  • ??? for Windows
  • Results in nice clear error messages if you don't have an easily supported system, and we can easily add extra fallback options later.
• Just remove this functionality entirely
  • It is sometimes useful, but also a little odd that we integrate with the local GUI file manager in this otherwise very CLI-focused tool
• Add a new config variable for the name of the file browser you want
  • Feels like overkill

I think I'm leaning towards the 2nd option. Thoughts?

[rmNULL]

I would prefer the 2nd option, we would also need to consider for BSD devices. I'll make a draft pull request. Throw in your suggestions.

edit:
Windows - start.exe

[Escyll]

I might be late to the party here. There is a charm to the 4th option as well. On command-line I like to use the ranger file manager, but for UI related stuff I use dolphin as my file manager.
However, I think that option 2 and 4 are orthogonal to each other: Having an option to overrule a, in 90% of the cases, good default (like xdg-open, open and start.exe).