| To: | Marko Myllynen <myllynen@xxxxxxxxxx> |
|---|---|
| Subject: | Re: [pcp] pmrep: improve command line parsing |
| From: | Nathan Scott <nathans@xxxxxxxxxx> |
| Date: | Wed, 29 Jun 2016 19:38:41 -0400 (EDT) |
| Cc: | pcp developers <pcp@xxxxxxxxxxx> |
| Delivered-to: | pcp@xxxxxxxxxxx |
| In-reply-to: | <5774061C.8070001@xxxxxxxxxx> |
| References: | <5767D307.9000002@xxxxxxxxxx> <5774061C.8070001@xxxxxxxxxx> |
| Reply-to: | Nathan Scott <nathans@xxxxxxxxxx> |
| Thread-index: | tCtdFjeKmj8iTzS2Dg2+sqN8X9pZJw== |
| Thread-topic: | pmrep: improve command line parsing |
Heya Marko, ----- Original Message ----- > Hi, > [...] > In general, of course, something so common that an application reads > its configuration from a file and then possibly overrides those values > with the ones the user provides on the command line shouldn't be this > hard. But I'm out of ideas so if noone can come up with a better > solution, I'm afraid we need to revert the previous patch. Hmmm one other option just occurred to me reading this; you might find using the environment variables (PCP_ARCHIVE, PCP_HOST) provides a way to inject these values reliably & more simply. i.e. grab source names from the config, inject em into appropriate env var (deciding whether to override env in the process or not, yet another wrinkle) ... it may become simpler that way, since pmGetOptions handles that internally. Or it may just get trickier still. :) Lemme know commit id if revert is the way to go here, thanks. cheers. -- Nathan |
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | RE: [pcp] RFC: allowing longer metric and instance names in MMV(5) format, Ken McDonell |
|---|---|
| Next by Date: | Re: RFC: allowing longer metric and instance names in MMV(5) format, Nathan Scott |
| Previous by Thread: | Re: pmrep: improve command line parsing, Marko Myllynen |
| Next by Thread: | Re: [pcp] pmrep: improve command line parsing, Marko Myllynen |
| Indexes: | [Date] [Thread] [Top] [All Lists] |