New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Ambiguity between a stack command and a filename to execute #1471

Closed
harendra-kumar opened this Issue Dec 5, 2015 · 1 comment

Comments

Projects
None yet
2 participants
@harendra-kumar
Collaborator

harendra-kumar commented Dec 5, 2015

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

This comment has been minimized.

Collaborator

mgsloan commented Dec 6, 2015

Thanks for opening this issue! I like solution 1

@mgsloan mgsloan added the type: bug label Dec 7, 2015

@mgsloan mgsloan added this to the P2: Should milestone Dec 7, 2015

harendra-kumar added a commit to harendra-kumar/stack that referenced this issue Dec 11, 2015

Fix commercialhaskell#1471 stack commands and file name conflicts
We were prioritising execution of a file over stack commands if a filename in
the current directory was the same as a stack command. With this fix we first
try a stack command, then an external command stack-<command> and if those fail
we look for a file in the current directory to execute in interpreter mode.

If we intend to execute the file we can specify the path like ./filename.

I had to refactor `main` to make this work. I tried to minimise the refactoring
and limit the scope to only this fix. Main looks better and modular now.

closes commercialhaskell#1471

mgsloan added a commit that referenced this issue Dec 12, 2015

Merge pull request #1493 from harendra-kumar/fix-ambiguous-commands
Fix #1471 stack commands and file name conflicts
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment