multiple url link opening

[nagy135]

When opening url link (in format [[http://google.com |google]] ) with <CR> it opens 3 tabs (copies) in my browser. My xdg-open is set to qutebrowser, but simple xdg-open "https://google.com" opens just one. I can only conclude that it is not issue of xdg-open as well as my browser. I assume that if this was a bug it would be reported instantly so I guess i m doing something wrong...if anyone had the same issue, would appreciate some help. If i override link handler it works but i will loose link handling of normal vimwiki links, so I cant figure what to do :/

Vimwiki: 2.4.1
Neovim: 0.2.2

[ranebrown]

1. What is the output of :verbose imap <CR>?
2. Does the same the happen if you place the cursor on a link and call :VimwikiFollowLink?
3. Does the same thing occur if you use the dev branch?
4. Does changing the browser make any difference?

[nagy135]

1. i <CR> *@<Esc>:VimwikiReturn 1 5<CR> Last set from ~/.vim/plugged/vimwiki/ftplugin/vimwiki.vim
2. Yes
3. Yes
4. Yes, chromium works as expected. The interface between the two has to be a problem, but i would pressume that what vimwiki does in its guts is simple xdg-open link and while one of those works, it would have to be called more than once right ?

[ranebrown]

It is strange that it works for a different browser. xdg-open is being called from this function.

If you can try do do some debugging and add any more info here that would be helpful. You can take a look at this link about debugging or you can edit the source code to add print statements and then restart vim/vimwiki so the changes are loaded.

[nagy135]

I tried looking into it and I myself found that function as well...after doing so I concluded it has to be qutebrowser issue that somehow randomly happens only here :D ...I will definitelly search deeper and give an update, but for now I simply press X (close) twice ...thanks for tutorial, will check it out

[igorline]

Same issue here

[nagy135]

Lets recapitulate what we know. There are 3 pieces that might be faulty here:

• VimWiki - it just calls external program, might be somehow calling it 3 times ? Can any maintainer verify this?
• xdg-open - cant see how this could be issue, its called from one program and seems to be doing its job. Unlikely to be acting differently being called by another program.
• Qutebrowser - This doesnt seem like probable candidate, but it does not happen with my chromium. But without vimwiki, calling the same command works flawlessly.

I will have to leave this for someone more competent in this project to figure out or throw us to qutebrowser issues. Is there a possible reason that could run that function multiple times ...maybe on faulty exit codes that somehow only happen with qutebrowser?

[ratfactor]

It works fine for me (opens a single tab in Firefox), but xdg-open does produce the following STDERR output:

/usr/bin/xdg-open: line 719: : command not found
/usr/bin/xdg-open: line 781: x-www-browser: command not found

I sprinkled a copy of the script with echo statements to get to the bottom of it:

$ which xdg-open 
/usr/bin/xdg-open
$ file /usr/bin/xdg-open 
/usr/bin/xdg-open: POSIX shell script, ASCII text executable
$ cp /usr/bin/xdg-open my-xdg-open
$ vim my-xdg-open
$ ./my-xdg-open 'http://example.org'

For me, line 719 is attempting to run the Exec entry from the "Desktop Entry" file for Firefox (which appears to be wrong and is being turned into a blank string when the script attempts to which the path.)

Line 781 is where the script attempts to execute entries from the $BROWSER environment variable. I do not have one set, so the script supplies a list of defaults:

    # if BROWSER variable is not set, check some well known browsers instead
    if [ x"$BROWSER" = x"" ]; then
        BROWSER=www-browser:links2:elinks:links:lynx:w3m
        if [ -n "$DISPLAY" ]; then
            BROWSER=x-www-browser:firefox:iceweasel:seamonkey:mozilla:epiphany:konqueror:chromium-browser:google-chrome:$BROWSER
        fi
    fi

The three attempts is just a coincidence in my case, but it does make me wonder if this is an exit code problem. Perhaps the script is actually trying (and succeeding) three times?

[Z2h-A6n]

It looks like @ratfactor is probably right that xdg-open tries to and succeeds three times due to something related to exit codes. I also sprinkled some echo statements into xdg-open and looked for differences between opening a link in vimwiki and runing xdg-open URL directly in a shell. In both cases, the execution of xdg-open starts out the same:

1. After some argument-parsing and similar stuff, the case statement at the end of xdg-open runs. In my case this runs the generic case, resulting in a call to open_generic
2. The URL I'm testing with is not a file URL or a path, and I am in an X11 session, so open_generic_xdg_x_scheme_handler is called.
3. open_generic_xdg_x_scheme_handler calls open_generic_xdg_mime.
4. open_generic_xdg_mime looks for XDG directories and calls search_desktop_file
5. search_desktop_file looks for and eventually finds an appropriate *.desktop file. In my case, this is /usr/share//applications//org.qutebrowser.qutebrowser.desktop. It uses this to build a command line to execute, in this case /usr/bin/qutebrowser URL, where URL is replaced by the relevant URL. This command is then executed.

At this point the differences appear:

• When running xdg-open directly, qutebrowser opens the URL and returns an exit code of 0, so exit_success is called in xdg-open, and xdg-open finishes execution.
• When opening a link in vimwiki, qutebrowser opens the URL and returns an exit code of 120. xdg-open doesn't count this as a success, so it tries other ways of opening the URL and ends up calling open_envvar two more times. Each time it parses $BROWSER and in my case ends up running /usr/bin/qutebrowser URL. Both times qutebrowser opens the URL and returns 120, causing execution to continue. Finally, xdg-open runs out of things to try and calls exit_failure_operation_impossible to report the problem.

I guess the next thing to do is figure out why qutebrowser is sometimes returning 120. Qutebrowser's stdout/stderr output would probably be useful, but I'm not sure how to see that when opening links from vimwiki. I guess replacing this system call with something that logs to a file would work, but I don't know enough vimscript to know how to do that.

[lilyinstarlight]

Investigating this further with strace -f in the system() call in Vim, exit code 120 is coming from the Python interpreter due to being signaled SIGPIPE when qutebrowser is already running and therefore tries to print the message "INFO: Opening in existing instance". (This might possibly be occurring while the interpreter is flushing output on exit -- not sure why it would end in 120 instead of BrokenPipeError unless the interpreter was already trying to exit when the output was written.)

You can demonstrate this exit code in a similar fashion outside of Vim with this (bash) command line:

python -c 'import time; time.sleep(1); print("test")' 2>&1 | false ; echo ${PIPESTATUS[0]}

This problem can therefore be worked around by redirecting output (which wasn't captured anyway) to /dev/null which prevents SIGPIPE from occurring. You can test this by running each of this in Vim and noting that the first (which is what the current vimwiki code would call) encounters the problem with qutebrowser as default, but the second does not:

Fails:

:call system('xdg-open '.shellescape('https://vimwiki.github.io/').' &')

Works:

:call system('xdg-open '.shellescape('https://vimwiki.github.io/').' >/dev/null 2>&1 &')

I've opened a PR to address this, but I would welcome feedback from the maintainers as to whether discarding output like this is appropriate or if another behavior is desired. Either way though, the problem occurs because the system call finishes before qutebrowser tries to write output and breaks the pipe.

[brennen]

I've opened a PR to address this, but I would welcome feedback from the maintainers as to whether discarding output like this is appropriate or if another behavior is desired. Either way though, the problem occurs because the system call finishes before qutebrowser tries to write output and breaks the pipe.

Thanks for the detailed investigation. I think this is pretty reasonable for our use case, and I've gone ahead and merged your PR. That said, when I'm more awake than I am now I'm going to double-check and make sure there's not a case where xdg-open is actually trying to start an interactive program in the same terminal session or something that this messes with. I will freely admit that I have to relearn from scratch how this works every time I have to think about it for any reason.

[nwoeanhinnogaehr]

I just ran into this issue and managed to resolve it by removing the ampersand from the line that invokes xdg-open, i.e. I replaced call system('xdg-open ' . shellescape(a:url).' &') with call system('xdg-open ' . shellescape(a:url)). Functionality seems to be exactly the same except it only opens the page once.

I think the problem is likely that I use fish as my default shell. Fish probably returns a different value when launching a process in the background (vs bash).

Is there any specific reason why the command is being launched in the background?