This is the mail archive of the cygwin-apps mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [ITA] - base-files


On Thu, Dec 09, 2010 at 09:59:32AM -0800, Karl M wrote:
> > Date: Thu, 9 Dec 2010 12:04:39 +0000
> > From: andy
> > On 9 December 2010 06:29, David Sastre wrote:
> > > On Wed, Dec 08, 2010 at 11:21:38PM +0000, Andy Koppe wrote:
> > >> On 8 December 2010 21:22, David Sastre wrote:
> > >> > I have decided to pull out of /etc/profile the case switch that tries
> > >> > to detect the shell and sets PS1 (and HOSTNAME) accordingly.
> > >> >
> > >> That's not going to work for people whose .bash_profile and .bashrc
> > >> don't adhere to that pattern or who don't have those files for
> > >> whatever reason, i.e. they'll suddenly get the default "$ " prompt.
> > >>
> > Hang on, /etc/bash.bashrc isn't an official bash startup file, is it?

Nope. It is not listed as such in the GNU Bash manual, but it does exist in 
RHEL as /etc/bashrc and in debian as /etc/bash.bashrc, like in cygwin BTW.
The bash man page in debian even lists /etc/bash.bashrc as a startup 
file (and it's actually read before ~/.bashrc). So, yes, you are right.

> > > And in the case some people don't use this layout, well, AFAICT, if
> > > they don't use the default, they are supposed to know what they're
> > > doing, right?
> >
> > Sure, but that doesn't mean that breaking existing setups that don't
> > follow the /etc/skel layout is a good idea. I'd expect lots of
> > questions about how to fix the prompt.

I fail to see how any customised setup would end up broken.
The skeletal files are copied to the user's $HOME only if $HOME
doesn't exist and they are never overwritten nor updated; the installation of 
a new base-files package places its defaults in /etc/default/etc and does not 
touch anything that may have been modified by the user in /etc/skel.
And given that critical files will be detected as modified (even if
they are not) because of the cmp line in preremove, existing files
remain untouched and new files end up in /etc/default/etc.

> > That's the point I was trying to make. A bash login shell only
> > automatically sources the *profile files, not the *bashrc files. Users
> > have every right to customise their ~/.bash_profile and ~/.bashrc to
> > death, or to just delete them. Or perhaps they didn't have them in the
> > first place because they nominated an existing directory as their home
> > without copying the skel files. So there's no guarantee that ~/.bashrc
> > and /etc/bash.bashrc are sourced by a bash login shell.

That's true. Unless sourced from /etc/profile. Would that be
acceptable? Debian proposes this in its /etc/bash.bashrc. 
(now I wonder if that's a patch in Debian, a compile-time option for 
bash, or what...)
The whole thing would be:

  - /etc/profile is the login entry-point for everybody
  - There must be a switch for bash/mksh/* (again, but...)
  - The switch sources the corresponding /etc/${SHELL}rc
  - Afterwards, it will read ~/.*profile automatically, so we don't
    depend on ~/.bash_profile to have /etc/bash.bashrc sourced.

  - Interactive non-login access uses ~/.${SHELL}rc
  - There we source /etc/${SHELL}rc. Here, if the line sourcing
    /etc/bash.bashrc is removed, you're on your own.
    (and we wouldn't depend on ~/.bashrc either if the actual order was
    /etc/bash.bashrc -> ~/.bashrc. It's starting to make sense that 
    debian stuff...)

This requires minimal changes to the existing proposal, and still
solves a pair of annoyances. Opinions?

> But do we have to provide backward compatibility for user modified startup
> files?

I don't think we should. I don't even think we could. As I said above, user's
customised environments should have their base-files packages updated transparently. 
Only new users, new installations, and manual intervention should ever notice 
the changes.

> Can't we provide an efficient set of defaults that play together nicely with
> no redundancy and then let the user hack from there?

I hope so :)
Again, thanks for taking the time to review this.

-- 
Huella de clave primaria: 0FDA C36F F110 54F4 D42B  D0EB 617D 396C 448B 31EB

Attachment: signature.asc
Description: Digital signature


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]