[GRASS-dev] g.mlist list multiple types from all mapsets

[Huidae Cho]

I agree that it can be confusing. I think we have the following options:

1. Just don't replace g.list as it is more user friendly and g.mlist is
more machine friendly.
2. Replace g.list with the current version of g.mlist and use -p in
terminal as needed.
3. Redirect g.mlist output (separator=newline) to GRASS_PAGER if isatty ==
1. My main complaint with g.mlist in terminal is that I have to use a pager
in some case.
4. Change -p to parseable printing and use pretty printing by default.

Well, at this point, I think option 1 is best. We don't have to merge
g.mlist and g.list. IMO, it all comes down to when and how often we use
g.list vs g.mlist.

Unlike g.mlist, g.mremove doesn't have this problem.


On Fri, Jun 20, 2014 at 8:38 PM, Glynn Clements <glynn at gclements.plus.com>
wrote:

>
> Huidae Cho wrote:
>
> > Hmm... one flag -s (switch default) should be enough, I think.
>
> I think not. We need a way to specify a particular output format. A
> "switch" flag is only useful if you already know which format will be
> used without that flag, which isn't necessarily straightforward.
>
> A similar issue arose for r.{in,out}.bin.
>
> They used to have a -b (byte-swap) flag (it's actually still there,
> for compatibility).
>
> This is fine for interactive use, where the user (hopefully) knows
> whether the byte-order of the platform they're using matches that of
> the data.
>
> But a script which is intended to be portable would have to first
> determine the byte order of the platform then either use or omit the
> -b flag depending on the result.
>
> The current versions have an order= option (values: big, little,
> native, swap), so that a script can simply use order=big or
> order=little, and not have to work out whether that means
> byte-swapping or not.
>
> --
> Glynn Clements <glynn at gclements.plus.com>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/grass-dev/attachments/20140620/df36c389/attachment.html>