1

I have trouble with buffers in Vim (8.0 on a rhel8 server) apparently. That said ... I was not aware of the exitance of buffers before facing this problem. So as you can see, my expertise in vim is limited.

I got in contact via en error poppig up when tring to :q a file which I am allowed to edit via systemctl edit --full postgresql@.service which uses vim to edit /etc/systemd/system/postgresql@.service. Due to restrictions in my environment I do not have any write access beyond that in /etc

E173: 2 more files to edit

so I learned that buffers may be my problem

:ls
  1 %a   "/etc/systemd/system/.#postgresql@test.servicee356346753c261c9" line 1
  2      "/etc/systemd/system/.#postgresql@plakoda.servicee9258362d8896077" line 0
  3      "/etc/systemd/system/.#postgresql@plakodamvp.service19f58985a72e1639" line 0

now ... I found that :bd or :%bd should be the way to getting rid of those. However it does not work. :%bd says 3 buffers deleted and shows an empty file. It I try to get out of this :q I am getting a new E173 2 more files to edit. the only way getting out of this is a :q!.

Entering the file I wanted to work on again shows

:ls
  1 %a   "/etc/systemd/system/.#postgresql@test.servicee6523c2bbef84935" line 1
  2      "/etc/systemd/system/.#postgresql@plakoda.service857bcb8fb3ec8bd8" line 0
  3      "/etc/systemd/system/.#postgresql@plakodamvp.serviceaf054a3401922b7a" line 0

so I am back to where I startet.

Is it the restricted access to the location of that file I am trying to work on, which may prevent the buffers from being deleted? Is there any way around this?


Addition:

I may be worth mentioning that apparently files listed in the buffers list (i.e. /etc/systemd/system/.#postgresql@test.servicee6523c2bbef84935 ) do not exist. however:

$ ls -la /etc/systemd/system/postgresql@*.service*
-rw-r--r--. 1 root root 965 21. Sep 10:08 /etc/systemd/system/postgresql@plakodamvp.service
-rw-r--r--. 1 root root 933 21. Sep 09:18 /etc/systemd/system/postgresql@plakoda.service
-rw-r--r--. 1 root root 938  9. Sep 15:25 /etc/systemd/system/postgresql@.service
-rw-r--r--. 1 root root 922 21. Sep 09:16 /etc/systemd/system/postgresql@test.service

also a swap file matching somewhat that naming schema (.#postgresql@test.service4838413f9bf526f5.swp) exists

8
  • What happens if you do :wa and then :qa?
    – kadekai
    Sep 21 at 8:16
  • I exit the file. buffers survive though
    – vrms
    Sep 21 at 8:19
  • the buffers referr to other files, then the one I am working on actually. When opening those there is only one buffer listed. I would believe that is fine because it represents the current open file which potentially may be edited.
    – vrms
    Sep 21 at 8:30
  • sorry :bd & %bd is what I mean. Corrected that in the question
    – vrms
    Sep 21 at 8:46
  • @vrms Top tip: if you ever see an error of which you're unsure of the meaning, you can see more info by checking it in the documentation. In this instance: :help E173.
    – Rich
    Sep 21 at 9:18

1 Answer 1

4

It looks like systemctl is opening Vim with three "arguments", and Vim then prevents you from exiting until you have visted all these files with the :n command.

If you do want to exit without editing the files, just type :q again and it should work. (Or, as you mentioned in your question, and as kadekai suggested in a comment, you can tell Vim from the outset that you want to ignore the unedited files in the arglist by using :q! or :qa.)

So your :%bd command is working. If you try :ls again afterwards, you will see that the buffers are no longer in the buffer list. But they are still in the argument list, which is a different thing. You can use the :args command to view the argument list.

This is explained in :help E173 and :help arglist-quit.

The argument list is introduced in section 07.2 of the user manual.

9
  • 2
    @kadekai Ignore my comment above. :qa works (without the unnecessary :wa), but the OP said that does work. When they say the buffers "survive", I'm presuming they just mean if they run the same systemctl command again all three files are opened again.
    – Rich
    Sep 21 at 8:50
  • 1
    so I can get around this as described. That much ist true. I just did not think of this being a desired situation. Foremost it is a bit irritating, but I can live with that. Seems there is no solution the get rid of those files. I doubt however that systemctl edit --full passed those other files as arguments to vim. I can't see any sense in that. But that may be a different discussion. thx everybody
    – vrms
    Sep 21 at 9:47
  • 1
    @vrms You can get rid of the files by altering the arglist. One way would be with the command :args %, which replaces the current contents of the arglist with just the current file. Why do you believe that systemctl isn't adding the files to the arglist? Do the files appear in the arglist even when invoking vim with an explicit vim command? It's possible, although I think less likely, that something else in your Vim configuration is adding the files. Do the files appear if you run vim --clean to ignore your config?
    – Rich
    Sep 21 at 10:30
  • 1
    @vrms This is outside the scope of this site, but is your systemctl command definitely correct? I don't know much about systemctl, but reading the man page, it looks as though postgresql@.service might not the name of a service, but instead the name of a unit template?
    – Rich
    Sep 21 at 10:38
  • 1
    I understand the matter now a little better. 1. yes it is a unitfile I am trying to edit. The problem really is the * in the filename. This causes as you have suspected not only a single file but several ones, which leads to the buffer situation. The core problem is that I should edit a unit file without the * (postgresql@.service). That, however, does not work. Unfortunately I have no access rights to /etc/systemd whatsoever and will have to talk to the admins able to solve this. I have learned quite a bit & apologize whether I was seeing a vim problem, where there actually was none.
    – vrms
    Sep 22 at 15:44

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.