Re: [ITA] base-files
Christopher Faylor writes: Package updates happen every five minutes so you were probably only a minute or so from having inetutils upload privileges. I've seen that and almost put the update out, but I have one question: I gave the patched tar file a release number of 1p1 so that Chuck can continue to increment his releases as he wishes. That works fine when using genini, but I'm not sure what if upset would accept this as a valid package. If you think that's OK, then I'll set the !ready flags. Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ SD adaptation for Waldorf microQ V2.22R2: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada
Re: [ITA] base-files
On Tue, Apr 08, 2014 at 08:05:39PM +0200, Achim Gratz wrote: Christopher Faylor writes: Package updates happen every five minutes so you were probably only a minute or so from having inetutils upload privileges. I've seen that and almost put the update out, but I have one question: I gave the patched tar file a release number of 1p1 so that Chuck can continue to increment his releases as he wishes. That works fine when using genini, but I'm not sure what if upset would accept this as a valid package. If you think that's OK, then I'll set the !ready flags. That's very thoughtful of you but I think I'd rather not experiment with version number ordering. I think you should just bump the -N part to the next higher number and let Chuck deal with bumping his version number twice. I think that will be less confusing to upset and the end user. On a side note: I REALLY REALLY hope Chuck is ok and is just on vacation or something. cgf
Re: [ITA] base-files
Christopher Faylor writes: That's very thoughtful of you but I think I'd rather not experiment with version number ordering. I think you should just bump the -N part to the next higher number and let Chuck deal with bumping his version number twice. I think that will be less confusing to upset and the end user. Done and the update is triggered. Hopefully that works out with no errors from upset. If I may ask another question, is there a way to get the generated setup.ini files directly, before they get pushed out to the mirrors? On a side note: I REALLY REALLY hope Chuck is ok and is just on vacation or something. Seconded. Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ Waldorf MIDI Implementation additional documentation: http://Synth.Stromeko.net/Downloads.html#WaldorfDocs
Re: [ITA] base-files
On Tue, Apr 08, 2014 at 08:30:02PM +0200, Achim Gratz wrote: Christopher Faylor writes: That's very thoughtful of you but I think I'd rather not experiment with version number ordering. I think you should just bump the -N part to the next higher number and let Chuck deal with bumping his version number twice. I think that will be less confusing to upset and the end user. Done and the update is triggered. Hopefully that works out with no errors from upset. If I may ask another question, is there a way to get the generated setup.ini files directly, before they get pushed out to the mirrors? You can always download them directly from ftp.cygwin.com but I wouldn't advertise that fact too heavily. We have mirrors to keep the load on cygwin.com/sourceware.org as light as possible. cgf
Re: [ITA] base-files
Christopher Faylor writes: You can always download them directly from ftp.cygwin.com but I wouldn't advertise that fact too heavily. We have mirrors to keep the load on cygwin.com/sourceware.org as light as possible. Thanks. Being able to use this has alerted me to the fact that I needed to also change the setup.hint file on x86 due to the fact that a test package was present. On its way now… Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ SD adaptations for KORG EX-800 and Poly-800MkII V0.9: http://Synth.Stromeko.net/Downloads.html#KorgSDada
Re: [ITA] base-files
On Mon, Apr 07, 2014 at 02:19:10PM -0400, Christopher Faylor wrote: On Mon, Apr 07, 2014 at 02:08:42PM +0200, Corinna Vinschen wrote: On Apr 5 12:20, Achim Gratz wrote: Corinna Vinschen writes: FYI, I contacted Chuck off-list 6 days ago but he didn't reply yet. Same here. I hope Chuck will still reply in the next couple of days, but if not, we have to find some solution to be able to go forward. I am updating some packages this weekend, so if someone can make me temporarily maintainer for inetutils-server I'll repackage it without /etc/default/etc/shells and upload together with base-files and the other updates. Chris, can we do this by simple changing cygwin-pkg-maint temporarily? Yep. That would work. In theory, you shouldn't have to drop Chuck as a maintainer. You could have both Achim and Chuck as inetutils-server maintainers. cgf
Re: [ITA] base-files
On Mon, Apr 07, 2014 at 08:55:52PM +0200, Corinna Vinschen wrote: On Apr 7 14:20, Christopher Faylor wrote: On Mon, Apr 07, 2014 at 02:19:10PM -0400, Christopher Faylor wrote: On Mon, Apr 07, 2014 at 02:08:42PM +0200, Corinna Vinschen wrote: On Apr 5 12:20, Achim Gratz wrote: Corinna Vinschen writes: FYI, I contacted Chuck off-list 6 days ago but he didn't reply yet. Same here. I hope Chuck will still reply in the next couple of days, but if not, we have to find some solution to be able to go forward. I am updating some packages this weekend, so if someone can make me temporarily maintainer for inetutils-server I'll repackage it without /etc/default/etc/shells and upload together with base-files and the other updates. Chris, can we do this by simple changing cygwin-pkg-maint temporarily? Yep. That would work. In theory, you shouldn't have to drop Chuck as a maintainer. You could have both Achim and Chuck as inetutils-server maintainers. How so? Simply both maintainers in the same line, like this: inetutils Charles Wilson, Achim Gratz or two lines? inetutils Charles Wilson inetutils Achim Gratz The latter. The former would be viewed as one person named Charles Wilson, Achim Gratz. cgf
Re: [ITA] base-files
On Apr 7 15:23, Christopher Faylor wrote: On Mon, Apr 07, 2014 at 08:55:52PM +0200, Corinna Vinschen wrote: On Apr 7 14:20, Christopher Faylor wrote: On Mon, Apr 07, 2014 at 02:19:10PM -0400, Christopher Faylor wrote: On Mon, Apr 07, 2014 at 02:08:42PM +0200, Corinna Vinschen wrote: On Apr 5 12:20, Achim Gratz wrote: Corinna Vinschen writes: FYI, I contacted Chuck off-list 6 days ago but he didn't reply yet. Same here. I hope Chuck will still reply in the next couple of days, but if not, we have to find some solution to be able to go forward. I am updating some packages this weekend, so if someone can make me temporarily maintainer for inetutils-server I'll repackage it without /etc/default/etc/shells and upload together with base-files and the other updates. Chris, can we do this by simple changing cygwin-pkg-maint temporarily? Yep. That would work. In theory, you shouldn't have to drop Chuck as a maintainer. You could have both Achim and Chuck as inetutils-server maintainers. How so? Simply both maintainers in the same line, like this: inetutils Charles Wilson, Achim Gratz or two lines? inetutils Charles Wilson inetutils Achim Gratz The latter. Done. Achim, if you would be so kind... Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpSbOBkfHRpe.pgp Description: PGP signature
Re: [ITA] base-files
Corinna Vinschen writes: Done. Achim, if you would be so kind... I'll do it tomorrow evening as the latest update of the !package file hasn't picked it up yet. I have an early morning meeting tomorrow and need to fetch some sleep, so I don't want to wait another hour… hope this is OK. Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ Factory and User Sound Singles for Waldorf Q+, Q and microQ: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds
Re: [ITA] base-files
On Mon, Apr 07, 2014 at 09:39:46PM +0200, Achim Gratz wrote: Corinna Vinschen writes: Done. Achim, if you would be so kind... I'll do it tomorrow evening as the latest update of the !package file hasn't picked it up yet. I have an early morning meeting tomorrow and need to fetch some sleep, so I don't want to wait another hour… hope this is OK. Package updates happen every five minutes so you were probably only a minute or so from having inetutils upload privileges. cgf
Re: [ITA] base-files
Corinna Vinschen writes: FYI, I contacted Chuck off-list 6 days ago but he didn't reply yet. Same here. I hope Chuck will still reply in the next couple of days, but if not, we have to find some solution to be able to go forward. I am updating some packages this weekend, so if someone can make me temporarily maintainer for inetutils-server I'll repackage it without /etc/default/etc/shells and upload together with base-files and the other updates. Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ DIY Stuff: http://Synth.Stromeko.net/DIY.html
Re: [ITA] base-files
On Mar 23 15:04, Achim Gratz wrote:
Achim Gratz writes:
Other than that, it looks good to me. I'd say, let's go for it when
you're ready.
New version with those changes has been uploaded:
--8---cut here---start-8---
wget=wget -rxnH --cut-dirs=2 http://cygwin.stromeko.net/noarch/release;
${wget}/base-files/base-files-4.2-1.tar.xz
--8---cut here---end---8---
I still need to wait for Chuck to create an inetutils package without
/etc/defaults/etc/shells.
Chuck, could you let me know when you're ready so we can arrange for a
synchroneous upload?
FYI, I contacted Chuck off-list 6 days ago but he didn't reply yet.
I hope Chuck will still reply in the next couple of days, but if not, we
have to find some solution to be able to go forward.
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat
pgpEvfovs9Qik.pgp
Description: PGP signature
Re: [ITA] base-files
Achim Gratz writes:
Other than that, it looks good to me. I'd say, let's go for it when
you're ready.
New version with those changes has been uploaded:
--8---cut here---start-8---
wget=wget -rxnH --cut-dirs=2 http://cygwin.stromeko.net/noarch/release;
${wget}/base-files/base-files-4.2-1.tar.xz
--8---cut here---end---8---
I still need to wait for Chuck to create an inetutils package without
/etc/defaults/etc/shells.
Chuck, could you let me know when you're ready so we can arrange for a
synchroneous upload?
Regards,
Achim.
--
+[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+
DIY Stuff:
http://Synth.Stromeko.net/DIY.html
Re: [ITA] base-files
Hi Achim,
On Mar 15 18:45, Achim Gratz wrote:
Since the current maintainer David Le Sastre Medina seems to have gone
missing, here's my attempt to wrap up the changes that were implemented
after the 4.1-2 package was published as experimental (and then never
released). The pertinent discussions on the Cygwin ML are listed in the
ChangeLog.
Change Log
--
4.1-3
* Eliminate Windows PATH from default PATH if CYGWIN_NOWINPATH is
set. Record the Windows PATH in ORIGINAL_PATH unless that
variable is already set.
* Better guard for non-existent /etc/skel.
* Improve profile_d function.
cygwin.com/ml/cygwin/2012-08/msg00488.html
* Add /etc/shells.
cygwin.com/ml/cygwin/2014-03/msg00039.html
* Use full path for tools and avoid DOS file warning when creating
service files.
cygwin.com/ml/cygwin/2013-07/msg00114.html
Git repository (originally cloned from GitHub):
http://repo.or.cz/w/cygwin-base-files.git
Test package:
--8---cut here---start-8---
wget=wget -rxnH --cut-dirs=2 http://cygwin.stromeko.net/noarch/release;
${wget}/base-files/base-files/base-files-4.1-3.tar.xz
^
There's one base-files too much.
A few (rather minor) notes:
- I think you should bump the version number. 4.2 or whatever.
- In etc/postinstall/base-files-mketc.sh:
/usr/bin/chmod 1777 /tmp 2/dev/null
This looks gratuitious. Setup itself already sets /tmp to 1777.
I never heard of somebody changing the permission of /tmp to
something else, so it probably doesn't hurt...
- In etc/defaults/etc/profile:
Just a heads-up. Be prepared to remove the entire section about
mkpasswd/mkgroup checking. It won't work as expected anymore as soon
as my AD integration code goes release. Along these lines, I will
update the base-cygwin package not to create passwd and group files
anymore.
- Do we still need etc/defaults/etc/profile.d/1777fix.sh? How long has
it been?
Other than that, it looks good to me. I'd say, let's go for it when
you're ready.
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat
pgps351IR7_kG.pgp
Description: PGP signature
Re: [ITA] base-files
Corinna Vinschen writes:
--8---cut here---start-8---
wget=wget -rxnH --cut-dirs=2 http://cygwin.stromeko.net/noarch/release;
${wget}/base-files/base-files/base-files-4.1-3.tar.xz
^
There's one base-files too much.
Thanks for catching that, sorry. The middle button of my mouse acts up
since a few days and produces additional clicks sometimes…
A few (rather minor) notes:
- I think you should bump the version number. 4.2 or whatever.
I've no problem doing that once everything else is finalized.
- In etc/postinstall/base-files-mketc.sh:
/usr/bin/chmod 1777 /tmp 2/dev/null
This looks gratuitious. Setup itself already sets /tmp to 1777.
I never heard of somebody changing the permission of /tmp to
something else, so it probably doesn't hurt...
That has been in there since the 4.0 release. I cannot find out what
problem it was supposed to solve (it was introduced at the end of 2010).
I can remove it if setup.exe already does that.
- In etc/defaults/etc/profile:
Just a heads-up. Be prepared to remove the entire section about
mkpasswd/mkgroup checking. It won't work as expected anymore as soon
as my AD integration code goes release. Along these lines, I will
update the base-cygwin package not to create passwd and group files
anymore.
:-)
- Do we still need etc/defaults/etc/profile.d/1777fix.sh? How long has
it been?
Almost exactly two years. Again I can't really follow what the original
problem was, but if it's been solved in a different way in the meantime,
then that script certainly can be removed.
Other than that, it looks good to me. I'd say, let's go for it when
you're ready.
I still need to wait for Chuck to create an inetutils package without
/etc/defaults/etc/shells. Then we'll probably need someone with
sourceware access to create the four !ready files so that the upload
gets done in synchrony.
Regards,
Achim.
--
+[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+
SD adaptations for KORG EX-800 and Poly-800MkII V0.9:
http://Synth.Stromeko.net/Downloads.html#KorgSDada
Re: [ITA] base-files
On Sun, Mar 16, 2014 at 06:09:22PM +0100, Achim Gratz wrote: Corinna Vinschen writes: Other than that, it looks good to me. I'd say, let's go for it when you're ready. I still need to wait for Chuck to create an inetutils package without /etc/defaults/etc/shells. Then we'll probably need someone with sourceware access to create the four !ready files so that the upload gets done in synchrony. The files are moved a 14 minutes past the hour. Just don't upload a couple of minutes befor that time and you won't require error-prone external help. cgf
[ITA] base-files
Since the current maintainer David Le Sastre Medina seems to have gone
missing, here's my attempt to wrap up the changes that were implemented
after the 4.1-2 package was published as experimental (and then never
released). The pertinent discussions on the Cygwin ML are listed in the
ChangeLog.
Change Log
--
4.1-3
* Eliminate Windows PATH from default PATH if CYGWIN_NOWINPATH is
set. Record the Windows PATH in ORIGINAL_PATH unless that
variable is already set.
* Better guard for non-existent /etc/skel.
* Improve profile_d function.
cygwin.com/ml/cygwin/2012-08/msg00488.html
* Add /etc/shells.
cygwin.com/ml/cygwin/2014-03/msg00039.html
* Use full path for tools and avoid DOS file warning when creating
service files.
cygwin.com/ml/cygwin/2013-07/msg00114.html
Git repository (originally cloned from GitHub):
http://repo.or.cz/w/cygwin-base-files.git
Test package:
--8---cut here---start-8---
wget=wget -rxnH --cut-dirs=2 http://cygwin.stromeko.net/noarch/release;
${wget}/base-files/base-files/base-files-4.1-3.tar.xz
--8---cut here---end---8---
Regards,
Achim.
--
+[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+
SD adaptation for Waldorf rackAttack V1.04R1:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada
Re: [ ITA ] base-files
On Sat, Mar 12, 2011 at 10:12:01AM +0100, Corinna Vinschen wrote: On Mar 12 07:25, Andy Koppe wrote: On 11 March 2011 21:26, David Sastre wrote: Links to base-files-4.0-4: http://crapsteak.org/cygwin/release/base-files/base-files-4.0-4.tar.bz2 http://crapsteak.org/cygwin/release/base-files/base-files-4.0-4.tar.bz2.sig Looks good to me. Uploaded and cygwin-pkg-maint updated. Can versions before 3.9-3 be deleted? Keeper of the Gold Stars, please award a richly deserved one for adopting and revamping this vital package. Thanks for your patience! Indeed. It took so long to iron out the package that I already thought it would get the vaporware award at one point :) I'm really glad that you took over the package, David, and that you worked so diligently on it. A gold star is well deserved. Big ditto. It's a huge relief to have this package in capable hands. Awarded. http://cygwin.com/goldstars/#DS
Re: [ ITA ] base-files
On Mar 12 07:25, Andy Koppe wrote: On 11 March 2011 21:26, David Sastre wrote: Links to base-files-4.0-4: http://crapsteak.org/cygwin/release/base-files/base-files-4.0-4.tar.bz2 http://crapsteak.org/cygwin/release/base-files/base-files-4.0-4.tar.bz2.sig Looks good to me. Uploaded and cygwin-pkg-maint updated. Can versions before 3.9-3 be deleted? Keeper of the Gold Stars, please award a richly deserved one for adopting and revamping this vital package. Thanks for your patience! Indeed. It took so long to iron out the package that I already thought it would get the vaporware award at one point :) I'm really glad that you took over the package, David, and that you worked so diligently on it. A gold star is well deserved. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: [ ITA ] base-files
On 12 March 2011 09:14, Corinna Vinschen wrote: On Mar 12 07:25, Andy Koppe wrote: On 11 March 2011 21:26, David Sastre wrote: Links to base-files-4.0-4: http://crapsteak.org/cygwin/release/base-files/base-files-4.0-4.tar.bz2 http://crapsteak.org/cygwin/release/base-files/base-files-4.0-4.tar.bz2.sig Looks good to me. Uploaded and cygwin-pkg-maint updated. Andy, I don't see the change in cygwin-pkg-maint. Did you forget to checkin? Yep, sorry. Now done. Andy
Re: [ ITA ] base-files
On Sat, Mar 12, 2011 at 10:12:01AM +0100, Corinna Vinschen wrote: On Mar 12 07:25, Andy Koppe wrote: On 11 March 2011 21:26, David Sastre wrote: Can versions before 3.9-3 be deleted? If this is a question for me, I think they can be safely deleted now. Keeper of the Gold Stars, please award a richly deserved one for adopting and revamping this vital package. Indeed. It took so long to iron out the package that I already thought it would get the vaporware award at one point :) I'm really glad that you took over the package, David, and that you worked so diligently on it. A gold star is well deserved. Being part (even such a little one) of the awesome collective effort the cygwin project represents is the Real Gold Star I'm the recipient of. Thank You. -- Huella de clave primaria: 0FDA C36F F110 54F4 D42B D0EB 617D 396C 448B 31EB signature.asc Description: Digital signature
Re: [ ITA ] base-files
On Sat, Mar 12, 2011 at 10:12:01AM +0100, Corinna Vinschen wrote: On Mar 12 07:25, Andy Koppe wrote: On 11 March 2011 21:26, David Sastre wrote: Links to base-files-4.0-4: http://crapsteak.org/cygwin/release/base-files/base-files-4.0-4.tar.bz2 http://crapsteak.org/cygwin/release/base-files/base-files-4.0-4.tar.bz2.sig Looks good to me. Uploaded and cygwin-pkg-maint updated. Can versions before 3.9-3 be deleted? Keeper of the Gold Stars, please award a richly deserved one for adopting and revamping this vital package. Thanks for your patience! Indeed. It took so long to iron out the package that I already thought it would get the vaporware award at one point :) I'm really glad that you took over the package, David, and that you worked so diligently on it. A gold star is well deserved. Big ditto. It's a huge relief to have this package in capable hands. cgf
Re: [ ITA ] base-files
On 11 March 2011 21:26, David Sastre wrote: Links to base-files-4.0-4: http://crapsteak.org/cygwin/release/base-files/base-files-4.0-4.tar.bz2 http://crapsteak.org/cygwin/release/base-files/base-files-4.0-4.tar.bz2.sig Looks good to me. Uploaded and cygwin-pkg-maint updated. Can versions before 3.9-3 be deleted? Keeper of the Gold Stars, please award a richly deserved one for adopting and revamping this vital package. Thanks for your patience! Andy
Re: [ITA] - base-files
On 7 March 2011 13:05, Andy Koppe wrote: On 6 March 2011 17:19, David Sastre wrote: - Not that it makes a great difference, but I think the interactive checks should be done before sourcing /etc/bash.bashrc and ~/.bashrc from /etc/profile and ~/.profile, respectively, rather than doing it in the rc files. That would save opening the rc files in non-interactive login shells and unnecessary checks in interactive non-login shells. That's true, but the check also serves the purpose of avoiding those files to be sourced in non-interactive sesions, regardless who's calling. You mean from users' scripts? That's up to them, isn't it? The important thing is that it isn't sourced automatically for non-interactive sessions. On third thoughts, there is a very good reason for doing the interactive checks in the bashrc files rather than the profile files: the ~/.bash_profile from base-files 3.9 sources them both unconditionally, and existing users will continue to use that. Objection withdrawn. Andy
Re: [ITA] - base-files
On 6 March 2011 17:19, David Sastre wrote: - Not that it makes a great difference, but I think the interactive checks should be done before sourcing /etc/bash.bashrc and ~/.bashrc from /etc/profile and ~/.profile, respectively, rather than doing it in the rc files. That would save opening the rc files in non-interactive login shells and unnecessary checks in interactive non-login shells. That's true, but the check also serves the purpose of avoiding those files to be sourced in non-interactive sesions, regardless who's calling. You mean from users' scripts? That's up to them, isn't it? The important thing is that it isn't sourced automatically for non-interactive sessions. - I think the commented-out CVS stuff in /etc/profile would be better placed in ~/.bash_profile, to allow non-admin users to uncomment it. Or perhaps just delete it altogether; since CVSROOT=:pserver:anon...@sources.redhat.com:/cvs/src isn't what's recommended at http://cygwin.com/cvs.html anymore anyway. Done. I've dropped it. Cheers. And a question: - Can we do away with ~/.bash_profile, and move the commented-out PATH, MANPATH, and INFOPATH setting from there into ~/.profile? I see the latter sources .bashrc anyway for bash shells, which makes sense. I'd rather keep .bash_profile around, because it has higher precedence in case both files exist. Sourcing .bashrc from .profile only exists as a fallback mechanism. Fair enough. In case you are about to upload this, could you please apply this patch to your local 4.0-3 copy? If you think these changes deserve a release bump, I'd roll a 4.0-4 version. Yeah, sorry, better do another one, I wouldn't trust myself to repackage this correctly. Also, I'm afraid I've stumbled across another possible issue regarding the unsetting of TMP and TEMP. I'll raise that in the relevant thread. Andy
Re: [ITA] - base-files
On Sat, Mar 05, 2011 at 05:03:37PM +, Andy Koppe wrote: The problem appears to be back: Sorry for not getting round to this sooner. Hello Andy, It should be alive again. Thanks for checking. -- Huella de clave primaria: 0FDA C36F F110 54F4 D42B D0EB 617D 396C 448B 31EB signature.asc Description: Digital signature
Re: [ITA] - base-files
On Sun, Mar 06, 2011 at 07:07:18AM +, Andy Koppe wrote:
On 5 March 2011 17:03, Andy Koppe wrote:
Actually I had already downloaded this anyway. Looks great, only two
suggestions:
- Not that it makes a great difference, but I think the interactive
checks should be done before sourcing /etc/bash.bashrc and ~/.bashrc
from /etc/profile and ~/.profile, respectively, rather than doing it
in the rc files. That would save opening the rc files in
non-interactive login shells and unnecessary checks in interactive
non-login shells.
That's true, but the check also serves the purpose of avoiding those
files to be sourced in non-interactive sesions, regardless who's
calling.
- I think the commented-out CVS stuff in /etc/profile would be better
placed in ~/.bash_profile, to allow non-admin users to uncomment it.
Or perhaps just delete it altogether; since
CVSROOT=:pserver:anon...@sources.redhat.com:/cvs/src isn't what's
recommended at http://cygwin.com/cvs.html anymore anyway.
Done. I've dropped it.
And a question:
- Can we do away with ~/.bash_profile, and move the commented-out
PATH, MANPATH, and INFOPATH setting from there into ~/.profile? I see
the latter sources .bashrc anyway for bash shells, which makes sense.
I'd rather keep .bash_profile around, because it has higher precedence in
case both files exist. Sourcing .bashrc from .profile only exists as a
fallback mechanism.
In case you are about to upload this, could you please apply this patch
to your local 4.0-3 copy?
If you think these changes deserve a release bump, I'd roll a 4.0-4
version.
Thanks!
--- a/etc/defaults/etc/profile
+++ b/etc/defaults/etc/profile
@@ -42,12 +42,6 @@ unset TEMP
read -r PRINTER '/proc/registry/HKEY_CURRENT_USER/Software/Microsoft/Windows
NT/CurrentVersion/Windows/Device'
PRINTER=${PRINTER%%,*}
-# It is recommended that cvs uses ssh for it's remote shell environment
-# CVS_RSH=/usr/bin/ssh
-
-# Patches to Cygwin always appreciated ;)
-# CVSROOT=:pserver:anon...@sources.redhat.com:/cvs/src
-
# Default to removing the write permission for group and other
# (files normally created with mode 777 become 755; files created with
# mode 666 become 644)
@@ -123,7 +117,7 @@ else PS1=$
fi
export PATH MANPATH INFOPATH USER PRINTER PS1 HOSTNAME
-# export TMP TEMP CVS_RSH CVSROOT
+# export TMP TEMP
# Check to see if mkpasswd/mkgroup needs to be run try and cut down the emails
# about this on the lists!
--- a/usr/share/doc/base-files/ChangeLog
+++ b/usr/share/doc/base-files/ChangeLog
@@ -15,6 +15,7 @@ Change Log
* Supressed a fork in /etc/profile routine for copying skeletal files and
added a test to `cd' command - Cyrille Lefevre
* Removed /bin from path, as it is included via /usr/bin.
+* Dropped CVS stuff from /etc/profile - Andy Koppe
4.0-2
* Never released.
* A modified version of a case switch to run shell dependent stuff based
--
Huella de clave primaria: 0FDA C36F F110 54F4 D42B D0EB 617D 396C 448B 31EB
signature.asc
Description: Digital signature
Re: [ITA] - base-files
On 24 February 2011 10:14, David Sastre wrote: 2011/2/24, Corinna Vinschen: Hi David, On Feb 23 19:02, David Sastre wrote: Hello, I think the links to the latest revision got lost in the replies to my question about privileged users. In the meantime, the domain I was using expired. These are the valid links now: http://crapsteak.org/cygwin/release/base-files/base-files-4.0-3.tar.bz2 http://crapsteak.org/cygwin/release/base-files/base-files-4.0-3.tar.bz2.sig I can't download: wget http://crapsteak.org/cygwin/release/base-files/base-files-4.0-3.tar.bz2 http://crapsteak.org/cygwin/release/base-files/base-files-4.0-3.tar.bz2.sig --2011-02-24 10:07:06-- http://crapsteak.org/cygwin/release/base-files/base-files-4.0-3.tar.bz2 Resolving crapsteak.org... 87.217.145.147 Connecting to crapsteak.org|87.217.145.147|:80... failed: Connection refused. --2011-02-24 10:07:06-- http://crapsteak.org/cygwin/release/base-files/base-files-4.0-3.tar.bz2.sig Connecting to crapsteak.org|87.217.145.147|:80... failed: Connection refused. Weird. I checked it out early this morning. Sometimes it doesn't work for me either due to dyndns (or my router's ddclient client, I can't tell for sure) not refreshing properly. (...calls home and requests a whatsmyip query...) OK. I've manually refreshed the IP and checked it out, it should be working now. The problem appears to be back: $ wget http://crapsteak.org/cygwin/release/base-files/base-files-4.0-3.tar.bz2 --2011-03-05 17:01:20-- http://crapsteak.org/cygwin/release/base-files/base-files-4.0-3.tar.bz2 Resolving crapsteak.org (crapsteak.org)... 87.217.144.185 Connecting to crapsteak.org (crapsteak.org)|87.217.144.185|:80... connected. HTTP request sent, awaiting response... Read error (Connection reset by peer) in headers. Retrying. ... Sorry for not getting round to this sooner. Andy
Re: [ITA] - base-files
On 5 March 2011 17:03, Andy Koppe wrote: Weird. I checked it out early this morning. Sometimes it doesn't work for me either due to dyndns (or my router's ddclient client, I can't tell for sure) not refreshing properly. (...calls home and requests a whatsmyip query...) OK. I've manually refreshed the IP and checked it out, it should be working now. The problem appears to be back. Actually I had already downloaded this anyway. Looks great, only two suggestions: - Not that it makes a great difference, but I think the interactive checks should be done before sourcing /etc/bash.bashrc and ~/.bashrc from /etc/profile and ~/.profile, respectively, rather than doing it in the rc files. That would save opening the rc files in non-interactive login shells and unnecessary checks in interactive non-login shells. - I think the commented-out CVS stuff in /etc/profile would be better placed in ~/.bash_profile, to allow non-admin users to uncomment it. Or perhaps just delete it altogether; since CVSROOT=:pserver:anon...@sources.redhat.com:/cvs/src isn't what's recommended at http://cygwin.com/cvs.html anymore anyway. And a question: - Can we do away with ~/.bash_profile, and move the commented-out PATH, MANPATH, and INFOPATH setting from there into ~/.profile? I see the latter sources .bashrc anyway for bash shells, which makes sense. Andy
Re: [ITA] - base-files
Hi David, On Feb 23 19:02, David Sastre wrote: Hello, I think the links to the latest revision got lost in the replies to my question about privileged users. In the meantime, the domain I was using expired. These are the valid links now: http://crapsteak.org/cygwin/release/base-files/base-files-4.0-3.tar.bz2 http://crapsteak.org/cygwin/release/base-files/base-files-4.0-3.tar.bz2.sig I can't download: wget http://crapsteak.org/cygwin/release/base-files/base-files-4.0-3.tar.bz2 http://crapsteak.org/cygwin/release/base-files/base-files-4.0-3.tar.bz2.sig --2011-02-24 10:07:06-- http://crapsteak.org/cygwin/release/base-files/base-files-4.0-3.tar.bz2 Resolving crapsteak.org... 87.217.145.147 Connecting to crapsteak.org|87.217.145.147|:80... failed: Connection refused. --2011-02-24 10:07:06-- http://crapsteak.org/cygwin/release/base-files/base-files-4.0-3.tar.bz2.sig Connecting to crapsteak.org|87.217.145.147|:80... failed: Connection refused. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: [ITA] - base-files
On Feb 24 11:14, David Sastre wrote: 2011/2/24, Corinna Vinschen: Hi David, On Feb 23 19:02, David Sastre wrote: Hello, I think the links to the latest revision got lost in the replies to my question about privileged users. In the meantime, the domain I was using expired. These are the valid links now: http://crapsteak.org/cygwin/release/base-files/base-files-4.0-3.tar.bz2 http://crapsteak.org/cygwin/release/base-files/base-files-4.0-3.tar.bz2.sig I can't download: wget http://crapsteak.org/cygwin/release/base-files/base-files-4.0-3.tar.bz2 http://crapsteak.org/cygwin/release/base-files/base-files-4.0-3.tar.bz2.sig --2011-02-24 10:07:06-- http://crapsteak.org/cygwin/release/base-files/base-files-4.0-3.tar.bz2 Resolving crapsteak.org... 87.217.145.147 Connecting to crapsteak.org|87.217.145.147|:80... failed: Connection refused. --2011-02-24 10:07:06-- http://crapsteak.org/cygwin/release/base-files/base-files-4.0-3.tar.bz2.sig Connecting to crapsteak.org|87.217.145.147|:80... failed: Connection refused. Weird. I checked it out early this morning. Sometimes it doesn't work for me either due to dyndns (or my router's ddclient client, I can't tell for sure) not refreshing properly. (...calls home and requests a whatsmyip query...) OK. I've manually refreshed the IP and checked it out, it should be working now. Sorry for the inconvenience (and the html mail). Thanks. Looks good to me, but I'm a tcsh user so I'm only marginally affected. I would be glad if somebody else would review this one more time. Otherwise I'm inclined to upload it in a few days. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: [ITA] - base-files
I have a request, David. Next time you have a new version of base-files to upload, please start a NEW thread. And give it a title like [RFU] base-files or something. The current thread started in Sept2010, with new threads (which were inexplicably simply started as replies to the final message in the previous iteration) in early Dec2010, early Jan2011, and early Feb2011 and now late Feb2011. (In fairness, the early Feb and late Feb instances really are part of the same thread). I ask, because by starting each new thread off as a reply -- when it really isn't -- my threaded newsreader shifts the subject of the post all the way out-of-frame. I can deal when it really IS a long thread with lots of discussion and replies...but when it really ISN'T a single discussion, it's annoying. New discussion or subject: new thread. Please. Now, if I've misunderstood, and this really IS a single discussion that spans six months, well, never mind then. Thanks, Chuck
Re: [ITA] - base-files
New discussion or subject: new thread. Please. Has anyone ever tried to port KDE to Cygwin? (ducks)
Re: [ITA] - base-files
Hello, I think the links to the latest revision got lost in the replies to my question about privileged users. In the meantime, the domain I was using expired. These are the valid links now: http://crapsteak.org/cygwin/release/base-files/base-files-4.0-3.tar.bz2 http://crapsteak.org/cygwin/release/base-files/base-files-4.0-3.tar.bz2.sig -- Huella de clave primaria: 0FDA C36F F110 54F4 D42B D0EB 617D 396C 448B 31EB signature.asc Description: Digital signature
Re: [ITA] - base-files
On 2/6/2011 4:40 PM, David Sastre wrote: I have a question yet: is there a consistent way of knowing the GID of users with administrative privileges (from a windows perspective) so that could be used to add /usr/sbin to their paths? AFAIK, this requires Win32 C code. Take a look at the code in winsec.c that is part of cygwin's login package -- and how it is used in login.c to determine Administrator membership (see isROOT_UID() in login,.c). It's possible some part of this functionality could be added to an executable utility in cygutils or csih, but...should base-files really depend on either of those packages? Maybe instead, base-files should also ship some new utility .exe for this purpose in /usr/bin/? Would that be useful? Maybe, but admin user accounts can always add /usr/sbin themselves, in ~/.bash_profile or ~/.bashrc. (I usually don't bother, and just invoke sbin progs by full path). Dunno if it's worth the effort. -- Chuck
Re: [ITA] - base-files
On Feb 9 10:42, Charles Wilson wrote: On 2/6/2011 4:40 PM, David Sastre wrote: I have a question yet: is there a consistent way of knowing the GID of users with administrative privileges (from a windows perspective) so that could be used to add /usr/sbin to their paths? AFAIK, this requires Win32 C code. Take a look at the code in winsec.c that is part of cygwin's login package -- and how it is used in login.c to determine Administrator membership (see isROOT_UID() in login,.c). It's possible some part of this functionality could be added to an executable utility in cygutils or csih, but...should base-files really depend on either of those packages? Maybe instead, base-files should also ship some new utility .exe for this purpose in /usr/bin/? When you call mkgroup, you have the admins group with gid 544. It will be in the user token and id(1) will contain it in its output. We should really start to rely on that. Here's the test I'm doing: admin=$(/usr/bin/id -G | /usr/bin/grep -Eq '\544\' echo yes || echo no) Would that be useful? Maybe, but admin user accounts can always add /usr/sbin themselves, in ~/.bash_profile or ~/.bashrc. (I usually don't bother, and just invoke sbin progs by full path). Dunno if it's worth the effort. I agree. It's an interesting idea but it costs an extra call to one or more external applications in the profile which most users won't need. I guess we should avoid that. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: [ITA] - base-files
Hello, I have corrected some stuff in the /etc/profile reported offlist by Cyrille Lefevre and a pair of little annoyances (e.g. hostname was not referenced by its full path). I have a question yet: is there a consistent way of knowing the GID of users with administrative privileges (from a windows perspective) so that could be used to add /usr/sbin to their paths? Would that be useful? Anyway, there is a new pkg hopefully ready for release here: http://eco-lution.tv/cygwin/release/base-files/base-files-4.0-3.tar.bz2 http://eco-lution.tv/cygwin/release/base-files/base-files-4.0-3.tar.bz2.sig -- Huella de clave primaria: 0FDA C36F F110 54F4 D42B D0EB 617D 396C 448B 31EB signature.asc Description: Digital signature
Re: [ITA] - base-files
On 11 January 2011 12:01, David Sastre wrote: Also, I'd appreciate opinions regarding the guard-like tests in some config files, namely /etc/profile, /etc/bash.bashrc, ~/.bash_profile and ~/.bashrc. I'm not very convinced about including them. Why do we need them? I don't see equivalent tests on Linux... There aren't, indeed. And re-thinking the idea, those tests are not needed in any of the files but maybe in /etc/bash.bashrc, which is definitely affected by changes in this version of base-files that modify the order in which startup files are read. I think you're right, the guard is only needed in /etc/bash.bashrc. Andy
Re: [ITA] - base-files
On Jan 12 08:06, Andy Koppe wrote: On 11 January 2011 12:01, David Sastre wrote: Also, I'd appreciate opinions regarding the guard-like tests in some config files, namely /etc/profile, /etc/bash.bashrc, ~/.bash_profile and ~/.bashrc. I'm not very convinced about including them. Why do we need them? I don't see equivalent tests on Linux... There aren't, indeed. And re-thinking the idea, those tests are not needed in any of the files but maybe in /etc/bash.bashrc, which is definitely affected by changes in this version of base-files that modify the order in which startup files are read. I think you're right, the guard is only needed in /etc/bash.bashrc. I'm a tcsh user so I only have a vague relationship to these startup files. Nevertheless, this sounds right to me. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: [ITA] - base-files
On Jan 10 19:40, David Sastre wrote: On Mon, Jan 10, 2011 at 06:08:06PM +0100, Corinna Vinschen wrote: On Jan 6 17:04, Andrew Schulman wrote: New package available at: http://www.eco-lution.tv/cygwin/release/base-files/base-files-4.0-2.tar.bz2 http://www.eco-lution.tv/cygwin/release/base-files/base-files-4.0-2.tar.bz2.sig I was trying to download the files, but I get a permanent error: Yep...the box has been down all day long. Files are available again. Sorry for the inconvenience. Also, I'd appreciate opinions regarding the guard-like tests in some config files, namely /etc/profile, /etc/bash.bashrc, ~/.bash_profile and ~/.bashrc. I'm not very convinced about including them. Why do we need them? I don't see equivalent tests on Linux... Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: [ITA] - base-files
2011/1/11, Corinna Vinschen wrote: On Jan 10 19:40, David Sastre wrote: On Mon, Jan 10, 2011 at 06:08:06PM +0100, Corinna Vinschen wrote: On Jan 6 17:04, Andrew Schulman wrote: New package available at: http://www.eco-lution.tv/cygwin/release/base-files/base-files-4.0-2.tar.bz2 http://www.eco-lution.tv/cygwin/release/base-files/base-files-4.0-2.tar.bz2.sig Also, I'd appreciate opinions regarding the guard-like tests in some config files, namely /etc/profile, /etc/bash.bashrc, ~/.bash_profile and ~/.bashrc. I'm not very convinced about including them. Why do we need them? I don't see equivalent tests on Linux... There aren't, indeed. And re-thinking the idea, those tests are not needed in any of the files but maybe in /etc/bash.bashrc, which is definitely affected by changes in this version of base-files that modify the order in which startup files are read. Its purpose would be avoiding double sourcing of a file, given the following scenario: - a user updates base-files. - base-files' preremove script keeps modified files untouched (which is the correct behaviour). - a user's modified ~./bash_profile still sources /etc/bash.bashrc, when that has already been done by new /etc/profile. One goal here is to define a SYS-level of configuration that does not rely in the existence or content of any USER-level conffile (e.g. ./bash_profile). Related to this, bash-4.1 will have SYS_BASHRC (/etc/bash.bashrc) enabled.
Re: [ITA] - base-files
On Jan 6 17:04, Andrew Schulman wrote: New package available at: http://www-eco-lution.tv/cygwin/release/base-files/base-file-4.0-2.tar.bz2 http://www-eco-lution.tv/cygwin/release/base-files/base-file-4.0-2.tar.bz2.sig http://www.eco-lution.tv/cygwin/release/base-files/base-files-4.0-2.tar.bz2 http://www.eco-lution.tv/cygwin/release/base-files/base-files-4.0-2.tar.bz2.sig I was trying to download the files, but I get a permanent error: wget http://www.eco-lution.tv/cygwin/release/base-files/base-files-4.0-2.tar.bz2 --2011-01-10 18:06:26-- http://www.eco-lution.tv/cygwin/release/base-files/base-files-4.0-2.tar.bz2 Resolving www.eco-lution.tv... 87.217.144.54 Connecting to www.eco-lution.tv|87.217.144.54|:80... connected. HTTP request sent, awaiting response... Read error (Connection reset by peer) in headers. Retrying. [...] Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: [ITA] - base-files
On Mon, Jan 10, 2011 at 06:08:06PM +0100, Corinna Vinschen wrote: On Jan 6 17:04, Andrew Schulman wrote: New package available at: http://www.eco-lution.tv/cygwin/release/base-files/base-files-4.0-2.tar.bz2 http://www.eco-lution.tv/cygwin/release/base-files/base-files-4.0-2.tar.bz2.sig I was trying to download the files, but I get a permanent error: Yep...the box has been down all day long. Files are available again. Sorry for the inconvenience. Also, I'd appreciate opinions regarding the guard-like tests in some config files, namely /etc/profile, /etc/bash.bashrc, ~/.bash_profile and ~/.bashrc. I'm not very convinced about including them. -- Huella de clave primaria: 0FDA C36F F110 54F4 D42B D0EB 617D 396C 448B 31EB signature.asc Description: Digital signature
Re: [ITA] - base-files
On Sun, Dec 19, 2010 at 05:20:14PM +, Andy Koppe wrote: On 14 December 2010 20:41, David Sastre wrote: On Fri, Dec 10, 2010 at 06:50:32AM +, Andy Koppe wrote: I'll try selective sourcing from /etc/profile e.g. bash sources *sh, and not *.zsh, and viceversa. Done. On a related note, due to the many possible combinations of old and new startup files, double sourcing is a distinct possibility, e.g. due to the current /etc/defaults/etc/skel/.bash_profile sourcing /etc/bash.bashrc. Perhaps this should be addressed with guard variables similar to include guards in C headers? Done. I learnt that enabling /etc/bash.bashrc to be sourced as a system-wide *rc file can be defined in a header file in the bash sources, and also /etc/bash.bash_logout, BTW. Forthcoming bash-4.1 will have SYS_BASHRC and SYS_BASH_LOGOUT enabled. Wasn't there a patch for doing that switch without forks? Found it. Daniel Colascione suggested the following at http://cygwin.com/ml/cygwin/2010-11/msg00464.html: - Detect the current shell by examining BASH_VERSION, ZSH_VERSION, and so on, not by forking for the echo|tr|sed pipeline Done. New package available at: http://www-eco-lution.tv/cygwin/release/base-files/base-file-4.0-2.tar.bz2 http://www-eco-lution.tv/cygwin/release/base-files/base-file-4.0-2.tar.bz2.sig Regards. -- Huella de clave primaria: 0FDA C36F F110 54F4 D42B D0EB 617D 396C 448B 31EB signature.asc Description: Digital signature
Re: [ITA] - base-files
New package available at: http://www-eco-lution.tv/cygwin/release/base-files/base-file-4.0-2.tar.bz2 http://www-eco-lution.tv/cygwin/release/base-files/base-file-4.0-2.tar.bz2.sig http://www.eco-lution.tv/cygwin/release/base-files/base-files-4.0-2.tar.bz2 http://www.eco-lution.tv/cygwin/release/base-files/base-files-4.0-2.tar.bz2.sig
Re: [ITA] - base-files
On 14 December 2010 20:41, David Sastre wrote:
On Fri, Dec 10, 2010 at 06:50:32AM +, Andy Koppe wrote:
Speaking of /etc/profile.d, it seems wrong to do that from
/etc/bash.bashrc. The name of the directory suggests that its content
is for login shells only.
Absolutely. I'll try selective sourcing from /etc/profile e.g. bash sources
*sh, and not *.zsh, and viceversa.
Great.
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.
This is important. The conclusion of this reasoning is that users'
personal files (~/.bash{rc,_profile}) shouldn't be trusted at all in
order to define a system-wide configuration.
I agree.
On a related note, due to the many possible combinations of old and
new startup files, double sourcing is a distinct possibility, e.g. due
to the current /etc/defaults/etc/skel/.bash_profile sourcing
/etc/bash.bashrc. Perhaps this should be addressed with guard
variables similar to include guards in C headers?
http://www.gnu.org/software/bash/manual/html_node/Is-this-Shell-Interactive_003f.html
If you propose to check for *i* in $- instead of PS1 (as I'm doing now),
yeah, it does look more reliable.
Sorry, I hadn't noticed the existing PS1 check. But you're right, the
$- check should be more reliable as PS1 might already be set when the
shell is invoked, e.g. in a Windows environment variable.
Zsh sources *profile files in login shells and the *zshrc files in
interactive shells, so an interactive login shell sources both.
Not in bash. This is an example of a login shell. I have commented out
the code that sources /etc/bash.bashrc and ~/.bashrc from
~/.bash_profile:
$ grep MY_TEST /etc/profile /etc/bash.bashrc .bashrc .bash_profile
/etc/profile:MY_TEST=${MY_TEST}:/etc/profile
/etc/bash.bashrc:MY_TEST=${MY_TEST}:/etc/bash.bashrc
.bashrc:MY_TEST=${MY_TEST}:~/.bashrc
.bash_profile:MY_TEST=${MY_TEST}:~/.bash_profile
$ echo $MY_TEST
:/etc/profile:/home/dawud/.bash_profile
$ echo $-
himBH
(Erm...I just realized know that was _exactly_ your point, was it?)
Yep.
Hence
stuff that needs to be done once at login (e.g. setting up paths) goes
into *profile, and stuff to make an interactive shell comfortable
(e.g. prompt and aliases) goes into *zshrc. I think that makes plenty
of sense.
It does, indeed.
Bash isn't going to change in this respect though, so emulating it by
/etc/profile sourcing /etc/bash.bashrc and ~/.bash_profile sourcing
~/.bashrc is the next best thing.
I learnt that enabling /etc/bash.bashrc to be sourced as a system-wide *rc
file can be defined in a header file in the bash sources, and also
/etc/bash.bash_logout, BTW.
Good find!
The concern I'd have about that is that bash manuals and books don't
tend to mention that possibility, so users might be surprised by it.
Having said that, Ubuntu and Opensuse at least do enable that feature
and change the bash man page accordingly, so that should be plenty of
precedent.
Login shells of course will still only source the *profile files automatically.
Wasn't there a patch for doing that switch without forks?
Not that I know of... I'll try to write it down, though.
Found it. Daniel Colascione suggested the following at
http://cygwin.com/ml/cygwin/2010-11/msg00464.html:
- Detect the current shell by examining BASH_VERSION, ZSH_VERSION, and
so on, not by forking for the echo|tr|sed pipeline
Andy
Re: [ITA] - base-files
On Fri, Dec 10, 2010 at 06:50:32AM +, Andy Koppe wrote:
On 10 December 2010 00:05, David Sastre wrote:
Speaking of /etc/profile.d, it seems wrong to do that from
/etc/bash.bashrc. The name of the directory suggests that its content
is for login shells only.
Absolutely. I'll try selective sourcing from /etc/profile e.g. bash sources
*sh, and not *.zsh, and viceversa.
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.
This is important. The conclusion of this reasoning is that users'
personal files (~/.bash{rc,_profile}) shouldn't be trusted at all in
order to define a system-wide configuration. That's what happens both in my
proposal and in the current base-files. (See below for a possible solution)
That's true. Unless sourced from /etc/profile. Would that be
acceptable?
I think that would make sense, but it should only do so when the shell
is an interactive login shell. Here's how to find out:
http://www.gnu.org/software/bash/manual/html_node/Is-this-Shell-Interactive_003f.html
If you propose to check for *i* in $- instead of PS1 (as I'm doing now),
yeah, it does look more reliable.
Zsh sources *profile files in login shells and the *zshrc files in
interactive shells, so an interactive login shell sources both.
Not in bash. This is an example of a login shell. I have commented out
the code that sources /etc/bash.bashrc and ~/.bashrc from
~/.bash_profile:
$ grep MY_TEST /etc/profile /etc/bash.bashrc .bashrc .bash_profile
/etc/profile:MY_TEST=${MY_TEST}:/etc/profile
/etc/bash.bashrc:MY_TEST=${MY_TEST}:/etc/bash.bashrc
.bashrc:MY_TEST=${MY_TEST}:~/.bashrc
.bash_profile:MY_TEST=${MY_TEST}:~/.bash_profile
$ echo $MY_TEST
:/etc/profile:/home/dawud/.bash_profile
$ echo $-
himBH
(Erm...I just realized know that was _exactly_ your point, was it?)
Hence
stuff that needs to be done once at login (e.g. setting up paths) goes
into *profile, and stuff to make an interactive shell comfortable
(e.g. prompt and aliases) goes into *zshrc. I think that makes plenty
of sense.
It does, indeed.
Bash isn't going to change in this respect though, so emulating it by
/etc/profile sourcing /etc/bash.bashrc and ~/.bash_profile sourcing
~/.bashrc is the next best thing.
I learnt that enabling /etc/bash.bashrc to be sourced as a system-wide *rc
file can be defined in a header file in the bash sources, and also
/etc/bash.bash_logout, BTW.
I'm sending a request to enable both of them to the bash mantainer;
if he agrees to include them, it would be easier for me to define
a system-wide configuration layer that doesn't interfere with (neither
depend on) users' custom files, and also, presumably, allows smoother updates
from there on.
- There must be a switch for bash/mksh/*
Wasn't there a patch for doing that switch without forks?
Not that I know of... I'll try to write it down, though.
--
Huella de clave primaria: 0FDA C36F F110 54F4 D42B D0EB 617D 396C 448B 31EB
signature.asc
Description: Digital signature
Re: [ITA] - base-files
On 9 December 2010 06:29, David Sastre wrote: On Wed, Dec 08, 2010 at 11:21:38PM +, 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. The reason for this change is that all of bash, mksh, zsh and tcsh, provide their own files for doing that job. The result is a lighter /etc/profile that sets a minimun PS1='$ ' that will be used by posh and dash (the only two shells in the repo that lack specific startup files), allowing shells that do have that files to alter this setting(s). Notice that neither posh nor mksh, despite being ksh derivatives, read /etc/ksh.kshrc nor ~/.kshrc. (I=interactive,L=login,N=non-interactive,B=bash,M=mksh,Z=zsh,T=tcsh,O=posh,dash,!=not) BL= /etc/profile - ~/.bash_profile - ~/.bashrc - /etc/bash.bashrc 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. BI!L= /etc/bash.bashrc - ~/.bashrc Doesn't /etc/bash.bashrc end up being sourced twice here, due to ~/.bashrc including it. As far as I tested, it doesn't. It happens like I described above. I'll repeat the tests, though. Hang on, /etc/bash.bashrc isn't an official bash startup file, is it? So it depends on ~/.bashrc sourcing it, i.e. that line should say: BI!L= ~/.bashrc - /etc/bash.bashrc That explains why it isn't sourced twice. FYI, the way I did it was placing a line like this: TEST_RC=$TEST_RC:/name/of/the/file in every startup file, and echeoing the var after opening the shell, both interactive-login and interactive non-login. And in the case some peolple 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 think your startup file list should distinguish between files that are automatically sourced by the shell and those that are sourced by other startup files. All of those files are automatically sourced, depending on the shell being a login shel or an interactive shell. That's exactly what I'm trying to get advantage of. To be fair, in the case of a login shell, we force the course of things, but also does ~/.bash_profile in 3.9-3. 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. Andy
RE: [ITA] - base-files
Hi All... Date: Thu, 9 Dec 2010 12:04:39 + Subject: Re: [ITA] - base-files From: andy On 9 December 2010 06:29, David Sastre wrote: On Wed, Dec 08, 2010 at 11:21:38PM +, 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. The reason for this change is that all of bash, mksh, zsh and tcsh, provide their own files for doing that job. The result is a lighter /etc/profile that sets a minimun PS1='$ ' that will be used by posh and dash (the only two shells in the repo that lack specific startup files), allowing shells that do have that files to alter this setting(s). Notice that neither posh nor mksh, despite being ksh derivatives, read /etc/ksh.kshrc nor ~/.kshrc. (I=interactive,L=login,N=non-interactive,B=bash,M=mksh,Z=zsh,T=tcsh,O=posh,dash,!=not) BL= /etc/profile - ~/.bash_profile - ~/.bashrc - /etc/bash.bashrc 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. BI!L= /etc/bash.bashrc - ~/.bashrc Doesn't /etc/bash.bashrc end up being sourced twice here, due to ~/.bashrc including it. As far as I tested, it doesn't. It happens like I described above. I'll repeat the tests, though. Hang on, /etc/bash.bashrc isn't an official bash startup file, is it? So it depends on ~/.bashrc sourcing it, i.e. that line should say: BI!L= ~/.bashrc - /etc/bash.bashrc That explains why it isn't sourced twice. FYI, the way I did it was placing a line like this: TEST_RC=$TEST_RC:/name/of/the/file in every startup file, and echeoing the var after opening the shell, both interactive-login and interactive non-login. And in the case some peolple 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 think your startup file list should distinguish between files that are automatically sourced by the shell and those that are sourced by other startup files. All of those files are automatically sourced, depending on the shell being a login shel or an interactive shell. That's exactly what I'm trying to get advantage of. To be fair, in the case of a login shell, we force the course of things, but also does ~/.bash_profile in 3.9-3. 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. Andy But do we have to provide backward compatibility for user modified startup files? Can't we provide an efficient set of defaults that play together nicely with no redundancy and then let the user hack from there? Thanks, ...Karl
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 +
From: andy
On 9 December 2010 06:29, David Sastre wrote:
On Wed, Dec 08, 2010 at 11:21:38PM +, 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
signature.asc
Description: Digital signature
Re: [ITA] - base-files
On Fri, Dec 10, 2010 at 01:05:44AM +0100, David Sastre wrote: 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. Scratch that. Preremove can't do that kind of sorcery. It is PRE remove... (and it's triggered _before_ installing anything...) It looks like /etc/bash.bashrc and /etc/profile deserve some special treatment. The rest of the reasoning is still valid, I think. -- Huella de clave primaria: 0FDA C36F F110 54F4 D42B D0EB 617D 396C 448B 31EB signature.asc Description: Digital signature
Re: [ITA] - base-files
On 10 December 2010 00:05, David Sastre wrote:
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.
The current /etc/skel/.bash_profile sources /etc/bash.bashrc. If a
user's ~/.bash_profile doesn't do that, then the stuff that's moving
from /etc/profile to /etc/bash.bashrc no longer gets sourced. Result:
Updating Cygwin broke the prompt (and anything that depends on
/etc/profile.d)!.
Speaking of /etc/profile.d, it seems wrong to do that from
/etc/bash.bashrc. The name of the directory suggests that its content
is for login shells only.
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?
I think that would make sense, but it should only do so when the shell
is an interactive login shell. Here's how to find out:
http://www.gnu.org/software/bash/manual/html_node/Is-this-Shell-Interactive_003f.html
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...)
Zsh sources *profile files in login shells and the *zshrc files in
interactive shells, so an interactive login shell sources both. Hence
stuff that needs to be done once at login (e.g. setting up paths) goes
into *profile, and stuff to make an interactive shell comfortable
(e.g. prompt and aliases) goes into *zshrc. I think that makes plenty
of sense.
Bash isn't going to change in this respect though, so emulating it by
/etc/profile sourcing /etc/bash.bashrc and ~/.bash_profile sourcing
~/.bashrc is the next best thing.
The whole thing would be:
- /etc/profile is the login entry-point for everybody
- There must be a switch for bash/mksh/* (again, but...)
Wasn't there a patch for doing that switch without forks?
- 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?
Sounds good to me.
Andy
Re: [ITA] - base-files
Hello,
I have a base-files-4.0-1 package ready to receive testing. You can fetch it
from this URL:
http://www.eco-lution.tv/cygwin/release/base-files/base-files-4.0-1.tar.bz2
http://www.eco-lution.tv/cygwin/release/base-files/base-files-4.0-1.tar.bz2.sig
md5sums:
ff8000e0c128c9a7732d17c5eaace129 base-files-4.0-1.tar.bz2
bcdea646fcf7038f0796c68838759829 base-files-4.0-1.tar.bz2.sig
Setup.hint is unchanged.
I'd like to explain the most important change I've made, and also the
purpose of that change.
I have decided to pull out of /etc/profile the case switch that tries
to detect the shell and sets PS1 (and HOSTNAME) accordingly.
The reason for this change is that all of bash, mksh, zsh and tcsh, provide
their own files for doing that job. The result is a lighter /etc/profile
that sets a minimun PS1='$ ' that will be used by posh and dash (the only
two shells in the repo that lack specific startup files), allowing shells
that do have that files to alter this setting(s).
Notice that neither posh nor mksh, despite being ksh derivatives, read
/etc/ksh.kshrc nor ~/.kshrc.
(I=interactive,L=login,N=non-interactive,B=bash,M=mksh,Z=zsh,T=tcsh,O=posh,dash,!=not)
BL= /etc/profile - ~/.bash_profile - ~/.bashrc - /etc/bash.bashrc
BI!L= /etc/bash.bashrc - ~/.bashrc
ML= /etc/profile - ~/.mkshrc - /etc/mkshrc
MI!L= ~/.mkshrc - /etc/mkshrc
OL= /etc/profile - ~/.profile (as of now, /etc/profile is not
posh-compatible!!)
ZLZI!L= Well... the startup routines for zsh are complicated enough to let
the end
users craft their own environment (IMHO).
It's in the system-wide /etc/${SHELL}rc where PS1 and HOSTNAME are defined
now (overriding the /etc/profile default). Also, the logic that sources
/etc/profile.d/ scripts will be included there, to avoid the current situation,
where /etc/profile sources everything under /etc/profile.d, regardless
the calling shell (bash sources /etc/profile.d/*.zsh)
This changes solve the reported bug about interactive shells with a
non-interactive ancestor presenting an unset PS1 prompt.
The bug was reported regarding bash, but this logic should apply to
every shell now.
Also, the reported bug about mksh not having a well-defined PS1 can
be considered solved, since mksh will set its own PS1 in /etc/mkshrc,
sourced by ~/.mkshrc. For completeness, a skeleletal .mkshrc is provided
now which sources a system-wide /etc/mkshrc. Should that file be provided
by the mksh mantainer and installed in /etc/defaults/etc/mkshrc ?
As of now, this is the panorama: three shells offer a default system-wide rc
file in their packages, dash and posh won't use it and bash's is included in
base-files, though only two of them install it per default (tcsh and bash).
It would be better if all shells unify their criteria regarding this.
$ cygcheck -l zsh mksh tcsh dash posh bash | grep rc$
/usr/share/doc/mksh/examples/dot.mkshrc
/etc/defaults/etc/csh.cshrc
/usr/share/doc/zsh-4.3.10/StartupFiles/etc/zshrc
All changes (and bugfixes) included in this release are detailed in the
ChangeLog.
Whilst I've tried to be thorough, there are probably errors/bugs, so
I'd appreciate any testing people can give to this, in order to find
them. TIA, and sorry for the long post.
--
Huella de clave primaria: 0FDA C36F F110 54F4 D42B D0EB 617D 396C 448B 31EB
signature.asc
Description: Digital signature
Re: [ITA] - base-files
Hi David, I've not had chance to install this but I have pulled and taken a look. May I be (amongst) the first to thank you for the work you've put into this. Regards, John.
Re: [ITA] - base-files
On 8 December 2010 21:22, David Sastre wrote:
Hello,
I have a base-files-4.0-1 package ready to receive testing. You can fetch it
from this URL:
http://www.eco-lution.tv/cygwin/release/base-files/base-files-4.0-1.tar.bz2
http://www.eco-lution.tv/cygwin/release/base-files/base-files-4.0-1.tar.bz2.sig
md5sums:
ff8000e0c128c9a7732d17c5eaace129 base-files-4.0-1.tar.bz2
bcdea646fcf7038f0796c68838759829 base-files-4.0-1.tar.bz2.sig
Thanks for all that work.
I'm afraid there's a syntax error in /etc/profile though:
elif [ ! -O $HOME -a ${HOME#/home/} != ${HOME} ]
That's missing a ; then.
Also, indentation is rather wonky, due to a mix of tabs and spaces.
You appear to be using a tab size of 2?
I have decided to pull out of /etc/profile the case switch that tries
to detect the shell and sets PS1 (and HOSTNAME) accordingly.
The reason for this change is that all of bash, mksh, zsh and tcsh, provide
their own files for doing that job. The result is a lighter /etc/profile
that sets a minimun PS1='$ ' that will be used by posh and dash (the only
two shells in the repo that lack specific startup files), allowing shells
that do have that files to alter this setting(s).
Notice that neither posh nor mksh, despite being ksh derivatives, read
/etc/ksh.kshrc nor ~/.kshrc.
(I=interactive,L=login,N=non-interactive,B=bash,M=mksh,Z=zsh,T=tcsh,O=posh,dash,!=not)
BL= /etc/profile - ~/.bash_profile - ~/.bashrc - /etc/bash.bashrc
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.
BI!L= /etc/bash.bashrc - ~/.bashrc
Doesn't /etc/bash.bashrc end up being sourced twice here, due to
~/.bashrc including it.
I think your startup file list should distinguish between files that
are automatically sourced by the shell and those that are sourced by
other startup files.
Regarding the ChangeLog:
* New file: skel/.bash_logout: clear the screen after logout.
Why is that necessary? Do other systems do that?
Andy
Re: [ITA] - base-files
On Wed, Dec 08, 2010 at 11:21:38PM +, Andy Koppe wrote:
On 8 December 2010 21:22, David Sastre wrote:
Hello,
I have a base-files-4.0-1 package ready to receive testing. You can fetch it
I'm afraid there's a syntax error in /etc/profile though:
elif [ ! -O $HOME -a ${HOME#/home/} != ${HOME} ]
That's missing a ; then.
Oops, it looks like I only corrected that in my win7 box and that never made it
to my git repo.
(git newbie here, you've been warned! O:-) )
da...@win7 ~
$ grep elif /etc/profile
elif [ ! -O $HOME -a ${HOME#/home/} != ${HOME} ]; then
(...and now, I'll have to check for other differences :-D)
Also, indentation is rather wonky, due to a mix of tabs and spaces.
You appear to be using a tab size of 2?
Yep. Sorry for that. It was invisible to me... I'll correct this ASAP.
I have decided to pull out of /etc/profile the case switch that tries
to detect the shell and sets PS1 (and HOSTNAME) accordingly.
The reason for this change is that all of bash, mksh, zsh and tcsh, provide
their own files for doing that job. The result is a lighter /etc/profile
that sets a minimun PS1='$ ' that will be used by posh and dash (the only
two shells in the repo that lack specific startup files), allowing shells
that do have that files to alter this setting(s).
Notice that neither posh nor mksh, despite being ksh derivatives, read
/etc/ksh.kshrc nor ~/.kshrc.
(I=interactive,L=login,N=non-interactive,B=bash,M=mksh,Z=zsh,T=tcsh,O=posh,dash,!=not)
BL= /etc/profile - ~/.bash_profile - ~/.bashrc - /etc/bash.bashrc
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.
BI!L= /etc/bash.bashrc - ~/.bashrc
Doesn't /etc/bash.bashrc end up being sourced twice here, due to
~/.bashrc including it.
As far as I tested, it doesn't. It happens like I described above.
I'll repeat the tests, though.
FYI, the way I did it was placing a line like this:
TEST_RC=$TEST_RC:/name/of/the/file
in every startup file, and echeoing the var after opening the shell,
both interactive-login and interactive non-login.
And in the case some peolple don't use this layout, well, AFAICT, if
they don't use the default, they are supposed to know what they're
doing, right? And this is the default currently (3.9-3).
I think your startup file list should distinguish between files that
are automatically sourced by the shell and those that are sourced by
other startup files.
All of those files are automatically sourced, depending on the shell
being a login shel or an interactive shell. That's exactly what I'm
trying to get advantage of. To be fair, in the case of a login shell,
we force the course of things, but also does ~/.bash_profile in 3.9-3.
Regarding the ChangeLog:
* New file: skel/.bash_logout: clear the screen after logout.
Why is that necessary? Do other systems do that?
It's not necessary. Just a nice(?) touch. IIRC, RHEL does.
Andy
Thanks you for your time.
--
Huella de clave primaria: 0FDA C36F F110 54F4 D42B D0EB 617D 396C 448B 31EB
signature.asc
Description: Digital signature
Re: [ITA] - base-files
On Wed, Dec 08, 2010 at 11:21:38PM +, Andy Koppe wrote:
On 8 December 2010 21:22, David Sastre wrote:
Hello,
I have a base-files-4.0-1 package ready to receive testing. You can fetch it
from this URL:
I'm afraid there's a syntax error in /etc/profile though:
elif [ ! -O $HOME -a ${HOME#/home/} != ${HOME} ]
That's missing a ; then.
Corrected. New files and md5sums:
1ccd796eb9f1406806f75c624ba287c5 base-files-4.0-1.tar.bz2
6802a8d33ad4effdecd3c130a4982d70 base-files-4.0-1.tar.bz2.sig
http://www.eco-lution.tv/cygwin/release/base-files/base-files-4.0-1.tar.bz2
http://www.eco-lution.tv/cygwin/release/base-files/base-files-4.0-1.tar.bz2.sig
--
Huella de clave primaria: 0FDA C36F F110 54F4 D42B D0EB 617D 396C 448B 31EB
signature.asc
Description: Digital signature
[ITA] - base-files base-passwd
Hello,
Regarding the ITA of these packages, and the proposed patches, I have
some thoughts to share and discuss before I repackage them.
1 http://sourceware.org/ml/cygwin/2010-04/msg00521.html
case sensitivity of system32 dir (win7 and vista)
2 http://cygwin.com/ml/cygwin/2010-02/msg00503.html
PS1 not inherited by interactive shells with a non interactive
ancestry
3 http://sourceware.org/ml/cygwin/2010-05/msg0.html
PS1 setting for *ksh shells
4 Merging base-files and base passwd together.
5 http://cygwin.com/ml/cygwin-developers/2010-09/msg7.html
/home security problem
1 This is a simple fix, so it'd be applied.
2 This could be solved by redefinig the skeletal files for every shell
(more below).
3 This one might deserve some discussion:
Because of, as of now, the default shell in cygwin is bash, as I see it,
there are two possible approaches:
a) base-files provides the skel defaults and profile.d/ for the bash shell
and delegates in the other shells' packages the way they want to set PS1,
and/or have /etc/${SYSTEM_WIDE_RC} and/or /etc/skel/.{USER_RC} and/or
/etc/profile.d/${CUSTOM_FILES} and/or update the alternatives system.
(bash-sh, tcsh-csh, mksh-ksh, etc...).
The same would apply for every shell (bash, mksh, tcsh, posh, dash).
This is currently the approach in the case of tcsh (except for
/etc/defaults/etc/profile.d/lang.csh)
b) base-files provides skel defaults and profile.d customizations for
every shell (some are common: i.e. /etc/skel/.profile).
What do you people think?
4 Can we consider this? what are the circular dependencies in that scenario?
AFAICT, including base-passwd in base-files, and afterwards dropping
base-passwd dependencies anywhere else should be harmless.
5 As stated in the referenced thread, there is no way to prevent attackers
to create a user's home dir before she/he logins the first time other than
disallowing anyone but the Administrator to do that.
If the proposed workaround (issuing a warning if $HOME already exists and
is owned by someone else) is considered enough, I'll include it.
I haven't thought of anything better than that.
TIA for the feedback.
--
Huella de clave primaria: 0FDA C36F F110 54F4 D42B D0EB 617D 396C 448B 31EB
signature.asc
Description: Digital signature
Re: [ITA] - base-files base-passwd
On Fri, Sep 17, 2010 at 01:59:32PM +0200, David Sastre wrote: 4 Can we consider this? what are the circular dependencies in that scenario? AFAICT, including base-passwd in base-files, and afterwards dropping base-passwd dependencies anywhere else should be harmless. Unless Corinna disagrees, I'd rather not. I'd rather keep the two separate. cgf
Re: [ITA] - base-files base-passwd
On Sep 17 13:59, David Sastre wrote:
Hello,
Regarding the ITA of these packages, and the proposed patches, I have
some thoughts to share and discuss before I repackage them.
1 http://sourceware.org/ml/cygwin/2010-04/msg00521.html
case sensitivity of system32 dir (win7 and vista)
2 http://cygwin.com/ml/cygwin/2010-02/msg00503.html
PS1 not inherited by interactive shells with a non interactive
ancestry
3 http://sourceware.org/ml/cygwin/2010-05/msg0.html
PS1 setting for *ksh shells
4 Merging base-files and base passwd together.
5 http://cygwin.com/ml/cygwin-developers/2010-09/msg7.html
/home security problem
1 This is a simple fix, so it'd be applied.
2 This could be solved by redefinig the skeletal files for every shell
(more below).
3 This one might deserve some discussion:
Because of, as of now, the default shell in cygwin is bash, as I see it,
there are two possible approaches:
a) base-files provides the skel defaults and profile.d/ for the bash shell
and delegates in the other shells' packages the way they want to set PS1,
and/or have /etc/${SYSTEM_WIDE_RC} and/or /etc/skel/.{USER_RC} and/or
/etc/profile.d/${CUSTOM_FILES} and/or update the alternatives system.
(bash-sh, tcsh-csh, mksh-ksh, etc...).
The same would apply for every shell (bash, mksh, tcsh, posh, dash).
This is currently the approach in the case of tcsh (except for
/etc/defaults/etc/profile.d/lang.csh)
b) base-files provides skel defaults and profile.d customizations for
every shell (some are common: i.e. /etc/skel/.profile).
Tcsh is somewhat different from the other shells because it's using
an entirly different script syntax.
WHat's wrong with the proposed patch? The only problem I have with it
is the fact that it uses tr and sed to find out what shell it's running
in. There is probably a way to do this without starting more processes.
Like this:
read x /proc/self/exename
case $x in
*/bash)
...
*/dash|*/ash|*/sh)
...
*/ksh)
...
*/zsh)
...
*
...
What do you people think?
4 Can we consider this? what are the circular dependencies in that scenario?
AFAICT, including base-passwd in base-files, and afterwards dropping
base-passwd dependencies anywhere else should be harmless.
I agree with Chris. Let's keep them separate. I can imagine that the
process to create default /etc/passwd and /etc/group files might change
in the future (more intelligent, no such files at all, you name it), and
there's no reason to change base-files in that case.
5 As stated in the referenced thread, there is no way to prevent attackers
to create a user's home dir before she/he logins the first time other than
disallowing anyone but the Administrator to do that.
If the proposed workaround (issuing a warning if $HOME already exists and
is owned by someone else) is considered enough, I'll include it.
I haven't thought of anything better than that.
It's good enough for a start. If we come up with a better solution,
we can still change it, right?
Thanks,
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat
Re: [ITA] - base-files base-passwd
On Fri, Sep 17, 2010 at 04:50:40PM +0200, Corinna Vinschen wrote:
On Sep 17 13:59, David Sastre wrote:
Regarding the ITA of these packages, and the proposed patches, I have
some thoughts to share and discuss before I repackage them.
2 http://cygwin.com/ml/cygwin/2010-02/msg00503.html
PS1 not inherited by interactive shells with a non interactive
ancestry
3 http://sourceware.org/ml/cygwin/2010-05/msg0.html
PS1 setting for *ksh shells
4 Merging base-files and base passwd together.
5 http://cygwin.com/ml/cygwin-developers/2010-09/msg7.html
/home security problem
3 This one might deserve some discussion:
Because of, as of now, the default shell in cygwin is bash, as I see it,
there are two possible approaches:
a) base-files provides the skel defaults and profile.d/ for the bash
shell
and delegates in the other shells' packages the way they want to set PS1,
and/or have /etc/${SYSTEM_WIDE_RC} and/or /etc/skel/.{USER_RC} and/or
/etc/profile.d/${CUSTOM_FILES} and/or update the alternatives system.
(bash-sh, tcsh-csh, mksh-ksh, etc...).
The same would apply for every shell (bash, mksh, tcsh, posh, dash).
This is currently the approach in the case of tcsh (except for
/etc/defaults/etc/profile.d/lang.csh)
b) base-files provides skel defaults and profile.d customizations for
every shell (some are common: i.e. /etc/skel/.profile).
Tcsh is somewhat different from the other shells because it's using
an entirly different script syntax.
WHat's wrong with the proposed patch? The only problem I have with it
is the fact that it uses tr and sed to find out what shell it's running
in. There is probably a way to do this without starting more processes.
Like this:
read x /proc/self/exename
case $x in
*/bash)
...
*/dash|*/ash|*/sh)
...
*/ksh)
...
*/zsh)
...
*
...
Absolutely nothing is wrong with the patch. I'm only thinking about
an unified method for supplying skeletal files, regardless the
shell. I mean, currently /etc/profile includes logic to deal with all kinds
of shells; being mksh an example, a /etc/skel/.mkshrc could be supplied,
to source a system-wide /etc/mkshrc provided by the mksh package,
this is a simplified example taken from Debian:
case $KSH_VERSION in
*MIRBSD\ KSH*) ;;
*) return 0 ;;
esac
[[ -s /etc/mkshrc ]] . /etc/mkshrc
This would be my solution to nº2 and nº3 above, i.e. PS1 is correctly
set and inherited, because every shell that needs it, provides a
system-wide *rc file to set PS1 and HOSTNAME, distributed with that
shell's package.
I think this is positive because it frees /etc/profile from a work
that can be done by the shells on-demand. Base-files would only
provide /etc/defaults/etc/skel/.${SHELL}rc files to source
/etc/${SHELL}rc, installed by the packages, unneeded otherwise.
BTW, mksh is the only *ksh shell in the distro, being pdksh orphaned
and unmaintained upstream.
Also, I am curious to know if there is a reason why
/etc/defaults/etc/profile.d/lang.csh is not included in tcsh.
4 Can we consider this? what are the circular dependencies in that scenario?
AFAICT, including base-passwd in base-files, and afterwards dropping
base-passwd dependencies anywhere else should be harmless.
I agree with Chris. Let's keep them separate. I can imagine that the
process to create default /etc/passwd and /etc/group files might change
in the future (more intelligent, no such files at all, you name it), and
there's no reason to change base-files in that case.
OK. No problem.
5 As stated in the referenced thread, there is no way to prevent attackers
to create a user's home dir before she/he logins the first time other than
disallowing anyone but the Administrator to do that.
If the proposed workaround (issuing a warning if $HOME already exists and
is owned by someone else) is considered enough, I'll include it.
I haven't thought of anything better than that.
It's good enough for a start. If we come up with a better solution,
we can still change it, right?
All right.
--
Huella de clave primaria: 0FDA C36F F110 54F4 D42B D0EB 617D 396C 448B 31EB
signature.asc
Description: Digital signature
Re: [ITA] - base-files base-passwd
On Sep 17 18:47, David Sastre wrote:
On Fri, Sep 17, 2010 at 04:50:40PM +0200, Corinna Vinschen wrote:
What's wrong with the proposed patch? The only problem I have with it
is the fact that it uses tr and sed to find out what shell it's running
in. There is probably a way to do this without starting more processes.
Like this:
read x /proc/self/exename
case $x in
*/bash)
...
*/dash|*/ash|*/sh)
...
*/ksh)
...
*/zsh)
...
*
...
Absolutely nothing is wrong with the patch.
Well, except that it calls tr and sed for a simple job which could be
handled entirely in the shell itself, but we had that already...
I'm only thinking about
an unified method for supplying skeletal files, regardless the
shell. I mean, currently /etc/profile includes logic to deal with all kinds
of shells; being mksh an example, a /etc/skel/.mkshrc could be supplied,
to source a system-wide /etc/mkshrc provided by the mksh package,
this is a simplified example taken from Debian:
case $KSH_VERSION in
*MIRBSD\ KSH*) ;;
*) return 0 ;;
esac
[[ -s /etc/mkshrc ]] . /etc/mkshrc
This would be my solution to nº2 and nº3 above, i.e. PS1 is correctly
set and inherited, because every shell that needs it, provides a
system-wide *rc file to set PS1 and HOSTNAME, distributed with that
shell's package.
I think this is positive because it frees /etc/profile from a work
that can be done by the shells on-demand. Base-files would only
provide /etc/defaults/etc/skel/.${SHELL}rc files to source
/etc/${SHELL}rc, installed by the packages, unneeded otherwise.
That sounds fine, but it requires that all other shell maintainers play
along. I think it makes sense to provide a short term solution which
does not involve changing all shell packages. The aforementioned solution
should be carefully discussed with all (bourne-like) shell maintainers
and released in a collective effort.
Who's affected?
bash Eric Blake
dash Eric Blake
mksh Chris Sutcliffe
posh Jari Aalto
zsh Peter A. Castro
pdksh orphaned (I guess we should remove it from the distro)
BTW, mksh is the only *ksh shell in the distro, being pdksh orphaned
and unmaintained upstream.
Don't forget posh. Oh, and, btw., whatever ksh derivative you use, it's
a ksh. So, IMHO, the startup file for all of them should be /etc/kshrc
or /etc/ksh.kshrc. This in turn speaks for keeping the startup files
centralized in base-files. But that's just me. I'm not affected
anyway, being a long-time tcsh user...
Also, I am curious to know if there is a reason why
/etc/defaults/etc/profile.d/lang.csh is not included in tcsh.
The tcsh package only contains files which are part of the upstream tcsh
package and we don't have a default-lang package, so it seemed quite
natural at the time. There are other packages as well, like openssl,
which provide *.sh and *.csh profiles.
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat
Re: [ITA] - base-files base-passwd
On 17 September 2010 15:50, Corinna Vinschen wrote: 5 As stated in the referenced thread, there is no way to prevent attackers to create a user's home dir before she/he logins the first time other than disallowing anyone but the Administrator to do that. If the proposed workaround (issuing a warning if $HOME already exists and is owned by someone else) is considered enough, I'll include it. I haven't thought of anything better than that. It's good enough for a start. If we come up with a better solution, we can still change it, right? I think there's little point in just adding a warning actually, because that wouldn't stop prepared startup scripts in the user's fake home from being sourced. Also, there likely are some users whose home directory is owned by someone else for innocuous reasons, e.g. because they themselves created it when they were logged in as administrator. And of course they wouldn't take kindly to a warning, and even less to a fatal error. If that sounds as if I don't know what should be done about this, that's because I don't. Andy
Re: [ITA] - base-files base-passwd
On Sep 17 21:23, Andy Koppe wrote: On 17 September 2010 15:50, Corinna Vinschen wrote: 5 As stated in the referenced thread, there is no way to prevent attackers to create a user's home dir before she/he logins the first time other than disallowing anyone but the Administrator to do that. If the proposed workaround (issuing a warning if $HOME already exists and is owned by someone else) is considered enough, I'll include it. I haven't thought of anything better than that. It's good enough for a start. If we come up with a better solution, we can still change it, right? I think there's little point in just adding a warning actually, because that wouldn't stop prepared startup scripts in the user's fake home from being sourced. Also, there likely are some users whose home directory is owned by someone else for innocuous reasons, e.g. because they themselves created it when they were logged in as administrator. And of course they wouldn't take kindly to a warning, and even less to a fatal error. Which is not a good idea anyway. The home dir should belong to the user. After all, Cygwin is not Windows(*) but a POSIX system. OpenSSH for instance checks if the home dir belongs to the user and has sufficiently strict permissions. Corinna (*) Yes, yes, I know. Don't rub it in. -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: [ITA] - base-files base-passwd
On 17 September 2010 21:43, Corinna Vinschen wrote: On Sep 17 21:23, Andy Koppe wrote: On 17 September 2010 15:50, Corinna Vinschen wrote: 5 As stated in the referenced thread, there is no way to prevent attackers to create a user's home dir before she/he logins the first time other than disallowing anyone but the Administrator to do that. If the proposed workaround (issuing a warning if $HOME already exists and is owned by someone else) is considered enough, I'll include it. I haven't thought of anything better than that. It's good enough for a start. If we come up with a better solution, we can still change it, right? I think there's little point in just adding a warning actually, because that wouldn't stop prepared startup scripts in the user's fake home from being sourced. Also, there likely are some users whose home directory is owned by someone else for innocuous reasons, e.g. because they themselves created it when they were logged in as administrator. And of course they wouldn't take kindly to a warning, and even less to a fatal error. Which is not a good idea anyway. The home dir should belong to the user. After all, Cygwin is not Windows(*) but a POSIX system. OpenSSH for instance checks if the home dir belongs to the user and has sufficiently strict permissions. Good point. Andy
