[SOLVED] nvi misteriously started opening the files in O_RDWR mode

louigi600 · 02-19-2021, 12:53 AM

Is there any particular reason why nvi should suddenly switch to permanently opening the scripts I'm editing in O_RDWR mode ?

I was doing my 2 terminal thing as usual: one with the editor on the scripts and the other for testing the script while editing.
Suddenly I started getting this message when I was attempting to run test the script:

Code:

root@rpi4:~# ./spm "*sqlite3"
-bash: ./spm: /bin/bash: bad interpreter: Text file busy
root@rpi4:~#

I was sure there was nothing wrong with the shebang and moreover the message disappears if i quit the nvi session on the script.
I also reproduced the problem on any given bash script on my system.

Out of desperation I switched back to elvis and the problem disappeared : what was nvi doing ? I spent quite some time searching if there was some setting that crept in to nvi but found nothing.

I found this thread that at least describes why it is happening ... and I did a strace to confirm that:

Code:

openat(AT_FDCWD, "spm", O_RDWR)         = 4
fcntl64(4, F_SETFD, FD_CLOEXEC)         = 0
flock(4, LOCK_EX|LOCK_NB)               = 0
access("spm", W_OK)                     = 0

Is there any cure for this ?

Incidentally the normal output od the script is like this:

Code:

root@rpi4:~# ./spm "*sqlite3"
/usr/bin/sqlite3 contained in sqlite-3.34.1-arm-1 [INSTALLED]
root@rpi4:~#

I've sent Robby an issue on github ... maybe this functionality can be added to slackpkg since the file-search function in there is somewhat lacking wildchar management (the pertinent section for doing this is just 13 lines of script so nothing complicated):

Code:

#find which package contains a file (absolute path with optional wildchars)
Find_Package_Owning_file ()
{ Regexp="$(sed 's?^/??; s?\*?.\*?g; s/?/./g' <<< $1)" 
  Info="$(bzcat $DB | awk -v filename="$Regexp" '
  $2 ~ /Package:/ {package=$3; sub("./","",package)}; 
  $NF ~ "^"filename"$" {printf("%s:/%s\n",package,$NF)} ')"

  for hit in $Info
  do
    PackageInfo=${hit%%:*}
    PackageFile=${PackageInfo##*/}
    PackageName=${PackageFile%%.t*z}
    File=${hit##*:}
    [ -f ${InstalledPKGDir}/$PackageName ] && Installed="INSTALLED" || Installed="UNINSTALLED" 
    echo -e "$File contained in $PackageName [${Installed}]" 
  done
}

I also made a function that will try to find for you the packages that contain your missing dll for any given file/package.
I made a blog about it here.

shruggy · 02-19-2021, 07:10 PM

What I don't understand is why the problem with nvi only surfaces now. The thread you linked to is from year 2009. In the blog post mentioned there the change in behavior was noticed when switching from Debian Etch (which still used nvi 1.79) to Debian Lenny (nvi 1.81.6).

I checked other vi clones (vim, neovim, neatvi, xvi, levee, vile), and nvi seems to be the only one doing this.

louigi600 · 02-21-2021, 01:41 AM

I have no idea ... I was using nvi happily and suddenly it started doing it. Not sure if I did an update that may have triggered it, if nvi got upset because I accidentally appended something with echo to the file I was editing (I discarded that by forcing :w!) or whatever else may have triggered it ... but now it is persistent across reboots and across reinstalls of the nvi package: I can't have it that way as I always do the 2 terminal thing when writing scripts.
It is happening on a testing uSD so I could probably get rid of the issue by starting clean again (if it is not something that came with an update) ... but I think it is worth while figuring it out and possibly preventing it from happening again. I looked for any dirt nvi might have left around but could not find any (even with the help of strace) ... moreover it is now doing the same with every bash script on the system (not tested with other interpreters yet).

Actually while doing a little more investigation I found an interesting thing: before I had the issue I may have been using vim without being aware, then I probably did something which changed the vi link. When I got the issue I looked and I saw that vi pointed to nvi so I assumed I was using nvi all the time but this may not be the case. I have another uSD with current on it and there vi still points to vim ... explicitly using nvi will reproduce the problem over there too.

louigi600 · 03-01-2021, 07:07 AM

So it's not something that started happening at some random point so maybe the thread can be marked as solved, but will it ever be fixed: will it be possible to execute a script that is being edited with nvi ?

shruggy · 03-01-2021, 08:38 AM

It did start happening somewhere between the release of nvi 1.79 (October 1996) and nvi 1.81.6 (November 2007). There's not much recent activity in nvi's git repo, the latest commit being from September 2020. I'm currently running nvi updated to that commit, and it still prevents the execution of a script that's being edited.

Try asking the current maintainer, Sven Verdoolaege directly per email (the email address can be seen in the commit message).

louigi600 · 03-09-2021, 05:17 AM

I've switched to elvis ... as nvi has the issue with cant run a script being edited and vim has something wrong mouse cut and paste from clipboard (at least from may favorite windowmanager [fluxbox]).
Not sure if asking the nvi maintainer about this will change anything ... maybe there is a reason for this as it appears to have been like this for several years now.

shruggy · 03-09-2021, 06:23 AM

Unfortunately, elvis doesn't support Unicode (at least, it didn't when I last checked).

As to cut and paste operations in Vim, try Neovim instead. Clipboard handling is one of the few areas where Neovim differs from Vim. For details, see this post. And I believe this rather has to do with the terminal emulator you're using than the window manager.

louigi600 · 03-09-2021, 11:18 AM

I had an idea it could be that but I did not think it was so likely. I had fiddled with the system wide default settings to invert background and foreground settings ... I may have touched something else.
I went back to the simplest + just the modified background and foreground : I get slightly more reliable cut and paste from clipboard but still I get a red warning message when I paste into vim:

Code:

E353: Nothing in register "

but then, the previously selected text with the mouse, gets pasted in. It's still not perfect but better then before where it would do really odd things.
It does the exact same thing if I use vim from xrvt (untouched system-wide default settings).
Same setup on 14.2 will not do this odd thing.
I looked up the error and this seems to fix it:

Code:

echo "set clipboard=unnamed" >> ~/.vimrc

I will now look for a system wide solution to this as doing the very same in /usr/share/vim/vimrc will not work (but it will honor other settings ... something else must overwrite this clipboard setting).

louigi600 · 03-11-2021, 11:58 PM

I see there is a new vim update on current ... it distributes, among other things, a new /usr/share/vim/vimrc ... but it doe not fix clipboard issues on my setup.
If the maintainer would like any specific info from my system ....

louigi600 · 04-03-2021, 12:11 AM

I had an exchange with the current nvi maintainer: he was not involved at the time the decision was made to open files in O_RDWR mode so I doubt there will be a change in that respect.
However there is a workaround: although the file cannot be execve'd while nvi has it locked, it can still be read, so to sort out your testing while editing you can still start a new interpreter and have it interpret the the script.
Supposing bash is the intended interpreter, instead of

Code:

./script.sh

one could use this while editing the script

Code:

bash ./script.sh

It's what the shebang would do anyway. I should have thought of this the minute I realized I could source the script into the current shell (in case of bash scripts) while nvi had it locked ... but my mind was in loop elsewhere.