On May 22, 2015 4:59:13 AM EDT, Andrey Semashev
Note that not only paths can be present in multi-element env. variables. For example, LS_COLORS contains a list of color specifications for ls command. I think, it's better for the environment library to
split to a sequence of strings and let the user interpret those strings as filesystem paths or something else.
Exactly. $PATH isn't the only "array-like" variable, hence my reasoning for encapsulating the raw name/value string pair in a 'variable' class
On Friday 22 May 2015 18:35:09 Michael Ainsworth wrote: perform a that can
iterate over the substrings in the value string. It may be confusing though. Will think more on it.
I think it's better to have a separate interface for splitting/joining - preferably, an algorithm (a free function).
+1 I was going to say the same.
I'm not sure a 'variable' class which contains both name and value is a good thing, at least as the main interface. When I get a variable, I expect to have to pass only its name and receive only its value, like:
std::string value = env["FOO"];
+1 ___ Rob (Sent from my portable computation engine)