2024年5月21日(火) 14:56 Phi Debian <phi.deb...@gmail.com>: > Apparently konsolebox wrote a package manager, and survived the source 'as > is', yet he still advocate for 'enhancement'. I do have a package manager > too, and survived source 'as is' and don't require any enhancement.
I'm not sure if it is the case for konsolebox, but I think it is valid to suggest including the features that turned out to be useful in maintaining a package manager as built-in ones. Those suggested features are meant to replicate the useful part of the features of the package manager, so it is not surprising that the suggested features are not needed for the package manager itself. That said, I think it would be difficult to reach an agreement on the detailed behavior of the suggested features to make them consistent with many existing package managers. > 'May be' bash could investigate the ksh93/zsh $FPATH autoload, but don't > know if that would be good enough for the initial purpose. There are already shell-function implementations at /examples/functions/autoload* in the Bash source. They reference FPATH to load functions, though one needs to call `autoload' for each function in advance (by e.g. `autoload "$fpath_element"/*' ). However, I personally do not think the FPATH mechanism is useful because a file can only contain one function per file. Significantly non-trivial functions are usually implemented by a set of helper functions or sub-functions. Also, in libraries, we usually have a set of functions that are closely related to one another and share the implementations. I don't think it is practical to split those functions into dozens or hundreds of files. It would also be slow to read many different files, which requires access to random positions on the disk. -- Koichi
