On Wed, Feb 19, 2020 at 12:01 PM Verma, Vishal L <vishal.l.ve...@intel.com> wrote: > > On Wed, 2020-02-19 at 10:53 -0800, Dan Williams wrote: > > > > > > > Will this break existing code that parses the javascript output? > > > > > > > > Always a potential for that. That said, I'd rather attempt to make it > > > > symmetric and replace it if someone screams, rather than let this > > > > quirk persist because it makes it impossible to ingest region data > > > > with the same script across -R and -Rv. > > > > > > Yeah, I see where you're coming from. However, script authors will > > > still have to deal with older versions of ndctl in the wild (for many > > > years). If the decision was up to me, I'd live with the wart in favor > > > of not breaking scripts when ndctl gets updated. Users hate that. > > > > Let's do a compromise, because users also hate nonsensical legacy that > > they can't avoid. How about an environment variable, > > "NDCTL_LIST_LINT", that users can set to opt into the latest / > > cleanest output format with the understanding that the clean up may > > regress scripts that were dependent on the old bugs. > > > Hm, this sounds good in concept, but how about waiting for this cleanup > to go in after the (yes, long pending) config rework. Then this can just > be a global config setting, and we won't have config things coming from > the environment as well (which this would be a first of).
That does make some sense, but I notice that git deals with "cosmetic" environment variables (GIT_EDITOR, GIT_PAGER, etc) in addition to its config file. So if we're borrowing from git, I'd also borrow that config vs environment logic. _______________________________________________ Linux-nvdimm mailing list -- linux-nvdimm@lists.01.org To unsubscribe send an email to linux-nvdimm-le...@lists.01.org
