Stabilize `[script(…)]` attribute #2260

casey · 2024-07-18T06:02:39Z

A [script(…)] attribute was added in #2259. See #1479 for discussion.

The attribute is currently unstable.

Before stabilization:

Make sure it's tested and has the right semantics.
Is script the right name?
Consider renaming "shebang recipes" in readme to "script recipes" and consider both shebang recipes and recipes with the script attribute as cases of script recipes.
Add a script-interpreter setting and allow an empty [script] attribute.

The text was updated successfully, but these errors were encountered:

linux-china · 2024-07-19T01:48:50Z

Is it possible to add ext name support for script annotation:

[script("pluto")]
[extension: 'lua']
foo:
  print(os.getenv("NICK"))

And following code is clean.

[script("pluto", "lua")]
foo:
  print(os.getenv("NICK"))

If you use JavaScript/Types, lots of extension names: js, cjs, mjs, ts, mts.

[script("bun", "ts")]
foo:
  let name: string = "jackie"
  console.log(name)

casey · 2024-07-19T02:03:52Z

I think that would probably be confusing, and using an additional attribute for the extension isn't much of a burden. But note that an extension is only required if the interpreter requires one. Most don't, in fact the only interpreters I know if that will fail without the correct extension is cmd.exe and PowerShell.

casey · 2024-07-20T00:19:52Z

Also, one more reason for not stabilizing the [script] annotation right away: Since this is a new attribute, while it is unstable it is possible in a backwards compatible way to change the semantics of recipes with that attribute. In #1413 I discussed some shortcomings with shebang recipes, and discussed a lot of somewhat radical ideas for changing the semantics of recipes with a [script] attribute. Ultimately I don't think any of those were great ideas, and I don't have any particular ideas for changing the semantics of recipes with the [script] attribute, but I think it's a good idea to let it stew for a bit in case anyone can come up with some.

g9wp · 2024-07-24T06:03:43Z

I wonder if there's a way to conditionally includes settings or variables to recipt like the cfg_attr in rust.

  SH := "sh"

  [cfg_attr(unix, ```
     set shell := ["bash", "-c"]   // setting 
     SH := bash                    // variable
  ```)]
  [cfg_attr(windows, ```
     set shell := ["cmd", "/c"]
     SH := cmd
  ```)]
  [cfg_attr(cygwin, ```
     set shell := ["bash", "-c"]   // overwrite windows
     SH := cygwin
     CYGWIN := 1
  ```)]
  [cfg_attr(true, ```
     set unstable
     UNSTABLE := 1
  ```)]
  foo:
    echo {{SH}} // print "cygwin" or "bash" or "cmd"
    echo {{CYGWIN}} // print "1" or ""
    echo {{UNSTABLE}} // print "1"
  
  bar:
    echo {{SH}} // print "sh"
    echo {{CYGWIN}} // print ""
    echo {{UNSTABLE}} // print ""

casey · 2024-07-24T15:05:55Z

@g9wp This seems unrelated to the [script] attribute.

g9wp · 2024-07-24T21:37:55Z

@g9wp This seems unrelated to the [script] attribute.

This is a more general solution, [script] is just equivalent to [cfg_attr(true, set shell)].

RoloEdits · 2025-02-05T23:16:25Z

One thing I have come across was that to get syntax highlighting to work in helix I need to use the #! shebang line. But for other reasons I want to use the [script] attribute, but doing so means I cannot have the shebang line, which also means I dont have proper syntax highlighting. Is the hard error when having both a must have, or could we prioritize the script attribute, for example?

casey · 2025-02-06T00:16:30Z

@RoloEdits Good catch! I think I would lean heavily towards not allowing both #! and [script]. Having two potentially conflicting interpreters is rather confusing. Ideally the syntax highlighters would learn to parse the [script] attribute and apply the correct syntax highlighting.

RoloEdits · 2025-02-06T01:51:30Z

It wouldn't fix all the issues with shebangs, but what are your thoughts on adding the functionality of cygpath in source to remove the dependency of it? Id be willing to try to tackle this, but would need to better understand what it does and what we need from it first. This way, at least where it works, this could be used crossed platform without the need for cygwin on windows. This would remove some cases where the [script] attribute is required for this.

casey · 2025-02-06T02:10:11Z

I would love to move the functionality of cygpath into just itself. However I can't really provide any pointers, since I'm not sure how cygpath works. In particular, I don't think it does the same transformation in all environments. For example, I think the transformation might produce different paths in Git bash vs a Cygwin installation. If so, I'm not sure if it reads some kind of environment variable or configuration which controls the transformation.

RoloEdits · 2025-02-06T03:27:11Z

I'll discuss more in #1549 as that seems to encompass this more specifically.

cspotcode · 2025-03-20T15:37:38Z

I'm hitting an issue where I can't set a different script-interpreter on Windows.

My use-case is using busybox sh on Window, sh on all other platforms. Context: #2671 (comment)

I want to do this:

set script-interpreter := if os() == "windows" {
  ["busybox", "sh", "-eu"]
} else {
  ["sh", "-eu"]
}

Is there any clever way to hack this?

casey · 2025-03-20T19:52:46Z

@casey There isn't, unfortunately. For the shell, we have the windows-shell setting, but nothing equivalent for the script-interpreter. We should either add windows-script-interpreter as as separate setting or make it possible to use os attributes (like [windows]) on settings. The latter is probably more principled and generally useful, but it's a larger change, so the former is fine.

casey mentioned this issue Jul 18, 2024

[script] annotation #1479

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Stabilize `[script(…)]` attribute #2260

Stabilize `[script(…)]` attribute #2260

Stabilize [script(…)] attribute #2260

Stabilize [script(…)] attribute #2260

Comments

Stabilize `[script(…)]` attribute #2260

Stabilize `[script(…)]` attribute #2260