In some circunstances, you want to remove a key for your config in
viper, so, instead of setting the key value to nil, it's better to
have a new Unset function to remove the key from the inner map.
* Added support for accessing slices
* Processed PR feedback
- renamed searchMapWithPathPrefixes to searchIndexableWithPathPrefixes
- moved source type specific search logic to speparate functions
- Inverted if statments to avoid the arrow pattern
* Quickly return from searchSliceWithPathPrefixes and searchMapWithPathPrefixes functions without intermediate variables
This change modifies BindEnv to permit a list of environment variable
names in order to support multiple env. vars. for the same config key.
When this form is used, env. keys take precedence in the written order.
Closes#971
* add parsing for stringToString flags
* add logic to return flags default if not val set, add a test
* extract parsing into single func
* add a few more cases
* return nil if unable to parse instead of panicing
* return map[string]interface in order to work with cast.ToStringMap
* mostly copy pflags implementation of the conversion to a stringtostring
* Add support to save file with no extension
The support introduced for files with no file extension is only partial as trying to save the config file would fail with `<file name> requires valid extension`
This adds support to saving such files
* Only consider files without extension if the config type is explicitly specified
* Hides unused variable in test
* First check for config type then for file without extension
Default value should be looked for by Get(), but not by IsSet().
This logic should remain inside find(), to make sure that shadowing
of keys is handled properly.
Fixes Issue #276.
If the config file does not exist and the force flag is not set,
OpenFile would not use O_CREATE flag, causing viper to fail with
error "File not exist" and to not create the config file.
This patch changes the behavior of writeConfig() so that if force is set
to false, OpenFile will use O_EXCL flag, thus failing if the file
already exists or creating a new file otherwise.
Signed-off-by: Rodrigo Chiossi <rodrigo.chiossi@intel.com>
Defering can cause trouble because we're writing to the file outside the function
where the defering is registered, calling f.Sync() ensures that bytes are flushed
to disk even is Close() is called too soon.
