Where in codebase is first comment in file parsed when executing Stack script via shebang?

[Martinsos]

I hope you don't mind me asking, but I am trying to find a piece of code that parses the first comment from the .hs file that is provided to stack as a script.

I am talking about https://docs.haskellstack.org/en/stable/GUIDE/#script-interpreter functionality.
I looked into https://github.com/commercialhaskell/stack/blob/master/src/main/Main.hs and I see that https://github.com/commercialhaskell/stack/blob/master/src/Stack/Options/ScriptParser.hs is used to parse the options and that https://github.com/commercialhaskell/stack/blob/master/src/Stack/Script.hs takes those options and executes script.

This makes sense in the case when stack is called directly, e.g. stack script myScript.hs.
However, in the case when it is called via shebang, I am assuming that stack first needs to get hold of that first comment in the .hs file, be it one-line or multi-line comment -> so there must be some step where that comment is parsed and then the usual flow of the code goes (parsing the options, calling scriptCmd from Script.hs.).
I just can't find that piece of code -> thank you for any directions!

[ketzacoatl]

This makes sense in the case when stack is called directly, e.g. stack script myScript.hs.

I believe the answer to your question is that this is the only way stack script myScript.hs is called.

However, in the case when it is called via shebang, I am assuming that stack first needs to get hold of that first comment in the .hs file, be it one-line or multi-line comment

AFAICT, the shell is actually responsible for parsing the shebang bits, and translates that to the stack script myScript.hs as you noted above.

[Martinsos]

@ketzacoatl thanks for the answer!
I see now that my question was somewhat unclear -> what I actually wanted to ask is, when the stack script myScript.hs command is called, where is the piece of code in Stack that reads the first Haskell comment from myScript.hs, the one containing info on how the script is to be called, e.g.:

{- stack
  script
  --resolver lts-6.25
  --package turtle
  --package "stm async"
  --package http-client,http-conduit
-}

[ketzacoatl]

@Martinsos, ah, thank you for clarifying!

I went digging for that myself, and while I ran in circles at first, I eventually located this gem:
https://github.com/commercialhaskell/stack/blob/18634d26ba739438438e5b454c9d50a498801113/src/Data/Attoparsec/Interpreter.hs

That defines interpreterArgsParser and getInterpreterArgs, the first of which is used by the latter. getInterpreterArgs is then used in Main, see here for example:

stack/src/main/Main.hs

Lines 524 to 538 in 255cd83

	runInterpreterCommand path stackArgs fileArgs = do
	progName <- getProgName
	iargs <- getInterpreterArgs path
	let parseCmdLine = commandLineHandler currentDir progName True
	-- Implicit file arguments are put before other arguments that
	-- occur after "--". See #3658
	cmdArgs = stackArgs ++ case break (== "--") iargs of
	(beforeSep, []) -> beforeSep ++ ["--"] ++ [path] ++ fileArgs
	(beforeSep, optSep : afterSep) ->
	beforeSep ++ [optSep] ++ [path] ++ fileArgs ++ afterSep
	-- TODO show the command in verbose mode
	-- hPutStrLn stderr $ unwords $
	-- ["Running", "[" ++ progName, unwords cmdArgs ++ "]"]
	(a,b) <- withArgs cmdArgs parseCmdLine
	return (a,(b,mempty))

That was fun, thanks for the challenge to figure out :)

[Martinsos]

Thanks @ketzacoatl that is it!! Glad you had fun in the process :D.
I haven't figured out that runInterpreterCommand was focused on running stack scripts, I thought maybe it is doing something with ghci, but this now makes sense. I also wasn't aware that import Data.Attoparsec.Interpreter is importing Stack code, I assumed it is some kind of attoparsec stuff.

[ketzacoatl]

I also wasn't aware that import Data.Attoparsec.Interpreter is importing Stack code, I assumed it is some kind of attoparsec stuff.

That's a great point! In this case, the import Data.Attoparsec.Interpreter is importing the stuff exported by a module Data.Attoparsec.Interpreter. That module could come from any package.. and in this case, it's not defined in the attoparsec package, but here in stack's code (with a file that has the module declaration for Data.Attoparsec.Interpreter), and while I didn't check for it, I would guess there is a entry for that module in the stack cabal file (so the build can find the module). This is a typical way of extending an existing library without changing the upstream package.