Vim: Less verbose way of listing files to recover?

7 views
Skip to first unread message

Ottavio Caruso

unread,
Feb 24, 2021, 10:54:01 AM2/24/21
to
Hi,

[re-posted from vim...@googlegroups.com with edits; no replies over there]

$ echo $BASH_VERSION
4.4.12(1)-release

$ nvi -r
vi: no files to recover.

$ vim -r
Swap files found:
In directory ~/.vim/tmp:
-- none --


Is there a way to make vim behave like nvi, that is, give a less verbose
message natively, without, e.g., using a shell script?

And, should I have to use a script or a function, what would be a good
one liner? I've tried both: `find` and `ls -al` but they both return
success even if they don't find files in ~/.vim/tmp.

$ ls -al .vim/tmp/
total 8
drwxr-xr-x 2 oc oc 4096 Feb 24 10:15 .
drwxr-xr-x 3 oc oc 4096 Jan 23 11:06 ..
$ (ls -al .vim/tmp/ >/dev/null) && echo yes ||echo no
yes
$ (find .vim/tmp/ >/dev/null) && echo yes ||echo no
yes


Thanks.

--
Ottavio Caruso

Chris Elvidge

unread,
Feb 24, 2021, 12:01:41 PM2/24/21
to
You have run 'ls -al .vim/tmp' and found 2 files, namely . and .. (the
actual directory and its parent).
So your first test will return 'true' (why did you put it in parentheses?)
Try 'ls -Al' to stop listing . and ..
Your second test finds .vim/tmp (the directory you're searching) - also
returns true (ditto parens)


--
Chris Elvidge
England

Spiros Bousbouras

unread,
Feb 24, 2021, 12:07:29 PM2/24/21
to
On Wed, 24 Feb 2021 15:53:58 +0000
Ottavio Caruso <ottavio2006...@yahoo.com> wrote:
> Hi,
>
> [re-posted from vim...@googlegroups.com with edits; no replies over there]

There exists also gmane.editors.vim which is a gateway for the mailing list
at v...@vim.org .

> $ echo $BASH_VERSION
> 4.4.12(1)-release
>
> $ nvi -r
> vi: no files to recover.
>
> $ vim -r
> Swap files found:
> In directory ~/.vim/tmp:
> -- none --
>
>
> Is there a way to make vim behave like nvi, that is, give a less verbose
> message natively, without, e.g., using a shell script?
>
> And, should I have to use a script or a function, what would be a good
> one liner? I've tried both: `find` and `ls -al` but they both return
> success even if they don't find files in ~/.vim/tmp.
>
> $ ls -al .vim/tmp/
> total 8
> drwxr-xr-x 2 oc oc 4096 Feb 24 10:15 .
> drwxr-xr-x 3 oc oc 4096 Jan 23 11:06 ..
> $ (ls -al .vim/tmp/ >/dev/null) && echo yes ||echo no
> yes
> $ (find .vim/tmp/ >/dev/null) && echo yes ||echo no
> yes

[ -z "$( find .vim/tmp/ -type f )" ] && echo Directory empty

This assumes that .vim/tmp/ may only have regular files.

Kaz Kylheku

unread,
Feb 24, 2021, 12:59:53 PM2/24/21
to
On 2021-02-24, Ottavio Caruso <ottavio2006...@yahoo.com> wrote:
> Hi,
>
> [re-posted from vim...@googlegroups.com with edits; no replies over there]
>
> $ echo $BASH_VERSION
> 4.4.12(1)-release
>
> $ nvi -r
> vi: no files to recover.
>
> $ vim -r
> Swap files found:
> In directory ~/.vim/tmp:
> -- none --
>
>
> Is there a way to make vim behave like nvi, that is, give a less verbose
> message natively, without, e.g., using a shell script?
>
> And, should I have to use a script or a function, what would be a good
> one liner? I've tried both: `find` and `ls -al` but they both return
> success even if they don't find files in ~/.vim/tmp.

Ah yes, the cursed how to test for an empty directory.

empty_expansion()
{
local pat=$1 # local variable, not in POSIX

set -- $pat # set positional parameters to expansion of pattern

# expansion is empty: success (e.g. this is Bash and nullglob is set)
[ $# == 0 ] && return 0

# expansion has one field, identical to pattern: success
[ $# == 1 ] && [ "$1" == "$pat" ] && return 0

# expansion not empty
return 1
}

vim()
{
if [ $# == 1 ] && [ "$1" == "-r" ] ; then
if empty_expansion '~/.vim/tmp/*.sw*' ; then
echo "vim: no files to recover"
return 0
else
return 1 # or run command vim "$@" here too?
fi
else
command vim "$@"
fi
}

Vim looks in multiple directories for recovery files, so this has to be
factored in in a general solution. It looks like you reconfigured the
temp files to go into a single place.

--
TXR Programming Language: http://nongnu.org/txr
Cygna: Cygwin Native Application Library: http://kylheku.com/cygnal

Kaz Kylheku

unread,
Feb 24, 2021, 1:07:37 PM2/24/21
to
On 2021-02-24, Kaz Kylheku <563-36...@kylheku.com> wrote:
> if empty_expansion '~/.vim/tmp/*.sw*' ; then

Erratum: that probably wants to be '~/vim/tmp/.*.sw*'.

Vim swap files nowadays are hidden.

Lewis

unread,
Feb 24, 2021, 1:26:56 PM2/24/21
to
In message <s15sqn$n7a$1...@dont-email.me> Ottavio Caruso <ottavio2006...@yahoo.com> wrote:
> Hi,

> [re-posted from vim...@googlegroups.com with edits; no replies over there]

> $ echo $BASH_VERSION
> 4.4.12(1)-release

> $ nvi -r
> vi: no files to recover.

> $ vim -r
> Swap files found:
> In directory ~/.vim/tmp:
> -- none --


> Is there a way to make vim behave like nvi, that is, give a less verbose
> message natively, without, e.g., using a shell script?

> And, should I have to use a script or a function, what would be a good
> one liner? I've tried both: `find` and `ls -al` but they both return
> success even if they don't find files in ~/.vim/tmp.

> $ ls -al .vim/tmp/
> total 8
> drwxr-xr-x 2 oc oc 4096 Feb 24 10:15 .
> drwxr-xr-x 3 oc oc 4096 Jan 23 11:06 ..
> $ (ls -al .vim/tmp/ >/dev/null) && echo yes ||echo no
> yes

Of course yes, the -a means that two files (well, directories) will be found.

Perhps try ls -A

or find /.vim/tmp/ -not -empty

> $ (find .vim/tmp/ >/dev/null) && echo yes ||echo no
> yes

Because find found .vim/tmp

perhaps find .vim/tmp -type f

--
Greedo didn't shoot first, motherfucker!

Keith Thompson

unread,
Feb 24, 2021, 2:21:40 PM2/24/21
to
Kaz Kylheku <563-36...@kylheku.com> writes:
> On 2021-02-24, Kaz Kylheku <563-36...@kylheku.com> wrote:
>> if empty_expansion '~/.vim/tmp/*.sw*' ; then
>
> Erratum: that probably wants to be '~/vim/tmp/.*.sw*'.
>
> Vim swap files nowadays are hidden.

Not always. For example, if you have

set directory=~/vimswap

then the swap files in ~/vimswap are not hidden.

--
Keith Thompson (The_Other_Keith) Keith.S.T...@gmail.com
Working, but not speaking, for Philips Healthcare
void Void(void) { Void(); } /* The recursive call of the void */

Eli the Bearded

unread,
Feb 24, 2021, 3:41:04 PM2/24/21
to
In comp.editors, Spiros Bousbouras <spi...@gmail.com> wrote:
> Ottavio Caruso <ottavio2006...@yahoo.com> wrote:
> > [re-posted from vim...@googlegroups.com with edits; no replies over there]
> There exists also gmane.editors.vim which is a gateway for the mailing list
> at v...@vim.org .

I subscribe to the vim mailing list. His post to vim...@googlegroups.com
made it to the list and no one replied. There is probably no way, short
of a patch, to get what Ottavio wants.

>> $ vim -r
>> Swap files found:
>> In directory ~/.vim/tmp:
>> -- none --
>>
>> Is there a way to make vim behave like nvi, that is, give a less verbose
>> message natively, without, e.g., using a shell script?

Likely not.

>> And, should I have to use a script or a function, what would be a good
>> one liner? I've tried both: `find` and `ls -al` but they both return
>> success even if they don't find files in ~/.vim/tmp.

This gets tricky unless you are willing to hardcode the directory to
look in for swap files. That is not a standard location. When I run
`vim -r` I get lists from four directories (., ~/tmp/, /var/tmp/, /tmp/)
and two results in /var/tmp/ for files that are not mine. For those
files, the results are terser than for files that are mine.

:r! vim -r 2>&1
Swap files found:
In current directory:
1. .configure.swp
owned by: username dated: Fri Feb 19 15:12:46 2021
file name: ~username/src/mimedown/configure
modified: no
user name: username host name: shelhost.panix.com
process ID: 29440 (STILL RUNNING)
2. .smtp.c.swp
owned by: username dated: Fri Feb 19 15:04:37 2021
file name: ~eli/src/mimedown/smtp.c
modified: no
user name: username host name: shelhost.panix.com
process ID: 29440 (STILL RUNNING)
In directory ~/tmp:
-- none --
In directory /var/tmp:
4. .mutt-panix5-905-24883-2717832404293756297.swp
owned by: user1 dated: Wed Feb 24 15:21:02 2021
[cannot be opened]
5. .nn.O2ZmDb.swp
owned by: user2 dated: Thu Jan 28 21:21:06 2021
[cannot be opened]
In directory /tmp:
-- none --


A one liner _could_ run "vim -r" and parse the output saving the
directory name and then combining it with filenames listed on the
lines starting with a number, perhaps rejecting ones that cannot be
opened. That starts to get complicated for one line.


>> $ ls -al .vim/tmp/

"ls -Al" might be better.

>> $ (find .vim/tmp/ >/dev/null) && echo yes ||echo no

find $HOME/.vim/tmp -type f -name \*.sw\?

I know my record is about five swap files with the same initial name.
For me, these come from as yet unamed files, and the names count
backwards in letters: .swp, .swo, .swn, .swm, .swl, ...

> [ -z "$( find .vim/tmp/ -type f )" ] && echo Directory empty
> This assumes that .vim/tmp/ may only have regular files.

I'm not sure I follow "may only have regular files". Are you commenting
about the possibilty of a non-swap file may be in there? I'd have said
"will not have regular files" for that case.

Elijah
------
doesn't know if/how nvi reports other people's recovery files

jo...@schily.net

unread,
Feb 24, 2021, 4:47:51 PM2/24/21
to
In article <eli$21022...@qaz.wtf>,
Eli the Bearded <*@eli.users.panix.com> wrote:

>:r! vim -r 2>&1
>Swap files found:
> In current directory:
>1. .configure.swp
> owned by: username dated: Fri Feb 19 15:12:46 2021
> file name: ~username/src/mimedown/configure
> modified: no
> user name: username host name: shelhost.panix.com
> process ID: 29440 (STILL RUNNING)
...

This reminds me on a detail, that I discovered many years ago...

It may be if interest to know that vim does not act collaborative.

While other editors install a write lock on the edited file to inform all
other possible editors that the file is currently being edited, vim is only
willing to tell other vim instances that a file is being edited. This is done
by vim via checking for the swap file that of course is unknown by other
editors.

--
EMail:jo...@schily.net Jörg Schilling D-13353 Berlin
Blog: http://schily.blogspot.com/
URL: http://cdrecord.org/private/ http://sourceforge.net/projects/schilytools/files/

Eli the Bearded

unread,
Feb 24, 2021, 5:24:37 PM2/24/21
to
In comp.editors, <jo...@schily.net> wrote:
> This reminds me on a detail, that I discovered many years ago...
>
> It may be if interest to know that vim does not act collaborative.

To me this is the expected case for Unix file editing. Undefined things
happen when multiple entities try to edit a file at once.

> While other editors install a write lock on the edited file to inform all
> other possible editors that the file is currently being edited, vim is only
> willing to tell other vim instances that a file is being edited. This is done
> by vim via checking for the swap file that of course is unknown by other
> editors.

How many times has that lock failed to work? Not all filesystems
support all lock types, and aren't they largely "advisory" only? In
particular think of networked filesystems, where the lock cannot just be
in the local kernel. vim works on many OSs, not just Unix like, and across
many filesystems. I'm not sure how locks work with, eg, sshfs or files
being edited over ftp.

(That is not to say that vim could not do better, but to say there will
be places where it can't win. Same as nvi.)

Elijah
------
also wondering about loopback filesystems now

jo...@schily.net

unread,
Feb 24, 2021, 5:50:24 PM2/24/21
to
In article <eli$21022...@qaz.wtf>,
Eli the Bearded <*@eli.users.panix.com> wrote:
>In comp.editors, <jo...@schily.net> wrote:

>> While other editors install a write lock on the edited file to inform all
>> other possible editors that the file is currently being edited, vim is only
>> willing to tell other vim instances that a file is being edited. This is done
>> by vim via checking for the swap file that of course is unknown by other
>> editors.
>
>How many times has that lock failed to work? Not all filesystems
>support all lock types, and aren't they largely "advisory" only? In
>particular think of networked filesystems, where the lock cannot just be
>in the local kernel. vim works on many OSs, not just Unix like, and across
>many filesystems. I'm not sure how locks work with, eg, sshfs or files
>being edited over ftp.

In former times, Linux was a problem with locking over the network, but this
seems to have become better.

BTW: locking is not a property of the filesystem, but of it's implementation
so this is not limited to UNIX filesystems and if you use archaic and
non-POSIX remote filesystems like smbfs, you are lost. NFS supports it...

>(That is not to say that vim could not do better, but to say there will
>be places where it can't win. Same as nvi.)

nvi does it right.

>also wondering about loopback filesystems now

lofs just forwards the lock to the underlying filesystem.

Finally, it is a nice hint that you may get from your friendly editor.

Eli the Bearded

unread,
Feb 24, 2021, 6:43:59 PM2/24/21
to
In comp.editors, <jo...@schily.net> wrote:
> BTW: locking is not a property of the filesystem, but of it's implementation
> so this is not limited to UNIX filesystems and if you use archaic and
> non-POSIX remote filesystems like smbfs, you are lost. NFS supports it...

Locking, in Unix, is done in the kernel. Network filesystems need to
support network fowarding of locks for locks to work on that filesystem.
NFS is a popular network filesystem, but not the only one. Userspace
filesystems ("FUSE") like sshfs are where I suspect the most problems
will exist.

>> also wondering about loopback filesystems now
> lofs just forwards the lock to the underlying filesystem.

When a loopback makes a file available via two different paths, how does
that work vis-a-vis locks? I honestly don't know.

Traditionally the device-id plus inode is a unique identifier. With a
loopback, doesn't the device-id change?

(With some exotic filesystem features, like snapshots, device-id plus
inode ceases to be a unique identifier. Since snapshots are read only,
that's not really an editing problem, but I've seen it break "cp" having
it wrongly claim to be copying a file to itself.)

Elijah
------
in Netbsd at least, add st_mtimensec for uniquely identifying a file

Kaz Kylheku

unread,
Feb 24, 2021, 8:42:27 PM2/24/21
to
On 2021-02-24, jo...@schily.net <jo...@schily.net> wrote:
> In article <eli$21022...@qaz.wtf>,
> Eli the Bearded <*@eli.users.panix.com> wrote:
>
>>:r! vim -r 2>&1
>>Swap files found:
>> In current directory:
>>1. .configure.swp
>> owned by: username dated: Fri Feb 19 15:12:46 2021
>> file name: ~username/src/mimedown/configure
>> modified: no
>> user name: username host name: shelhost.panix.com
>> process ID: 29440 (STILL RUNNING)
> ...
>
> This reminds me on a detail, that I discovered many years ago...
>
> It may be if interest to know that vim does not act collaborative.
>
> While other editors install a write lock on the edited file to inform all
> other possible editors that the file is currently being edited, vim is only
> willing to tell other vim instances that a file is being edited. This is done
> by vim via checking for the swap file that of course is unknown by other
> editors.

Vim also generates warnings that an edited file has changed changed. It
does so spontaneously, i.e. in advance of the next time you attempt a
save.

You can load the new file, or keep working with the existing buffer
with the knowledge it is out of sync.

jo...@schily.net

unread,
Feb 25, 2021, 7:16:24 AM2/25/21
to
In article <eli$21022...@qaz.wtf>,
Eli the Bearded <*@eli.users.panix.com> wrote:
>In comp.editors, <jo...@schily.net> wrote:
>> BTW: locking is not a property of the filesystem, but of it's implementation
>> so this is not limited to UNIX filesystems and if you use archaic and
>> non-POSIX remote filesystems like smbfs, you are lost. NFS supports it...
>
>Locking, in Unix, is done in the kernel. Network filesystems need to
>support network fowarding of locks for locks to work on that filesystem.
>NFS is a popular network filesystem, but not the only one. Userspace
>filesystems ("FUSE") like sshfs are where I suspect the most problems
>will exist.

Such filesystems typically use a user-space NFS server and thus could support
locking.

>When a loopback makes a file available via two different paths, how does
>that work vis-a-vis locks? I honestly don't know.
>
>Traditionally the device-id plus inode is a unique identifier. With a
>loopback, doesn't the device-id change?

I cannot speak for clone implementations, but the original lofs implementation
does not change fs-id nor inode number. So a command like tar that sees both
files may incorrectly assume a hardlink in case it does not also check the link
count from stat().

>(With some exotic filesystem features, like snapshots, device-id plus
>inode ceases to be a unique identifier. Since snapshots are read only,
>that's not really an editing problem, but I've seen it break "cp" having
>it wrongly claim to be copying a file to itself.)

Not all snapshots are readonly. ZFS allows writable snapshots - a feature
typically used for variants of a boot environment.


>in Netbsd at least, add st_mtimensec for uniquely identifying a file

st_mtimensec is nonstandard. Standard is statbuf.st_mtim.tv_nsec.

Anyway, this is not really usable for the purpose you proposed, since there
also is statbuf.st_mtim.tv_sec and since there is utimensat() that allows to
change the timestamp.

Also note that while Solaris (and probably BSD as well) traditionally uses
a time provider software in the kernel to make sure that no two traditionally
created time stamps are equal, this does not apply to Linux. A "touch *.c"
command on Linux frequently results in files with identical time stamps.

Also note that the nice thing with file locking is that an editor is able to
warn *before* the file did change, typically when you start editing the file.
I of course on the other side expect something like an error message
"Modified by another user" from any editor instead of overwriting the file.

Spiros Bousbouras

unread,
Feb 27, 2021, 12:33:13 PM2/27/21
to
On Wed, 24 Feb 2021 20:41:01 +0000 (UTC)
Eli the Bearded <*@eli.users.panix.com> wrote:
> In comp.editors, Spiros Bousbouras <spi...@gmail.com> wrote:
> > Ottavio Caruso <ottavio2006...@yahoo.com> wrote:
> > > [re-posted from vim...@googlegroups.com with edits; no replies over there]
> > There exists also gmane.editors.vim which is a gateway for the mailing list
> > at v...@vim.org .
>
> I subscribe to the vim mailing list. His post to vim...@googlegroups.com
> made it to the list and no one replied. There is probably no way, short
> of a patch, to get what Ottavio wants.

So v...@vim.org and vim...@googlegroups.com are the same list ? I didn't
know this.

[...]

> >> $ ls -al .vim/tmp/
>
> "ls -Al" might be better.
>
> >> $ (find .vim/tmp/ >/dev/null) && echo yes ||echo no
>
> find $HOME/.vim/tmp -type f -name \*.sw\?
>
> I know my record is about five swap files with the same initial name.
> For me, these come from as yet unamed files, and the names count
> backwards in letters: .swp, .swo, .swn, .swm, .swl, ...

:help swapname gives the details.

> > [ -z "$( find .vim/tmp/ -type f )" ] && echo Directory empty
> > This assumes that .vim/tmp/ may only have regular files.
>
> I'm not sure I follow "may only have regular files". Are you commenting
> about the possibilty of a non-swap file may be in there? I'd have said
> "will not have regular files" for that case.

Simply that the message Directory empty will be correct if the directory
.vim/tmp/ may only have regular files (apart from . ). This isn't what the
opening poster asked but I don't know what .vim/tmp/ may contain and I was
simply aiming for a reply which would hopefully steer him towards a useful
direction.

--
The phrase "Have you ever had sex on the beach ?" is ambiguous when spoken.
Reply all
Reply to author
Forward
0 new messages