John H Palmieri <jhpalmier...@gmail.com> writes: > 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.
Yes, that does seem to be the behavior. By the way, Sage does not seem to be able to accept .pyx files on the command line, only .spyx files. Incidentally, if we had subcommands for running files, this ambiguity would go away - say, `sage run` for .sage files, `sage run-py` for .py files, and `sage run-spyx` for .spyx files. This would worsen the notorious Linux `env` non-splitting arguments headache, though: while "!#/usr/bin/env sage" works, "!#/usr/bin/env sage subcommand" does not, as `env` on Linux gets passed "sage subcommand" as a single argument and (wisely) does not split it into an executable to look for and an argument to pass. Any shell wizards know if there's some standard way of getting around this? We could also install hyphenated wrappers into the PATH like git does, i.e. `sage run-py` would be equivalent to `sage-run-py`. This solves the `env` problem. -Keshav ---- Join us in #sagemath on irc.freenode.net ! -- 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
