On 02/28/2012 03:45 PM, Keshav Kini wrote:
William Stein<wst...@gmail.com> writes:
On Tue, Feb 28, 2012 at 8:43 AM, Keshav Kini<keshav.k...@gmail.com> 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?
Almost all of my code works like this. Libraries of code.py, and
hashbang'd scripts to call some library functions and e.g. display a graph.
The standard behavior seems to favor subcommands and switches over
filenames, allowing the -- to terminate the command-line options. An
example:
$ touch ./-i
$ rm -i
rm: missing operand
Try `rm --help' for more information.
$ rm -- -i
So I guess it would make the most sense to require 'sage -- test' if
someone decides to name their file 'test'.
--
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
