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 shell. 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 in. 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 argument. 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 itself. Regards, Joey -- VFS: no free i-nodes, contact Linus -- finlandia, Feb '94
Attachment:
pgpqyxfOETgNb.pgp
Description: PGP signature