#18256 `shfmt` assumes downloaded executable will be named `shfmt_{version}_{platform}`, and breaks if it isn't Issue created by danxmoran Describe the bug To reduce network transfer & flakiness during CI, we've pre-cached all the "external" tools used by Pants in our executor container. As part of this I've overridden the

url_template

for each tool to use a

file://

URL. The URL-paths I ended up using in the image were "simplified" from the defaults - for example, I have:

[shfmt]
url_template = "file:///opt/pants-tools/shfmt/{version}/shfmt"

When CI runs with this config, it fails with:

Error launching process: Os { code: 2, kind: NotFound, message: "No such file or directory" }

I `ssh`'d into one of the executors that hit this failure, and looked inside the failing sandbox. There I saw: 1. The

shfmt

binary was in the sandbox, and runnable 2. According to

__run.sh

, Pants was trying to invoke

./shfmt_v3.2.4_linux_amd64

instead of plain

./shfmt

I believe this is happening because the

shfmt

subsystem defines

generate_exe

to hard-code the same naming pattern as is used in the default `url_pattern`: pants/src/python/pants/backend/shell/lint/shfmt/subsystem.py Lines 56 to 58 in </pantsbuild/pants/commit/ac9e27b142b14f079089522c1175a9e380291100|ac9e27b> I think things would operate as expected if we deleted that

generate_exe

override, since the

shfmt

download is the executable itself. Pants version 2.15.0rc4 OS Observed on Linux Additional info https://app.toolchain.com/organizations/color/repos/color/builds/pants_run_2023_02_15_12_48_26_897_660d20c55cc041fbb63374c79a4402b0/ pantsbuild/pants

#18256 `shfmt` assumes downloaded executable will be named `shfmt_{version}_{platform}`, and breaks if it isn't Issue closed as completed by danxmoran pantsbuild/pants