[oi-dev] /etc/profile.d and /etc/csh/login.d directories

[Peter Tribble]

On Fri, Nov 29, 2013 at 7:44 AM, Alexander Pyhalov <alp at rsu.ru> wrote:

> Good morning.
>
>
> On 11/28/2013 13:36, Jonathan Adams wrote:
>
>> I know this sounds silly, because a standard of sorts already exists
>> (other
>> platforms use something similar), but can we not have a common
>> subdirectory
>> in /etc for these scripts, e.g. /etc/shell.d with the relevant
>> shells/scripts as subdirectories. e.g. /etc/shell.d/profile and
>> /etc/shell.d/login ?
>>
>
> 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?
>

I've not got a debian box to check right now, but /etc/csh/login.d
doesn't exist on the Ubuntu system I just checked, and it doesn't
exist on  Red Hat, which uses /etc/profile.d/*.csh - if you did want
to adopt such a mechanism (and that's a good thing - remember my
objections are to it being forced onto all users by default) then I
would think that /etc/profile.d would be the place to choose.


> just as a suggestion, which you are free to ignore, when you get a new
>> Apache2 server set up on an Ubuntu box, you get the "sites-available" and
>> "sites-enabled" directories. All available scripts/setup are in
>> sites-available, and if they are wanted they are soft-linked into the
>> sites-enabled directory ... do we want to consider doing something like
>> this for shell scripts?
>>
>
> 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.


The only way this could work is for everything to be disabled by default.
If it's enabled by default, and you disable it, then IPS would fix it back
to
enabled, which would violate administrator intent. If you ship everything
disabled, then IPS won't touch the enabling links made by an admin,
and behaviour on fix or upgrade is safe.

 Just out of interest, how did you envisage sorting the run order for the
>> scripts in the subdirectories?
>
>
I think you have to assume that ordering is unspecified. In general,
behaviour is badly defined for systems like this - even if the execution
order is defined, any script can override or wreck the customizations
in other scripts, and changes to any script (or addition or removal
of any scripts) can cause random changes to system behaviour.


> Are we planning on instigating the 2 digit
>> leading order, in a similar fashion to the rc.d scripts? if we were, then
>> we could check for filenames beginning with numbers, which would allow
>> "README" and other documentation to exist in those directories that isn't
>> run automatically.
>>
>
Well, the systems I've seen use *.sh, so README would get skipped
automatically in any case.

 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).
>

Not really. Under Red Hat it's mostly junk environment variables and
aliases. Ubuntu seems to run a whole load of completions, which
doesn't seem to be enabled by default on my Red Hat boxes, but
is all specific to bash and doesn't seem to be implemented for
other shells.

-- 
-Peter Tribble
http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://openindiana.org/pipermail/oi-dev/attachments/20131129/1f64ca21/attachment-0005.html>