Non-zero error code upon regularly exit

[tbreslein]

Hi,
just a small thing that I saw when playing around with it. When I exit xplr, it returns a non-zero error code, and writes Error: terminated into stderr. Guessing this is just a bug, because it would actually mess with scripting and piping, if you want to only continue the script if the error code is zero.

So, to summarise:

Expected behavior:
Expected the error code for a regular exit (hitting q, ctrl-c, or esc) to be 0.

Actual behavior:
Error code is non-zero.

Additional info:
Fresh Arch-Linux
Freshly built the app from source through the AUR xplr-git package

[sayanarijit]

Hi
Actually non-zero exit code is the regular behavior

➜  sleep 100
^C
➜  echo $?
130 

Also, the same with fzf (press ctrl-c or esc)

When exiting xplr, I want it to return a printable string as the result.
Else, I want it to fail.
Although, whether the result string should only be a (list of) path or any string may be debated.

But yes, the Error: terminated error message can be a little annoying, and I'll probably remove the message in the future.

[sayanarijit]

Hi, hopefully the concern was answered. Closing this issue.

[maximbaz]

Hello @sayanarijit, I would agree that default behavior makes sense and is inline with fzf and other apps, however it can be useful to have a command for an exit with exit code 0 in addition to the default Terminate command that we could bind ourselves.

One example I can give you is I'm using nnn in a script that is reviewing installation files in a directory, so the script opens in a directory with several installation files, I will preview / edit them, review the contents, etc, and if I'm happy I'm closing nnn with exit code 0 and installation begins, otherwise I'm closing nnn with non-zero exit code and installation aborts.

I guess I could just find a random regular file and press Enter for it, but it's just not nice 🙂

For this scenario, nnn added q and Q bindings. We don't have to have two bindings by default, but having an option to do so would be nice.

And +1 for removing Error: terminated message 🙂

[sayanarijit]

Ah now with the use case, 0 exit without output seems valid.

[sayanarijit]

I think we can map 'q' to successfully quit without result and ctrl+c to terminate with error.