Leading spaces before shebang break custom cargo runner

[andre-richter]

Problem

Newer versions of cargo fail to execute a test runner shell script which has leading spaces before the shebang.

Earlier versions of cargo were immune to this.

Steps

.cargo/config.toml:

[target.x86_64-unknown-linux-gnu]
runner = "./indented_bash_script.sh"

indented_bash_script.sh:

    #!/bin/bash

echo "I don't work

$ cargo test
error: test failed, to rerun pass '--lib'

Caused by:
  could not execute process `/tmp/foo/./indented_bash_script.sh /tmp/foo/target/debug/deps/foo-918a0726eb7b9123` (never executed)

Possible Solution(s)

No response

Notes

No response

Version

cargo 1.64.0 (387270bc7 2022-09-16)

[weihanglo]

I did reproduce it with the script you provided, but it is broken in every version of Cargo (on my macbook with either bash v3 or v5).

Would it be that the script itself is broken? I spotted that the last line echo is missing a ".

indented_bash_script.sh:

    #!/bin/bash

echo "I don't work

Though I got a slightly different error message.

/projects/issue11254/broken.sh: line 3: unexpected EOF while looking for matching `"'
/projects/issue11254/broken.sh: line 4: syntax error: unexpected end of file
error: test failed, to rerun pass '--bin xxx'

Is it possible to provide a minimal reproducible example? Also helps if we could have the full version info of cargo, how rust toolchain is installed, environment info (distro?), and bash version info. Thank you.

[weihanglo]

I am not sure why, but current beta and nightly channels are providing more error contexts, for example.

error: test failed, to rerun pass `--bin issue11254`

Caused by:
  could not execute process `/projects/issue11254/./roken.sh /projects/issue11254/target/debug/deps/issue11254-42ad338b1363e653` (never
 executed)

Caused by:
  No such file or directory (os error 2)

Could you also try it out on beta/nightly channel?

[epage]

Newer versions of cargo fail to execute a test runner shell script which has leading spaces before the shebang.

Under what situations are spaces legal? I've not personally dealt with this corner case but in looking around, wikipedia lists #! as the file's magic number which implies it has to be the first bytes.

I did reproduce it with the script you provided, but it is broken in every version of Cargo (on my macbook with either bash v3 or v5).

@andre-richter has anything else about the system changed? I wonder if something else broke this and the symptom is just visible through cargo since weihanglo couldn't reproduce it.

[andre-richter]

Sorry, it was a copy paste error that the closing " was missing in my original post.

With

#!/bin/bash

echo "I don't work"

I get

    Finished test [unoptimized + debuginfo] target(s) in 0.00s
     Running unittests src/lib.rs (target/debug/deps/foo-918a0726eb7b9123)
I don't work
   Doc-tests foo

running 0 tests

test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

With (four leading spaces)

    #!/bin/bash

echo "I don't work"

I get

    Finished test [unoptimized + debuginfo] target(s) in 0.00s
     Running unittests src/lib.rs (target/debug/deps/foo-918a0726eb7b9123)
error: test failed, to rerun pass '--lib'

Caused by:
  could not execute process `/tmp/foo/./indented_bash_script.sh /tmp/foo/target/debug/deps/foo-918a0726eb7b9123` (never executed)

I haven't found a resource yet whether leading spaces are legal. If the script with leading spaces is provided to bash or zsh, both don't care and execute it, so I thought it should be fine.
I know its an odd example. It results from the bash script being auto generated and the auto generation was introducing the spaces.

cargo from nightly version 2022-08-01 for example works in both cases, so I thought this was a regression.

[epage]

What if you try something with syntax that is incompatible with your runner (bash, zsh), like:

    #!/usr/bin/env python3

import pathlib

print("Running in {}".format(pathlib.Path.cwd()))
```

for me
```console
$ ./shebang.py  # without spaces
Running in /home/epage/src/personal/dump

$ ./shebang.py  # with spaces (it "hung", hence ^C)
^C./shebang.py: line 5: syntax error near unexpected token `"Running in {}".format'
./shebang.py: line 5: `print("Running in {}".format(pathlib.Path.cwd()))'
```

[andre-richter]

Attached is a minimal reproducer. In rust-toolchain.toml, change to 2022-08-01 to make it work (again). Tested on Ubuntu 22.04.

foo.zip

[ehuss]

I think this is a duplicate of rust-lang/rust#101511, and based on that discussion it looks like it is "wontfix". This is due to a change in glibc.

[weihanglo]

Labelled this as such to be aligned with rust-lang/rust#101511.

@rustbot label +P-low +S-blocked-external -S-needs-info