2023年2月4日(土) 19:41 Robert Elz <k...@munnari.oz.au>: > [...] > > Incidentally, while I understand your desire to make function namespaces > using '/'
I think this is a separate interesting discussion, so let me reply in a separate mail. I guess you understand me, but just to be sure, I'm not desiring to make it in the POSIX standard but just desiring, if possible, a room where an implementation can choose its behavior so that I can rely on them in my Bash scripts (not POSIX scripts). > (though some other character, maybe @ or % or something might > have been a better choice) As I have explained in another reply, the slash had an affinity with the user experience of the command completion system. It was also easier for me to categorize the public and private functions. When I made the decision to entirely switch to slashes at an early stage, I didn't see any effective difference between / and @, %, or whatever in Bash's behavior, which is the reason that I didn't think @ or % is better then. If I knew that the Bash could change its behavior, I wouldn't have chosen a slash, but I couldn't imagine that the Bash might partially stop the support leaving other frequently used characters, such as hyphens, periods, and colons. > but how does your system work with global > variables that those functions might need? This is a good question. First of all, I do not use global variables so much because I'm using the function names with slashes in Bash scripts, and Bash has local variables. Nevertheless, I occasionally need to store information in global variables. In that case, I need to choose a different naming convention for the variable names. Currently, I'm using roughly the form of `_<FrameworkName>_<ModuleName>_<VariableName>'. To avoid conflicts, it is sufficient to assume that the other frameworks and the applications do not use the variables starting with `_<Frameworkname>_...`. The function names and the variable names do not need to be the same as far as the namespace is effectively separated by the prefix `_<FrameworkName>'. There is no 100% guarantee that no other scripts use the same prefix, but so far it seems to work fine. The conflict rate is so small that I can manage it after noticing it. -- Koichi