Asdf: rm: .tool-versions.bak: No such file or directory

Created on 17 Apr 2019  路  7Comments  路  Source: asdf-vm/asdf

Steps to reproduce

  1. Open new terminal window in iTerm2
  2. Restart macOS

Expected behavior

The terminal window to open after login with no error messages.

Actual behavior

The following messages appear:

Session Contents Restored

Last login: Wed Apr 17 10:40:29 on ttys006
rm: /Users/dnicolson/.tool-versions.bak: No such file or directory
rm: /Users/dnicolson/.tool-versions.bak: No such file or directory

Sometimes it does not appear, most commonly it appears only once and not twice.

Environment

OS: macOS 10.14.4 (18E226)

asdf version: 0.7.1

iTerm2 3.2.7
fish 3.0.0

I have the following in my config.fish file:

source /usr/local/opt/asdf/asdf.fish
asdf global ruby 2.6.2
asdf global nodejs 11.13.0
asdf global python 3.6.8 2.7.15

I think it could be related to this:
https://github.com/asdf-vm/asdf/blob/1d43a052febf200d26e4992dca29aeb769876ebf/lib/commands/version_commands.sh#L41

All 7 comments

I'm on the same version of OSX, and I've got a similar setup, but I've not come across that issue. What happens if you run those asdf global commands manually in your fish shell? Does the error occur then? This is odd because that backup file should always exist before the rm command is run.

Running those commands in a shell results in no error.

The error only occurs when iTerm is restoring a session.

This is quite weird, I suppose we could add -f to rm but this should not be happening in the first place.

Also, why you have adsf global in config.fish? asdf global should only be run once, not every time you open a new shell. Although it should in principle not create any error, it will slow down your shell startup for no good reason.

Yes, if our code is being executed as it should rm should always come after the sed command that creates the file. So this should never happen. But some how with iTerm session restoration it is.

Echo what @danhper said, if you want to get things working just don't use asdf global in your config.fish. Once you've got a .tool-versions file in your home directory with the versions you want you don't need to run asdf global ever again. Running asdf global when starting up a shell isn't something that asdf users typically do.

It is due to a race condition, the following can trigger the error in a bash shell:

asdf global ruby 2.6.2 &
asdf global ruby 2.6.2 &
asdf global ruby 2.6.2 &

Yes, that would definitely cause problems. And it may not be just asdf, it may be caused by sed as well. I suppose we could devise some sort of locking mechanism to fix this. But in practice this is something that should never be done. There is no reason to run concurrent version changes on the same file. Just make sure they are run sequentially.

Ok, so I suppose the issue with iTerm restoring the session is that it runs multiple shells (one per tab I suppose) at the same time and there is therefore a race condition.
This is really an edge case, which I think is better fixed on the user side.
In your case, I suggest you simply remove asdf global from config.fish.

Was this page helpful?
0 / 5 - 0 ratings