2023年2月4日(土) 17:14 Oğuz <oguzismailuy...@gmail.com>: > 4 Şubat 2023 Cumartesi tarihinde Koichi Murase <myoga.mur...@gmail.com> yazdı: >> >> Wouldn't it be possible to make the result of defining the function >> names with slashes unspecified in a similar idea? > > If you mean like declaring that a shell's overall behavior be unspecified
I didn't mean that the overall behavior is unspecified. By ``a similar idea'', I meant that, similarly to XCU 2.4 and 2.10.2/7b (as listed just before the question ``Woundn't it ...''), the standard might declare that the behavior of the related parts becomes unspecified. Changing the behavior related to the function names wouldn't make the behavior of the shell entirely unspecified, though the impact is admittedly wider than e.g. just defining a function with « function NAME { list; } » syntax. > But then how would you execute a program that resides in, for example, the > current directory portably? `(exec ./program)`? If the script would intend to be portable, the script doesn't define a function named `./program' to begin with, so one can safely call any programs in the current directly portably. Also, the name conflicts are not specific to this type of function name but can happen more frequently with the simple NAME as the size of the namespace is limited. In that case, maybe the user wants to intentionally replace the utility of that name with a shell function, but a user might also intentionally replace the utility specified by a pathname containing slashes intentionally. > I don't have any personal reason to support or not support what you propose, > but that names of functions and pathnames of executables can clash even under > POSIX mode doesn't feel right. I think this is the point to discuss. I actually think that that is also a valid way of thinking if we could carefully design the behavior of Bash thirty years ago, but now I'm not sure if it would be beneficial to change the behavior that has existed for thirty years. I believe this behavior hasn't caused any real problems because portable scripts do not define functions that have a slash in their name. With old versions of Bash, one could export functions with slashes through environment variables, but now it is also disabled after Shellcheck. As far as I test, there are four implementations that allow defining functions with slashes: Bash and Zsh allow executing the functions (even in their POSIX modes), and mksh and Yash don't allow executing them by default. I'm not sure if we can count Yash in thinking about reasonable behavior because Yash intends to strictly conform to the standard and is not designed for reasonable behaviors. If a non-POSIX (ksh-like) shell script defines any functions with names that have a slash and conflict with the real executable files the script wants to run, the script should be responsible for any problems caused by it. If the script wants to run the executable, the script obviously shouldn't define the function with the same name as the executable path. Also, in reality, the script currently cannot expect that either one (the function or the executable file) is called consistently and portably in Bash, Zsh, mksh, and Yash when there is a conflict. -- Koichi