On 2/23/06, Axel Liljencrantz <[EMAIL PROTECTED]> wrote: > On 2/23/06, Philip Ganchev <[EMAIL PROTECTED]> wrote: > > On 2/22/06, Axel Liljencrantz <[EMAIL PROTECTED]> wrote: > > > At the suggestion of Freso and Jamessan, I have remade the fish > > > directory structure so that archidecture independant data, such as > > > completion information and shellscript function definitions now live > > > in $PREFIX/share/fish/, not /etc/fish.d/. This new layout means much > > > fewer files in /etc, and much fewer changes in those files. > > > > I'd prefer all the config files to be in the same directory, or at > > least be linked to /etc/, despite the purist ideals of the Unix > > Filesystem Hierarchy Standard. > > > > If Fish's hierarchy must be changed, how about adding links to /etc/ > > so that users can find the files? > > It is kind of hard to decide what is configuration and what is data. > The things that have been moved are the command specific completions > and a host of shelscript functions. From my point of view, these > things are not configuration options, they are a core part of fish, > and the files should never actually be edited by the user or sysadmin. > If the user wants to change the completions, s/he should create a new > completion file to override the old one, and put it earlier in the > completion search path. That way the edited completion will get loaded > after the next fish upgrade as well. > > Things like setting the prompt command, IFS, etc.. still live in /etc.
Makes sense, I suppose, though completions, etc. still may be configured. I don't understand the harm in including links to them in /etc/. > > > But changing such things always results in potential upgrade glitches. > > > I'm worried that a lot of the poeplte who upgrade using the source > > > tarball will skip using 'make uninstall' before installing the new > > > fish version, hoping that the new files will simply overwrite the old > > > ones. In this case, it will leave a lot of dangling files in /etc, > > > files whose functionality is replaced by other files in > > > $PREFIX/share/fish/. I'm thinking that maybe the fish installation > > > scripts should try to help the user with this task, but I'm not sure > > > > Is this different than the question What to do with existing > > configuration files in general (i.e. if Fish's directory hierarchy > > stays the same)? I suggest treating them the same way. > > Yes it is. The only concern I have here is that it is rather common > when updating to a new version of a program to simply do a > './configure; make; make install', in which case old files will be > left in the filesystem, and in some cases they will override new, > better versions of the same functionality, leading the bugs. > > If the user does a 'make install' s/he is probably aware that the old > versions of the fish files will be toasted, but might not have though > about dangling files that cause chaos and mayhem.. [...] > > > * Automatically rename files with a name that is known to have been > > > previously used by fish. This seems scary since a sysadmin might > > > create a /etc/fish.d/fish_functions.fish files and be in for a > > > surprise. > > > * Pause the install process to interactively ask the user if s/he want > > > to rename the relevant files. > > > * Refuse to install if old deprecated init files still exist, and tell > > > the user to use 'make uninstall' first. > > > * Just send a big warning message if the relevant files are already > > > present, but don't take any action. > > > > > > The first one, while helpfull, seems a bit to dangerous. The second > > > one, while nice, seems like it could jam up automated buildprocesses. > > > The third one is probably the one I like best, it might be a hassle, > > > but it should be safe. The fourth one, while not very dangerous, means > > > that all the people who don't pay attention to the build logs, will > > > have a less than > > > > Of those four I prefer (3) and (4), if I understand correctly. I agree > > (1) is not desirable. > > > > How about > > > > 5. Rename the old files to filename.fish_old or filename_date.fi and > > inform the user. The new filename should not end on .fish, or the > > init script cannot safely source *.fish. > > Isn't that the same thing as (1)? Rename the files so they won't get > autoloaded. Oh, so it is. Sorry, I misunderstood (1). In this new light, (2) this seems the best option to me, followed by (1). (2) makes sure to install a working Fish and that the user knows about the changes. As I understand, the renaming is not automatic, and the user may decide to stop the installation and take action. (1) insalls a working Fish with the advantage of not interrupting the install process. A sysadmin ought to test the newly installed system anyway, especially if s/he has previously customized Fish and (thanks to the warning message) would know where to look if the old customization was invalidated. Still, it is probably nicer to deal with the issue during installation, rather than having to remember to return to it. (3) ultimately achieves the same, but you have to jump throught the hoops before you can try your new Fish installation and re-customize it. (Presumably, "make uninstall" also prints a warning message and renames the files.) Option (4) does not achieve much, since the files are still there, possibly causing trouble in the newly installed Fish version. But I understand you have decided this in favor of (3) and moved to the next issue. ------------------------------------------------------- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid0944&bid$1720&dat1642 _______________________________________________ Fish-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/fish-users
