--- Martin Bähr <[EMAIL PROTECTED]> skrev: > On Mon, Oct 02, 2006 at 01:41:44AM +0200, Axel > Liljencrantz wrote: > > > i have a discussion item that will force a > filename > > > change in anycase, > > Ok. Is it something like timestamping commands, or > > giving each command a unique id? > > no, it is nothing about the format ir information > stored, but simply > about the filenames or rather locations themselves. > > at present, fish is putting 5 items in my > homedirectory: > .fish.d/ (Directory) .fish_read_history > (File, 77B) > .fish_history (File, 57kB) .fishd.tomoyo > (File, 1.1kB) > .fish_inputrc (File, 90B)
Never thought about that aspect, but I guess you are right. > > and many other apps dropping files there too. > my homedirectory is a mess!!! > > please don't do that. > > take a look at what the filesystem hierarchy > standard has to say about that: > > http://www.pathname.com/fhs/pub/fhs-2.3.html#HOMEUSERHOMEDIRECTORIES > User specific configuration files for applications > are stored in the > user's home directory in a file that starts with > the '.' character (a > "dot file"). If an application needs to create > more than one dot file > then they should be placed in a subdirectory with > a name starting with a > '.' character, (a "dot directory"). In this case > the configuration files > should not start with the '.' character. > > in other words: do not create multiple files in the > users homedirectory, > but please move all of them into one directory > called .fish (and not > .fish.d as the .d is redundant) One note here: The way I read the part of the standard you quote, it does not make any mention either of the use of either the '.d' or the 'rc' suffix, both of which are common. _My_ interpretation is that both are allowed, though I have been told that the '.d' suffix is a recent invention and should is frowned upon as non-Unixy. Unfortunatley, I think that it's a bit late for removing the '.d', I expect there are quite a few users that have their own functions and completions in ~/.fish.d. Even worse, there are definitely many users with a ~/.fish file, so a new directory name would cause a clash. The current naming is partially there for historical reasons. Originally, fish did not have autoloaded completions or functions, they where all contained in separate files in /etc/fish.d/. The main fish file would then source all .fish files in that directory. This would allow an administrator to drop in site specific initializations into files in that directory without running into trouble with package managers. This arrangement is modelled after the bash layout using /etc/profile and /etc/profile.d/. I feel that a ~/.fish configuration file makes much more sense than a ~/.fish.d/fish file, it's too much to write for a file that you occasionally want to edit, and two files in ~ isn't that much. The rest of the files you mention should not usually be edited by the user, so keeping them out of sight makes more sense. Does the following hierarchy sound like a sound solution to everybody (anybody?): .fish .fish.d/ .fish.d/fish_read_history .fish.d/fish_history .fish.d/fishd.[HOSTNAME]... .fish.d/fish_inputrc As a sidenote, I'll mention that emacs uses ~/.emacs as a user accessible configuration file, and uses ~/.emacs.d for 'strange' files. And everybody here uses emacs and trusts the judgement of the FSF in all things, right? ;-) > > the same is true for /etc > ls /etc/fish<tab> > ...tc/fish (File, 1.3kB) ...tc/fish_inputrc > (File, 888B) > ...tc/fish.d/ (Directory) True. By the same logic I used above, fish_inputrc should be moved, but fish shouldn't. > (btw it seems odd that /e is reduced to one '...' > character while there > is plenty of space left.) Yes, it does. But you have to draw the line somewhere. Maybe fish should make the prefix significanlt shorter once it abbrevates things to keep things less silly? > http://www.pathname.com/fhs/pub/fhs-2.3.html#FTN.AEN540 > It is recommended that files be stored in > subdirectories of /etc rather > than directly in /etc. > > fish is again doing both here for no good reason. > also here it would be nice if all files could be > stored under /etc/fish/ > > > for the home directory, it would be even nicer if > all applications could > store their config files under $HOME/etc/<appname>/ > or $HOME/.etc/<appname>/ > but unfortunately there is currently no standard for > that (and the fhs > won't accept this as a standard until a greater part > of user > applications already implements it). you could > however be very > progressive and implement it anyways :-) I could, but my honest opinion is that ~ is a pretty sane place to store the configuration files that you routinely want to edit. How do other people feel on this? > > in general, having things not spread out into > multiple places makes > things like backup much easier. (with one fish > config dir i could more > easely share fish setup among machines. with an > $HOME/.etc/ dir i could > make a backup of just my config data, etc...) True, that is a distinct advantage of a deeper hierarchy. > > greetings, martin. > -- > cooperative communication with sTeam - > caudium, pike, roxen and unix > offering: programming, training and administration > - anywhere in the world > -- > pike programmer travelling and working in europe > open-steam.org > unix system- bahai.or.at > iaeste.(tuwien.ac|or).at > administrator (caudium|gotpike).org > is.schon.org > Martin Bähr http://www.iaeste.or.at/~mbaehr/ > ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Fish-users mailing list Fish-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fish-users
