Support for other task languages

[dschep]

Many markdown renderers, including Github&Gitlab Flavored markdown support specifying a language for syntax highlighting.

It'd be awesome to use this to specify a different shell/interpreter for tasks

eg,

```bash
cp foo bar
```

will explicitly run bash

and

```python
import json
print(json.load(open('foobar.json')))
```

would invoke python instead

[joerdav]

I think this is an interesting idea, and intuitive. The only concern I have is whether this is something that makes sense in xc, being a task runner equivelant to Make or npm run but more discoverable. Welcome your thoughts on some real use cases.

For example currently my main use for xc is the document things such as how to deploy a project, or how to build it.

[waldyrious]

a task runner equivelant to Make or npm run but more discoverable

A bit off topic, but I have to say that this description is IMO much clearer than the current one in the README:

a task runner designed to maximise convenience, and minimise complexity.

Would a PR changing the latter to (some variant of) the former be considered?

[joerdav]

@waldyrious I'm open to contributions, if you open a PR we can spitball some alternatives. It's hard to explain exactly what something does in such few words, but it's valuable once you get it right!

[dschep]

I've all too often had a task runner (npm or make) just call a python script, so implementing this would remove that intermediary step.

For example... does this repo implement update-nix.sh as a script called by xc because interp doesn't implement all the shell/bash features it requires? If so and if we(I say we, bc I'd be willing to try and implement this if you like the idea) were to implement this, you could remove that script and inline it into README.md with a ```bash gate to have it invoke real bash.

[joerdav]

@dschep I'm thinking on this, and I'm in two minds about it. The purpose of xc is so that your "useful commands runner" and the documentation for them are stored in the same place.

It also means that even if xc is not installed someone could find use in the Tasks section. Say someones task contained a python script, would they not have to copy it out into a file then run it, rather than copying it straight into their shell?

Would defining a whole python script in a task, be too verbose?

Just jotting down my thoughts. I'll keep this issue open, for commenting.

[waldyrious]

Just a small note from someone casually following the discussion: since the rendered markdown only uses the language specification for syntax highlighting, would it make sense to require shebangs (or for tasks defined in languages other than bash, just to make things explicit in case xc isn't available and people want to run the commands manually (so they'll know which interpreter to invoke)?

#!/usr/bin/env python 

print("foo")

Note that this would enable straight copy-paste into a terminal if the #! is not copied, i.e.

/usr/bin/env python

print("foo")

(But it does feel pretty hacky/brittle...)

[joerdav]

@waldyrious It seems a better approach to drive which interpreter is used from the shebang line, more discoverable, but like you say I still think that it detriments the experience of someone coming to the README without a knowledge of xc, apposed to if it was a smaller task that calls a python script directly.

[dschep]

I like that idea too @waldyrious !

[jasonmorganson]

Just uses that method: https://just.systems/man/en/chapter_40.html

[joerdav]

Started tinkering on this at https://github.com/joerdav/xc/tree/other-languages