Ambiguity between a stack command and a filename to execute

[harendra-kumar]

Separating this from issue #1394

Problem

If we have a file in the current directory whose name matches any of the stack commands then instead of running the command stack will execute the file as an interpreter. Here is an example:

cueball $ cat build 
-- stack --verbosity silent runghc

main = putStrLn "Hello there!"
cueball $ stack build
Hello there!

Currently we look at the argument and if it is a file and contains a valid stack comment we execute it. There is an ambiguity here about whether build should be treated as a command or a file.

A couple of ways to handle this:

Solution 1

An easy fix is to give preference to commands i.e. reserve the syntax stack build for the command build. If you want to execute a file with that name then you can say stack ./build which will work fine.

shebang case works fine with this solution. Consider executing a file named build having a #!/usr/bin/env stack line. The OS will execute a stack ./build command instead of a plain stack build (at least Linux has that behavior) and so a ./build command will not accidentally result in a stack build in the current directory.

Solution 2

We can distinguish the case by using a subcommand e.g. use #!/usr/bin/env stack runghc but the OS may not allow that. Linux treats stack runghc as the filename in this case and tries to execute that which obviously won't exist.

So the alternative is to use a distinct stack binary name let's say runstack for the purposes of an interpreter and then use #!/usr/bin/env runstack. runstack would be a symlink to stack. stack will behave differently when it is invoked as runstack. This will resolve the ambiguity cleanly.

Any other ideas?

[mgsloan]

Thanks for opening this issue! I like solution 1