Comments (14)
@cspotcode something like this following should take care of things. 😉
shebang := if os() == 'windows' {
'python'
} else {
'/usr/bin/env python3'
}
recipe:
#!{{shebang}}
# Script code goes here
from just.
I did that, but it's still error-prone. If the variable includes the #!
then it doesn't trigger just
's shebang logic.
from just.
Note that the #!
part is outside the curly braces. As long as that is the first line of the script (which is required for any use of shebang) you are good. I do this all the time.
from just.
Do we think the /usr/bin/env
special-casing is a net win, given that windows shebangs are already special-cased?
from just.
@cspotcode There are a few ways to interpret what you said as I'm not sure if you're referring to how Just manages shebangs at all on Windows or that having a shebang start with /usr/bin/env
works but isn't part of the original UNIX spec?
from just.
The idea is that common devtools are often available on PATH but at a path that may vary or be onerous to add to a shebang. For example, on my Linux box:
❯ which node
/home/cspotcode/.volta/bin/node
The practical solution here, acknowledging that it's not part of an original UNIX spec, is #!/usr/bin/env node
. This form of shebang is well-known and works reliably.
We can add logic to just
so that, only when interpreting a shebang on Windows, just will detect a /usr/bin/env
prefix.
When just
sees #!/usr/bin/env python
on Windows, it will do what it already does for #!python
This means that users writing a well-known and well-understood shebang of the form #!/usr/bin/env python
will have that shebang work correctly on Windows, too: it will call the python
executable found on $PATH
from just.
I always thought having to specify the exact path to the "interpreter" was lame in the shebang spec. It being an option was completely reasonable but required is just problematic. I believe I've already proposed to @casey to have how shebang is handled on Windows also work for other operating systems. I forget where he landed on that exactly at the moment. But I'd prefer that to Just ignoring /usr/bin/env
on Windows. If I could only have one option that is.
from just.
When users rely on cygpath to convert /usr/bin/env
into C:\cygwin64\bin\env.exe
, what features of env
are they typically relying on? -i
, -S
, -C
?
from just.
Hm, -C
isn't even an option on my Mac, or in Bash according to https://ss64.com/osx/env.html . None-the-less those options are almost never used in any shebang line that I've ever seen. Using env
is typically used only for it's side effect of searching PATH for the binary so that the command in the shebang isn't fixed and instead uses the first version found in PATH.
from just.
That's my thinking as well. -S allows passing args, so I see that one used in the wild a fair bit.
I was playing around with writing a PR for this. It's predicated on the assumption that Windows users never actually care that they're invoking cygwin's env.exe
.
from just.
Check out our discussion at #1256 to get more insight. You could write a PR as @casey is appreciative of help coding. Hopefully he will jump in this discussion a bit though. Hey @casey ! 😀
from just.
Thanks for opening this issue, and sorry for not responding here!
I definitely agree that there's a problem here, but I think I'm on balance against special-casing /usr/bin/env
on windows.
/usr/bin/env
has different capabilities on different platforms, and even different unix kernels split shebang lines differently, so trying to get shebang lines to behave consistently across platforms feels like a losing battle to me. My preferred approach to this is to introduce a new script
annotation, which allows passing a command to run the script which is looked up in $PATH
like usual, and be fully cross platform with no special cases, e.g.:
[script('python3')]
foo:
print('hello')
from just.
Just ran into this myself and took a lot of searching to find the solution given here (#1549 (comment)).
While it's inelegant, it does work. I would strongly recommend listing it somewhere in the Docs until a "proper" solution is added to just. I think enough people write cross platform recipes to warrant its inclusion in the docs.
from just.
I thought an example like mine was in the docs for some time. Maybe it was removed due to some redundancy in the docs at the time. @casey do you know anything about that example? I think you wrote the one that ended up in the docs, no?
from just.
Related Issues (20)
- failed to select a version for `env_logger` which could resolve this conflict HOT 4
- Run in existing shell OR create interactive child shell HOT 5
- Trouble loading .env file from path HOT 1
- feature request: idempotentcy guards HOT 10
- Allow const expressions in settings
- Bug: Incorrect run just command in just file HOT 2
- [feature request] Installation via pip? HOT 6
- Improvements to cross-platform path environment variable manipulation
- Cannot have a dependencies when using module HOT 2
- Publish checksums of release binaries HOT 2
- Do subsequents of a recipe run "immediately" after the recipe (by specification)? HOT 1
- `completions::bash` test failing under Alpine since 1.28.0 HOT 5
- Fallback for submodules HOT 3
- justfile does not preserver the command exit code HOT 1
- just submodule -l HOT 3
- set working-directory := justfile_directory() HOT 5
- Add variable to have just require a program to be present on the system HOT 1
- Color-code `just` groups HOT 3
- Unknown start of token for simple just HOT 1
- "ignore-comments" does not completely ignore commented lines HOT 6
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from just.