env -S is platform-specific

[simonmichael]

On three entries (crappy-flappy, fifteen, pong) I just responded

Unfortunately I think we'll have to disallow env -S as it's not available on GNU/Linux (at least not until coreutils 9.x).

And in README I just added

Tips for rule 4 (runnability):

• We must avoid arguments on the shebang line and env -S, which is not available on GNU/Linux, or at least not before coreutils such-and-such.

I imagine this will be bitter news for some. But achieving programs that "just work" is a core principle and very much part of the challenge, and env -S seems incompatible with this, alas.

What are your thoughts, do you see other options ?

[simonmichael]

I modified play so at least they are runnable that way.

[simonmichael]

https://unix.stackexchange.com/questions/399690/multiple-arguments-in-shebang

[TristanCacqueray]

Perhaps lines without expressions (like comment or import) should not contribute to the 10 lines limit? That way, the games have room to declare the cabal/stack script preamble, and no longer need a separate Import file.

Otherwise, I think we should allow env -S since it enables using the first line, and more importantly, because games already rely on it.

[simonmichael]

For this round they do contribute, because it makes for a more realistic comparison with other languages (such as BASIC) and because the other entrants have worked to this constraint.

But.. we have already allowed dropping the shebang line as long as decent runnability is still maintained, eg by providing a reliable build command in the comments, and a couple of entries have relied on this. This is partly why the play script exists, to provide and paper over the required special invocations. (Also we have allowed unlimited comments at the end.)

I guess accepting special invocations to work around a missing shebang line, or a shebang line with arguments, are equivalent, and the status quo.

On the other hand it seems to mean that everybody working hard to fit the constraint, need not have bothered, and henceforth there's no point in putting any shebang line. This is slightly against the goal of challenging ourselves to produce self-contained haskell games comparable to classic BASIC games.

[bradrn]

Forgive my ignorance, but would there be anything wrong with using #!/usr/bin/sh instead? Or does env do something special? I used it mostly because other people were using it, so I assumed it was the right thing to do.

[simonmichael]

/usr/bin/env PROG is considered a little more robust, because sh or other PROG can be installed at different paths on different systems. env searches $PATH for it.

[gergoerdi]

In my case, I used env -S like this:

#!/usr/bin/env -S stack script --resolver=lts-19.21 --package ansi-terminal-game
-- stack script --ghc-options -threaded

So as you can see, I'm not really saving a line because I use up a second line for the ghc-options. However, I can't fit both --ghc-options -threaded and all the other Stack options into one --stack script line because then it goes over the 80-column limit.

Anyway I've found out that on LTS 20.10, it seems ansi-terminal-game no longer requires -threaded so I've removed env -S from my programs.