On Tuesday, February 28, 2012 12:45:08 PM UTC-8, Keshav Kini wrote: > > William Stein writes: > > On Tue, Feb 28, 2012 at 8:43 AM, Keshav Kini wrote: > >> It's not actually a fallback for b), though. If a file does exist with > >> the same name as a subcommand, b) makes it impossible to use that > >> subcommand without changing directory or deleting/moving the file. One > >> might say that in such cases we should do `sage foo` to execute the > >> file foo and `sage foo --` to execute the subcommand, but this means > >> you are no longer allowed to pass $@ along to the .sage file without > >> snooping it, which is an ugly situation. > > > > You would do "sage foo.sage". It seems like you're ignoring that > > files end in .py, .pyx, .sage, and no commands end in those > > extensions. I don't see how there will ever be a conflict. > > People often remove file extensions when making executable scripts they > want to place in their PATH. Sage should be callable as an interpreter > from a hashbang, too, should it not? > With the current setup, "foo.sage" needs to be preparsed into a Python file, and the way Sage knows to preparse it is to recognize its extension ".sage": see the script sage-run. I think if you do "sage foo", then it treats "foo" as a Python file. So I guess there is an issue here for Python files, but not (the way things are now) for files like foo.sage which require preparsing.
-- John -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
