Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Shebangs as comments #1772

Closed
mcandre opened this issue Feb 7, 2012 · 12 comments
Closed

Shebangs as comments #1772

mcandre opened this issue Feb 7, 2012 · 12 comments
Labels
A-frontend Area: Compiler frontend (errors, parsing and HIR) C-enhancement Category: An issue proposing an enhancement or a PR with one. E-easy Call for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue.

Comments

@mcandre
Copy link

mcandre commented Feb 7, 2012

Can we treat shebangs as comments for those who like doing #!/usr/bin/env rustx?

It would be nice to compile or interpret the same Rust code as desired, but currently, when you try to compile Rust code with a shebang, you get an ugly syntax error.

hello.rs:

#!/usr/bin/env rustx

use std;

fn main() {
    std::io::println("Hello World!");
}

expected output:

$ rustc hello.rs 
$ ./hello
Hello World!

actual output:

$ rustc hello.rs 
hello.rs:1:1: 1:2 error: expecting '[' but found '!'
hello.rs:1 #!/usr/bin/env rustx
@brson
Copy link
Contributor

brson commented Feb 8, 2012

It seems pretty harmless to allow the first line to be a shebang. rustx could also filter it out and feed the script to rustc via stdin.

@killerswan
Copy link
Contributor

True, but the drawback to making rustx filter it out is that then you'd have to manually edit the program source to start using rustc.

@brson
Copy link
Contributor

brson commented Feb 8, 2012

good point

@mcandre
Copy link
Author

mcandre commented Feb 9, 2012

Agreed. That's how a lot of languages do it (Pascal, OCaml). And it's a pain.

Many people have trouble understanding why anyone would like to dot slash their compiled scripts. I guess dot slash is preferable because it standardizes the cli for scripts from different languages. It's POSIX, it's treating every piece of code, compiled, interpreted, whathaveyou, as if it were recombinant bash script, pipable to unix commands and other scripts.

@killerswan
Copy link
Contributor

Another alternative to try, on some platforms, is binfmt:
http://manpages.ubuntu.com/manpages/oneiric/man8/update-binfmts.8.html
http://en.wikipedia.org/wiki/Binfmt_misc

This is what I was trying to remember earlier, @mcandre.

@graydon
Copy link
Contributor

graydon commented Apr 11, 2012

Yeah, I'd be ok with this. And agree with @Wensleydale that this would be a not-too-awful way of marking a file with "pre-parse" metadata such as "version of rust grammar this file depends on, in order to even parse". A problem we've been discussing elsewhere.

@catamorphism
Copy link
Contributor

I'm hearing consensus for "yes, implement as @mcandre suggested". If I'm wrong, yell.

@brson
Copy link
Contributor

brson commented May 23, 2012

Fixed by @mmeyerho

@brson brson closed this as completed May 23, 2012
@killerswan
Copy link
Contributor

Nice!

@mqudsi
Copy link
Contributor

mqudsi commented Mar 16, 2020

Complete necro, but thank you for implementing this. I just abused it considerably to write a rust “script” that is simultaneously a valid rust program and a valid bash/sh script, primarily just to see if it would be realistic to do so. Much obliged!

@guest271314
Copy link

@mqudsi How would I do that using the Rust archive that I extract rustc and rust-std-x86_64-unknown-linux-gnu folder from, yet don't install in PATH?

#!/bin/sh
//usr/bin/env /home/user/bin/rustc/bin/rustc $0 -o a.out && ./a.out; rm -f a.out; exit

use std::env;

fn main() {
  let args: Vec<String> = env::args().collect();
  if args.len() > 1 {
      println!("Hello {}!", &args[1]);
  } else {
      println!("Hello world!");
  }
}
$ ./rust.sh


You need to link your code to the relevant crate in order to be able to use it (through
Cargo or the -L option of rustc, for example).

Common causes
*   The crate is not present at all. If using Cargo, add it to [dependencies]
     in Cargo.toml.
*   The crate is present, but under a different name. If using Cargo, look for package
    =  under [dependencies] in Cargo.toml.

Common causes for missing std or core
*   You are cross-compiling for a target
    which doesn't have std prepackaged. Consider one of the following: + Adding
    a pre-compiled version of std with rustup target add + Building std from
    source with cargo build -Z build-std + Using #![no_std] at the crate root,
    so you won't need std in the first place.
*   You are developing the compiler itself and haven't built libstd from source. You
    can usually build it with x.py build library/std. More information about
:


@guest271314
Copy link

@mqudsi I figured it out for the test script using -L /home/user/bin/rust-std-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-frontend Area: Compiler frontend (errors, parsing and HIR) C-enhancement Category: An issue proposing an enhancement or a PR with one. E-easy Call for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue.
Projects
None yet
Development

No branches or pull requests

7 participants