Support for shebang

[MikkelHJuul]

It would be neat (if one would like to use cue for scripting) to be able to run the file using syntax: cue <file> <name> just like one would call cue cmd <name> this allow for portable usage of cue using the linux builtin portable shebang syntax. ie. ./<file> <name> for calling a given command(<name>) in a file(<file>) if the file's first line is #!/usr/bin/env cue.

This requires the cue <file> <name> to validate the existence of command: <name>: #Command in the given .cue-file before defaulting to the current error message.

The installation of cue itself (as with any go programs) makes the non-portable shebang (#!/direct/path/to/cue cmd) not particularly useable. As it would be very unlikely to be able to "hit" the cue executable directly in any environment. Also the current implementation of cue cmd dissallow file-targetting.

It is therefore required that one uses the portable version shebang (#!/usr/bin/env cue) which unfortunately removes the possibility of the user script controlling the "second" argument (set to the file) when cmd/cue expects this to be a command argument (cmd).

The minimum implementation is simply: run cue without a command only a cue-file (whatever it's name), must comply to command: [<name>]: _, (uncertainty on which additional files to load, if any, package?).

There may be some uncertainty on the _tool.cue-suffix vs. package loading etc. in fact this is a possibility of moving away from that syntax completely, to use direct file references in stead of implicit cwd runtime environment "enrichment" via magically named *_tool.cue-files. it does however increase the call syntax to require the file when running, such that the required syntax is cue cmd <file> <name> == cue <file> <name> (should calling without a file fallback to cwd as it currently does?). however the direct file helps picking the package/dependencies (multiple packages in the same folder? disallow directory loading? target multiple files? how should this be done best?)

I know cue as a scripting language is not particularly a priority, this is only a nice to have, not a need to have.

[myitcv]

Interesting thought. I haven't given this a huge amount of thought (will come back to it), but I will note in passing that we have plans to replace cue cmd with cuerun, which might make a solution in this space more "natural".

[myitcv]

Linking to #1325 for the cuerun proposal