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

Hash-bang scripts without .jl extension no longer work #1550

Closed
davidkh opened this issue Nov 14, 2012 · 5 comments
Closed

Hash-bang scripts without .jl extension no longer work #1550

davidkh opened this issue Nov 14, 2012 · 5 comments

Comments

@davidkh
Copy link
Contributor

davidkh commented Nov 14, 2012

Hash-bang Julia scripts that don't end in .jl are broken as of commit 8d7f53c, which adds ".jl" to the end of filenames passed to require() that don't already end in .jl.

For example, given an executable file "hello":

$ cat hello 
#!/home/david/bin/julia

println("Hello!")
$ # Before commit that adds .jl to filenames that lack it
$ ./hello 
Hello!
$ # Current behavior
$ ./hello
Cannot find ./hello.jl
 in realpath at file.jl:151
 in find_in_path at util.jl:203
 in require at util.jl:174
 in process_options at client.jl:182
 in _start at client.jl:239
$ 
@JeffBezanson
Copy link
Member

I'm with you here. I've never liked interfaces that say "here, let me mess with that filename for you", but I guess as a compromise we can leave the filename alone if it refers to an existing file.

@davidkh
Copy link
Contributor Author

davidkh commented Nov 15, 2012

It's an easy fix, but I'm not sure where to do it. Right now the interpreter calls require(name) when a program name is passed on the command line, so I put a fix in require(), but I wonder if it's desirable to use require() for this purpose, since it searches the LOAD_PATH. To me it makes sense for "julia -L foo" to use require() and "julia foo" to treat foo as an absolute or relative pathname, but I don't know if that would break things for other people.

@davidkh
Copy link
Contributor Author

davidkh commented Nov 15, 2012

After looking at load_now and remote_load, I decided to keep it simple and put the fix in find_in_path. Pull request: #1551

@StefanKarpinski
Copy link
Member

The point of this change was that we want the names of packages to match the names of modules defined in them. Jeff, you've said multiple times that you want a more declarative approach to require resolution – using explicit path names is the opposite of that. This fix is fine, but the real issue here is why #! loading of a file is going through load or require and passing through file_in_path at all. That is completely broken, IMO. Shebang loading should work like include.

@JeffBezanson
Copy link
Member

OK, I will switch load to include for program files, and still use load for -L. That should give us everything we need.

JeffBezanson added a commit that referenced this issue Nov 16, 2012
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants