LP #1081733: pt-stalk plugins can't access the real --prefix
Description
Environment
Smart Checklist
Activity
lpjirasync January 24, 2018 at 5:23 PM
**Comment from Launchpad by: Daniel Nichter on: 17-04-2013 22:52:21
Brian: is there a branch or patch for this?
lpjirasync January 24, 2018 at 5:23 PM
**Comment from Launchpad by: Daniel Nichter on: 03-04-2013 19:18:21
[1:04pm] Daniel: re not changing OPT_*, why save and restore OPT_PREFIX ^ ?
[1:05pm] brian: Daniel: That way the "default" behavior for OPT_PREFIX ggets called on every iteration
[1:05pm] brian: date +%F-%T | tr ':-' '_'
[1:05pm] brian: ^that being the default
[1:06pm] brian: So if you don't restore it, every iteration will have the same prefix, which is not the current behavior.
[1:06pm] brian: Perhaps I should add a test for that?
[1:07pm] Daniel: brian: i think the fix is just:
[1:07pm] Daniel: - local prefix="${OPT_PREFIX:$(date +%F%T | tr ':-' '_')}"
[1:07pm] Daniel: er wait
[1:07pm] • Daniel looks at the option again
[1:09pm] Daniel: hm it's weird because the default is not constant
[1:09pm] Daniel: but a specified --prefix would be constant
[1:09pm] brian: (you can't do local OPT_PREFIX=... because local in bash has function scope, unlike Perl)
[1:10pm] Daniel: well, i guess the default is contant too: the string that is the cmd that runs date
[1:11pm] Daniel: brian: i think perhaps providing OPT_PREFIX to the plugin would confuse things...
[1:11pm] Daniel: we say "don't change OPT_ values" which kind of implies that we (i.e. the tool) doesn't change them either...
[1:12pm] Daniel: so OPT_whatever is guaranteed to be whatever --whatever actually was...
[1:13pm] Daniel: in the case of --prefix, it would make OPT_prefix different each time, or not if --prefix was specified
[1:13pm] Daniel: therefore, i think plugins should use $prefix, which is "shorthand" for either default --prefix or the specified --prefix
[1:14pm] Daniel: this way we don't bastardize how OPT_ act or should be treated.
[1:14pm] Daniel: what do you think?
[1:15pm] brian: Agreed. Mark the bug as invalid, but commit a patch pointing out that the current prefix is in $prefix?
[1:15pm] Daniel: yes
lpjirasync January 24, 2018 at 5:23 PM
**Comment from Launchpad by: Daniel Nichter on: 22-11-2012 16:34:39
Brian pointed out that local in Bash is like local in Perl, so a plugin does have access to $prefix, but the tool should really update OPT_PREFIX with its default value so plugins can use that.
Details
Assignee
UnassignedUnassignedReporter
lpjirasynclpjirasync(Deactivated)Priority
Low
Details
Details
Assignee
Reporter
Priority
Smart Checklist
Open Smart Checklist
Smart Checklist
Open Smart Checklist
Smart Checklist

**Reported in Launchpad by Fernando Ipar last update 17-04-2013 22:52:22
When writing plugins that will collect additional data, it would be useful to have access to the prefix used for current collections.
If the user does not specify --prefix, right now the $prefix is created local and therefore unavailable to plugins:
if [ "$OPT_COLLECT" ]; then
local prefix="${OPT_PREFIX:$(date +%F%T | tr ':-' '_')}"