#21137 inconsistencies in workdir handling with in-workspace execution and shell backend Issue created by tdyas A user testing the in-workspace execution feature (

experimental_workspace_execution

) found inconsistencies in how the working directory ordinarily configured by default for

shell_command

/

adhoc_tool

conflicted with how output capture is performed and where execution actually occurs. Namely, output capture for in-workspace execution does not use the root of the sandbox directory as the base for

output_files

/

output_directories

.

shell_command

normally sets the working directory to the directory where the

BUILD

file containing the applicable target lives. This works fine for ordinary execution in a sandbox (whether local, Docker, or remote) because the files to be captured should be in the same working directory as used for execution. With in-workspace execution, however, there is still a "sandbox" for materialized inputs and outputs to be captured but it is an entirely different directory than the workspace directory in which the process will be executed. Yet, the working directory used in the workspace will still be applied to output paths to be captured, even though no such working directory exists in the sandbox. Another issue is the fact that in-workspace execution even executes in a subdirectory in the first place. Given the sandbox and workspace working directory are different, it might be worth considering to just default the working directory for in-workspace executions to the root of the repository even for targets defined in a subdirectory. This will need some research to come up with a proposal since the REAPI specifies that output paths are relative to the working directory not relative to the root of the execution sandbox. pantsbuild/pants