On Mon, Jan 30, 2012 at 04:36, Ivan Andrus <darthand...@gmail.com> wrote: > I agree it's ugly. I think what the user really wants is things like > > sage test --build-first > > rather than > > sage build test > > I can't imagine any ever wanting > > sage build shell test notebook > > In other words, the test command would know how to (optionally) build first, > but the build command wouldn't know how to test afterwards. I suppose run > could know how to build and test first, but I don't see a real use case for > that off the top of my head.
I think this is solved by having an enforced action order and just using options instead of subcommands. $ sage --build --shell --test --notebook # equivalently sage -bstn would build, then test, then open a shell and ignore the notebook option, or, perhaps better, quit with an error message about conflicting actions. >> Or actually, why don't we just create an option "-C/--shell-command" >> which feeds "-c" to the sage subshell? Then we would have, for >> example, "sage -C gp" or "sage -C python" or whatever, which just adds >> two characters. Some of the commands which call external programs seem >> to have some initialization stuff done before the program is actually >> called, so we could prepend some directory to PATH in sage-env which >> contains scripts named after the actual program binaries in >> $SAGE_LOCAL/bin, that initialize and call the actual program binaries, >> just as we are currently doing with a bunch of five-line if statements >> in $SAGE_ROOT/spkg/bin/sage . > > This would be a nice feature to have, but I want to be able to run something > like > > sage gap -o 2g > > to tell GAP how much memory to use. I _think_ sub command parsers handle > that where as I would have to run > > sage -C gap -- -o 2g > > if there were no subcommands. Hmm. Indeed, `sage -sh -c gap -b` still displays a banner, for example, whereas `sage -gap -b` does not. `sage -sh -c gap -- -b` doesn't work either. `sage -sh -c 'gap -b'` does, though, so that's a workaround. The question then becomes, would we want `sage -C` to be consistent with `sh -c`, or would we want it to be consistent with how `sage -gap` et al. work currently? I would be fine with the latter (say, wrapping $@ into a single argument to the -c of the subshell). -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
