Ambiguity between a stack command and a filename to execute #1471
Labels
Milestone
Comments
Thanks for opening this issue! I like solution 1 |
harendra-kumar
added a commit
to harendra-kumar/stack
that referenced
this issue
Dec 11, 2015
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
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
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:
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 saystack ./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 astack ./build
command instead of a plainstack build
(at least Linux has that behavior) and so a./build
command will not accidentally result in astack 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 treatsstack 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?
The text was updated successfully, but these errors were encountered: