Refactor in-place strips shebangs, only if given prefixed path argument

[pbrisbin]

When given a path argument with some kind of prefix:

• ./foo/bar
• ../foo/bar
• /foo/bar

HLint with --refactor will strip shebangs:

% head tools/promote-restylers
#!/usr/bin/env stack
{- stack script
  --resolver lts-16.10
-}
-- vim: ft=haskell
module Main
    ( main
    )
where

% stack exec -- hlint --refactor --refactor-options=-i ./tools/promote-restylers
% head tools/promote-restylers
  
{- stack script
  --resolver lts-16.10
-}
-- vim: ft=haskell
module Main
    ( main
    )
where

But, if given a path without any such prefix:

• foo/bar

It works fine:

% head tools/promote-restylers
#!/usr/bin/env stack
{- stack script
  --resolver lts-16.10
-}
-- vim: ft=haskell
module Main
    ( main
    )
where

% stack exec -- hlint --refactor --refactor-options=-i tools/promote-restylers 
% head tools/promote-restylers
#!/usr/bin/env stack
{- stack script
  --resolver lts-16.10
-}
-- vim: ft=haskell
module Main
    ( main
    )
where

% stack exec -- hlint --version
HLint v3.1.6, (C) Neil Mitchell 2006-2020

By the way, Brittany currently has the same bug, and it feels too weirdly specific to not be the same underlying cause.

[ndmitchell]

Running hlint --refactor with -i calls:

refactor ..\hlint\Sample.hs -i --refact-file empty.txt

Assuming that empty.txt has the contents [].

I tried in a bunch of configurations and it didn't strip the first line away. Could you try that more direct command line, and then if necessary we can raise a bug at https://github.com/mpickering/apply-refact/.

I've also made it so --verbose prints out the refactor command line, since before it was a bit hard to figure out.

CC @zliu41

[pbrisbin]

Definitely makes sense this would be a bug in rafactor.

% echo '[]' > empty.txt
% cat > example <<'EOM'
\`heredoc> #!/usr/bin/env stack
\`heredoc> {- stack --resolver lts-16.10 script -}
\`heredoc> module Main (main) where
\`heredoc> main :: IO ()
\`heredoc> main = putStrLn "hi"
\`heredoc> EOM
% chmod +x example
% ./example
hi
% stack exec refactor -- --version
v0.7.0.0%   

It indeed reproduces with ./example:

% stack exec refactor -- ./example --refact-file empty.txt
Applying 0 hints

{- stack --resolver lts-16.10 script -}
module Main (main) where
main :: IO ()
main = putStrLn "hi"

And works fine with example:

% stack exec refactor -- example --refact-file empty.txt
Applying 0 hints
#!/usr/bin/env stack
{- stack --resolver lts-16.10 script -}
module Main (main) where
main :: IO ()
main = putStrLn "hi"

Note that it's not a "first line" problem; it's specifically a shebang. Everything works fine in files without shebangs, even when invoked as ./example:

% tail -n +2 example | sponge example
% cat example
{- stack --resolver lts-16.10 script -}
module Main (main) where
main :: IO ()
main = putStrLn "hi"
% stack exec refactor -- ./example --refact-file empty.txt
Applying 0 hints
{- stack --resolver lts-16.10 script -}
module Main (main) where
main :: IO ()
main = putStrLn "hi"
%

% { echo "#\!something"; cat example; } | sponge example
% cat example
#!something
{- stack --resolver lts-16.10 script -}
module Main (main) where
main :: IO ()
main = putStrLn "hi"
% stack exec refactor -- ./example --refact-file empty.txt
Applying 0 hints

{- stack --resolver lts-16.10 script -}
module Main (main) where
main :: IO ()
main = putStrLn "hi"

FWIW, since this is so related to the actual syntax used to name the file argument, it's possible it's Linux-only and the windows-style ..\ paths don't trigger it either. 🤷

^ Mostly adding this here to keep it in context. I'll report it over on apply-refact soon (unless someone else does first). Feel free to close this Issue if you think that makes sense.

[ndmitchell]

I'm ambivalent whether it gets moved to apply-refact and left open here with a link to it there, or closed here - whatever people prefer. But definitely should end up with apply-refact so they can fix it :)

[pbrisbin]

mpickering/apply-refact#88. I'm also ambivalent on if we close this Issue or not.

[zliu41]

I tried in a bunch of configurations and it didn't strip the first line away.

Since 0.8.1.0, apply-refact no longer attempts to parse the target file if there's no hint. It just prints the target file as it is. So this problem does not occur if there's no hint. I think @pbrisbin was using an older version.

This is a ghc-exactprint bug, and I raised alanz/ghc-exactprint#92.