I was converting my fish functions for modifying my Anaconda virtual environment and was surprised to find I could not do keys $E: or has-key $E: MY-ENV-VAR. Is there some other way to iterate over, or test for the existence of a key, in that namespace? Note that relying on $E:vname expanding to an empty string is not the same thing as knowing if the env var is set, even if set to the empty string.
The text was updated successfully, but these errors were encountered:
Treating the $e: namespace (external commands) like other namespaces might be a bridge too far because you can already do the equivalent of has-key $e: prog via has-external prog. However, I would argue that has-external is redundant if you can treat $e: as a read-only Elvish map usable by has-key and keys.
Regarding the e: namespace for external commands. Note that if it could be treated like a readonly Elvish map then doing $e[a_command] would evaluate to the command path that would be used if you ran e:a_command. That would be extremely useful.
The has-env command does exist, and mitigitates this issue a bit, just as has-external does for the e: name space.
Also as for the immediately preceding comment, search-external already does that.
But still, I agree that it could be handy to have e: and E: behave more like other namespaces. Personally, I'd like to even see the top-level interactive name space in the same way, but that is perhaps because I am a big fan of introspective capabilities (even if there is always a potential for misuse).
Thanks, @hanche, as I had overlooked the has-env and search-external commands. Nonetheless, I think we both agree the magic builtin namespaces, such as e: and E:, shouldn't behave differently from a namespace created by the use command. Specifically with respect to builtins like keys, has-key, and indexing into the namespace.