Is there an Official Shebang for Julia

General Usage
1

Is there an Official Shebang for Julia and if so how do I install and use it ?

2 Likes
2

I’m a little confused about what you mean by “install and use it”, but #!/usr/bin/env julia should work in most cases (assuming you can run it successfully on the command line).

7 Likes
3

In addition to the previous answer and in case you need to (portably) provide julia with additional command-line arguments, the recommended way is documented in the FAQ:

#!/bin/bash
#=
exec julia --color=yes --startup-file=no "${BASH_SOURCE[0]}" "$@"
=#

@show ARGS  # put any Julia code here
14 Likes
4

For the benefit of future readers of this thread, the FAQ has now changed and recommends

#!/usr/bin/env -S julia -t 4 -- project

as the header for executable Julia scripts (where you may change the Julia command line options to suit your needs).

None of the above headers work if julia is an alias, so I made the following to handle this situation as well:

#!/usr/bin/bash -i
#=
    exec bash -ic 'julia -t 4 --project "$@"' Julia "${BASH_SOURCE[0]}" "$@"
=#

println.(ARGS, '.')

Again, -t 4 --project is just an example of some Julia command line options that one could use and println.(ARGS, '.') is just an example of some Julia code.

This header is much more complex than the one from the FAQ, but as far as I can see it is more general. Please let me know if you find any issues with it, I have only tested it on myself.

1 Like
5

I got /usr/bin/env: invalid option -- 'S' Try '/usr/bin/env --help' for more information on

Linux node01 3.10.0-957.el7.x86_64 #1 SMP Thu Nov 8 23:39:32 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

It simply doesn’t work without -S

6

That flag was added to GNU coreutils in v8.30 (2018-07-01), perhaps you have an older version (or a different env binary) installed?

Try

/usr/bin/env --version

to find out.

3 Likes
7

I think so

(base) [customer@node01 dev]$ /usr/bin/env --version
env (GNU coreutils) 8.22
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Written by Richard Mlynarik and David MacKenzie.

Then is there a suggested shebang for older version?

10

I see from the official docs:

this recommended:

#!/usr/bin/env -S julia --color=yes --startup-file=no

That said, Julia isn’t preinstalled, so no shebang works in the sense of will work out-of-the-box, as for python or bash that is preinstalled. Only after installing with e.g. juliaup. [Neither does Python always work that way, i.e. on Windows. AppBundler.jl works cross-platform for Julia everywhere.]

@GHTaarn, I would not use -t 4 or -t including with auto, as a rule. It’s probably not needed, for scripts, it likely doesn’t hurt (or help), but it might. Julia or at least some packages are not thread safe. You should only enable threads if you know them helping and supported by packages. Some packages only handle single-threaded, might break when Julia isn’t. This is I think not a huge concern, since I believe Pluto enables threads, but at least I want to say I’SA noT the official recommenced shebang to use it.

Some recommendations like --compile=min helped much in the past, less so now with packages precompiled:

See rather recent addition:

11

I can see that there was an error in my post, it should have been:

#!/usr/bin/env -S julia -t 4 --project
println.(ARGS, '.')

(note that there is no space between -- and project)

@Palli : Thanks for pointing out the problems with -t. My post was not a recommendation to use -t 4, it was merely meant as an example. What flags you actually put after julia depends on what you want to accomplish in your unique situation.

12

You can’t take python or bash for granted either (in general).

The shebang line most likely to work is still the #!/usr/bin/env -S ... from the docs. It assumes that you have a julia executable in $PATH, but that is probably the bare minimum for working with scripts and is easy to satisfy.

13

Well yes, there’s not a lot you can know is preinstalled, not python, on macOS, or any one language available on all platforms, not even env with -S, before 2018, on Linux, but truly portable is still possible for Julia, like already for unofficial Python build (i.e. if someone want to do similar work for Julia itself, OR for scripts run with official Julia as is):

Update (2024-04-15): The Python executable build process described in this post is from 2021, and both Cosmopolitan Libc and the surrounding tooling have improved since 2021. The build process is much simpler now, you can download Python 3.11.4 Actually Portable Executables built via Github Actions at GitHub - ahgamut/superconfigure: wrap autotools configure scripts to build with Cosmopolitan Libc

While you can rely on the #! capability itself, the shebang, on all Linux and macOS, you can’t on Windows, you can still make truly universal binaries:

https://justine.lol/ape.html

In the above one-liner, we’ve basically reconfigured the stock compiler on Linux so it outputs binaries that’ll run on MacOS, Windows, FreeBSD, OpenBSD, and NetBSD too. They also boot from the BIOS.

I can see that this could be used (with tiny overhead to your script), by having some code and then your Julia script appended, and run if the appended code if Julia is preinstalled, and if not download (juliaup and install) julia for you (it could even be bundled in your script) and then run the script cross platform.

It might take a while for Julia to adopt the Cosmo libc, APE is based on, but it needs not, since it can be done in a system like AppBundler.jl, or even for juliaup.

Currently AppBundler is also cross-platform, i.e. supports all platforms Julia supports (except I think FreeBSD), though for:

For Linux, the extension .snap and Windows .zip

Ubuntu supports snaps, and many more Linux distros, but not all…

Updated on Sep 22nd, 2024

Portability and Performance (Pick Two)

The end result is that if you switch your Linux build process to use cosmocc instead of cc then the programs you build, e.g. Bash and Emacs, will just work on the command prompts of totally different platforms like Windows and MacOS, and when you run your programs there, it’ll feel like you’re on Linux. However portability isn’t the only selling point. Cosmo Libc will make your software faster and use less memory too.

https://justine.lol/cosmopolitan/

Cosmopolitan Libc makes C a build-anywhere run-anywhere language
[…]
Congratulations! You just made your first fat actually portable executable. It’ll run on Linux/MacOS/Windows/FreeBSD/NetBSD/OpenBSD on the AMD64 and ARM64 architectures.

14

I don’t think that there are other official suggestions, but maybe my bash -i based suggestion above would work for you. I have also previously used awk based shebangs e.g.:

#!/usr/bin/awk BEGIN{ for (x = 1; x < ARGC; x++) {args=args sprintf("\"%s\" ", ARGV[x]); ARGV[i]=""} cmd = "julia -i --project --history-file=no " args; system(cmd)}

println.(ARGS, '.')

(again, change the Julia options to suit your own needs)

15

Thanks! I will check