:pre not working on macOS, missing /var/tmp/vi.recover

[kajukenbo]

:preserve does not seem to work with macOS/homebrew v7.4.26 using the default /var/tmp/vi.recover location.

Low priority.

Works normally on GNU/Linux (compiled).

Simple missing directory:

$ ovi -r
Error: recdir: /var/tmp/vi.recover: No such file or directory

~
:pre
Preservation of this file not possible

:set recdir?
recdir="/var/tmp/vi.recover"

$ ls -la /var/tmp/vi*
ls: /var/tmp/vi*: No such file or directory

/var/tmp does exist so maybe add mkdir -p /var/tmp/vi.recover to the build process somehow?
Appears to work like I'd expect once I do that manually.

mkdir -p /home/kajukenbo/vi.recover and set recdir="/home/kajukenbo/vi.recover" also seems to work.

Thanks as always for keeping vi alive.

[johnsonjh]

@kajukenbo

Thanks for the report, confirmed.

A quick search shows that /private/var/tmp/ is probably the correct location for macOS. The /tmp is a symlink to /private/tmp and it looks like /var/tmp is a hard link to /private/var/tmp but I have double check to be sure.

Ideally, the preserve directory should be something that doesn't get deleted too often, and isn't in a private namespace, so you can run the recover script on unclean reboot. However, (since nobody really runs it anymore), if we do use a private namespace, I can just have OpenVi itself make the subdirectory if it's missing.

So, let me think a bit more about how to best handle it, but a fix should be easy enough and will come soon.

[kajukenbo]

Just a heads-up, this now (?) seems to occur with Linux builds on compiled OpenVi 7.4.27.
I just compiled it on a new install to make sure it was not my imagination.

Maybe it worked before since I was using nvi and it automatically made /var/tmp/vi.recover beforehand?

Version 7.4.27 (OpenVi) 09/07/2023.

:set recdir?
recdir="/var/tmp/vi.recover"
:pre
Preservation of this file not possible.

The work-around still seems to be:

# sudo mkdir -m 1777 -p /var/tmp/vi.recover

[johnsonjh]

@kajukenbo

I'm not really sure if there is an equivalent to this directory on macOS that exists by default in the current versions, that is, something that is a shared amongst users and doesn't get cleaned up automatically too often, or on reboots.

There does seem to be a /private/var/tmp directory, which I think doesn't get cleaned out on reboot. It's only for the current user, but I think that's OK.

I'll look into it, but on macOS, I think using /private/var/tmp as _PATH_PRESERVE for recdir could work.

In the meantime, you can try adding set recdir="/private/var/tmp" to your .(n)exrc file and seeing if that works the way you want.

[kajukenbo]

Update, it's back when I switched machines.
Not the end of the world, since I can still just mkdir -p /var/tmp/vi.recover

BTW, I still get Error: recdir: "/private/var/tmp": No such file or directory when trying the .{n}exrc setting above, likely for the obvious reasons.

$ system_profiler SPSoftwareDataType | grep -i version ; brew config | grep HOMEBREW ; echo "ver" | oex -s ; oex -r
      System Version: macOS 14.7 (23H124)
      Kernel Version: Darwin 23.6.0
HOMEBREW_VERSION: 4.4.0
HOMEBREW_PREFIX: /opt/homebrew
HOMEBREW_CASK_OPTS: []
HOMEBREW_EDITOR: vi
HOMEBREW_MAKE_JOBS: 10
Version 7.5.29 (OpenVi) 04/25/2024
Error: recdir: /var/tmp/vi.recover: No such file or directory

$ brew info openvi
==> openvi: stable 7.5.29 (bottled), HEAD
Portable OpenBSD vi for UNIX systems
https://github.com/johnsonjh/OpenVi
Installed
/opt/homebrew/Cellar/openvi/7.5.29 (14 files, 588KB) *
  Poured from bottle using the formulae.brew.sh API on 2024-05-21 at 10:27:21
From: https://github.com/Homebrew/homebrew-core/blob/HEAD/Formula/o/openvi.rb
License: BSD-3-Clause
==> Dependencies
Required: ncurses ✔
==> Options
--HEAD
	Install HEAD version
==> Analytics
install: 8 (30 days), 28 (90 days), 260 (365 days)
install-on-request: 8 (30 days), 28 (90 days), 260 (365 days)
build-error: 0 (30 days)

[johnsonjh]

I'll look into this this week I hope, see what the best appropriate place is.

[kajukenbo]

@johnsonjh

No big deal, sir.
The work-around is trivial either way.

Thanks for your efforts.