On Thu, Jan 8, 2015 at 3:08 PM, Luke Diamand <l...@diamand.org> wrote:
> On 08/01/15 17:53, Avery Payne wrote: > >> The use of hidden directories was done for administrative and aesthetic >> reasons. The rationale was that the various templates and scripts and >> utilities shouldn't be mixed in while looking at a display of the various >> definitions. >> > > Why shouldn't they be mixed in? Surely better to see everything clearly > and plainly, than to hide some parts away where people won't expect to find > them. I think this may confuse people, especially if they use tools that > ignore hidden directories. > Ok, I'll take this as part of the consideration. > Move everything down one level then? > I've given it a bit of thought. I would be willing to remove the dots. However, the current naming convention would create confusion if you were to eliminate the support directories altogether. Keep in mind the purpose of the directories was to separate out functionality and clearly define what a group of things does; a service template is vastly different from a logging template. The script names were meant as a reminder to how they are used, along with the directories. This is why there is a run-svlogd, and not a log-svlogd. However, I suppose I could rename things to better match their intended use. And while I don't want to drop the prefix (for reasons of clarity when writing the script) as long as the directories remain, I'm willing to drop those as well. The proposal woudl be, inside of sv/, something like: /bin /bin/use-daemontools /bin/use-runit /bin/use-s6 /env /env/PATH /env/FRAMEWORK /env/ENABLE_DEPENDS /finish /finish/clean /finish/notify /finish/force /log /log/multilogd /log/svlogd /log/s6-log /log/logger /log/socklog /run /run/envdir /run/getty /run/user-service /(definition 1) /(definition 2) ...and so on, without the dots. I'm not wild about the "messy appearance" it will give but if it makes adoption easier, then I'll do it. That, and we now have five words that are reserved and can never be used by any service (although I doubt that a service would use any of the above), because the names exist alongside the definitions. That was another reason I wanted dot-files - it was one less thing to worry about, one less issue that needed attention. Good thing the bulk of the defintions are symlinks...makes it easy to switch the directory name. ;)