search

landam / grass-gis-git-migration-test

0 stars 0 forks source link

pattern option for t.list and t.remove #182

Open landam opened 5 years ago

landam commented 5 years ago

Reported by veroandreo on 20 Nov 2015 13:29 UTC Would that be possible to have a "pattern" option both in t.list and t.remove (as we have in g.list and g.remove) to make it easier to search and remove stds according to a pattern in their name??

Operating system

Linux

Migrated-From: https://trac.osgeo.org/grass/ticket/2804

landam commented 5 years ago

Modified by veroandreo on 21 Jan 2016 01:23 UTC

landam commented 5 years ago

Comment by lucadelu on 25 Feb 2016 17:18 UTC Soeren (and all) I looked into code of t.list and I discovered two possible way to implement this:

What do you suggest? (also other ways are welcome)

Solving the list problem also the remove one should be simpler to implement.

landam commented 5 years ago

Modified by @landam on 12 May 2016 06:36 UTC

landam commented 5 years ago

Modified by @landam on 25 Aug 2016 15:51 UTC

landam commented 5 years ago

Comment by @landam on 27 Aug 2016 13:42 UTC Milestone renamed

landam commented 5 years ago

Comment by lucadelu on 21 Dec 2016 15:12 UTC Could someone answer to my question?

so I could work on this ticket...

landam commented 5 years ago

Comment by veroandreo on 19 Mar 2017 22:25 UTC https://grass.osgeo.org/grass77/manuals/t.unregister would also benefit from a "pattern" option :).html

landam commented 5 years ago

Comment by neteler on 27 Apr 2017 19:12 UTC Replying to [comment:2 lucadelu]:

Soeren (and all) I looked into code of t.list and I discovered two possible way to implement this:

  • simpler add into get_dataset_list function a LIKE operetor passing the pattern string

Would there be the problem that the LIKE operator behaviour then depends on the DB backend?

  • more complex using the python fnmatch module to fetch the right databases, but in this case we should get always the name of dataset in the query and later check if it is a required column otherwise not print/write the field

What do you suggest? (also other ways are welcome)

Solving the list problem also the remove one should be simpler to implement.

Overall, it would be good to achieve a similar usability as for g.list/g.remove if all possible.

landam commented 5 years ago

Comment by neteler on 26 Jan 2018 11:40 UTC Ticket retargeted after milestone closed

landam commented 5 years ago

Modified by neteler on 12 Jun 2018 20:48 UTC

landam commented 5 years ago

Comment by @landam on 25 Sep 2018 16:52 UTC All enhancement tickets should be assigned to 7.6 milestone.

landam commented 5 years ago

Comment by @landam on 25 Jan 2019 21:07 UTC Ticket retargeted after milestone closed