[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Another possible slink goal (multipackages users profile)

I haven't expected this thread to be extended that much.  In order to
not add another 10 messages I'll put all into one.

Wichert Akkerman wrote:
> Previously Martin Schulze wrote:
> > Therefore I believe that we should elaborate a mechanism that can be
> > used for all shells. This could be /etc/profile.d/ containing scripts
> > or fragments. It could alternatively contain some data that will be
> > evaluated and changed into code that can be read by the used shell.
> Don't include scripts then, but something really simple that can be
> translated into legal script. Also add update-profile so not all
> fragments in /etc/profile.d/ doesn't need to be parsed when you open
> a shell, but only once.

Thats what I was referring to when I said "elaborate a mechanism".
Think of the dircolors program.  Call it with -b and it generates
bourne shell source, call it with -c and its output is used for any C

Raul Miller wrote:
> Because I think the problem you're trying to solve is larger than
> what goes into /etc/passwd -- if that was the extent of the problem
> then we could solve it by having /bin/login interpret something
> like /etc/environment.

No objections.  Except that it doesn't solve all problems.  Some
packages require that special programs are called when the user logs

As an example, if you're receiving files via SAFT the normal setup is
that you're notified via write(1).  The benefit of this means of file
transfer is that you don't have to be at your machine.  This means
that the file is received but you don't get a notification about its
existance.  Therefore a small program is started during login that
notifies you that there are files waiting in your queue.

Guy Maor wrote:
> Adding programs to be run automatically is an even worse idea.  On a
> single-person system, the user knows what software is installed
> because he installed it.  And a user on a multi-user system certainly
> doesn't want random programs run on login because the administrator
> thinks they're neat.

Since Debian comes with >1500 packages and since people simply install
things they don't know of - even I do that partially - we cannot depend
on people knowing what programs and services are running.

Guy Maor wrote:
> Martin Schulze <joey@kuolema.Infodrom.North.DE> writes:
> >    Therefore I believe that we should elaborate a mechanism that can be
> >    used for all shells. This could be /etc/profile.d/ containing scripts
> >    or fragments. It could alternatively contain some data that will be
> >    evaluated and changed into code that can be read by the used shell.
> I completely disagree with this proposal.  Packages should be
> configured so that they run correctly without any environment
> variables or other cruft set.

This is a different story.  Programs still have to run without that
environment but they may run better with a modified environment.

For example, think of the coloured ls.  ls runs perfectly without
colours and without the special environment that tells it to use
colours.  But it runs "better" (here: nicer, easier to read) when
colours are used.  This is triggered by some variables (two iirc).

Jules Bean wrote:
> Actually, I agree with this point.  Environment variables are evil.  Like
> 'http_proxy' (Jason ;-).

Oh well, this is another story.  As a sysadmin I want people to use
the proxy.  In my network often people reading the same things and
it's just a waste of bandwidth not to use the proxy.

Therefore I have installed /usr/bin/lynx.sh, /usr/bin/wget.sh,
/usr/X11R6/bin/xmosaic.sh etc. that read information about the proxy,
set some environment variables and execute the browser afterwards.

I haven't made a proposal about this because I'm unsure what's the
best method for its implementation.

a) Generally set http_proxy, ftp_proxy, gopher_proxy and no_proxy
   through /etc/profile or a similar file.

b) Create /etc/www.conf contain information about the proxy to use and
   replace the brower binary with a simple shell script that evaluates
   the conffile and executes the browser afterwards.

b) Can be easily ignored since the user can use browser.bin to go
   without a proxy or call the browser (script) with the -noproxy

a) Can be ignored by unsetting these variables in the users profile.

I have to admit that b) is easier to do if you want to ignore the
proxy just for some few pages every now and then.

Jules Bean wrote:
> However, I would ask the proponents of this plan to back off one step from
> implementation, and give the list some examples of the kind of problem it
> is designed to solve.

I'm thinking of the following things:

 . Call check-sendfile to check the SAFT queue
 . Call dircolors in order to give coloured ls
 . Call fortune so users can smile when they start working
 . Maybe: Force the use of proxies
 . Set system-wide consistant shell prompt (I guess PS1 from
   /etc/profile only works for bourne shells?)
 . Make it possible for the local sysadmin to add local environment
   variables, aliases, functions etc. [where this is possible]
 . Add more components to the PATH such as ~/bin if it exits,
   /usr/local/<package>/bin, /opt/<package>/bin etc.

I'm sure that I've missed some.


I the new mechanism is based on _one_ config file then we need tools
to modify it since the policy forbids us to randomly modify
configuration files that belong to other packages except if there are
certain tools that can be called and that handle the modifications



VFS: no free i-nodes, contact Linus  -- finlandia, Feb '94 

Attachment: pgpqyxfOETgNb.pgp
Description: PGP signature

Reply to: