> % sage ARGS # this would be for running sage scripts, or a couple of
> oddball arguments
> % sage notebook ARGS
> % sage pkg ARGS # this would include spkg stuff
> % sage pkg install # since install has some special flags like -f or -s
> % sage test ARGS
> % sage build ARGS
> % sage {python,maxima,R,gp,...} ARGS # we can consider these programs
> as subcommands of sageI think this is a good idea. Some suggestions: * As Jeroen has pointed out, we should keep a thin shell script that calls off to programs like gp and gap, and runs the pkg install subcommand. * For backward compatibility, why don't we have a shell script that prints out a deprecation warning and then translates all of the allowable commands in the old syntax to their new equivalents. * I would like to still allow "sage -t" as a way to access the "sage test" subcommand, "sage -b" to access the "sage build" subcommand, etc. I think the key change should be to become Posix compliant, and these are allowable short options. And they combine nicely: "sage -bta" would mean rebuild everything and test everything. * I think that each of the subcommands should be separated out into its own python script that handles the appropriate options. David -- 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
