Nnn: ToDo list

[jarun]

Rolled from #386.

For next release

• [x] program option -e replaces NNN_USE_EDITOR
• [x] program option -t replaces NNN_IDLE_TIMEOUT
• [x] use umount on macOS to unmount
• [x] confirm and try lazy unmount when regular unmount fails
• [x] quit with error code on Q
• [x] additional key F5 to toggle hidden
• [x] fix crash on entering empty dir, then Down
• [x] add glow as Markdown viewer in nuke

Proposed features and tasks (up for grabs)

• [ ] take list of files as input and show
• [ ] add PCRE code within a macro and add Makefile target to compile with PCRE library (sample code)
• [ ] support pre-defined filters like bookmarks
• [ ] Cygwin package
• [ ] update the nnn.vim plugin to show a persistent bar (https://github.com/mcchrish/nnn.vim/issues/46)
• [ ] a video exploring nnn plugins

Anything else which would add value (please discuss in this thread).

List of completed features and tasks.

[ghistes]

My absolutely biggest usability problem at the moment is that I search, don't find what I want and press "up" to access the search history.

In nnn this means that you don't access the search history but move up in the file-list, the status bar is displayed again and your previous search-term is gone for good.

So a big gain for me would be for nnn to at least remember the last search item, so you could search, see what you find, move around, and then maybe slightly tweak your search without having to retype everything. It would be even better if maybe the last 5 items or so could be kept - maybe even saved to disk so that they would be accessible again after a restart.

I don't know if the string-search as it currently works is intended to work across directories, because I could live very well with typing "/" to start a search, then if the next char is again a "/" it will be a regex search (which should be case-sensitive as you can build case-insensitivy into the regex if you want it) and if not it's a string.

So "/hubba" would search case-insensitive for "hubba", while "//h[0-9]{2}" would regex-search for a lower-case h followed by 2 digits. If I also wanted to include upper-case "H", I would simply do "//[hH][0-9]{2}"

I would not really need all the powers of pcres, that would be silly in a file manager, but to be able to search for patters of digits and letters in a simple way would be very handy - so I would like to have things like "d" or "w" etc.

One idea would be to allow occurances of d in a typed-in regex and then translate this regex into a POSIX-compatible version.

That would mean a user could type in "//d{2}-d{2} and nnn would in a first step replace all occurances of "d" with "[[:digit:]]" before it's handed over to the regex-library.
In that way there would be no real need for a pcre-engine, while still having the benefit of being able to express pattern is a succinct way suitable for typing in (I do want to search for digits, but I do not want to type "[[:digit:]]" every time).

[ghistes]

Oh - to your idea about triggering case-sensitivtiy via capital-letters - I think that's not bad.

"/hubba" => case insensitive
/"Hubba" => case sensitive

So how would I search for an all-lower case word in a case-sensitive way?

If regexes would be case-sensitive (as I proposed above) and started with "//" you simply do

"//hubba"

All cases covered I believe.

[jarun]

@ghistes I have added the line items. These are up for grabs now. If possible, please get your hands dirty with the code, understand how it is today and raise PRs.

[jarun]

The last filter is remembered at commit 0e203288b4662c7781a2c5fc519da219f9eb7403.

[jarun]

@ghistes I sent you 2 invites - for nnn collab and dev-discussions. Can you please join? I want to share the notes I was talking about.

[jarun]

@ghistes

maybe slightly tweak your search without having to retype everything

is not possible without redesigning search. Filters are _search as you type_ - you type the next char and the scan happens. This also helps in having a very efficient algorithm wrt. performance. So if you wanna come back, you have to delete chars and come back. Another advantage is the left and right key work as they should in normal mode.

I don't know if the string-search as it currently works is intended to work across directories,

No, it's not. We can have what you are proposing with some modification I guess.

One idea would be to allow occurrences of d in a typed-in regex and then translate this regex into a POSIX-compatible version.

This is hacky. Tomorrow there might be another case. I wouldn't want to parse and modify input provided by users. That warrants documentation and may take users by surprise. Compiling in the PCRE lib option is really not that scary. Probably give it a shot yourself.

Oh - to your idea about triggering case-sensitivtiy via capital-letters - I think that's not bad.

It wouldn't work. Say the string is "abcDeF". If you erase F and come back the logic would need to scan the whole string to determine case-sensitivity. I think the best is to have a toggle.

Similarly I think it would be best to have a toggle like \ to enable regex filter.

[jarun]

regex and string toggle is implemented at 8588b3f0bd39496dbcf481c31aa7a61d7e6df20a.

[jarun]

Toggle filter case-sensitivity is implemented at 70dcbf43d786da63598ad1080c518e4c44baa7bd.

[ghistes]

Wow, quick progess again. This is really getting very useful very fast.

There seems to be a little bug (or at least an inconsistent behaviour) with the history:

Press "/" to search. Then enter "n". Files are filtered. Press backspace. Filter is now empty, all files are visible. Press backspace again. Filter-prompt is replaced with status-bar. Press "/" to search again. Now "up" to access history (should either result in an empty filter or "n", depending on whether an empty search should go to history) but what happens is that the filter-prompt is closed and instead a file is selected.

So sometimes "/" + "up" accesses history and sometimes not.

I would want predictable behaviour. When you are in the prompt for a filter "up" should never leave this prompt. When the history is empty then simply nothing should be done.

The current key-bindings have a certain logic, but please keep in mind that "" and "|" are both a bit awkward to enter on non-us keyboards.

What I ultimately would like to have is remembering maybe 5 history-entries, so you could easily re-run previous searches.

But to do that the history would need to remember not just the filter-expression but also how to interpret them (ie if they should be seen as string or regex, and with what sort of sensitivity).

At the moment (as far as I understand it) the modes seem to be a state not of the individual filter, but of nnn.

So if I do a regex-search and then a string-search (assuming I had more than one history) and then wanted to repeat the regex-search I would have to change the mode first - recalling the history would not be enough.

Ideally I would like to have something like booksmarks for filter, where I could specify a specific filter including all the modes, eg. "=|hubba" to mean a case-insensitive string search for hubba or "/-abc[0-9]*" to mean a case-sensitive regex-search and associate such filter-expressions with a key (like the regular bookmarks) so that these filters could be accessed very fast.

Finally I started to look at the code a little bit and noticed that the dependency on dbg.h is missing from the Makefile and that in the DPRINTF_D-macro there seems to be a spurious __LINE__ at the end that is absent from the other debug-macros.

Do you want a PR for that?

[jarun]

@ghistes please join the nnn-dev discussion.

[jarun]

There seems to be a little bug
Press backspace again

The filter is gone.

should either result in an empty filter
So sometimes "/" + "up" accesses history and sometimes not.

The filter is empty, meaning there is no filter in history, so the Up arrow's original behaviour picks up. It's the correct behaviour.

I would want predictable behaviour.

Yes, you should predict and expect that when you erased the filter with backspace, the filter is gone. ;) Let's word it this way - the Up arrow shows the last filter if one exists.

The current key-bindings have a certain logic, but please keep in mind that "" and "|" are both a bit awkward to enter on non-us keyboards.

Suggest alternatives. I changed | to :.

What I ultimately would like to have is remembering maybe 5 history-entries, so you could easily re-run previous searches.
Ideally I would like to have something like booksmarks for filter, where I could specify a specific filter including all the modes, eg. "=|hubba" to mean a case-insensitive string search for hubba or "/-abc[0-9]*" to mean a case-sensitive regex-search and associate such filter-expressions with a key (like the regular bookmarks) so that these filters could be accessed very fast.

Yes. Maybe a better option is to add custom filters with a keybind and use the same keybind to add a filter when the prompt is empty.

But to do that the history would need to remember not just the filter-expression but also how to interpret them (ie if they should be seen as string or regex, and with what sort of sensitivity).

We are talking about a structure with a char pointer and 2 bools here.

Do you want a PR for that?

I had something to push. To removed the spurious arg. Leave the Makefile dep. Not super-important.

[jarun]

Ideally I would like to have something like booksmarks for filter

Should they be pre-defined in your rc file or you would dynamically add and forget during a run? Maybe we can have 5 fixed and 5 dynamic?

[jarun]

Should they be pre-defined in your rc file or you would dynamically add and forget during a run? Maybe we can have 5 fixed and 5 dynamic?

Forget I asked. Maybe we are over-complicating this thing with filtering.

@0xACE @KlzXS @annagrram what do you think?

[ghistes]

Ideally (for christmas maybe?) I would like to have nnn remember the last 5 seaches/filters.
They should be persisted to a file so they survive a restart.

Also I would like to define searches/filters in the same way as bookmarks work today - every one
assigned to a letter via an enviroment variable.

When the search-prompt is open you should be able to navigate through the history with up and down keys.

And there should be a way to fast-acess them by having some hot-key where

+ : run the bookmarked filter associated with
+ : run the n-th last filter from the history.
+! : run last filter again (probably after navigating to a new dir)

Also I would like to have a way to edit the filter-prompt so you can iteratively build expressions.
At the moment all I seem to be able to do is to delete a character from the end and append to the end. So e.g. modifying a regex in the middle is hard work. Maybe some toggle to change the left-right keys from selecting files/dirs to move within the search-expression?

What I am striving for would be a workflow where you open nnn. Go to a bookmark. Run a pre-defined filter (eg list all log-files) with two keystrokes. Then you realise you've got the wrong dir. No problem. You navigate to the proper dir and just re-run your search with two keystrokes. etc etc etc

But clearly this won't happen overnight any maybe you have a different vision...

[ghistes]

And if I delete all chars from a filter I still have a filter (it's the emtpy filter showing all files).
So if I delete all the chars from a filter the last history-entry is this - the empty filter.
And when I then search the history it's not that there is no history.

What I am trying to say is that when you're in the search-prompt and press "up" you should NEVER select a file as (conceptually) the history is never empty.

I really dislike the behaviour that my search-history determines what happens when I press "Up".
I don't want to remember what I did before in oder to predict how the app will behave.

But it's a big step forward as it is.

[KlzXS]

Regarding getting list of files as input. Is it final that we create a subtree with symlinks in /tmp?

I wanted to discuss what we get for input. Does the user give absolute or relative paths, if absolute, do I assume that they point to something in the subtree of the current working dir i.e. relative paths but with cwd as prefix? Also can I assume that the paths don't contain /./, /../ and multiple slashes?

[jarun]

I think the tmp dir is the simplest solution. Note that the symlinks may point across volumes. We need to handle that.

Regarding absolute and relative, there can be a mix. We already handle that in main().

[KlzXS]

We already handle that in main().

What do you mean we already handle it?
My main concern is how should the tree in tmp look like. Say I get the following:

/a/b/c/d
/a/b/c/e
/a/b/c/f

Should I make a dir and put symlinks to d, e and f, should I make a dir c and in it make links to the files, should I go even higher? I would need to assume that they are pointing to something in the subtree of the cwd in which case just skip cwd prefix and pretend they are relative paths.

[jarun]

Okk, put symlinks to d, e, f in the same dir.

[KlzXS]

Ok. I'll make minimal assumptions and we'll see how it behaves.

[jarun]

I'll make minimal assumptions and we'll see how it behaves.

It should work. Because in this particular mode, for each file we will stat with follow_symlink and get the details of the target file.

[KlzXS]

It will. How does this sound:

• Get input from file
• Normalize input using a custom realpath() implementation (call it xrealpath()) that doesn't resolve symlinks
• Find the longest common prefix of all paths
• Make the tmp dir structure

I don't like the second point, but I don't like resolving symlinks even more, because that would make the result look confusing.

[jarun]

Find the longest common prefix of all paths

How does this help?

[KlzXS]

Say I have

/a/b/c/d/e
/a/b/c/f
/a/b/g

I would display the following

c/d/e
c/f
g

I could display everything, but I think this way is more compact and straight to the point.

[jarun]

Sounds good to me!

[jarun]

Some notes on the algos to avoid re-work (you can suggest better ones, of course):

I think to get the common path you'll use an algo like:

get first file and take it's dirname, get second one, see how far they match (I am not sure if there's an API to do that already) and now this is you minimum common. Match third file's dirname with minimum common and so on...

In case there's no API to find matching parts of strings, check xstrlcpy() code. We can use sizeof(long) byte comparisons at a time to find the first non matching 4 or 8 bytes and then XOR and get the offset to the first non-zero byte. It must follow a /.

[KlzXS]

Where should we draw the limit to the size of input? I need to allocate some memory for the input, but how much the first time, and when do I stop and say that's too much?

I think we can start with 256 paths which translates to 1MiB, and go up to 2¹⁶, which is 256MiB. If you need more than that you probably know how to use xargs.

What do you think?

[jarun]

Chunks of 4Kb would be fine with 0 gap. See dentfill on how we do this for file names today.

[jarun]

Ahh OK. The input. I think we should go in steps of 512 KB.

[KlzXS]

Ok. Do we put an upper limit or do we let it allocate until it crashes the system. I think 2¹⁶ paths is enough.

[jarun]

2^16 is more than enough!

[KlzXS]

I noticed there are like 3 occurrences of malloc() which are not checked for NULL. Will you take care of this or should I? They are in archive_selection(), get_kv_val() and setup_config().

[jarun]

Will you take care of this or should I?

Please take care. :)

[jarun]

Please raise this PR separately. We can have it for next release.

[maximbaz]

Idea: ability to exit nnn with non-zero exit code.

I have a real-world use-case that I'd like to try out in nnn (where I currently use vifm for this), and it requires both take list of files as input and show (so I would be interested to test a PR when it's ready) as well as ability to exit file manager with non-zero exit code.

Without going too much into details for now, an ability to exit file manager with non-zero exit code allows me to flag if I successfully completed or aborted the task I was doing.

vifm is a lot like vim in terms of key bindings, so :q means "exit vifm with exit code of 0" and :cq means "exit vifm with exit code of 1". I don't particularly have an opinion whether this should be a separate hotkey or something else (we already have 3 different flavors of "quit" functionality...), open for ideas and proposals.

[jarun]

@KlzXS is already working on the list of files input. Please discuss with him.

[maximbaz]

Yeah I know, that's why I wrote I would he interested to test the PR 🙂 What do you think about the idea of non zero exit codes though?

[jarun]

non 0 - raise a PR please!

[jarun]

@maximbaz I am considering replacing the config NNN_USE_EDITOR with a program option -e. Generally people use nnn with aliases and reading an env var is costlier than checking an option. What do you think?

[jarun]

I am looking for areas to reduce startup time.

[jarun]

Similarly -t can replace NNN_IDLE_TIMEOUT.

[maximbaz]

you are right about people using aliases, I do that too, and yes to be honest I do find it a bit unusual that some nnn options are configured via env variables and others via cli args.

I would support replacing some env variables with cli flags.

Let me ask this: why not replace ALL env variables with cli arguments?

[jarun]

There is a specific cases where we do not want data loss - NNN_TRASH.

The longer ones (strings) I want to keep as env vars. Users may find it intimidating they have to type a long option to do something. The alias is not always obvious to newbies.

[jarun]

For now, can you raise a PR for -e and -t? I have to go to sleep.

Notes:

• the man page needs to be updated
• usage() too

[maximbaz]

I can think of the opposite example, when you create a nnn.desktop as described on wiki, for many people this instance of nnn will not respect environment variables (users must know that they should these env variables not in .bashrc but in e.g. /etc/environment to have effect on nnn started as GUI app), and in this case data loss is very possible. When there only are cli arguments, users know they must pass them, no accidents like that can occur.

I unfortunately forgot my laptop at the office, I'm writing from phone, unable to contribute tonight... But yeah let's pick this up tomorrow!

[jarun]

That's a good point. But let's document that. It's a one time setting for a system. There are instances where people may run nnn as nnn without an alias.

[0xACE]

I have been away for about a month, and geez a lot of things happened while I was gone.

I try to keep up with master all the time (referring to you asking us to use the master branch), but I run my personal changes ontop of it.

I just spent the last 30minutes rebasing ontop of the latest version. and seems like a lot of keys has been changed. I was in particular not happy with the removal of:

1. SEL_RUNEDIT - used to edit rather than executing files
2. SEL_RUNPAGE - used to quickly view text files
3. SEL_EXEC - execute files which may be defaulted to another action (commonly done on sh scripts in my case)

I tried to skim through the discussion happening. I think KlzXS mentioned the changing of keys being a annoyance, and i agree.

But I would also like to add the changing of command line arguments nnn takes being annoying. Because that also requires me to update all my machines that use nnn: because they have their own wrapper script writing over nnn defaults.

Only my main machine runs on master, my other machines are based on the build from december last year, as i cba to update the commandline parameters on each machine (as my other machines dont have mvg/cpg i have to maintain a seperate config). and I'm dropping nnn.vim on my machine because it also needs another update because of this (though mostly over the past 6 months I have never used any thing to open files in vim other than :e, gf and various tag-jumping method...)

I'm still working on rebasing my personal branch ontop of master and will have to give a long term review at a later point. as I still haven't got my nnn environment restored...

[jarun]

Don't worry! These are convered. Only with more regular workflows.

Runedit and runpage can be easily achieved through run cmd as plugin. I have updated the plugin docs with your use-case in mind - https://github.com/jarun/nnn/tree/master/plugins#some-useful-key-command-examples

I am using EDITOR that way myself with ;e.

SEL_EXEC - did you try "./$nnn" at the prompt?

But I would also like to add the changing of command line arguments nnn takes being annoying

This has also been addressed and frozen in #422.

I'm dropping nnn.vim on my machine because it also needs another update because of this

Do you mean the plugin needs a change? Then @mcchrish should be informed right away.

[0xACE]

Don't worry! These are convered. Only with more regular workflows.

Runedit and runpage can be easily achieved through run cmd as plugin. I have updated the plugin docs with your use-case in mind - https://github.com/jarun/nnn/tree/master/plugins#some-useful-key-command-examples

I am using EDITOR that way myself with ;e.

Ah, my dumbass just got into the seat cold and started tinkering on things, ofc a plugin can do that... Alas as I have made another patch for it. i'm maintining it as seperate until i grow tired.

SEL_EXEC - did you try "./$nnn" at the prompt?

That's too many characters to hit for something i use commonly, i guess a plugin keystroke would do it better. but again I'll maintain this locally until i grow tired.

But I would also like to add the changing of command line arguments nnn takes being annoying

This has also been addressed and frozen in #422.

Yeah, i tried to read that thread but as my time was limited with all the catching up i had to do i couldn't read it through and through...

I'm dropping nnn.vim on my machine because it also needs another update because of this

Do you mean the plugin needs a change? Then @mcchrish should be informed right away.

Well I have this in my ~/.vimrc

let $NNN_BMS=$NNN_BMS
let $NNN_USE_EDITOR=$NNN_USE_EDITOR
let $NNN_NO_AUTOSELECT=$NNN_NO_AUTOSELECT
let $NNN_NOTE=$NNN_NOTE
let $NNN_OPS_PROG=$NNN_OPS_PROG
let $NNN_CP_MV_PROG=$NNN_CP_MV_PROG
let $NNN_SSHFS_OPTS=$NNN_SSHFS_OPTS

let $NNN_TRASH=$NNN_TRASH
let $NNN_COPIER=$NNN_COPIER
let $NNN_RESTRICT_NAV_OPEN=$NNN_RESTRICT_NAV_OPEN
let $NNN_OPENER=$NNN_OPENER
let $NNN_CONTEXT_COLORS=$NNN_CONTEXT_COLORS
let $NNN_IDLE_TIMEOUT=$NNN_IDLE_TIMEOUT
let $NNNLVL=$NNNLVL

I guess the probelm wasn't updating the commandline arguments, i guess it was the environment variable name changes. as you can see, some of those variable names has been deprecated... alas i tried it out for months and it never entered my workflow, i haven't used any of the other navigation plugins for vim either, im rather plugin free tbh (though vim-surround should be included in the default build if you ask me)

[jarun]

Shall we change $nnn to $n? What issues do you guys see? Any possibility of conflict with n used as var in a script?

[0xACE]

Shall we change $nnn to $n? What issues do you guys see? Any possibility of conflict with n used as var in a script?

I wouldn't recommend changing it to $n. We are already polluting the environment... My comment was regarding that hitting ./$nnn is a rather large key-stroke sequence for me, even ./$n would be considered too long for me, hence I'm sticking with SEL_EXEC.

[jarun]

OK.

[jarun]

@maximbaz I am working on -e and -t.

[deadpyxel]

Not sure if I am missing something, but the shortcut to extract files inside nnn is gone, right?

Does that mean I have to setup a special shortcut for it and bind it, or I need to enable something in configs? Sorry if this is a stupid question.

[jarun]

Not sure if I am missing something, but the shortcut to extract files inside nnn is gone, right?

Yes. Did you try to hit Enter on the file? ;)

nnn now understand gzip, bzip2, zip by default. For more, install atool or bsdtar which understand those formats and export NNN_ARCHIVE: https://github.com/jarun/nnn/wiki/Usage#configuration with all file extensions you want to use.

I have atool and:

export NNN_ARCHIVE="\\.(7z|a|ace|alz|arc|arj|bz|bz2|cab|cpio|deb|gz|jar|lha|lz|lzh|lzma|lzo|rar|rpm|rz|t7z|tar|tbz|tbz2|tgz|tlz|txz|tZ|tzo|war|xpi|xz|Z|zip)$"

[deadpyxel]

Oh, that is what I was missing. Ty @jarun , didn't think of Entersince I was thinking it would try to mount the zip. This way is much better to be honest.

[jarun]

Yes, for the basic formats you don't even need to install anything or set any config. As we mentioned, v2.9 has several smart workflows.

[jarun]

if you like the project do award a star and share with your friends. We invest a lot of our personal time on contributing to open source software for free. ;)

[pat-s]

I'd like to see a force umount option - often stuck with the normal umount and force helps :)

(Really like v2.9 - thanks a lot!)

[jarun]

Unfortunately pmount doesn't have a force unmount option. But you can easily have a plugin that takes the device name as input and force unmonts.

[jarun]

@pat-s are you talking about the Unmount shortcut?

[pat-s]

Yes, the one bound to u.

[jarun]

Ok, I'll check what can be done.

[jarun]

@pat-s please search a little and let me know the option for fusermount.

[pat-s]

One can pass mount options via -o to fusermount.

So far I use umount -f <mount point> if I get the message device not configured when failing with the current umount via nnn.

This usually happens when there is a network disconnect and I didn't manually disconnect the drive beforehand.

I sometimes also get

mount_osxfuse: mount point /Users/pjs/.config/nnn/edi is itself on a OSXFUSE volume

when unmounting via nnn.

[jarun]

I tried -o but it seemed it's not having any effect. My problem is I can't repro this.

Try this: when the unmount from nnn fails try fusermount with the required options. Maybe:

fusermount -u -o -f /mount/point

and see if it works. Share the command which works for you.

[jarun]

Also see if fusermount -z /mount/point works.

[maximbaz]

Please don't make any forced unmount by default, normally there is some process blocking the resource and it makes sense to get an error and investigate this manually. Maybe if unmount failed, show prompt "retry with force? y/n" ?

[jarun]

I am thinking of the following workflow:

u -> force? -> if y, force, else don't

@pat-s we can't use umount directly so please don't share umount solutions. I would like to know whatever works with fusermount.

[jarun]

@pat-s I think what we are looking for is fusermount -uz /mount/point.

Can you please confirm?

[jarun]

@pat-s please confirm if the following patch works.

diff --git a/src/nnn.c b/src/nnn.c
index ecf17e1..b69c39b 100644
--- a/src/nnn.c
+++ b/src/nnn.c
@@ -473,8 +473,9 @@ static char * const utils[] = {
 #define MSG_BOOKMARK_KEYS 35
 #define MSG_INVALID_REG 36
 #define MSG_ORDER 37
+#define MSG_LAZY 38
 #ifndef DIR_LIMITED_SELECTION
-#define MSG_DIR_CHANGED 38 /* Must be the last entry */
+#define MSG_DIR_CHANGED 39 /* Must be the last entry */
 #endif

 static const char * const messages[] = {
@@ -516,6 +517,7 @@ static const char * const messages[] = {
        "bookmark keys:",
        "invalid regex",
        "toggle 'a'u / 'd'u / 'e'xtn / 'r'everse / 's'ize / 't'ime / 'v'ersion?",
+       "unmount failed! try lazy?"
 #ifndef DIR_LIMITED_SELECTION
        "dir changed, range sel off", /* Must be the last entry */
 #endif
@@ -3555,8 +3557,15 @@ static bool unmount(char *name, char *newpath, int *presel, char *currentpath)
        }

        if (spawn(cmd, "-u", newpath, NULL, F_NORMAL)) {
-               printwait(messages[MSG_FAILED], presel);
-               return FALSE;
+               int r = get_input(messages[MSG_LAZY]);
+
+               if (r != 'y' && r != 'Y')
+                       return FALSE;
+
+               if (spawn(cmd, "-uz", newpath, NULL, F_NORMAL)) {
+                       printwait(messages[MSG_FAILED], presel);
+                       return FALSE;
+               }
        }

        return TRUE;

[pat-s]

Just found that fusermount does not exist on macOS.

Do you handle os-dependent calls in nnn? Seems one needs to go with umount for macOS.
Hence, I can't test the fusermount approach you wrote.

Thanks for tackling this.

[jarun]

Then it's a problem. I think mount requires superuser permissions. Are you able to unmount the directory as a normal user? I'm on Ubuntu and it fails. That's the reason we use fusermount.

[jarun]

Also, please share the following commands:

• umount without force/lazy that works in normal cases
• umount with force/lazy that works when you are disconnected

[pat-s]

Are you able to unmount the directory as a normal user?

umount -f works as a normal user in a normal scenario (mount/umount without network disconnect or other interruptions). I do not get prompted for sudo.

Are you using umount <mount point> for unmounts currently to support macOS? Or how is it done currently?

Looking at the linked issue and the fact that there were no updates since 2017 in sshfs for macOS and the README still talks about fusermount which is not available, I'd say there is only umount on macOS?
Not an expert in this field..

Also, please share the following commands:

umount without force/lazy that works in normal cases
umount with force/lazy that works when you are disconnected

Normal cases work fine with nnn.

Can't replicate the other case right now even though I tried. Let me get back to you when it happens the next time? I used sudo lately but just tried umount -f on a normal mount and didn't have any problems.

[jarun]

Are you using umount for unmounts currently to support macOS? Or how is it done currently?

We are using fusermount at the moment and as you mentioned, it is not available on MacOS.

I think we can have a mac-specific handling where we use umount if the regular mount fails.

[jarun]

@pat-s please test the following patch and confirm unmounting works for both remote mounts and mounted archives.

diff --git a/src/nnn.c b/src/nnn.c
index ecf17e1..e38841c 100644
--- a/src/nnn.c
+++ b/src/nnn.c
@@ -473,8 +473,9 @@ static char * const utils[] = {
 #define MSG_BOOKMARK_KEYS 35
 #define MSG_INVALID_REG 36
 #define MSG_ORDER 37
+#define MSG_LAZY 38
 #ifndef DIR_LIMITED_SELECTION
-#define MSG_DIR_CHANGED 38 /* Must be the last entry */
+#define MSG_DIR_CHANGED 39 /* Must be the last entry */
 #endif

 static const char * const messages[] = {
@@ -516,6 +517,7 @@ static const char * const messages[] = {
    "bookmark keys:",
    "invalid regex",
    "toggle 'a'u / 'd'u / 'e'xtn / 'r'everse / 's'ize / 't'ime / 'v'ersion?",
+   "unmount failed! try lazy?"
 #ifndef DIR_LIMITED_SELECTION
    "dir changed, range sel off", /* Must be the last entry */
 #endif
@@ -3518,18 +3520,24 @@ static bool remote_mount(char *newpath, int *presel)
  */
 static bool unmount(char *name, char *newpath, int *presel, char *currentpath)
 {
+#ifdef __APPLE__
+   static char cmd[] = "umount";
+#else
    static char cmd[] = "fusermount3"; /* Arch Linux utility */
    static bool found = FALSE;
+#endif
    char *tmp = name;
    struct stat sb, psb;
    bool child = FALSE;
    bool parent = FALSE;

+#ifndef __APPLE__
    /* On Ubuntu it's fusermount */
    if (!found && !getutil(cmd)) {
        cmd[10] = '\0';
        found = TRUE;
    }
+#endif

    if (tmp && strcmp(cfgdir, currentpath) == 0) {
        mkpath(cfgdir, tmp, newpath);
@@ -3554,9 +3562,24 @@ static bool unmount(char *name, char *newpath, int *presel, char *currentpath)
        return FALSE;
    }

+#ifdef __APPLE__
+   if (spawn(cmd, newpath, NULL, NULL, F_NORMAL)) {
+#else
    if (spawn(cmd, "-u", newpath, NULL, F_NORMAL)) {
-       printwait(messages[MSG_FAILED], presel);
-       return FALSE;
+#endif
+       int r = get_input(messages[MSG_LAZY]);
+
+       if (r != 'y' && r != 'Y')
+           return FALSE;
+
+#ifdef __APPLE__
+       if (spawn(cmd, "-l", newpath, NULL, F_NORMAL)) {
+#else
+       if (spawn(cmd, "-uz", newpath, NULL, F_NORMAL)) {
+#endif
+           printwait(messages[MSG_FAILED], presel);
+           return FALSE;
+       }
    }

    return TRUE;

[pat-s]

Works, even with a conflict I think. I think I spotted a short glimpse of the typical error I got but it was skipped immediately and the unmount worked.

Thanks!!

[jarun]

Thanks for the confirmation!

[jarun]

I am assuming you are used the lazy unmount version of the patch. If not sure, please test master.

[jarun]

Rolled at #448.