Strange behavior opening bash scripts (xdg-open, vim)

[StephenP-AL]

I have a curious problem when opening shell scripts.

The file previews fine, and on initial open displays correctly in Vim.

As soon as I attempt to navigate the file, it appears that cfiles is attempting to scroll through the current directory, overwriting the screen on top of Vim.

This doesn't happen with other files opening in Vim (c, c++, html, txt files tested), just bash scripts.

Even more curious is that I can open the files with xdg-open without any issue.

[mananapr]

Hi, Thanks for showing interest in cfiles.

This is a known issue and it happens when you open a file in vim (using cfiles) and then resize the terminal. I still haven't figured out what causes this. I'll let this bug report stay open and try to figure out what's going wrong

[mananapr]

Hi check out the latest commit (460c44e) and let me know if that fixes it for you or not. Thanks!

[StephenP-AL]

Still occurs in latest.

Only clues from terminal output as follows: `Vim: Error reading input, exiting... Vim: preserving files... Vim: Finished.

Opening "/home/stephen/scripts/cs221.sh" with Vim (application/x-shellscript)` I doubt this is helpful, but it is there.

As far as resizing, I have tested the following: Opening a .c file in Vim from cfiles then resizing by a. splitting a Tmux window, and resizing the panes b. Splitting and resizing the panes within Vim c. resizing the terminal window in the graphical environment (using i3wm if that matters) Problem does not manifest in these circumstances.

Thanks.

[StephenP-AL]

Just for grins, I booted without GUI. Problem still present, but displays somewhat differently (sorry for cellphone pic, but screenshots don't work in that mode).

Edit: playing with this more I found that xdg-open was trying to open this in Elinks; I'm suspecting xdg-open is true nemesis.

[StephenP-AL]

Experiments with #define FILE_OPENER in config.h: Setting it to vim still glitches on scripts, but now has the added bonus of producing the same error with images.

Setting to pcmanfm (file manager) resolves the problem, but opens shell scripts in Vim in a new graphical window. Opens most other plain text (.c, .h, .py) in Vim in the same window.

[mananapr]

This is strange. I am unable to reproduce it on my system. Can you share any one of the sh files that are making glitches?

[StephenP-AL]

Every one of the example user scripts will do it, or even a single line #!/bin/bash test.txt

I'll try to disable some of my Vim extensions to see if that makes a difference.

[StephenP-AL]

Removing Vim plugins and resetting vimrc had no effect.

I also just built and tested on a retired machine with Ubuntu 18.04 (32 bit): problem did not manifest.

System with the issue is running Manjaro 20.0.2 i3.

[mananapr]

Can you try using this script as your FILE_OPENER?

EDIT: Were you using the same terminal emulator on both Ubuntu and Manjaro?

[StephenP-AL]

Script works, but failed to open bash scripts (did not become unstable, just failed to open). Added case option: text/x-shellscript*) vim "$1" ;; and now opens shell scripts with no problem (solved?)

Manjaro I think is using Xterm, but problem existed when running from console. Ubuntu is console only mode (no GUI)

Thanks!

[StephenP-AL]

I don't know what gremlin I pissed off, but the script no longer works after reboot. I get the same glitch as with xdg-open.

Functional workaround seems to be invoke the script as a script (p).

I'm playing around with the source code to see if I can make the openFile function more like the code for running scripts, but I suspect it is beyond my current skills.

[StephenP-AL]

I threw in a bunch of debug messages into the openFile function and generally made a mess of your code and found the following:

Some file types (.c, .h, .md, .html, .xlsx) show the debug statements at the bottom of the screen (status window I think). Others (csv and shell scripts) display them at the bottom of the preview window. This doesn't seem to make a difference on how the file opens but was interesting.

Files that open correctly in Vim are employing invoking "editor" instead of "FILE_OPENER" because of the "text" mime type. Shell scripts are recorded in the mime variable as "application/x-shellscript\n" (actual new line character is in the string)

I tested stripping out the \n from the string (I've had trouble with those in the past), but it didn't seem to make a difference.

So my specific problem is solved by changing this line in the openFile function if(strcmp(mime,"text") == 0) to this: if(strcmp(mime,"text") == 0 || strcmp(mime,"application/x-shellscript\n") == 0) I understand this is probably not suitable for all users, but possibly as a configurable option. I can attempt to put in in a PR if you'd like, but I warn you it will be ugly.

[mananapr]

Hi, Thanks for all the debugging! I tried adding the strcmp condition in my build as well and everything seems to be working good. So I guess it's okay to add it to the main code. I've made the change in the latest commit so let me know if that works for you. Thanks!

[StephenP-AL]

My only concern would be the manner in which different systems might interpret the mime type, specifically with that new line character. I'd be tempted to remove the \n even though I have no indication that it might be a problem.

My inelegant solution would be to add for (j=0; j<strlen(mime); j++) { if (mime[j] == 10) mime[j] = 0; } after getting the mime type. Then alter the comparison line to if((strcmp(mime,"text") == 0) || (strcmp(mime, "application/x-shellscript") == 0))

Thanks again for your consideration, Cfiles has now officially replaced Ranger on my system.

[mananapr]

After some reading online, I decided to go with the solution mentioned here I have added it to the latest commit. Let me know how that works for you. Thanks for showing interest in cfiles but personally I think ranger is a much more mature file manager than cfiles and it has lesser bugs as well

[StephenP-AL]

Yeah, the for loop was a pretty dumb idea... wasteful. Current commit works just fine.

Ranger has a lot of features that I don't use, and it's functions are more complex to operate. cfiles fits my needs at ~1/3 the system resources. As an added bonus, it gives me an excuse to play with C again.

[mananapr]

That's good to know. I think we can close this issue now. Thanks!