* base-files revisited @ 2019-04-06 14:08 John Morrison 2019-04-07 18:58 ` Chris Wagner ` (2 more replies) 0 siblings, 3 replies; 8+ messages in thread From: John Morrison @ 2019-04-06 14:08 UTC (permalink / raw) To: cygwin Hi, I've been asked at work to get the standard base-files extended with specifics for the company I work for and wondered if this would be a good time to revisit how the .bashrc file in particular is put together. What I was considering would be introducing a ~/.bashrc.d/ folder and splitting the existing ~/.bashrc file into its component parts; * alias.bashrc * completion.bashrc * functions.bashrc * history.bashrc * shell.bashrc * umask.bashrc and changing .bashrc to source all the *.bashrc files. This would allow easier extension of the bashrc with, in my case, company specific options (proxies, common aliases etc). I was also thinking of taking some more of the sample from https://www.tldp.org/LDP/abs/html/sample-bashrc.html, for example the colours and some more of the aliases and adding them into the existing sets. Thoughts? I think Achim Gratz took over the base-files from me. Achim, are you still around? Open for a discussion? Kind regards John. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: base-files revisited 2019-04-06 14:08 base-files revisited John Morrison @ 2019-04-07 18:58 ` Chris Wagner 2019-04-08 7:05 ` Brian Inglis 2019-04-08 16:56 ` Achim Gratz 2 siblings, 0 replies; 8+ messages in thread From: Chris Wagner @ 2019-04-07 18:58 UTC (permalink / raw) To: cygwin Personally I wouldn't want to see yet another .directory in home. Endless fractionation of config is one of the things about unix that irks me. This is not to say that there aren't perfectly valid use cases for YACF (yet another config file). Perhaps this would be best served by a new shell configurator package. Or possibly some other already existing shell manager. If someone had a use for a non standard shell config, he could install and run shell-configurator which would walk him through all of the various possibilities for shell initialization. Whether to use foo.d, special files to include, color, etc. It could also save these settings to its own init file that could be applied to new users for organizational use or just to backup your own settings. Thanks. On 2019-04-06 10:08 am, John Morrison wrote: > Hi, > > I've been asked at work to get the standard base-files extended with > specifics for the company I work for and wondered if this would be a > good > time to revisit how the .bashrc file in particular is put together. > > What I was considering would be introducing a ~/.bashrc.d/ folder and > splitting the existing ~/.bashrc file into its component parts; > > * alias.bashrc > * completion.bashrc > * functions.bashrc > * history.bashrc > * shell.bashrc > * umask.bashrc > > and changing .bashrc to source all the *.bashrc files. > > This would allow easier extension of the bashrc with, in my case, > company > specific options (proxies, common aliases etc). > > I was also thinking of taking some more of the sample from > https://www.tldp.org/LDP/abs/html/sample-bashrc.html, for example the > colours and some more of the aliases and adding them into the existing > sets. > > Thoughts? > > I think Achim Gratz took over the base-files from me. Achim, are you > still > around? Open for a discussion? > > Kind regards > > John. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: base-files revisited 2019-04-06 14:08 base-files revisited John Morrison 2019-04-07 18:58 ` Chris Wagner @ 2019-04-08 7:05 ` Brian Inglis 2019-04-08 17:46 ` John Morrison 2019-04-08 16:56 ` Achim Gratz 2 siblings, 1 reply; 8+ messages in thread From: Brian Inglis @ 2019-04-08 7:05 UTC (permalink / raw) To: cygwin On 2019-04-06 08:08, John Morrison wrote: > I've been asked at work to get the standard base-files extended with > specifics for the company I work for and wondered if this would be a good > time to revisit how the .bashrc file in particular is put together. > > What I was considering would be introducing a ~/.bashrc.d/ folder and > splitting the existing ~/.bashrc file into its component parts; > > * alias.bashrc > * completion.bashrc > * functions.bashrc > * history.bashrc > * shell.bashrc > * umask.bashrc > > and changing .bashrc to source all the *.bashrc files. > > This would allow easier extension of the bashrc with, in my case, company > specific options (proxies, common aliases etc). > > I was also thinking of taking some more of the sample from > https://www.tldp.org/LDP/abs/html/sample-bashrc.html, for example the > colours and some more of the aliases and adding them into the existing sets. > > Thoughts? > > I think Achim Gratz took over the base-files from me. Achim, are you still > around? Open for a discussion? > > Kind regards You might want to consider using standard /etc/profile.d/ scripts named for, and conditional on, your company domain, Cygwin, shell, and components, depending on how you want to do things, possibly installed from /etc/defaults/etc/profile.d/. Or you could put a <domain>.sh driver script in /etc/profile.d/, and source scripts from /usr/local/{bin,lib,share}/<domain>/. You could use the Xwin directories ~/.local/ and ~/.config/ if you want user specific customization, perhaps setup in /etc/defaults/etc/skel and installed by a custom postinstall script base-files-<domain>.sh. Or some combo of those and other standard approaches to local customization, like .${OSTYPE}_profile, .${OSTYPE}rc, .${HOSTNAME}_profile, .${HOSTNAME}rc, etc. Have a look at the various systems and shells and their initialization and customization approaches, and adapt some existing infrastructure, rather than stuffing something unique somewhere unexpected. -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: base-files revisited 2019-04-08 7:05 ` Brian Inglis @ 2019-04-08 17:46 ` John Morrison 0 siblings, 0 replies; 8+ messages in thread From: John Morrison @ 2019-04-08 17:46 UTC (permalink / raw) To: Brian.Inglis, cygwin On Mon, 8 Apr 2019 at 08:05, Brian Inglis wrote: > On 2019-04-06 08:08, John Morrison wrote: > > I've been asked at work to get the standard base-files extended with > > specifics for the company I work for and wondered if this would be a good > > time to revisit how the .bashrc file in particular is put together. > > You might want to consider using standard /etc/profile.d/ scripts named > for, and > conditional on, your company domain, Cygwin, shell, and components, > depending on > how you want to do things, possibly installed from > /etc/defaults/etc/profile.d/. > > Or you could put a <domain>.sh driver script in /etc/profile.d/, and source > scripts from /usr/local/{bin,lib,share}/<domain>/. > > You could use the Xwin directories ~/.local/ and ~/.config/ if you want > user > specific customization, perhaps setup in /etc/defaults/etc/skel and > installed by > a custom postinstall script base-files-<domain>.sh. > > Or some combo of those and other standard approaches to local > customization, > like .${OSTYPE}_profile, .${OSTYPE}rc, .${HOSTNAME}_profile, > .${HOSTNAME}rc, etc. > > Have a look at the various systems and shells and their initialization and > customization approaches, and adapt some existing infrastructure, rather > than > stuffing something unique somewhere unexpected. > I'm sure these would work or could be made to, but this is intended to be a starting point for users to modify (with company placeholders), not globally enforced, but thanks! I've got a base-files-<company> package, but wanted to extend the .rc files installed by base-files. Achim has proffered some ideas along that front (see other mail). I wasn't trying for something unique, just trying to get things a little easier to customise :) -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: base-files revisited 2019-04-06 14:08 base-files revisited John Morrison 2019-04-07 18:58 ` Chris Wagner 2019-04-08 7:05 ` Brian Inglis @ 2019-04-08 16:56 ` Achim Gratz 2019-04-08 17:37 ` John Morrison 2 siblings, 1 reply; 8+ messages in thread From: Achim Gratz @ 2019-04-08 16:56 UTC (permalink / raw) To: cygwin John Morrison writes: > I've been asked at work to get the standard base-files extended with > specifics for the company I work for and wondered if this would be a good > time to revisit how the .bashrc file in particular is put together. > > What I was considering would be introducing a ~/.bashrc.d/ folder and > splitting the existing ~/.bashrc file into its component parts; > > * alias.bashrc > * completion.bashrc > * functions.bashrc > * history.bashrc > * shell.bashrc > * umask.bashrc > > and changing .bashrc to source all the *.bashrc files. > > This would allow easier extension of the bashrc with, in my case, company > specific options (proxies, common aliases etc). Been there, done that. You'll end up providing one or more company specific packages either as an overlay repository or merged into a local mirror repository. That is unless you only have a handful of users that either can and actually do follow instructions or you can handhold them during their installations. If you provide a company config package all you need to do is make sure it gets installed last (or arrange for the postinstall to do all the work and move that to a late place). Once you've replaced the default files setup (or rather the respective postinstalls) will keep them untouched. > I was also thinking of taking some more of the sample from > https://www.tldp.org/LDP/abs/html/sample-bashrc.html, for example the > colours and some more of the aliases and adding them into the existing sets. None of that strikes me as desirable to enable by default. > Thoughts? > > I think Achim Gratz took over the base-files from me. Achim, are you still > around? Open for a discussion? Tentatively, I'd say what you want to do doesn't belong into base-files. That is supposed to provide a clean starting point (mostly to work around some quirks of how Windows leaves your environment) and treat all POSIX shells the same to the extent possible, not create even more differences than there are out of the gate. There already are hooks in profile to enable your own scripting if that's what you want and anything that is purely bash-specific would need to go into its own package anyway. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Factory and User Sound Singles for Waldorf rackAttack: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: base-files revisited 2019-04-08 16:56 ` Achim Gratz @ 2019-04-08 17:37 ` John Morrison 2019-04-08 18:25 ` Achim Gratz 0 siblings, 1 reply; 8+ messages in thread From: John Morrison @ 2019-04-08 17:37 UTC (permalink / raw) To: cygwin On Mon, 8 Apr 2019 at 17:56, Achim Gratz wrote: > John Morrison writes: > > I've been asked at work to get the standard base-files extended with > > specifics for the company I work for and wondered if this would be a good > > time to revisit how the .bashrc file in particular is put together. > <snip original thoughts/> > Been there, done that. You'll end up providing one or more company > specific packages either as an overlay repository or merged into a local > mirror repository. The company won't allow anything to be installed directly from the internet. We were going to create a local mirror repo of the things which are allowed to be installed along with a 'package script' which will call setup with the appropriate commands. The company specifics we were planning to have as another, separate, local 'mirror' and get setup to merge them. It works, not very pretty though. If you know of a better strategy I'm all ears! > That is unless you only have a handful of users that > either can and actually do follow instructions or you can handhold them > during their installations. They don't get a choice, although we might open the default mirror up sufficiently for folks to request specific additional packages added to the installation. Best we're allowed to offer. > If you provide a company config package all > you need to do is make sure it gets installed last (or arrange for the > postinstall to do all the work and move that to a late place). Once > you've replaced the default files setup (or rather the respective > postinstalls) will keep them untouched. > I didn't think about installed last... I could get the postinstall to append to the actual files (/etc/defaults/skel or /etc/skel) directly... hum. The base-files-<company> package was already adding some additional /etc/skel/.rc files, what I really wanted was a way of adding the to /etc/skel/.bashrc and /etc/skel/.inputrc so that might work. I think some defaults for mintty were mentioned as well (we have fairly high spec monitors and everyone ends up boosting the font size). > > I was also thinking of taking some more of the sample from > > https://www.tldp.org/LDP/abs/html/sample-bashrc.html, for example the > > colours and some more of the aliases and adding them into the existing > sets. > > None of that strikes me as desirable to enable by default. > > > Thoughts? > > > > I think Achim Gratz took over the base-files from me. Achim, are you > still > > around? Open for a discussion? > > Tentatively, I'd say what you want to do doesn't belong into base-files. > That is supposed to provide a clean starting point (mostly to work > around some quirks of how Windows leaves your environment) and treat all > POSIX shells the same to the extent possible, not create even more > differences than there are out of the gate. There already are hooks in > profile to enable your own scripting if that's what you want and > anything that is purely bash-specific would need to go into its own > package anyway. > Fair enough :) Thanks for the thoughts. J. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: base-files revisited 2019-04-08 17:37 ` John Morrison @ 2019-04-08 18:25 ` Achim Gratz 2019-04-08 19:04 ` Brian Inglis 0 siblings, 1 reply; 8+ messages in thread From: Achim Gratz @ 2019-04-08 18:25 UTC (permalink / raw) To: cygwin John Morrison writes: > The company won't allow anything to be installed directly from the internet. > We were going to create a local mirror repo of the things which are allowed > to be installed along with a 'package script' which will call setup with > the appropriate commands. That sounds more or less exactly like my own place of work. > The company specifics we were planning to have as another, separate, local > 'mirror' and get setup to merge them. It works, not very pretty though. If > you know of a better strategy I'm all ears! What I'm doing is that I have a Perl script that is controlled by a setup.conf file and can use any number of local repos and merge them into a local install directory (it now also mirrors from the upstream repos just those files I really need instead of all of them). The reason for doing it that way was mainly to be able to inject arbitrary extra categories that I can then install (I have different types of installs for different users). I can also lock package versions for those days when I need to delay a package update (or want to pull in a test package). I still plan to clean that up enough so I can release it, but I'm continually out of round tuits on that. I also compile my own setup.exe and have replaced the PGP key in there plus made the signature check mandatory so nobody can use a setup.ini I haven't signed, which in turn means no packages I haven't put in the local repo. The setup is also run in a way that it leaves the installation with exactly those packages I specified for each install type, so if an installation is downgraded it'll remove any extra or reinstall uprev packages. Another less intrusive option is to just place a few packages in your mirror that "depend" on all the leaf packages you want to install and then just let setup install that single package and pull in the actual installation via dependencies. That will not allow you to easily remove packages when they are no longer needed, but if your installations aren't expected to change that way then this works. > They don't get a choice, although we might open the default mirror up > sufficiently for folks to request specific additional packages added to the > installation. Best we're allowed to offer. That's why I'm having different install types. The normal users don't want or need the development tools and even among the developers only I myself install with all the debuginfo packages and only on the package build machine. > I didn't think about installed last... I could get the postinstall to > append to the actual files (/etc/defaults/skel or /etc/skel) directly... Leave /etc/defaults alone or you defeat the detection of altered defaults. More generally, don't edit or overwrite files installed from any package, as removing or re-installing the package will nix all your changes. > The base-files-<company> package was already adding some additional > /etc/skel/.rc files, what I really wanted was a way of adding the to > /etc/skel/.bashrc and /etc/skel/.inputrc so that might work. I think some > defaults for mintty were mentioned as well (we have fairly high spec > monitors and everyone ends up boosting the font size). Once you change files in /etc/skel, you are continually responsible for them yourself. Packages never install there directly and if they are changed from the default they won't get touched again. 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 -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: base-files revisited 2019-04-08 18:25 ` Achim Gratz @ 2019-04-08 19:04 ` Brian Inglis 0 siblings, 0 replies; 8+ messages in thread From: Brian Inglis @ 2019-04-08 19:04 UTC (permalink / raw) To: cygwin On 2019-04-08 12:25, Achim Gratz wrote: > John Morrison writes: >> The company won't allow anything to be installed directly from the internet. >> We were going to create a local mirror repo of the things which are allowed >> to be installed along with a 'package script' which will call setup with >> the appropriate commands. > > That sounds more or less exactly like my own place of work. > >> The company specifics we were planning to have as another, separate, local >> 'mirror' and get setup to merge them. It works, not very pretty though. If >> you know of a better strategy I'm all ears! > > What I'm doing is that I have a Perl script that is controlled by a > setup.conf file and can use any number of local repos and merge them > into a local install directory (it now also mirrors from the upstream > repos just those files I really need instead of all of them). The > reason for doing it that way was mainly to be able to inject arbitrary > extra categories that I can then install (I have different types of > installs for different users). I can also lock package versions for > those days when I need to delay a package update (or want to pull in a > test package). I still plan to clean that up enough so I can release > it, but I'm continually out of round tuits on that. I also compile my > own setup.exe and have replaced the PGP key in there plus made the > signature check mandatory so nobody can use a setup.ini I haven't > signed, which in turn means no packages I haven't put in the local repo. > The setup is also run in a way that it leaves the installation with > exactly those packages I specified for each install type, so if an > installation is downgraded it'll remove any extra or reinstall uprev > packages. > > Another less intrusive option is to just place a few packages in your > mirror that "depend" on all the leaf packages you want to install and > then just let setup install that single package and pull in the actual > installation via dependencies. That will not allow you to easily remove > packages when they are no longer needed, but if your installations > aren't expected to change that way then this works. > >> They don't get a choice, although we might open the default mirror up >> sufficiently for folks to request specific additional packages added to the >> installation. Best we're allowed to offer. > > That's why I'm having different install types. The normal users don't > want or need the development tools and even among the developers only I > myself install with all the debuginfo packages and only on the package > build machine. > >> I didn't think about installed last... I could get the postinstall to >> append to the actual files (/etc/defaults/skel or /etc/skel) directly... > > Leave /etc/defaults alone or you defeat the detection of altered > defaults. More generally, don't edit or overwrite files installed from > any package, as removing or re-installing the package will nix all your > changes. > >> The base-files-<company> package was already adding some additional >> /etc/skel/.rc files, what I really wanted was a way of adding the to >> /etc/skel/.bashrc and /etc/skel/.inputrc so that might work. I think some >> defaults for mintty were mentioned as well (we have fairly high spec >> monitors and everyone ends up boosting the font size). > > Once you change files in /etc/skel, you are continually responsible for > them yourself. Packages never install there directly and if they are > changed from the default they won't get touched again. Adding files into defaults and skel directories are okay, just don't change the distributed files, as you *WILL* need a way to reset or bypass your local customizations, to diagnose problems against the base install on your systems. Safest way is normally to append required changes to the end of the default installed config files from a local postinstall script that checks whether the installed config file matches the default and needs the changes appended, has already had the changes appended, or has been further customized by the user. -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2019-04-08 19:04 UTC | newest] Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2019-04-06 14:08 base-files revisited John Morrison 2019-04-07 18:58 ` Chris Wagner 2019-04-08 7:05 ` Brian Inglis 2019-04-08 17:46 ` John Morrison 2019-04-08 16:56 ` Achim Gratz 2019-04-08 17:37 ` John Morrison 2019-04-08 18:25 ` Achim Gratz 2019-04-08 19:04 ` Brian Inglis
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).