<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Nov 29, 2013 at 7:44 AM, Alexander Pyhalov <span dir="ltr"><<a href="mailto:alp@rsu.ru" target="_blank">alp@rsu.ru</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Good morning.<div class="im"><br>
<br>
On 11/28/2013 13:36, Jonathan Adams wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
I know this sounds silly, because a standard of sorts already exists (other<br>
platforms use something similar), but can we not have a common subdirectory<br>
in /etc for these scripts, e.g. /etc/shell.d with the relevant<br>
shells/scripts as subdirectories. e.g. /etc/shell.d/profile and<br>
/etc/shell.d/login ?<br>
</blockquote>
<br></div>
I don't think that this is a good idea. It would be confusing. I like /etc/profile.d . Perhaps, I'd prefer to use /etc/profile.d/*.sh for sh scripts and /etc/profile.d/*.csh for csh. But if /etc/csh/login.d is used by Debian, why not do it in a more widespread way?<br>
<div class="im"></div></blockquote><div><br>I've not got a debian box to check right now, but /etc/csh/login.d<br>doesn't exist on the Ubuntu system I just checked, and it doesn't<br>exist on  Red Hat, which uses /etc/profile.d/*.csh - if you did want<br>
</div><div>to adopt such a mechanism (and that's a good thing - remember my<br>objections are to it being forced onto all users by default) then I<br>would think that /etc/profile.d would be the place to choose.<br></div>
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="im"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">

just as a suggestion, which you are free to ignore, when you get a new<br>
Apache2 server set up on an Ubuntu box, you get the "sites-available" and<br>
"sites-enabled" directories. All available scripts/setup are in<br>
sites-available, and if they are wanted they are soft-linked into the<br>
sites-enabled directory ... do we want to consider doing something like<br>
this for shell scripts?<br>
</blockquote>
<br></div>
I don't know if IPS can deliver link "on install". So, if admin later removes a link, it doesn't reappear on pkg update. </blockquote><div><br></div><div>The only way this could work is for everything to be disabled by default.<br>
</div><div>If it's enabled by default, and you disable it, then IPS would fix it back to<br>enabled, which would violate administrator intent. If you ship everything<br></div><div>disabled, then IPS won't touch the enabling links made by an admin,<br>
and behaviour on fix or upgrade is safe.<br></div><div><br> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="im">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Just out of interest, how did you envisage sorting the run order for the<br>
scripts in the subdirectories? </blockquote></div></blockquote><div><br>I think you have to assume that ordering is unspecified. In general,<br>behaviour is badly defined for systems like this - even if the execution<br>
order is defined, any script can override or wreck the customizations<br>in other scripts, and changes to any script (or addition or removal<br></div><div>of any scripts) can cause random changes to system behaviour.<br></div>
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="im"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Are we planning on instigating the 2 digit<br>
leading order, in a similar fashion to the rc.d scripts? if we were, then<br>
we could check for filenames beginning with numbers, which would allow<br>
"README" and other documentation to exist in those directories that isn't<br>
run automatically.<br>
</blockquote></div></blockquote><div><br>Well, the systems I've seen use *.sh, so README would get skipped<br>automatically in any case.<br><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div class="im">
</div>
By default, scripts are read in alphabetical order due to shell patterns expansion rule. I don't think that it has sense to support any particular execution order there. This is a place for additional customizations, which can be skipped/ignored (it seems that on Linux /etc/profile.d/* scripts are used mostly for different auto-completion rules).<br>
</blockquote></div><br clear="all">Not really. Under Red Hat it's mostly junk environment variables and<br>aliases. Ubuntu seems to run a whole load of completions, which<br>doesn't seem to be enabled by default on my Red Hat boxes, but<br>
is all specific to bash and doesn't seem to be implemented for<br>other shells.<br><br>-- <br>-Peter Tribble<br><a href="http://www.petertribble.co.uk/">http://www.petertribble.co.uk/</a> - <a href="http://ptribble.blogspot.com/">http://ptribble.blogspot.com/</a>
</div></div>