On Thu, Jun 19, 2014 at 1:47 PM, Huidae Cho <gras...@gmail.com> wrote:
> Hmm... one flag -s (switch default) should be enough, I think. > > I'm not sure what is the current proposal (I think I've seen something else in some other thread) but "flag -s (switch default)" seems like a very bad idea as well as switching the format according to isatty(). Both would be confusing/inconsistent behavior (trying something in command line and then getting something else in Python). Vaclav > > On Thu, Jun 19, 2014 at 1:38 PM, Huidae Cho <gras...@gmail.com> wrote: > >> Looks like we need pretty printing by default in terminal and parsable >> printing by default in non-terminal with -p to force pretty printing. When >> defaulting to pretty printing in terminal, we may need to ignore some flags >> only meant for parsable output. Also, a flag to force parsable printing in >> terminal would be useful too. >> >> >> >> On Thu, Jun 19, 2014 at 8:03 AM, Glynn Clements <gl...@gclements.plus.com >> > wrote: >> >>> >>> Huidae Cho wrote: >>> >>> > IMO, if we replace g.list with g.mlist, it would be better to remove >>> the -p >>> > flag and switch between the pretty output and machine-friendly output >>> based >>> > on isatty(STDOUT_FILENO). In most cases, if the user types a command >>> from >>> > the terminal without redirecting, they want to *see* output, not >>> *parse* >>> > it. This way, the new g.list (current g.mlist) will be backward >>> compatible >>> > *unless* any scripts depend on saved output of the old g.list. Also, >>> we can >>> > save additional typing. >>> > >>> > But I'm not sure if it's a good idea to print two different outputs >>> based >>> > on isatty. >>> >>> I don't think that isatty() should be the sole determining factor. I'd >>> rather see it used to select a default format but to allow the choice >>> to be overridden. >>> >>> E.g. you might want the "pretty" format to still be used if the output >>> is piped through more, less, pr, etc, but piping will result in stdout >>> being a pipe rather than a tty. >>> >>> -- >>> Glynn Clements <gl...@gclements.plus.com> >>> >> >> >
_______________________________________________ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev