On Thu, 2012-07-12 at 13:07 -0600, Ed Heron wrote:
> On Wed, 2012-07-11 at 19:40 -0400, Brian Mathis wrote:
> >
> > The use of "mv -v ...{,_}" is too clever for this kind of educational
> > document, and should be changed to spell out the full "mv" command. I
> > get what you're doing there, but the purpose of the document is not to
> > teach clever uses of bash, it's to make it obvious to people that
> > you're renaming the file. It will trip up the flow of reading for all
> > but the most knowledgeable users, and users who don't understand it
> > will be totally lost.
>
> I'm not trying to be clever, I just don't like to type it twice if I
> can avoid it and the typing the higher the chance for a typo. I don't
> have a problem having both forms. I'll add it and see what you think.
>
> > In most documents and scripts, I usually spell out the short form
> > options as well, such as using "--verbose". Short forms save you
> > typing, but documentation should not trip people up if they don't know
> > what the option means.
>
> Normally, I expect, if people don't understand a command, they will
> refer to the man page for the command. However, to my constant
> disappointment, I understand that many people aren't looking for long
> term knowledge improvement, they are looking for a recipe to blindly
> follow.
>
> > Also, I find the use of "_" to be obtuse and highly error prone if one
> > were to actually run a server that way. It's far more obvious to use
> > "disabled", which makes it very clear that those items are disabled.
> > It may work for you but only because that's a convention you came up
> > with so you're used to it, but we're not in dos 8.3 days with
> > filenames, so why not be more descriptive?
>
> Having both forms should make it plain that people can use any
> convention they wish. System administration is not a fixed target.
> Like many things, there are many ways to accomplish the same result.
> When approaching a system that someone else is administrating, we should
> try to maintain the existing conventions instead of forcing our own
> ideas onto a server for which we are not the primary responsible party.
>
> > In section 6.4, is there a reason not to make a "vhosts.conf" file
> > that contains the "Include" in the in the conf.d/ directory, instead
> > of appending to the httpd.conf, or do you run into ordering issues
> > there? I try to avoid changing the distro files if possible.
>
> Sections 6 and 7 are optional. There are certainly arguments against
> customization. In the past, upgrades might have replaced all files
> including configuration files. In that case, creating a vhosts.conf
> file in the conf.d directory to separate the directive would have been a
> must. However, the Linux distributions I have used for the past decade
> or so have avoided replacing existing configuration files, expecting
> they might be customized.
>
> That said, I like the suggestion. It would allow for the virtual host
> files to be packaged into an RPM file that could be installed on
> multiple web hosts.
>
> >
> > ❧ Brian Mathis
I made the changes I've described about a week ago. Brian, does that
satisfy your concerns? Does anybody else agree with Brian? Have the
changes I've made make it easier to read the document?
_______________________________________________
CentOS-docs mailing list
CentOS-docs@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos-docs
