2023年2月4日(土) 11:12 Chet Ramey <chet.ra...@case.edu>: > > But a posix conforming shell will still never execute a function that > > has a '/' in its name, even if it has extended the character set for > > function names, and allows '/' in that set. > > Yep. I'll probably change that.
I disagree with making the change to disallow the execution of functions with a slash in their names. First, this breaks backward compatibility. As I have mentioned in another reply, I'm using slashes in function names everywhere in my Bash scripts (of course, which is not the POSIX shell scripts). As I am using slashes for namespacing, almost all the shell functions in my shell library contain slashes in their function names. This might be a personal thing, but I'm really unhappy if this incompatible change is made. Anyway, I don't think there is a good reason to break backward compatibility for the feature that Bash had from the very beginning. Also, if a script is intended to be a portable POSIX-shell script, the script will never attempt to define a shell function that has slashes in its function name. So, even though Bash runs the functions whose names contain slashes, it doesn't change any behavior of the portable POSIX-shell scripts. The functions that have slashes in their names are Bash extensions. Is Bash required to strictly follow the POSIX standard even for non-POSIX shell scripts that use Bash extensions? For compatibility among shell implementations, Zsh also seems to support the execution of functions with a slash in their names, though Yash doesn't seem to attempt to run such functions. Also, it seems no one has pointed out this incompatibility with the standard for more than thirty years, which implies that no one including the POSIX people hasn't paid much attention to these detailed behavioral differences. I feel this is just an issue of the wording of the standard and its interpretation. Is it impossible that this is explicitly marked as `unspecified' in the standard? -- Koichi