With the new <definevar> resource file tag of 2.0a1 and the
<include> tag it is (painful but) possible to define
list specific values for custom variables while sharing
one main resource file for different archives.
I have recently added support for a default resource file.
The feature will be available in the next v2.0 alpha release.
To make user
defined variables handling easier I added a -uservars
option to mhonarc.
E.g., with
mhonarc -rcfile .shared.rc \
-uservars "LIST=>'TestList', SMILE=>':-)'" \
...
and a resource file .shared.rc:
<-- Should not the sub get_elem_content chomp the last newline? -->
<-- \n after the last 'la' is stored in .mhonarc.db! -->
I have added a "chop" attribute to instruct mhonarc to delete the
last end-of-line sequence of the resource.
The feature will be available in the next v2.0 alpha release.
Using -uservars instead of <include> has the additional advantage that
the values defined by -uservars are stored in .mhonarc.db itself and
therefore the archive does not depend on other files resource
files as with <include>.
The resources set from <include> files are stored in the database.
The allowed <string> values for -usersvars are that of a perl list
without surrounding '(' ')':
"'LIST','name','MYKEY','MYVALUE'" # for perl4/5
"LIST => 'name', MYKEY => 'MYVALUE'" # only perl5
[this is due to perl code: eval "%hash = "($uservars, %hash)" ]
Could this feature be added the next release/snapshot?
Yes, but with different syntax. It will be something like the
following:
mhonarc -definevars "LIST='name' MYKEY='MYVALUE'" ...
The reason for the different option name is to make it consistent
with the DEFINEVAR resource element. The syntax allows the
following:
o Spaces can be around the '='.
o Values that contain no whitespace do not need to be quoted.
o Single or double quotes can be used for a value.
Note: Certain characters may need to be escaped via the shell's escape
mechanism to avoid unwanted interpretation by the shell.
BTW, shouldn't your eval be:
eval "%hash = "(%hash, $uservars)"
To insure that the command-line settings take precedence over
other settings?
--ewh
