Asdf: duplicated shims and .tool-versions file suffixed with `-e-e-e`

[bschaeffer]

[akeating]

I've seen this a before. Here is a snippet:

> ls ~/.asdf/shims/
-rwxr-xr-x    1 adam  staff   142B Oct 12 11:36 ncu-e-e-e-e
-rwxr-xr-x    1 adam  staff   140B Oct 12 11:39 ng
-rwxr-xr-x    1 adam  staff   196B Oct 12 11:36 node
-rwxr-xr-x    1 adam  staff   137B Oct 12 11:36 node-e-e-e-e-e-e-e-e-e-e-e
-rwxr-xr-x    1 adam  staff   195B Oct 12 11:36 npm
-rwxr-xr-x    1 adam  staff   185B Oct 12 11:39 npm-check-updates
-rwxr-xr-x    1 adam  staff   156B Oct 12 11:36 npm-check-updates-e-e-e-e
-rwxr-xr-x    1 adam  staff   136B Oct 12 11:36 npm-e-e-e-e-e-e-e-e-e-e-e
-rwxr-xr-x    1 adam  staff   165B Oct 12 11:36 npx
-rwxr-xr-x    1 adam  staff   136B Oct 12 11:36 npx-e-e-e-e-e-e-e-e-e-e

I think it's related to some _filename too long_ errors. Will try to produce some steps to repro.

[vic]

Smells like a bug-e-e-e spirit

[vic]

yes, please, try to find a way to properly reproduce this :)

[akeating]

Some quick testing this morning ...

> asdf --version
v0.4.0
> rm -rf ~/.asdf/shims/*
> asdf current nodejs
8.7.0 (set by /Users/adam/.tool-versions)
> asdf reshim nodejs
> ls ~/.asdf/shims/
-rwxr-xr-x   1 adam  staff   171B Oct 23 07:21 ncu
-rwxr-xr-x   1 adam  staff   142B Oct 23 07:21 ncu-e
-rwxr-xr-x   1 adam  staff   140B Oct 23 07:21 ng
-rwxr-xr-x   1 adam  staff   196B Oct 23 07:21 node
-rwxr-xr-x   1 adam  staff   167B Oct 23 07:21 node-e
-rwxr-xr-x   1 adam  staff   195B Oct 23 07:21 npm
-rwxr-xr-x   1 adam  staff   185B Oct 23 07:21 npm-check-updates
-rwxr-xr-x   1 adam  staff   156B Oct 23 07:21 npm-check-updates-e
-rwxr-xr-x   1 adam  staff   166B Oct 23 07:21 npm-e
-rwxr-xr-x   1 adam  staff   170B Oct 23 07:21 npx
-rwxr-xr-x   1 adam  staff   141B Oct 23 07:21 npx-e
-rwxr-xr-x   1 adam  staff   143B Oct 23 07:21 uuid
-rwxr-xr-x   1 adam  staff   143B Oct 23 07:21 yarn
-rwxr-xr-x   1 adam  staff   146B Oct 23 07:21 yarnpkg

Running asdf reshim nodejs again increases the depth of the -e chain to, e.g. -e-e-e and so on.

[vic]

Hello @akeating I just tried with asdf master and followed your steps but no -e shims were created, I also grepped for -e just looking for anything obvious that would be appending that to the shim names but found nothing.

so I made a duplicate-shims branch containing a test for reshim command. Would you be so kind as to clone that branch and run bats test? could you give us more info on what OS/filesystem are you working on, in case the test fails for you? Thanks :)

[Jwashton]

I've been seeing this problem on MacOS High Sierra using APFS. I just now cloned that branch, ran all the tests, and saw them pass, including the new one. This is kind of disappointing, because my shims directory is full of -e artifacts.

[akeating]

I'm also on MacOS High Sierra using APFS if that helps to know and these tests also pass on my laptop.

[vic]

@akeating Hm.. I'm still on 'macOS Sierra' (10.12.6)

@Jwashton hm.. so the test doesn't even reproduce it

Is this happenning only for nodejs plugin or with any other?

[Jwashton]

I think I found it, maybe? Maybe someone who's actually familiar with bash can confirm/investigate further.

On this line and this line the calls to sed don't have a space between the -i flag and the empty-string extension getting passed to it. Is it at all possible that some versions of bash tokenize the command differently so that the empty string is ignored and the next token -e gets used as the backup extension?

Adding a space between the -i and the '' seems like a promising fix on my box. I rm -rf'd all the shims, and I haven't seen any -e's come back since then. @vic If this explanation seems reasonable then I'd be willing to submit a pull request with those two spaces.

[vic]

@Jwashton sounds pretty much like that's what is causing it. Perhaps the sed that comes with the latest macOS behaves like what you mention.

Now, how could we have a test that makes sure we don't have a regression, the test I did verifies only one shim exists for the dummy plugin, could you try modifying it to make it fail first on your env?

Feel free to send a PR :)

[Jwashton]

I'm not sure what to do about testing. One reason I'm doubtful of the correctness of this fix is that removing the spaces again isn't enough by itself to bring the -e's back. Before I touched those two lines I could reliably get a new -e every time I ran asdf reshim elixir. Now I'm not getting them back even without the space. There's more to this problem that I'm not understanding.

[Jwashton]

Potentially interesting: The original issue was with -e's showing up at the end of the .tool-versions file. The same sed -i -e problem might apply in that case too.

[vic]

@Jwashton omg! haha yes the original issue title mentioned -e on the .tool-versions file, nice catch, we should solve both cases (same issue) here.

[akeating]

> touch foo
> sed -i -e "s/oo/ff/" foo
> ls
-rw-r--r--   1 adam  staff     0B Oct 25 16:58 foo
-rw-r--r--   1 adam  staff     0B Oct 25 16:57 foo-e

[bschaeffer]

FYI had no idea this was the issue. Thought it was just some undocumented config file...

[Stratus3D]

@Jwashton that PR looks great!