I'd like to start a calm, respectful, reasonable discussion of the reasons that we tell people to RTFM, or reasons that people don't get their questions answered on mailing lists and usenet groups.
I'm not complaining about anything or anybody, just wanting to start some discussion which might lead to more answers and less 'noise'.
No one has been disrespectful to me, don't get the wrong idea.
I personally am a former Microsoft Certified Professional in NT Server 4.0, have used operating systems including, PC DOS, MS DOS, OS/2 Warp, all flavors of Windows through XP Pro (except ME, which sucked sooo bad), Linux, FreeBSD, and currently, Mac OS X Tiger.
I've administered networks consisting of hundreds of workstations and dozens of servers, installed lans and wans from scratch, taught Windows operating systems, software and networking.
I feel that might just barely qualify me as knowing a little about computers, and I say that seriously...'a little'.
There are a lot of things I don't know, and when I run out of research options, or get frustrated when all the troubleshooting solutions don't work, I'm heading for usenet or a mailing list, because time after time, that has been the resource that provided the solution. A wise man once told me, "Someone out there has solved that problem, you just have to find them."
I don't really know where to start, so here are some random thoughts...
Maybe I got told to RTFM because I missed something in it? Well, could you just politely point me to the section I missed, please? Or give me a link to a howto or some html page where it is explained?
Maybe the question has been answered in the FAQ for the list? Just point me to it, you don't have to say anything else.
I've seen lots of posts to this list and others with no subject or a subject that has nothing to do with the question, but the question was answered respectfully. So, when I post with a good subject, one that will show up in a Google search, help me out.
Many lists and groups regularly autopost the guidelines for posting, FAQ, and relevant howto pages, point me to those when necessary.
Someone used the phrase 'spoon feed' recently. I don't remember who, nor is it important, but what's wrong with a spoon full of sugar now and then? And why would you ignore a reasonable question unless you don't know the answer?
I think the members of this list are mostly doing things the way I would like to see them done, but I also think we could all do better, eh?
I don't mean to step on any toes, just want to start some discussion. Does anyone else have any thoughts on why questions don't get the respectful treatment they deserve?
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
-----Original Message----- From: fedora-list-bounces@redhat.com [mailto:fedora-list-bounces@redhat.com] On Behalf Of Charles Howse Sent: Wednesday, December 28, 2005 7:38 PM To: Fedora Subject: Why questions don't get answered, or "No, I've already RTFM, tell me the answer!"
I'd like to start a calm, respectful, reasonable discussion of the reasons that we tell people to RTFM, or reasons that people don't get their questions answered on mailing lists and usenet groups.
I'm not complaining about anything or anybody, just wanting to start some discussion which might lead to more answers and less 'noise'.
No one has been disrespectful to me, don't get the wrong idea.
I personally am a former Microsoft Certified Professional in NT Server 4.0, have used operating systems including, PC DOS, MS DOS, OS/2 Warp, all flavors of Windows through XP Pro (except ME, which sucked sooo bad), Linux, FreeBSD, and currently, Mac OS X Tiger.
I've administered networks consisting of hundreds of workstations and dozens of servers, installed lans and wans from scratch, taught Windows operating systems, software and networking.
I feel that might just barely qualify me as knowing a little about computers, and I say that seriously...'a little'.
I know how you feel. ;-)
There are a lot of things I don't know, and when I run out of research options, or get frustrated when all the troubleshooting solutions don't work, I'm heading for usenet or a mailing list, because time after time, that has been the resource that provided the solution. A wise man once told me, "Someone out there has solved that problem, you just have to find them."
I don't really know where to start, so here are some random thoughts...
Maybe I got told to RTFM because I missed something in it? Well, could you just politely point me to the section I missed, please? Or give me a link to a howto or some html page where it is explained?
Maybe the question has been answered in the FAQ for the list? Just point me to it, you don't have to say anything else.
I've seen lots of posts to this list and others with no subject or a subject that has nothing to do with the question, but the question was answered respectfully. So, when I post with a good subject, one that will show up in a Google search, help me out.
Many lists and groups regularly autopost the guidelines for posting, FAQ, and relevant howto pages, point me to those when necessary.
Someone used the phrase 'spoon feed' recently. I don't remember who, nor is it important, but what's wrong with a spoon full of sugar now and then? And why would you ignore a reasonable question unless you don't know the answer?
Is replying to say "I don't know" any more constructive than ignoring the question? At the least it lets the OP know that the mail was received, but really, that's about it.
I think the members of this list are mostly doing things the way I would like to see them done, but I also think we could all do better, eh?
I don't mean to step on any toes, just want to start some discussion. Does anyone else have any thoughts on why questions don't get the respectful treatment they deserve?
-- Thanks, Charles
While I agree with you on the general gist of what you're saying, I think that the people who are behaving negatively on lists are people who are demanding attention. *Most* people answer, if they know. Or point if they can. What I've found, is that at least 2 out of 3 times, when I go to google someone's problem, the answer is usually in the top 10 links found. For people that are particularly active on lists, this can be frustrating.
This list in particular seems to be relatively well behaved, although, I don't follow it as closely as I used to (switched distros). So I'm a little curious why you're asking these questions now.
- -- - - Charlie
5A27 58D2 C791 8769 D4A4 F316 7BF8 D1F6 4829 EDCF
In memoriam: http://www.militarycity.com/valor/1029976.html
On Wed, 2005-12-28 at 19:58 -0800, Charles Heselton wrote:
[mailto:fedora-list-bounces@redhat.com] On Behalf Of Charles Howse
*Most* people answer, if they know. Or point if they can. What I've found, is that at least 2 out of 3 times, when I go to google someone's problem, the answer is usually in the top 10 links found. For people that are particularly active on lists, this can be frustrating.
yes. This is very true. And bear in mind that perhaps as much/as less as 50% of people in this list actually do take the time to solve the issues for you. They're not support staff but they do it out of wanting to help.
The manner in this the question is asked is also pertinent to getting some answers. eg: They would have liked for the OP to at least have researched the question by themselves (no spoon feed) with a min of google (though of course the sequence/choice of search parameters will make/break the query) and perhaps some archive searching. (eg: like me, I have like 2 years worth of List archive which I consult before shooting an email to the list. That and the fact that I don't have I-net access at work, (only email ), so I make that clear as well.)
That's my 2 cents.
On 12/28/05, Ow Mun Heng Ow.Mun.Heng@wdc.com wrote:
On Wed, 2005-12-28 at 19:58 -0800, Charles Heselton wrote:
[mailto:fedora-list-bounces@redhat.com] On Behalf Of Charles Howse
*Most* people answer, if they know. Or point if they can. What I've found, is that at least 2 out of 3 times, when I go to google someone's problem, the answer is usually in the top 10 links found. For people that are particularly active on lists, this can be frustrating.
yes. This is very true. And bear in mind that perhaps as much/as less as 50% of people in this list actually do take the time to solve the issues for you. They're not support staff but they do it out of wanting to help.
The manner in this the question is asked is also pertinent to getting some answers. eg: They would have liked for the OP to at least have researched the question by themselves (no spoon feed) with a min of google (though of course the sequence/choice of search parameters will make/break the query) and perhaps some archive searching. (eg: like me, I have like 2 years worth of List archive which I consult before shooting an email to the list. That and the fact that I don't have I-net access at work, (only email ), so I make that clear as well.)
That's my 2 cents.
Much of this bashing would be alleviated if Red Hat, a publically held and for-profit company, put some real effort into incorporating a decent search engine for the archives.
From: "Kam Leo" kam.leo@gmail.com
On 12/28/05, Ow Mun Heng Ow.Mun.Heng@wdc.com wrote:
On Wed, 2005-12-28 at 19:58 -0800, Charles Heselton wrote:
[mailto:fedora-list-bounces@redhat.com] On Behalf Of Charles Howse
*Most* people answer, if they know. Or point if they can. What I've found, is that at least 2 out of 3 times, when I go to google someone's problem, the answer is usually in the top 10 links found. For people that are particularly active on lists, this can be frustrating.
yes. This is very true. And bear in mind that perhaps as much/as less as 50% of people in this list actually do take the time to solve the issues for you. They're not support staff but they do it out of wanting to help.
The manner in this the question is asked is also pertinent to getting some answers. eg: They would have liked for the OP to at least have researched the question by themselves (no spoon feed) with a min of google (though of course the sequence/choice of search parameters will make/break the query) and perhaps some archive searching. (eg: like me, I have like 2 years worth of List archive which I consult before shooting an email to the list. That and the fact that I don't have I-net access at work, (only email ), so I make that clear as well.)
That's my 2 cents.
Much of this bashing would be alleviated if Red Hat, a publically held and for-profit company, put some real effort into incorporating a decent search engine for the archives.
Rumor has it that Google will search into the archives. Experience bears out the rumors. (People who can tolerate Bugzilla also cite using Google as a surrogate search engine for Bugzilla. That might make that horrid, ugly, annoying tool (I'm being kind) almost bearable, too.)
{^_-}
From: "Kam Leo" kam.leo@gmail.com
On 12/28/05, Ow Mun Heng Ow.Mun.Heng@wdc.com wrote:
On Wed, 2005-12-28 at 19:58 -0800, Charles Heselton wrote:
[mailto:fedora-list-bounces@redhat.com] On Behalf Of Charles Howse
*Most* people answer, if they know. Or point if they can. What I've found, is that at least 2 out of 3 times, when I go to google someone's problem, the answer is usually in the top 10 links found. For people that are particularly active on lists, this can be frustrating.
yes. This is very true. And bear in mind that perhaps as much/as less as 50% of people in this list actually do take the time to solve the issues for you. They're not support staff but they do it out of wanting to help.
The manner in this the question is asked is also pertinent to getting some answers. eg: They would have liked for the OP to at least have researched the question by themselves (no spoon feed) with a min of google (though of course the sequence/choice of search parameters will make/break the query) and perhaps some archive searching. (eg: like me, I have like 2 years worth of List archive which I consult before shooting an email to the list. That and the fact that I don't have I-net access at work, (only email ), so I make that clear as well.)
That's my 2 cents.
Much of this bashing would be alleviated if Red Hat, a publically held and for-profit company, put some real effort into incorporating a decent search engine for the archives.
Rumor has it that Google will search into the archives. Experience bears out the rumors. (People who can tolerate Bugzilla also cite using Google as a surrogate search engine for Bugzilla. That might make that horrid, ugly, annoying tool (I'm being kind) almost bearable, too.)
Would you please give an example of a Google search through this list's archives?
On Wed, 2005-12-28 at 22:53 -0600, Charles Howse wrote:
From: "Kam Leo" kam.leo@gmail.com
On 12/28/05, Ow Mun Heng Ow.Mun.Heng@wdc.com wrote:
On Wed, 2005-12-28 at 19:58 -0800, Charles Heselton wrote:
[mailto:fedora-list-bounces@redhat.com] On Behalf Of Charles Howse
*Most* people answer, if they know. Or point if they can. What I've found, is that at least 2 out of 3 times, when I go to google someone's problem, the answer is usually in the top 10 links found. For people that are particularly active on lists, this can be frustrating.
yes. This is very true. And bear in mind that perhaps as much/as less as 50% of people in this list actually do take the time to solve the issues for you. They're not support staff but they do it out of wanting to help.
The manner in this the question is asked is also pertinent to getting some answers. eg: They would have liked for the OP to at least have researched the question by themselves (no spoon feed) with a min of google (though of course the sequence/choice of search parameters will make/break the query) and perhaps some archive searching. (eg: like me, I have like 2 years worth of List archive which I consult before shooting an email to the list. That and the fact that I don't have I-net access at work, (only email ), so I make that clear as well.)
That's my 2 cents.
Much of this bashing would be alleviated if Red Hat, a publically held and for-profit company, put some real effort into incorporating a decent search engine for the archives.
Rumor has it that Google will search into the archives. Experience bears out the rumors. (People who can tolerate Bugzilla also cite using Google as a surrogate search engine for Bugzilla. That might make that horrid, ugly, annoying tool (I'm being kind) almost bearable, too.)
Would you please give an example of a Google search through this list's archives?
---- pardon the html...trying to keep long line together...
stick this in a google search
"rmdir when directory is not empty" site:https://www.redhat.com/archives/fedora-list/
Craig
From: "Charles Howse" chowse@charter.net
From: "Kam Leo" kam.leo@gmail.com
On 12/28/05, Ow Mun Heng Ow.Mun.Heng@wdc.com wrote:
On Wed, 2005-12-28 at 19:58 -0800, Charles Heselton wrote:
[mailto:fedora-list-bounces@redhat.com] On Behalf Of Charles Howse
*Most* people answer, if they know. Or point if they can. What I've found, is that at least 2 out of 3 times, when I go to google someone's problem, the answer is usually in the top 10 links found. For people that are particularly active on lists, this can be frustrating.
yes. This is very true. And bear in mind that perhaps as much/as less as 50% of people in this list actually do take the time to solve the issues for you. They're not support staff but they do it out of wanting to help.
The manner in this the question is asked is also pertinent to getting some answers. eg: They would have liked for the OP to at least have researched the question by themselves (no spoon feed) with a min of google (though of course the sequence/choice of search parameters will make/break the query) and perhaps some archive searching. (eg: like me, I have like 2 years worth of List archive which I consult before shooting an email to the list. That and the fact that I don't have I-net access at work, (only email ), so I make that clear as well.)
That's my 2 cents.
Much of this bashing would be alleviated if Red Hat, a publically held and for-profit company, put some real effort into incorporating a decent search engine for the archives.
Rumor has it that Google will search into the archives. Experience bears out the rumors. (People who can tolerate Bugzilla also cite using Google as a surrogate search engine for Bugzilla. That might make that horrid, ugly, annoying tool (I'm being kind) almost bearable, too.)
Would you please give an example of a Google search through this list's archives?
Search for: vncserver fedora-users
That should be a workable example. {^_^}
From: "jdow" jdow@earthlink.net
Search for: vncserver fedora-users
Make that vncserver fedora-list.
That should be a workable example. {^_^}
Forgot where I was at the time. {o.o}
On Wed, 2005-12-28 at 22:23 -0800, jdow wrote:
From: "jdow" jdow@earthlink.net
Search for: vncserver fedora-users
Make that vncserver fedora-list.
That should be a workable example. {^_^}
Forgot where I was at the time.
---- the site: option is much more targeted...
site:https://www.redhat.com/archives/fedora-list/
is a bullet to searching this list on google
Craig
From: "Craig White" craigwhite@azapple.com
On Wed, 2005-12-28 at 22:23 -0800, jdow wrote:
From: "jdow" jdow@earthlink.net
Search for: vncserver fedora-users
Make that vncserver fedora-list.
That should be a workable example. {^_^}
Forgot where I was at the time.
the site: option is much more targeted...
site:https://www.redhat.com/archives/fedora-list/
is a bullet to searching this list on google
Craig, this is an 'ix'-like operating system. Users are expected to abbreviate commands into oblivion, ls for list and ps for process status come to mind. I concluded long LONG ago it was because people could not type. (Hey, I sympathized with that concept, too!)
Your way is a LOT more typing than mine.
{^_-} <- winking and being silly.
On Wed, 2005-12-28 at 22:46 -0800, jdow wrote:
Craig, this is an 'ix'-like operating system. Users are expected to abbreviate commands into oblivion, ls for list and ps for process status come to mind. I concluded long LONG ago it was because people could not type. (Hey, I sympathized with that concept, too!)
Actually I think it was because storage space use to be extremely limited in original unix - so keeping commands short saved extra bits in scripting.
On Thu, 2005-12-29 at 04:30, Michael A. Peters wrote:
Craig, this is an 'ix'-like operating system. Users are expected to abbreviate commands into oblivion, ls for list and ps for process status come to mind. I concluded long LONG ago it was because people could not type. (Hey, I sympathized with that concept, too!)
Actually I think it was because storage space use to be extremely limited in original unix - so keeping commands short saved extra bits in scripting.
Remember that input devices were mechanical 300 baud tty's (printer, keyboard, no video CRT) in those days. Typing was not fun; making corrections even less so.
From: "Les Mikesell" lesmikesell@gmail.com
On Thu, 2005-12-29 at 04:30, Michael A. Peters wrote:
Craig, this is an 'ix'-like operating system. Users are expected to abbreviate commands into oblivion, ls for list and ps for process status come to mind. I concluded long LONG ago it was because people could not type. (Hey, I sympathized with that concept, too!)
Actually I think it was because storage space use to be extremely limited in original unix - so keeping commands short saved extra bits in scripting.
Remember that input devices were mechanical 300 baud tty's (printer, keyboard, no video CRT) in those days. Typing was not fun; making corrections even less so.
NOW we know who some of the real old timers are.
{^_-} Don't even fit that tee-shirt anymore.
jdow wrote:
From: "Les Mikesell" lesmikesell@gmail.com
On Thu, 2005-12-29 at 04:30, Michael A. Peters wrote:
Craig, this is an 'ix'-like operating system. Users are expected to
abbreviate commands into oblivion, ls for list and ps for process
status
come to mind. I concluded long LONG ago it was because people could
not
type. (Hey, I sympathized with that concept, too!)
Actually I think it was because storage space use to be extremely limited in original unix - so keeping commands short saved extra bits in scripting.
Remember that input devices were mechanical 300 baud tty's (printer, keyboard, no video CRT) in those days. Typing was not fun; making corrections even less so.
Only the newer teletypes run at 300. ;-) I worked with some that used current loop and slower speeds 28.8, 38.4, 110 baud. Let's not paper tape for storage.
On 12/29/05, Neil Cherry ncherry@comcast.net wrote:
jdow wrote:
From: "Les Mikesell" lesmikesell@gmail.com
On Thu, 2005-12-29 at 04:30, Michael A. Peters wrote:
Craig, this is an 'ix'-like operating system. Users are expected
to
abbreviate commands into oblivion, ls for list and ps for process
status
come to mind. I concluded long LONG ago it was because people could
not
type. (Hey, I sympathized with that concept, too!)
Actually I think it was because storage space use to be extremely limited in original unix - so keeping commands short saved extra bits
in
scripting.
Remember that input devices were mechanical 300 baud tty's (printer, keyboard, no video CRT) in those days. Typing was not fun; making corrections even less so.
Only the newer teletypes run at 300. ;-) I worked with some that used current loop and slower speeds 28.8, 38.4, 110 baud. Let's not paper tape for storage.
--
Not to make anyone feel bad but the only teletypes I remember were the ones my Dad worked on when he was on ship in the Navy!
However, I acutally came on to say thanks for the google search tip. That has already helped me out a ton in 2 hours.
Usually when I come on for help I am looking for pointers, cause I want to find out and fix on my own - I just have no idea where to go. Googling usually doesn't help either.
Thanks.
JT
On Thu, 2005-12-29 at 18:42 +0100, Jeremy Thompson wrote:
Not to make anyone feel bad but the only teletypes I remember were the ones my Dad worked on when he was on ship in the Navy!
However, I acutally came on to say thanks for the google search tip. That has already helped me out a ton in 2 hours.
I think my dad used them - I don't remember them though. I do remember he had a bunch of programs on punch cards, and still does - though he has started raiding them to use as note paper.
I also remember he had a ?? 300baud acoustic coupler that he would use to dial his terminal in to the Berkeley game machine so that we could play Adventure and Rogue and Wumpus :D
OK - most of the time he used it to dial in to do work, but many nights he let us play.
Michael A. Peters wrote:
I think my dad used them - I don't remember them though. I do remember he had a bunch of programs on punch cards, and still does
- though he has started raiding them to use as note paper.
I also remember he had a ?? 300baud acoustic coupler that he would use to dial his terminal in to the Berkeley game machine so that we could play Adventure and Rogue and Wumpus :D
OK - most of the time he used it to dial in to do work, but many nights he let us play.
The first system here was the first working (for a living) computer. It was built in Australia and was used for astronomy and other tasks for some years.
http://images.google.com/imgres?imgurl=http://www.lemis.com/grog/Photos/2004... http://www.lemis.com/grog/Photos-20040904.html
The first machine I wrote programs for was a CDC 3200, also pictured. Ours was located in Perth, highlights were: 32K (kilybytes) of 24-bit words, core memory 6-8 7-track tape drives Card reader Card punch paper tape reader paper tape punch No disk 500 LPM drum printer.
I worked at the Commonwealth Bureau of Census and Statistics. We shared our equipment with Tax and Treasury.
Later I worked at the department of Social Services (Security), and IBM customer. Here's a list of IBM kit: http://www-03.ibm.com/ibm/history/exhibits/mainframe/mainframe_album.html
When I arrived we had S/360 model 16 (three or four), model 40 (2), model 65 (1) and also used Health's pair of '65s. We had disk (29 Mb 2314s on the '65, 13 Mb 2311s and some 2314s on the 40s), 9-track tape, chain! printers, a few 2260s (CRT displays, very swish then, very primitive now) on the 65.
This was in '71. When Health ordered the 65s there were very serious kit indeed. Ours had 512 Kb RAM, theirs would have been similar.
mid 70s we upgraded, finishing with 3x 135s, 2x 145s and a pair of 168s in Canberra. We had umpteen 100 Mb DASD (disks) (maybe as many as 48), 20 or so tapes, one of the 168s had 6 Mbytes of RAM (4K dynamic for those who remember, done up on big boards and using ECC), a 2350 "drum" (really 2 heads/track 11 Mb disk)
Here's a pic of a 168 configuration: http://www-03.ibm.com/ibm/history/exhibits/mainframe/mainframe_2423PH3168.ht...
On the (viewer's) left are some tape drives (they'd be 3420s, 9-track 6250 BPI) and a couple of dunnos (one may be a channel, a device that controls the physical connexion between host CPU and device controller) Foreground, left looks like punch card equipment, behind that 1 3270 terminal and right down the back is (probably) a controller. Centre, back, several boxes making up the computer itself: each box might contain a Mbyte of RAM or some other component. In front of that is the operator console (roughly ell-shaped) including a fine array of blinkenlights, switches, knobs and an uncovered button to IPL (boot) the system.
Those boxes at the back are about 2 metres high: I'm 190 cm and had to jump to see on top.
Foreground to the right are two 1100 LPM chain printers, and at the side a few 3330-1 (100 Mb) disk drives, a controller and a dunno.
About this time IBM was the largest computer company in the world, DEC was second.
jdow wrote:
Craig, this is an 'ix'-like operating system. Users are expected to abbreviate commands into oblivion, ls for list and ps for process status come to mind. I concluded long LONG ago it was because people could not type. (Hey, I sympathized with that concept, too!)
Your way is a LOT more typing than mine.
{^_-} <- winking and being silly.
and only references one archive.
On Fri, 2005-12-30 at 07:42 +0800, John Summerfied wrote:
jdow wrote:
Craig, this is an 'ix'-like operating system. Users are expected to abbreviate commands into oblivion, ls for list and ps for process status come to mind. I concluded long LONG ago it was because people could not type. (Hey, I sympathized with that concept, too!)
Your way is a LOT more typing than mine.
{^_-} <- winking and being silly.
and only references one archive.
---- yes but it was this specific archive that one wanted to search or more specifically, one particular person felt that Red Hat was deficient because they didn't provide much of a search interface for searching the archives of a specific list.
My point was that it was unnecessary, if you know how to use google, you can easily search one specific archive.
Craig
Charles Howse wrote:
Rumor has it that Google will search into the archives. Experience bears out the rumors. (People who can tolerate Bugzilla also cite using Google as a surrogate search engine for Bugzilla. That might make that horrid, ugly, annoying tool (I'm being kind) almost bearable, too.)
Would you please give an example of a Google search through this list's archives?
If I had a problem with vnc on FC then I'd likely google for vnc fedora which would likely turn up hits on and off the list. I rarely search any list for anything because there's a lot of good info elsewhere, but the dirty old woman's idea is fine for searching the list archives.
On 12/28/05, Ow Mun Heng Ow.Mun.Heng@wdc.com wrote:
On Wed, 2005-12-28 at 19:58 -0800, Charles Heselton wrote:
[mailto:fedora-list-bounces@redhat.com] On Behalf Of Charles Howse
*Most* people answer, if they know. Or point if they can. What I've found, is that at least 2 out of 3 times, when I go to google someone's problem, the answer is usually in the top 10 links found. For people that are particularly active on lists, this can be frustrating.
yes. This is very true. And bear in mind that perhaps as much/as less as 50% of people in this list actually do take the time to solve the issues for you. They're not support staff but they do it out of wanting to help.
The manner in this the question is asked is also pertinent to getting some answers. eg: They would have liked for the OP to at least have researched the question by themselves (no spoon feed) with a min of google (though of course the sequence/choice of search parameters will make/break the query) and perhaps some archive searching. (eg: like me, I have like 2 years worth of List archive which I consult before shooting an email to the list. That and the fact that I don't have I-net access at work, (only email ), so I make that clear as well.)
That's my 2 cents.
Much of this bashing would be alleviated if Red Hat, a publically held and for-profit company, put some real effort into incorporating a decent search engine for the archives.
BIG, BIG, BIG AMEN!!!
Anyone know why a good search engine isn't part of the mailing list? Although in all fairness google also searches public mailing lists.
On Wed, 2005-12-28 at 20:32 -0800, Kam Leo wrote:
On 12/28/05, Ow Mun Heng Ow.Mun.Heng@wdc.com wrote:
On Wed, 2005-12-28 at 19:58 -0800, Charles Heselton wrote:
[mailto:fedora-list-bounces@redhat.com] On Behalf Of Charles Howse
*Most* people answer, if they know. Or point if they can. What I've found, is that at least 2 out of 3 times, when I go to google someone's problem, the answer is usually in the top 10 links found. For people that are particularly active on lists, this can be frustrating.
yes. This is very true. And bear in mind that perhaps as much/as less as 50% of people in this list actually do take the time to solve the issues for you. They're not support staff but they do it out of wanting to help.
The manner in this the question is asked is also pertinent to getting some answers. eg: They would have liked for the OP to at least have researched the question by themselves (no spoon feed) with a min of google (though of course the sequence/choice of search parameters will make/break the query) and perhaps some archive searching. (eg: like me, I have like 2 years worth of List archive which I consult before shooting an email to the list. That and the fact that I don't have I-net access at work, (only email ), so I make that clear as well.)
That's my 2 cents.
Much of this bashing would be alleviated if Red Hat, a publically held and for-profit company, put some real effort into incorporating a decent search engine for the archives.
---- This would be especially helpful for whiners who don't know how to search I would suppose.
Craig
On Wed, 2005-12-28 at 19:58 -0800, Charles Heselton wrote:
[mailto:fedora-list-bounces@redhat.com] On Behalf Of Charles Howse
*Most* people answer, if they know. Or point if they can. What I've found, is that at least 2 out of 3 times, when I go to google someone's problem, the answer is usually in the top 10 links found. For people that are particularly active on lists, this can be frustrating.
yes. This is very true. And bear in mind that perhaps as much/as less as 50% of people in this list actually do take the time to solve the issues for you. They're not support staff but they do it out of wanting to help.
And that is very much appreciated. :-)
The manner in this the question is asked is also pertinent to getting some answers. eg: They would have liked for the OP to at least have researched the question by themselves (no spoon feed) with a min of google (though of course the sequence/choice of search parameters will make/break the query) and perhaps some archive searching. (eg: like me, I have like 2 years worth of List archive which I consult before shooting an email to the list. That and the fact that I don't have I-net access at work, (only email ), so I make that clear as well.)
But is it mandatory for me to list the research I've done and the results? I would hope not. Maybe I've gone off on a tangent in my research, or don't know how to Google as well as someone else? Is that a reason to RTFM me?
Charles Howse wrote:
But is it mandatory for me to list the research I've done and the results? I would hope not. Maybe I've gone off on a tangent in my research, or don't know how to Google as well as someone else? Is that a reason to RTFM me?
"Mandatory" isn't a helpful word, I think. It isn't mandatory for you to post or me to answer.
It's just that, out of courtesy to those who do try to help, it's nice if you can specify what you've done so they don't waste everyone's time suggesting it again.
But there are other factors as well. If you've gone off on a tangent, then that means your mental model of what's going on isn't accurate. You may find that the response says something like "don't worry about the BIOS, Linux sets this up for itself". That might tell you more about how hardware gets set up, and what has responsibility for what. It will give you a much better mental model for troubleshooting in the future.
If you don't mention the BIOS, then you still might think that what the BIOS says is necessarily accurate (for example).
If you can't Google, that is a problem. But the response might say "I googled on '"foo bar" --widget', WITH the double quotes". That might show you, by example, how to Google better.
And that *is* a life skill worth learning.
Hope this helps,
James.
James Wilkinson wrote:
Charles Howse wrote:
But is it mandatory for me to list the research I've done and the results? I would hope not. Maybe I've gone off on a tangent in my research, or don't know how to Google as well as someone else? Is that a reason to RTFM me?
"Mandatory" isn't a helpful word, I think. It isn't mandatory for you to post or me to answer.
[snip]
Nice answer. Another way to answer this is
YOU are the one trying to convince me to donate my most precious resource, my time, to you free of charge. Why should you expect that I would make that donation if you are unwilling to expend your OWN time trying to answer your question. So, show me that you are interested enough in your problem to expend some of your own resources, and THEN I'll be willing to expend some of mine.
Mike
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
-----Original Message----- From: fedora-list-bounces@redhat.com [mailto:fedora-list-bounces@redhat.com] On Behalf Of Charles Howse Sent: Wednesday, December 28, 2005 7:38 PM To: Fedora Subject: Why questions don't get answered, or "No, I've already RTFM, tell me the answer!"
I'd like to start a calm, respectful, reasonable discussion of the reasons that we tell people to RTFM, or reasons that people don't get their questions answered on mailing lists and usenet groups.
I'm not complaining about anything or anybody, just wanting to start some discussion which might lead to more answers and less 'noise'.
No one has been disrespectful to me, don't get the wrong idea.
I personally am a former Microsoft Certified Professional in NT Server 4.0, have used operating systems including, PC DOS, MS DOS, OS/2 Warp, all flavors of Windows through XP Pro (except ME, which sucked sooo bad), Linux, FreeBSD, and currently, Mac OS X Tiger.
I've administered networks consisting of hundreds of workstations and dozens of servers, installed lans and wans from scratch, taught Windows operating systems, software and networking.
I feel that might just barely qualify me as knowing a little about computers, and I say that seriously...'a little'.
I know how you feel. ;-)
There are a lot of things I don't know, and when I run out of research options, or get frustrated when all the troubleshooting solutions don't work, I'm heading for usenet or a mailing list, because time after time, that has been the resource that provided the solution. A wise man once told me, "Someone out there has solved that problem, you just have to find them."
I don't really know where to start, so here are some random thoughts...
Maybe I got told to RTFM because I missed something in it? Well, could you just politely point me to the section I missed, please? Or give me a link to a howto or some html page where it is explained?
Maybe the question has been answered in the FAQ for the list? Just point me to it, you don't have to say anything else.
I've seen lots of posts to this list and others with no subject or a subject that has nothing to do with the question, but the question was answered respectfully. So, when I post with a good subject, one that will show up in a Google search, help me out.
Many lists and groups regularly autopost the guidelines for posting, FAQ, and relevant howto pages, point me to those when necessary.
Someone used the phrase 'spoon feed' recently. I don't remember who, nor is it important, but what's wrong with a spoon full of sugar now and then? And why would you ignore a reasonable question unless you don't know the answer?
Is replying to say "I don't know" any more constructive than ignoring the question? At the least it lets the OP know that the mail was received, but really, that's about it.
For clarity, what I mean is, if I ask a question, and you know the answer, but it has been asked and answered many times, I would prefer to hear: "That question is answered in the list FAQ, which is here <link>." If you know the answer, but ignore the question because it is in the FAQ, then aren't you increasing bandwidth consumption by causing the thread to continue?
I think the members of this list are mostly doing things the way I would like to see them done, but I also think we could all do better, eh?
I don't mean to step on any toes, just want to start some discussion. Does anyone else have any thoughts on why questions don't get the respectful treatment they deserve?
-- Thanks, Charles
While I agree with you on the general gist of what you're saying, I think that the people who are behaving negatively on lists are people who are demanding attention. *Most* people answer, if they know. Or point if they can. What I've found, is that at least 2 out of 3 times, when I go to google someone's problem, the answer is usually in the top 10 links found. For people that are particularly active on lists, this can be frustrating.
I agree 100%, with the exception that I would prefer to hear: "I Googled for +"Fedora Core 4" +install" and the answer is..." That helps me learn how to do my own Googling and come away with answers.
This list in particular seems to be relatively well behaved, although, I don't follow it as closely as I used to (switched distros). So I'm a little curious why you're asking these questions now.
Ummmm...well, I just did a lot of research on some list archives, including this one, and there seemed to me to be a lot of negative responses. Now the worst list I've ever subscribed to as far as negative response and RTFM was freebsd-questions. Whew! Better put on your asbestos underwear and list all your research before you post there!
On 12/28/05, Charles Howse chowse@charter.net wrote:
[snip]
For clarity, what I mean is, if I ask a question, and you know the answer, but it has been asked and answered many times, I would prefer to hear: "That question is answered in the list FAQ, which is here <link>." If you know the answer, but ignore the question because it is in the FAQ, then aren't you increasing bandwidth consumption by causing the thread to continue?
This list does not have a FAQ. The main Fedora Core website does not have one. Fedora Forum has a FAQ but the main site does not direct FC4 users to there. Kind of dysfunctional, no?
Kam Leo wrote:
On 12/28/05, Charles Howse chowse@charter.net wrote:
[snip]
For clarity, what I mean is, if I ask a question, and you know the answer, but it has been asked and answered many times, I would prefer to hear: "That question is answered in the list FAQ, which is here <link>." If you know the answer, but ignore the question because it is in the FAQ, then aren't you increasing bandwidth consumption by causing the thread to continue?
This list does not have a FAQ. The main Fedora Core website does not have one. Fedora Forum has a FAQ but the main site does not direct FC4 users to there. Kind of dysfunctional, no?
http://fedoraproject.org/wiki/FAQ is clearly pointed to from http://fedoraproject.org/ http://fedoraproject.org/ is clearly pointed to from http://fedora.redhat.com/
http://fedoraproject.org/wiki/FAQ points to other FAQ and forum-type resources, including http://fedoraforum.org/
http://fedora.redhat.com/About/FAQ.html (less useful) has a clear pointer in the top-right corner of every page of http://fedora.redhat.com/
There are tons of other interconnected pointers all over the place to help people get where they need to go.
From: "Patrick Barnes" nman64@n-man.com
You meantion all manner of interconnected links. You DID read that the Fedora site was being upgraded and had lost all its links a few days ago, dincha?
We may all have to update our "FM" locations.
{^_-}
jdow wrote:
From: "Patrick Barnes" nman64@n-man.com
You meantion all manner of interconnected links. You DID read that the Fedora site was being upgraded and had lost all its links a few days ago, dincha?
We may all have to update our "FM" locations.
{^_-}
I refer to the current revisions. The links that fedora.redhat.com "lost" were dead or outdated ones. The links that remain are, for the most part, up-to-date and point to the correct and current locations. The new Fedora home - fedoraproject.org - has plenty of good links. As one of the people involved in that refitting, I have a pretty good idea of what is where. ;-)
Hi
This list does not have a FAQ. The main Fedora Core website does not have one. Fedora Forum has a FAQ but the main site does not direct FC4 users to there. Kind of dysfunctional, no?
http://fedoraproject.org/wiki/FAQ http://fedoraproject.org/wiki/MailinglistGuidelines
<snip>
I have a couple of thoughts on things raised in this thread:
1. When I first became a *NIX admin I went from being an assembly language programmer of code for embedded systems to administrating a system running 4.1a BSD. What saved my bacon was the KWIC index (KeyWord In Context) for the BSD man pages and documents.
I believe that some sort of comprehensive index to the Linux man pages and the LDP generated docs would allow many people to resolve their own issues. I do not know if ptx(1) would meet this need, but something like a KWIC index for the Linux documents would be of huge assistance.
2. In a past job I had occasion to give a bit of a class to new system administrators titled something like "Host Based Diagnosis of Network Problems." The part of the information which seemed to be most helpful was telling these admins was for any problem reported to them was to insist on details indicating a fault . This included a precise description of what the user was doing when the fault occurred, the precise text of any error messages received, and any log entries which resulted. There was some complaints that the users would know into which log files to look.
On that point all I could say was a computer is just a tool and people should know the rudiments of using their tools and that includes documentation, where the log files are and generally what type of logs go in which log files. Syslog.conf is a key resource to figure that out. Now "mere users" can't read the logs, usually, but on this list people can read logs for the most part.
It occurs to me that people who ask for help should do these things at a minimum. Precision is important, it is a great assistance to those of us who might help. It is key that we who try to help should not have to spend a lot of time trying to figure out what question is really being asked. Usually there multiple possible causes, so multiple possible responses. Make it easy on us, and you will get quicker and more accurate answer to questions.
dlg
Charles Heselton wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
-----Original Message----- From: fedora-list-bounces@redhat.com [mailto:fedora-list-bounces@redhat.com] On Behalf Of Charles Howse Sent: Wednesday, December 28, 2005 7:38 PM To: Fedora Subject: Why questions don't get answered, or "No, I've already RTFM, tell me the answer!"
[snip]
And why would you ignore a reasonable question unless you don't know the answer?
Is replying to say "I don't know" any more constructive than ignoring the question? At the least it lets the OP know that the mail was received, but really, that's about it.
[snip]
Only if it is a question which the responder has reason to believe that very few know the answer, and is trying to redirect the poster either in posing a better question, or to another echo.
Mike
From: "Charles Howse" chowse@charter.net
I'd like to start a calm, respectful, reasonable discussion of the reasons that we tell people to RTFM, or reasons that people don't get their questions answered on mailing lists and usenet groups.
I'm not complaining about anything or anybody, just wanting to start some discussion which might lead to more answers and less 'noise'.
When someone says "RTFM" it behooves them to point out which M contains the good data.
{^_-}
On Wed, 2005-12-28 at 21:37, Charles Howse wrote:
I don't mean to step on any toes, just want to start some discussion. Does anyone else have any thoughts on why questions don't get the respectful treatment they deserve?
Usually if the answer doesn't fit in a short paragraph the best you are likely to get on a list like this is a pointer to the full version. The discussions tend to revolve around things that are wrong in the references or what has changed recently, not repeating what is already available elsewhere. If you describe a specific step that didn't work the way you expected you'll probably get help with it.
On Wed, 2005-12-28 at 21:37 -0600, Charles Howse wrote:
I'd like to start a calm, respectful, reasonable discussion of the reasons that we tell people to RTFM, or reasons that people don't get their questions answered on mailing lists and usenet groups.
I'm not complaining about anything or anybody, just wanting to start some discussion which might lead to more answers and less 'noise'.
No one has been disrespectful to me, don't get the wrong idea.
I personally am a former Microsoft Certified Professional in NT Server 4.0, have used operating systems including, PC DOS, MS DOS, OS/2 Warp, all flavors of Windows through XP Pro (except ME, which sucked sooo bad), Linux, FreeBSD, and currently, Mac OS X Tiger.
I've administered networks consisting of hundreds of workstations and dozens of servers, installed lans and wans from scratch, taught Windows operating systems, software and networking.
I feel that might just barely qualify me as knowing a little about computers, and I say that seriously...'a little'.
There are a lot of things I don't know, and when I run out of research options, or get frustrated when all the troubleshooting solutions don't work, I'm heading for usenet or a mailing list, because time after time, that has been the resource that provided the solution. A wise man once told me, "Someone out there has solved that problem, you just have to find them."
I don't really know where to start, so here are some random thoughts...
Maybe I got told to RTFM because I missed something in it? Well, could you just politely point me to the section I missed, please? Or give me a link to a howto or some html page where it is explained?
Maybe the question has been answered in the FAQ for the list? Just point me to it, you don't have to say anything else.
I've seen lots of posts to this list and others with no subject or a subject that has nothing to do with the question, but the question was answered respectfully. So, when I post with a good subject, one that will show up in a Google search, help me out.
Many lists and groups regularly autopost the guidelines for posting, FAQ, and relevant howto pages, point me to those when necessary.
Someone used the phrase 'spoon feed' recently. I don't remember who, nor is it important, but what's wrong with a spoon full of sugar now and then? And why would you ignore a reasonable question unless you don't know the answer?
I think the members of this list are mostly doing things the way I would like to see them done, but I also think we could all do better, eh?
I don't mean to step on any toes, just want to start some discussion. Does anyone else have any thoughts on why questions don't get the respectful treatment they deserve?
---- 1 - this is a voluntary list and thus responders offer their time without compensation. No answers are to be expected at all.
2 - if you can concisely describe the problem, you are more likely to get an answer. You are verbose which will always diminish the likelihood of an answer.
3 - A few replies that state roughly, RTFM reflect the opinion of the responder...it may or may not be fair, they are what they are.
4 - this is a high traffic list and sometimes messages are lost in the deluge
5 - there is a general type of guideline for open source questions... http://www.catb.org/~esr/faqs/smart-questions.html
It's harsh but pretty much on target
Craig
On Wed, 2005-12-28 at 21:37 -0600, Charles Howse wrote:
I'd like to start a calm, respectful, reasonable discussion of the reasons that we tell people to RTFM, or reasons that people don't get their questions answered on mailing lists and usenet groups.
I'm not complaining about anything or anybody, just wanting to start some discussion which might lead to more answers and less 'noise'.
No one has been disrespectful to me, don't get the wrong idea.
I personally am a former Microsoft Certified Professional in NT Server 4.0, have used operating systems including, PC DOS, MS DOS, OS/2 Warp, all flavors of Windows through XP Pro (except ME, which sucked sooo bad), Linux, FreeBSD, and currently, Mac OS X Tiger.
I've administered networks consisting of hundreds of workstations and dozens of servers, installed lans and wans from scratch, taught Windows operating systems, software and networking.
I feel that might just barely qualify me as knowing a little about computers, and I say that seriously...'a little'.
There are a lot of things I don't know, and when I run out of research options, or get frustrated when all the troubleshooting solutions don't work, I'm heading for usenet or a mailing list, because time after time, that has been the resource that provided the solution. A wise man once told me, "Someone out there has solved that problem, you just have to find them."
I don't really know where to start, so here are some random thoughts...
Maybe I got told to RTFM because I missed something in it? Well, could you just politely point me to the section I missed, please? Or give me a link to a howto or some html page where it is explained?
Maybe the question has been answered in the FAQ for the list? Just point me to it, you don't have to say anything else.
I've seen lots of posts to this list and others with no subject or a subject that has nothing to do with the question, but the question was answered respectfully. So, when I post with a good subject, one that will show up in a Google search, help me out.
Many lists and groups regularly autopost the guidelines for posting, FAQ, and relevant howto pages, point me to those when necessary.
Someone used the phrase 'spoon feed' recently. I don't remember who, nor is it important, but what's wrong with a spoon full of sugar now and then? And why would you ignore a reasonable question unless you don't know the answer?
I think the members of this list are mostly doing things the way I would like to see them done, but I also think we could all do better, eh?
I don't mean to step on any toes, just want to start some discussion. Does anyone else have any thoughts on why questions don't get the respectful treatment they deserve?
1 - this is a voluntary list and thus responders offer their time without compensation. No answers are to be expected at all.
Then what is the purpose of the list? The title of the subscribe page says, "For users of Fedora Core releases." It doesn't say not to expect any answers.
2 - if you can concisely describe the problem, you are more likely to get an answer. You are verbose which will always diminish the likelihood of an answer.
I can't think of a concise way to reply to that. ;-) Perhaps I am too wordy...but...isn't it better to list everything I've tried that didn't work, rather than just say, "Why isn't <this> working?"
3 - A few replies that state roughly, RTFM reflect the opinion of the responder...it may or may not be fair, they are what they are.
I guess that's fair.
4 - this is a high traffic list and sometimes messages are lost in the deluge
Fair again.
5 - there is a general type of guideline for open source questions... http://www.catb.org/~esr/faqs/smart-questions.html
It's harsh but pretty much on target
I've read that...a good while ago. Didn't memorize it, but have bookmarked it.
Craig
On Wed, 2005-12-28 at 22:50 -0600, Charles Howse wrote:
I don't mean to step on any toes, just want to start some discussion. Does anyone else have any thoughts on why questions don't get the respectful treatment they deserve?
1 - this is a voluntary list and thus responders offer their time without compensation. No answers are to be expected at all.
Then what is the purpose of the list? The title of the subscribe page says, "For users of Fedora Core releases." It doesn't say not to expect any answers.
---- that's the purpose - but there is absolutely no reason to expect answers since the answers can only come from volunteers on their own time. If you want a supported Linux where you can expect to get answers to your questions, RHEL is for you. ----
2 - if you can concisely describe the problem, you are more likely to get an answer. You are verbose which will always diminish the likelihood of an answer.
I can't think of a concise way to reply to that. ;-) Perhaps I am too wordy...but...isn't it better to list everything I've tried that didn't work, rather than just say, "Why isn't <this> working?"
---- A post that has too much information will likely get passed over - that's a fact. If you want an answer to your question, state your question as succinctly as possible. If you want sympathy for your confusion, post in volume.
Craig
----- Original Message ----- From: "Charles Howse" chowse@charter.net
On Wed, 2005-12-28 at 21:37 -0600, Charles Howse wrote:
I'd like to start a calm, respectful, reasonable discussion of the reasons that we tell people to RTFM, or reasons that people don't get their questions answered on mailing lists and usenet groups.
I'm not complaining about anything or anybody, just wanting to start some discussion which might lead to more answers and less 'noise'.
No one has been disrespectful to me, don't get the wrong idea.
I personally am a former Microsoft Certified Professional in NT Server 4.0, have used operating systems including, PC DOS, MS DOS, OS/2 Warp, all flavors of Windows through XP Pro (except ME, which sucked sooo bad), Linux, FreeBSD, and currently, Mac OS X Tiger.
I've administered networks consisting of hundreds of workstations and dozens of servers, installed lans and wans from scratch, taught Windows operating systems, software and networking.
I feel that might just barely qualify me as knowing a little about computers, and I say that seriously...'a little'.
There are a lot of things I don't know, and when I run out of research options, or get frustrated when all the troubleshooting solutions don't work, I'm heading for usenet or a mailing list, because time after time, that has been the resource that provided the solution. A wise man once told me, "Someone out there has solved that problem, you just have to find them."
I don't really know where to start, so here are some random thoughts...
Maybe I got told to RTFM because I missed something in it? Well, could you just politely point me to the section I missed, please? Or give me a link to a howto or some html page where it is explained?
Maybe the question has been answered in the FAQ for the list? Just point me to it, you don't have to say anything else.
I've seen lots of posts to this list and others with no subject or a subject that has nothing to do with the question, but the question was answered respectfully. So, when I post with a good subject, one that will show up in a Google search, help me out.
Many lists and groups regularly autopost the guidelines for posting, FAQ, and relevant howto pages, point me to those when necessary.
Someone used the phrase 'spoon feed' recently. I don't remember who, nor is it important, but what's wrong with a spoon full of sugar now and then? And why would you ignore a reasonable question unless you don't know the answer?
I think the members of this list are mostly doing things the way I would like to see them done, but I also think we could all do better, eh?
I don't mean to step on any toes, just want to start some discussion. Does anyone else have any thoughts on why questions don't get the respectful treatment they deserve?
1 - this is a voluntary list and thus responders offer their time without compensation. No answers are to be expected at all.
Then what is the purpose of the list? The title of the subscribe page says, "For users of Fedora Core releases." It doesn't say not to expect any answers.
2 - if you can concisely describe the problem, you are more likely to get an answer. You are verbose which will always diminish the likelihood of an answer.
I can't think of a concise way to reply to that. ;-) Perhaps I am too wordy...but...isn't it better to list everything I've tried that didn't work, rather than just say, "Why isn't <this> working?"
3 - A few replies that state roughly, RTFM reflect the opinion of the responder...it may or may not be fair, they are what they are.
I guess that's fair.
4 - this is a high traffic list and sometimes messages are lost in the deluge
Fair again.
5 - there is a general type of guideline for open source questions... http://www.catb.org/~esr/faqs/smart-questions.html
It's harsh but pretty much on targetI've read that...a good while ago. Didn't memorize it, but have bookmarked it.
Craig
Charles, several reasons for not getting an answer exist. I know I have many reasons for not answering. Many of those reasons mean I don't answer many questions I know how to answer. Some of those reasons are a rather harsh reflection on this list. I may and may not include them below depending on whether I can get my armored undies out of the drier in time. But one of the chief reasons I don't answer is that I do not read the list very much. Frankly I see too many repeated questions, some regarding information that was just discussed at depth for several days in the last week ending hours before the question was posted.
1) If you expect God to create a miracle so that you win the lottery you need to give God some material with which to work, Invest in the lottery. The Q&A lottery on this list requires investing some information in the queries. "I can't get my Fubaracity2 IEEE1394 to be recognized as a proper 132 channel sound card. Help!" That's not enough investment. Give us something to work with. At LEAST give us some error messages. It also helps to mention some of the steps you've already been through.
2) Do Google for answers. It can save you from the need to wipe that icky egg off your face when the answer was very easily available. And if you get no answers specifically add this list, "fedora-users", to the query. That seems to wake up Google sometimes. (in a silly voice she says, "Gee, I dunno why but sometimes it works." {o.o})
3) Commonly used items have enough users that you can get answers far quicker than with that Fubaracity2 device above. In this case no response means everybody reading the question has avoided an AOL response, "I dunno!" followed by 203 "Me too!" responses and 1816 other "I dunno!" responses.
4) The list is busy. I scan it. If a problem is common I'll often make the rash assumption that someone else either has already answered it or will "RSN." This happens when I am otherwise rather busy.
5) If I don't think I have a pretty good answer I opt to seem wiser than I am by not saying anything. (<harsh 1>Even when I do have a pretty good answer people with rather poor answers will often shout me down. Thus is the Fedora-users list. It's why I only scan it.</harsh>
6) Even when I think I have a "pretty good" answer I will hang back if I suspect there is an even better answer. I watch for that answer. If it really is good I add it to my bag of tricks. Otherwise I try to chip in with a brief description of my way.
7) If I really DO get moved to make a serious answer to a large problem I am prone to waxing rather prolix. This message is an example. It is often better to avoid motivating Joanne to a "big answer." {^_-} This falls back on "silence makes me seem wiser than I am."
8) <harsh 2>In some cases, particularly when I've been shouted down, I have quite literally cringed at the competing solutions promulgated and adopted by the questioner. This list is overloaded with mis- information from time to time. Some solutions work but have side effects "you don't really want and don't have to suffer." When that happens it leads me into a period of "why bother?"</harsh>
All that said, I made a remark earlier. "If you tell a critter to RTFM at least have the basic humanity to throw the poor fellow a bone and tell him which manual is worth reading." <harsh 3>I take a bare RTFM response as an indication that the responder doesn't know crap and is trying to hide that fact.</harsh>
Now watch Joanne get flamed for daring to comment that this list is one of the most hostile areas outside of UseNet itself.
{o.o} Joanne said all that.
Dude, OT, but WinME is the only version of Windows that I liked besdies 3.11(now I am a Fedora guy)
On 12/28/05, Charles Howse chowse@charter.net wrote:
I'd like to start a calm, respectful, reasonable discussion of the reasons that we tell people to RTFM, or reasons that people don't get their questions answered on mailing lists and usenet groups.
I'm not complaining about anything or anybody, just wanting to start some discussion which might lead to more answers and less 'noise'.
No one has been disrespectful to me, don't get the wrong idea.
I personally am a former Microsoft Certified Professional in NT Server 4.0 , have used operating systems including, PC DOS, MS DOS, OS/2 Warp, all flavors of Windows through XP Pro (except ME, which sucked sooo bad), Linux, FreeBSD, and currently, Mac OS X Tiger.
I've administered networks consisting of hundreds of workstations and dozens of servers, installed lans and wans from scratch, taught Windows operating systems, software and networking.
I feel that might just barely qualify me as knowing a little about computers, and I say that seriously...'a little'.
There are a lot of things I don't know, and when I run out of research options, or get frustrated when all the troubleshooting solutions don't work, I'm heading for usenet or a mailing list, because time after time, that has been the resource that provided the solution. A wise man once told me, "Someone out there has solved that problem, you just have to find them."
I don't really know where to start, so here are some random thoughts...
Maybe I got told to RTFM because I missed something in it? Well, could you just politely point me to the section I missed, please? Or give me a link to a howto or some html page where it is explained?
Maybe the question has been answered in the FAQ for the list? Just point me to it, you don't have to say anything else.
I've seen lots of posts to this list and others with no subject or a subject that has nothing to do with the question, but the question was answered respectfully. So, when I post with a good subject, one that will show up in a Google search, help me out.
Many lists and groups regularly autopost the guidelines for posting, FAQ, and relevant howto pages, point me to those when necessary.
Someone used the phrase 'spoon feed' recently. I don't remember who, nor is it important, but what's wrong with a spoon full of sugar now and then? And why would you ignore a reasonable question unless you don't know the answer?
I think the members of this list are mostly doing things the way I would like to see them done, but I also think we could all do better, eh?
I don't mean to step on any toes, just want to start some discussion. Does anyone else have any thoughts on why questions don't get the respectful treatment they deserve?
-- Thanks, Charles
-- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
-- As a boy I jumped through Windows, as a man I play with Penguins.
On 12/28/05, Charles Howse chowse@charter.net wrote:
There are a lot of things I don't know, and when I run out of research options, or get frustrated when all the troubleshooting solutions don't work, I'm heading for usenet or a mailing list, because time after time, that has been the resource that provided the solution. A wise man once told me, "Someone out there has solved that problem, you just have to find them."
You may also want to give irc://freenode/fedora a try for quick help. -- As a boy I jumped through Windows, as a man I play with Penguins.
On Wed, 2005-12-28 at 21:37 -0600, Charles Howse wrote:
I'd like to start a calm, respectful, reasonable discussion of the reasons that we tell people to RTFM, or reasons that people don't get their questions answered on mailing lists and usenet groups.
When I first started using Linux, there were several times when I tried to RTFM but completely failed. Often it was because I simply did not understand the manual.
This was with ppc so people were kinder because it was a smaller group, some people like ppc David Gatwood took time to help me out while a few others did tell me to RTFM - and that's probably what kept me in Linux.
Documentation is a mess. Many cli binaries don't have a man page, some man pages say look at the info documentation, some w/o man pages aren't even adequately documented in /usr/share/doc/package, many gui apps don't have scrollkeeper documentation, yelp doesn't display man or info (it use to), tetex has its own documentation system separate from man/info, documentation on the web is sometimes outdated or distro specific or wrong or bad advice, etc.
When documentation is a little better on the desktop (searchable man pages and searchable scrollkeeper, less documentation systems that the documentation might be stored as, etc.) there will probably be less of this issue.
I personally think every CLI executable in /usr/bin should have a man page, and every GUI app should have scrollkeeper documentation. yelp should support man pages (and perhaps an FAQ) and yelp should be searchable for all documentation it supports (not just the find widget that seems to only search through what it is viewing).
Plugins for yelp to allow it to extend to other documenation systems that really can't be done via man/scrollkeeper (like tetex) would be nice too, but I'm not holding my breath on that one.
On Wed, 2005-12-28 at 21:37 -0600, Charles Howse wrote:
I'd like to start a calm, respectful, reasonable discussion of the reasons that we tell people to RTFM, or reasons that people don't get their questions answered on mailing lists and usenet groups.
When I first started using Linux, there were several times when I tried to RTFM but completely failed. Often it was because I simply did not understand the manual.
My first experience with Linux was when I bought a book about Linux that contained Red Hat 5. Didn't know what a man page was until I finished reading the book. Today I am still dumbfounded sometimes by the lack of help contained in a man page, or by the over abundance of terms that I have to stop and look up, then try and understand whether that applies to my situation.
This was with ppc so people were kinder because it was a smaller group,
Yep, there's a ratio hiding in that statement somewhere...as the size of the group goes up, the kindness factor goes down..?
On Thu, 2005-12-29 at 09:07, Charles Howse wrote:
My first experience with Linux was when I bought a book about Linux that contained Red Hat 5. Didn't know what a man page was until I finished reading the book. Today I am still dumbfounded sometimes by the lack of help contained in a man page, or by the over abundance of terms that I have to stop and look up, then try and understand whether that applies to my situation.
You really have to understand what the shell does to every command line before starting a program before reading other man pages. The concepts of i/o redirection, wildcard filename expansion, and environment variable setting are not repeated in the man pages for every program even though they may be useful or even necessary. Man pages are meant to be a reference, not a tutorial. A tutorial should be a separate volume since you normally only need it once and never want to see it again while you may need the reference for obscure options later. Unfortunately, a tutorial doesn't exist for some programs you might want to use.
On Thu, 2005-12-29 at 09:07, Charles Howse wrote:
My first experience with Linux was when I bought a book about Linux that contained Red Hat 5. Didn't know what a man page was until I finished reading the book. Today I am still dumbfounded sometimes by the lack of help contained in a man page, or by the over abundance of terms that I have to stop and look up, then try and understand whether that applies to my situation.
You really have to understand what the shell does to every command line before starting a program before reading other man pages. The concepts of i/o redirection, wildcard filename expansion, and environment variable setting are not repeated in the man pages for every program even though they may be useful or even necessary. Man pages are meant to be a reference, not a tutorial. A tutorial should be a separate volume since you normally only need it once and never want to see it again while you may need the reference for obscure options later. Unfortunately, a tutorial doesn't exist for some programs you might want to use.
Agreed, but apply what you just said to someone who decides to trash Windows and start using Fedora for the first time.
There's lots of documentation on installing, so if they get it installed, I would think that they would have a tremendous amount of studying to do to become fairly competent. Troubleshooting can be a nightmare.
I don't want to take the thread off towards open-source vs. 'closed-source', but I think you will agree that there is a steep learning curve going from Windows to Linux. Probably not so steep if Linux is your first OS.
I guess I'm saying that there just has to be better help...onboard and online.
On Thu, 2005-12-29 at 11:27, Charles Howse wrote:
You really have to understand what the shell does to every command line before starting a program before reading other man pages. The concepts of i/o redirection, wildcard filename expansion, and environment variable setting are not repeated in the man pages for every program even though they may be useful or even necessary. Man pages are meant to be a reference, not a tutorial. A tutorial should be a separate volume since you normally only need it once and never want to see it again while you may need the reference for obscure options later. Unfortunately, a tutorial doesn't exist for some programs you might want to use.
Agreed, but apply what you just said to someone who decides to trash Windows and start using Fedora for the first time.
How would it work the other way around? Suppose you were having your first experience by installing windows and about 3,000 programs all at once. It doesn't usually happen that way because you buy the box with windows pre-installed and can't afford that many add-on programs at once.
There's lots of documentation on installing, so if they get it installed, I would think that they would have a tremendous amount of studying to do to become fairly competent. Troubleshooting can be a nightmare.
I don't want to take the thread off towards open-source vs. 'closed-source', but I think you will agree that there is a steep learning curve going from Windows to Linux. Probably not so steep if Linux is your first OS.
Windows and Linux are equally complex. If you are going to do something that doesn't 'just work' it is going to take some time. Visit the 'xxx for dummies' section about windows and it's various apps in any bookstore to see what it takes to get started. Sometimes an equivalent exists for Linux, sometimes it doesn't. Since you see those books everywhere they must sell, but the value seems questionable. You don't see people carrying them around for reference.
I guess I'm saying that there just has to be better help...onboard and online.
There is, but keep in mind the size of the content using the windows equivalents section of a large bookstore as a reference. Quite a bit of that does exist for the Linux versions, but you seem to be asking someone to have it all memorized and be able to quote massive sections on demand. It's one thing to say "I typed this command and got this error:... - has that happened to anyone else?" and something else to ask how to start something that needs a whole tutorial book to answer.
Of course when you ask the question, you may not know the complexity of the answer...
On Thu, 2005-12-29 at 11:27, Charles Howse wrote:
You really have to understand what the shell does to every command line before starting a program before reading other man pages. The concepts of i/o redirection, wildcard filename expansion, and environment variable setting are not repeated in the man pages for every program even though they may be useful or even necessary. Man pages are meant to be a reference, not a tutorial. A tutorial should be a separate volume since you normally only need it once and never want to see it again while you may need the reference for obscure options later. Unfortunately, a tutorial doesn't exist for some programs you might want to use.
Agreed, but apply what you just said to someone who decides to trash Windows and start using Fedora for the first time.
How would it work the other way around? Suppose you were having your first experience by installing windows and about 3,000 programs all at once. It doesn't usually happen that way because you buy the box with windows pre-installed and can't afford that many add-on programs at once.
Whew! I'd hate to know I had to spend that much time installing Windows apps. I think it's great that Linux comes with so many applications! But, since Linux is open-source, not everything works as expected, nor has sufficient documentation. Would you agree?
I don't want to take the thread off towards open-source vs. 'closed-source', but I think you will agree that there is a steep learning curve going from Windows to Linux. Probably not so steep if Linux is your first OS.
Windows and Linux are equally complex. If you are going to do something that doesn't 'just work' it is going to take some time. Visit the 'xxx for dummies' section about windows and it's various apps in any bookstore to see what it takes to get started. Sometimes an equivalent exists for Linux, sometimes it doesn't. Since you see those books everywhere they must sell, but the value seems questionable. You don't see people carrying them around for reference.
That's why I love my Mac. It 'just works', and it gives me all the great Unix tools. Yep, there's more Windows books in the stores than Linux, but Windows has a bigger share of the market, eh?
I guess I'm saying that there just has to be better help...onboard and online.
There is, but keep in mind the size of the content using the windows equivalents section of a large bookstore as a reference. Quite a bit of that does exist for the Linux versions, but you seem to be asking someone to have it all memorized and be able to quote massive sections on demand. It's one thing
Actually, I'm thinking the other way round on this. Sometimes, it seems like I'm required to have memorized everything I've ever read on the web and in print. Take for example, the smart-posting page referenced earlier; yeah, I read it...probably 2 years ago. I'm getting old, and can't remember that far back. ;-)
to say "I typed this command and got this error:... - has that happened to anyone else?" and something else to ask how to start something that needs a whole tutorial book to answer.
That's fair, but *really*, I don't post until I run out of reference options, or get frustrated after researching for a *long* time. If the tutorial exists, just point me to it. If it doesn't exist, we'll have to punt, eh?
Of course when you ask the question, you may not know the complexity of the answer...
No one can know everything, that's why we ask questions. :-)
On Thu, 2005-12-29 at 12:30, Charles Howse wrote:
How would it work the other way around? Suppose you were having your first experience by installing windows and about 3,000 programs all at once. It doesn't usually happen that way because you buy the box with windows pre-installed and can't afford that many add-on programs at once.
Whew! I'd hate to know I had to spend that much time installing Windows apps.
A few years back I bought one of those Dell specials that came bundled with win95 and a bunch of windows apps. It came with 21 CDs. Later I changed the hard drive and reinstalled everything with win98. It took 3 days and I'm not sure I had it all working at that point.
I think it's great that Linux comes with so many applications! But, since Linux is open-source, not everything works as expected, nor has sufficient documentation. Would you agree?
No, it isn't a symptom of being open source. It is more that you didn't pay someone to build and test your hardware with exactly the set of apps you need and pre-install most of it. If you google for any windows app and 'install problem' you'll find just as much trouble as anyone has with linux. If you look through Microsoft's knowledge base for problems you'll see they exist and things don't work as expected even on things that aren't open source. You just avoid a lot of the problems if you buy a pre-loaded, tested bundle. You can do approximately the same if you know someone with a system that already works the way you want by copying his exact hardware and software setup - and with free software it is even legal.
That's why I love my Mac. It 'just works', and it gives me all the great Unix tools.
Even there, you are just lucky - and you can expect to buy a new version of the software every year or so if you want to stay current. Macs rarely have to deal with the case of someone installing something that hasn't been tested under exactly the same hardware/OS combination - and I've had trouble with it anyway. My powerbook stopped talking to my firewire camcorder halfway through importing a tape. Several months and a few software updates later it worked again and there was nothing I could do meanwhile to fix it.
No one can know everything, that's why we ask questions. :-)
And no one can answer everything, so they tend to reply to things where they have recently solved the same problem. Thus 'I got this error...' is a good thing to include with the question.
On Thu, 2005-12-29 at 12:30 -0600, Charles Howse wrote:
On Thu, 2005-12-29 at 11:27, Charles Howse wrote:
You really have to understand what the shell does to every command line before starting a program before reading other man pages. The concepts of i/o redirection, wildcard filename expansion, and environment variable setting are not repeated in the man pages for every program even though they may be useful or even necessary. Man pages are meant to be a reference, not a tutorial. A tutorial should be a separate volume since you normally only need it once and never want to see it again while you may need the reference for obscure options later. Unfortunately, a tutorial doesn't exist for some programs you might want to use.
Agreed, but apply what you just said to someone who decides to trash Windows and start using Fedora for the first time.
How would it work the other way around? Suppose you were having your first experience by installing windows and about 3,000 programs all at once. It doesn't usually happen that way because you buy the box with windows pre-installed and can't afford that many add-on programs at once.
Whew! I'd hate to know I had to spend that much time installing Windows apps. I think it's great that Linux comes with so many applications! But, since Linux is open-source, not everything works as expected, nor has sufficient documentation. Would you agree?
The lack of ducumentation in some cases is true. However, How do you propose to change that?
Applications are written by a developer. From experience I know that it often takes more time to do good documentation than it does to develop the application. If the developer is doing the app on his own time (and most are) with limited time available, the part that often gets ignored is the documentation.
OTOH, commercial development software (usually closed source) depends on good documentation for their users. Sometimes more is spent on the documentation than on the actual coding of the product.
I don't know of any solution that will apply to the wealth of applications available from a multitude of sources except for users to step up and volunteer to assist the developers when a need is seen.
I guess I'm saying that there just has to be better help...onboard and online.
There is, but keep in mind the size of the content using the windows equivalents section of a large bookstore as a reference. Quite a bit of that does exist for the Linux versions, but you seem to be asking someone to have it all memorized and be able to quote massive sections on demand. It's one thing
Actually, I'm thinking the other way round on this. Sometimes, it seems like I'm required to have memorized everything I've ever read on the web and in print. Take for example, the smart-posting page referenced earlier; yeah, I read it...probably 2 years ago. I'm getting old, and can't remember that far back. ;-)
<rant> Many times the best answer is not a "here is the fix"; but rather a gentle nudge in the direction of a "how to do that" man page/web site/mail message/etc., in the tone of 'here you can learn more'.
It I can get a new user to think, try, and research instead of depending on the mail list for the smallest answer; then ask questions after at least having made a diligent effort we all gain. The new user learns how to get answers, how to relate what he already knows to his current problem, and a wealth of other things. Always building on his current knowledge base.. The list member gains by having a new user guided in the way to learn rather than having to answer in detail the "how to" question that may have worked for him but may not work exactly the same on the other users machine due to distribution/release level/application level/misunderstanding of the problem/etc.
One of the biggest failings in new users I see are the ones who have the attitude of "tell me how to do my job" and will not even make a reasonable effort to do it on their own.
Answers on this list by most are a balancing act between hand holding (do this) and guiding (look there) as they answer questions. </rant>
to say "I typed this command and got this error:... - has that happened to anyone else?" and something else to ask how to start something that needs a whole tutorial book to answer.
That's fair, but *really*, I don't post until I run out of reference options, or get frustrated after researching for a *long* time. If the tutorial exists, just point me to it. If it doesn't exist, we'll have to punt, eh?
An attitude I applaud in everyone.
Of course when you ask the question, you may not know the complexity of the answer...
No one can know everything, that's why we ask questions. :-)
The facts are, as I see it, fairly simple.
1. This is a public list and there will always be people coming around looking for an easy answer. Learn to deal with it.
2. All replies are voluntary, you don't have to answer and are free to ignore any and all requests for help.
3. Fedora Core, like any other product, will benefit from good customer service.
The point being, if you do choose to reply to someone, be friendly even when asking if the person has RTFM. My $.02 says that the people of this list do a pretty good job of staying civil and friendly.
When is Core 5 due? Wait, don't answer that, I'll go read the manual.
tepy
***** "The World is a ghetto, pretty nice one too!" Red - A Kansas City Wino 1983
On Thu, 2005-12-29 at 10:59 -0600, Les Mikesell wrote:
On Thu, 2005-12-29 at 09:07, Charles Howse wrote:
My first experience with Linux was when I bought a book about Linux that contained Red Hat 5. Didn't know what a man page was until I finished reading the book. Today I am still dumbfounded sometimes by the lack of help contained in a man page, or by the over abundance of terms that I have to stop and look up, then try and understand whether that applies to my situation.
You really have to understand what the shell does to every command line before starting a program before reading other man pages. The concepts of i/o redirection, wildcard filename expansion, and environment variable setting are not repeated in the man pages for every program even though they may be useful or even necessary. Man pages are meant to be a reference, not a tutorial. A tutorial should be a separate volume since you normally only need it once and never want to see it again while you may need the reference for obscure options later. Unfortunately, a tutorial doesn't exist for some programs you might want to use.
-- Les Mikesell lesmikesell@gmail.com
The facts are, as I see it, fairly simple.
- This is a public list and there will always be people coming around
looking for an easy answer. Learn to deal with it.
Just to get a little humorous...
RTFM Answer = "Honey, have you seen my car keys?" "Yes, I know where they are, but you will have to find them yourself."
Good answer = "Honey, have you seen my car keys?" "The last time I saw them, they were on the kitchen counter."
Great Answer = "Honey, have you seen my car keys?" "Here they are, sweetheart."
- Fedora Core, like any other product, will benefit from good customer
service.
All of us users being the Customer Service Department?
The point being, if you do choose to reply to someone, be friendly even when asking if the person has RTFM. My $.02 says that the people of this
My point exactly.
list do a pretty good job of staying civil and friendly.
Agreed.
When is Core 5 due? Wait, don't answer that, I'll go read the manual.
lol!
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Charles Howse wrote:
Just to get a little humorous...
RTFM Answer = "Honey, have you seen my car keys?" "Yes, I know where they are, but you will have to find them yourself."
A better analogy might be (based on an actual conversation):
She: "Honey, when that guy from Italy designed the boiler that the plumber from the next town installed for the previous owners, how did he get the pressure vessel attached to the outlet?"
Me: "God knows, read the schematics."
:-) C.
- -- Craig McLean http://fukka.co.uk craig@fukka.co.uk Where the fun never starts Powered by FreeBSD, and GIN!
On Thu, 2005-12-29 at 10:59 -0600, Les Mikesell wrote:
Man pages are meant to be a reference, not a tutorial.
Yes. The info system is much better for actual documentation (or scrollkeeper).
Unfortunately, packages seem to use one or the other when many of them would benefit from both.
info also is uncomfortable to use for some people - but back when yelp actually supported it (gnome 2.2?) yelp was a user friendly frontend to the info system - and gave one app that users could use for most of the documentation on the system.
On 12/29/05, Michael A. Peters mpeters@mac.com wrote:
On Thu, 2005-12-29 at 10:59 -0600, Les Mikesell wrote:
info also is uncomfortable to use for some people - but back when yelp actually supported it (gnome 2.2?) yelp was a user friendly frontend to the info system - and gave one app that users could use for most of the documentation on the system.
Well for those of us who use KDe/Konqueror, i think there is kio-help, kio-info, and kio-man
-- As a boy I jumped through Windows, as a man I play with Penguins.
On 12/29/05, Arthur Pemberton pemboa@gmail.com wrote:
On 12/29/05, Michael A. Peters mpeters@mac.com wrote:
On Thu, 2005-12-29 at 10:59 -0600, Les Mikesell wrote:
info also is uncomfortable to use for some people - but back when yelp actually supported it (gnome 2.2?) yelp was a user friendly frontend to the info system - and gave one app that users could use for most of the documentation on the system.
Well for those of us who use KDe/Konqueror, i think there is kio-help, kio-info, and kio-man
-- As a boy I jumped through Windows, as a man I play with Penguins.
-- As a boy I jumped through Windows, as a man I play with Penguins.
From: "Arthur Pemberton" pemboa@gmail.com On 12/29/05, Arthur Pemberton pemboa@gmail.com wrote:
-- As a boy I jumped through Windows, as a man I play with Penguins.
-- As a boy I jumped through Windows, as a man I play with Penguins.
And as a penguin I pray alot? ---->>>> Thataway! {O,o}
On 12/29/05, Les Mikesell lesmikesell@gmail.com wrote:
On Thu, 2005-12-29 at 09:07, Charles Howse wrote:
My first experience with Linux was when I bought a book about Linux that contained Red Hat 5. Didn't know what a man page was until I finished reading the book. Today I am still dumbfounded sometimes by the lack of help contained in a man page, or by the over abundance of terms that I have to stop and look up, then try and understand whether that applies to my situation.
You really have to understand what the shell does to every command line before starting a program before reading other man pages. The concepts of i/o redirection, wildcard filename expansion, and environment variable setting are not repeated in the man pages for every program even though they may be useful or even necessary. Man pages are meant to be a reference, not a tutorial. A tutorial should be a separate volume since you normally only need it once and never want to see it again while you may need the reference for obscure options later. Unfortunately, a tutorial doesn't exist for some programs you might want to use.
-- Les Mikesell lesmikesell@gmail.com
It would greatly help if most of the man pages included examples of usage.
From: "Kam Leo" kam.leo@gmail.com
It would greatly help if most of the man pages included examples of usage.
Many do, Kam. It's hit or miss when the tool's developer come to making a man page, if he even bothers. It may be somebody else's quick effort.
Everybody complains about documentation; but, DARNED few do anything about it.
{o.o}
On Thursday 29 December 2005 20:40, Kam Leo wrote:
On 12/29/05, Les Mikesell lesmikesell@gmail.com wrote:
On Thu, 2005-12-29 at 09:07, Charles Howse wrote:
My first experience with Linux was when I bought a book about Linux that contained Red Hat 5. Didn't know what a man page was until I finished reading the book. Today I am still dumbfounded sometimes by the lack of help contained in a man page, or by the over abundance of terms that I have to stop and look up, then try and understand whether that applies to my situation.
You really have to understand what the shell does to every command line before starting a program before reading other man pages. The concepts of i/o redirection, wildcard filename expansion, and environment variable setting are not repeated in the man pages for every program even though they may be useful or even necessary. Man pages are meant to be a reference, not a tutorial. A tutorial should be a separate volume since you normally only need it once and never want to see it again while you may need the reference for obscure options later. Unfortunately, a tutorial doesn't exist for some programs you might want to use.
-- Les Mikesell lesmikesell@gmail.com
It would greatly help if most of the man pages included examples of usage.
Hear hear!!
Hi
It would greatly help if most of the man pages included examples of usage.
Hear hear!!
As a general principle it is a good idea for man pages to provide example. In some cases they already do. If not use bugzilla.
On Thu, 2005-12-29 at 21:07, Gene Heskett wrote:
It would greatly help if most of the man pages included examples of usage.
Hear hear!!
Often the man pages have examples of the way the author expected the program to be used. However, there's still a good chance that isn't exactly what you want to do with it.
On Thursday 29 December 2005 22:36, Les Mikesell wrote:
On Thu, 2005-12-29 at 21:07, Gene Heskett wrote:
It would greatly help if most of the man pages included examples of usage.
Hear hear!!
Often the man pages have examples of the way the author expected the program to be used. However, there's still a good chance that isn't exactly what you want to do with it.
I submit to you all the manpages for bash.
Paragraph after paragraph of explanation of this option and that option in a quite verbose manner, and not a single actual example of a command line, and the results it should return. That makes writing even a 10 line bash script into an extended reading and re-reading session with heavy use of the manpages builtin grep because its so poorly organized that the complete answer may be in 3 or more places scattered through it. And the chances of it doing what you wanted on the first execution are slim to zip. Bash scripts can be made to do litterally anything you need them to do, but... So I come to one of these lists and ask for help, finally getting acceptable results in 3-4 days, often using a method thats not at all clear in the manpages. The help I have received on one list or another has often been far more clearly and concisely stated than the manpages for bash that I have printed out and bound, and read from end to end probably 30 times now.
I rest my case.
From: "Gene Heskett" gene.heskett@verizon.net
On Thursday 29 December 2005 22:36, Les Mikesell wrote:
On Thu, 2005-12-29 at 21:07, Gene Heskett wrote:
It would greatly help if most of the man pages included examples of usage.
Hear hear!!
Often the man pages have examples of the way the author expected the program to be used. However, there's still a good chance that isn't exactly what you want to do with it.
I submit to you all the manpages for bash.
Paragraph after paragraph of explanation of this option and that option in a quite verbose manner, and not a single actual example of a command line, and the results it should return. That makes writing even a 10 line bash script into an extended reading and re-reading session with heavy use of the manpages builtin grep because its so poorly organized that the complete answer may be in 3 or more places scattered through it. And the chances of it doing what you wanted on the first execution are slim to zip. Bash scripts can be made to do litterally anything you need them to do, but... So I come to one of these lists and ask for help, finally getting acceptable results in 3-4 days, often using a method thats not at all clear in the manpages. The help I have received on one list or another has often been far more clearly and concisely stated than the manpages for bash that I have printed out and bound, and read from end to end probably 30 times now.
I rest my case.
During the three or four days you're waiting for a GOOD answer you could be perusing the system's various bash script files to see if you can find an example of what you're trying to do. "Read the source, Luke." It's an ironic funny. It actually can help if you are trying to use a language to read some source code in that language and figure out what it's doing. (That's another of my tricks to try to seem wiser than I really am.)
{^_-}
On Thursday 29 December 2005 22:36, Les Mikesell wrote:
On Thu, 2005-12-29 at 21:07, Gene Heskett wrote:
It would greatly help if most of the man pages included examples of usage.
Hear hear!!
Often the man pages have examples of the way the author expected the program to be used. However, there's still a good chance that isn't exactly what you want to do with it.
I submit to you all the manpages for bash.
Paragraph after paragraph of explanation of this option and that option in a quite verbose manner, and not a single actual example of a command line, and the results it should return. That makes writing even a 10 line bash script into an extended reading and re-reading session with heavy use of the manpages builtin grep because its so poorly organized that the complete answer may be in 3 or more places scattered through it. And the chances of it doing what you wanted on the first execution are slim to zip. Bash scripts can be made to do litterally anything you need them to do, but... So I come to one of these lists and ask for help, finally getting acceptable results in 3-4 days, often using a method thats not at all clear in the manpages. The help I have received on one list or another has often been far more clearly and concisely stated than the manpages for bash that I have printed out and bound, and read from end to end probably 30 times now.
I rest my case.
I feel your pain, my friend. I've been scripting bash for quite a while. Maybe I can contribute something to this thread, here's my list of bookmarks for bash scripting:
http://www.opengroup.org/onlinepubs/009695399/toc.htm http://cfaj.freeshell.org/shell/ http://www.shelldorado.com/ http://home.comcast.net/~j.p.h/cus-faq.html http://sed.sourceforge.net/sed1line.txt http://www.student.northpark.edu/pemente/sed/sedfaq.html http://www.faqs.org/faqs/unix-faq/faq/part1/ http://www.shelldorado.com/goodcoding/cmdargs.html http://www.macobserver.com/tips/macosxcl101/ http://www.wagoneers.com/UNIX/FIND/find-usage.html http://cnswww.cns.cwru.edu/~chet/bash/bashref.html http://www.tldp.org/LDP/abs/html/
On Friday 30 December 2005 06:56, Charles Howse wrote: [...]
I rest my case.
I feel your pain, my friend. I've been scripting bash for quite a while. Maybe I can contribute something to this thread, here's my list of bookmarks for bash scripting:
http://www.opengroup.org/onlinepubs/009695399/toc.htm http://cfaj.freeshell.org/shell/ http://www.shelldorado.com/ http://home.comcast.net/~j.p.h/cus-faq.html http://sed.sourceforge.net/sed1line.txt http://www.student.northpark.edu/pemente/sed/sedfaq.html http://www.faqs.org/faqs/unix-faq/faq/part1/ http://www.shelldorado.com/goodcoding/cmdargs.html http://www.macobserver.com/tips/macosxcl101/ http://www.wagoneers.com/UNIX/FIND/find-usage.html http://cnswww.cns.cwru.edu/~chet/bash/bashref.html http://www.tldp.org/LDP/abs/html/
Many thanks, marked as important and therefore a keep forever to kmail. Or till all drives in the box expire simultainiously. :)
Charles Howse wrote:
On Thursday 29 December 2005 22:36, Les Mikesell wrote:
On Thu, 2005-12-29 at 21:07, Gene Heskett wrote:
[snip]
The help I have received on one list or another has often been far more clearly and concisely stated than the manpages for bash that I have printed out and bound, and read from end to end probably 30 times now.
I rest my case.
I feel your pain, my friend. I've been scripting bash for quite a while. Maybe I can contribute something to this thread, here's my list of bookmarks for bash scripting:
http://www.opengroup.org/onlinepubs/009695399/toc.htm http://cfaj.freeshell.org/shell/ http://www.shelldorado.com/ http://home.comcast.net/~j.p.h/cus-faq.html http://sed.sourceforge.net/sed1line.txt http://www.student.northpark.edu/pemente/sed/sedfaq.html http://www.faqs.org/faqs/unix-faq/faq/part1/ http://www.shelldorado.com/goodcoding/cmdargs.html http://www.macobserver.com/tips/macosxcl101/ http://www.wagoneers.com/UNIX/FIND/find-usage.html http://cnswww.cns.cwru.edu/~chet/bash/bashref.html http://www.tldp.org/LDP/abs/html/
Which is why, my friends, when I need a quickie one-off I *never* write a script. My longest scripts are no more than 20 lines or so. As soon as I need an "if" I switch to C and write in a language which is documented, understandable, and portable between systems.
When I left the IBM mainframe world in 1981 I left JCL behind, and have never looked back. Writing long involved scripts is a throw-back to the Jurassic age. Join the 21st Century and abandon shell scripts.
Just my $0.02 worth.
Mike
Mike McCarty wrote:
Which is why, my friends, when I need a quickie one-off I *never* write a script. My longest scripts are no more than 20 lines or so. As soon as I need an "if" I switch to C and write in a language which is documented, understandable, and portable between systems.
When I left the IBM mainframe world in 1981 I left JCL behind,
You could have been using Jol, which is much nicer.
In the early 70s I wrote a set of assembler macros to generate JCL (similar to sysgen). Way better than catalogued procedures.
My boss thought it a great joke when I submitted a job that submitted 50 or so jobs to copy tapes, then went off to college. It seems the computer centre staff got excited at having to do some work, and he took the call.
You could also have bene using TSO command procedures. Note to others; imagine JCL as assembler-like, and TSO (with MVS, before MVS was different) command procedures as akin to a well-structured third-generation language compled with do/end blocks. Statements looked like this: allocate file(fred) dataset(good.stuff) new - space (1000 100) block(4096) round
and have never looked back. Writing long involved scripts is a throw-back to the Jurassic age. Join the 21st Century and abandon shell scripts.
Just my $0.02 worth.
Way overpriced.
How many lines of C is this worth: for f in $(find unix/ common/ -type f -name *.h -o -name *.cxx \ |xargs grep -lw secTypeVncAuth); do vim -c /secTypeVncAuth $f; done
That's the sort of thing I type at the commandline.
How long would this take in C? [summer@bilby ~]$ cat bin/cleanaustin | expand -t 3 #!/bin/bash U=http://dugite/~summer/vendors/www.austin.net.au/components.html lynx -source ${U} \ | grep -v cgi3 \ | tr '\t\r\n!' ' ' \ | tr "']" '"#' \ | ( sed \ -e 's=</html>.*==' \ -e 's~.*<BODY[-a-zA-Z0-9 ;"=_)(,]*~@@~' \ -e 's=@@.*& availability==g' \ -e 's= = =g' \ -e 's=&=and=g' \ -e 's="="=g' \ -e 's=</tr>=|=g' \ -e 's=</td>=!=g' \ -e 's~<[-A-Za-z0-9 "/#%@_?*#=.]*>~~g' \ -e 's= *= =g' \ -e 's=[ |!]| *=|=g' \
) \ | tr '|!' '\n\t'
It did a passable (better than lynx) job of cleaning up a web page, making it readable.
There is and will be for the foreseeable future, a place for scripts, for light programming tasks and for glueing stuff together.
It's way easier to read /sbin/dhclient-script and discover what it does than it is to locate, download (maybe), install and patch (maybe) the source to /sbin/dhclient find what _it_ does.
I've been through the process of debugging vendor-provided scripts (eg debmirror) and vendor-provided binaries (cyrus-imapd), and the edit and rerun process for the former beats the edit, rebuild, copy and reinstall of the latter.
John Summerfied wrote:
Mike McCarty wrote:
Which is why, my friends, when I need a quickie one-off I *never* write a script. My longest scripts are no more than 20 lines or so. As soon as I need an "if" I switch to C and write in a language which is documented, understandable, and portable between systems.
When I left the IBM mainframe world in 1981 I left JCL behind,
You could have been using Jol, which is much nicer.
In the early 70s I wrote a set of assembler macros to generate JCL (similar to sysgen). Way better than catalogued procedures.
My boss thought it a great joke when I submitted a job that submitted 50 or so jobs to copy tapes, then went off to college. It seems the computer centre staff got excited at having to do some work, and he took the call.
You could also have bene using TSO command procedures. Note to others; imagine JCL as assembler-like, and TSO (with MVS, before MVS was different) command procedures as akin to a well-structured third-generation language compled with do/end blocks. Statements looked like this: allocate file(fred) dataset(good.stuff) new - space (1000 100) block(4096) round
and have never looked back. Writing long involved scripts is a throw-back to the Jurassic age. Join the 21st Century and abandon shell scripts.
Just my $0.02 worth.
Way overpriced.
How many lines of C is this worth: for f in $(find unix/ common/ -type f -name *.h -o -name *.cxx \ |xargs grep -lw secTypeVncAuth); do vim -c /secTypeVncAuth $f; done
I have no idea, since it is essentially incomprensible goop.
That's the sort of thing I type at the commandline.
Well, I don't want to waste the brain cells.
How long would this take in C?
Nobody would claim that all programming languages are equally suited to all tasks.
[rest of horrible example cut as unworthy of reasonable individual line by line comment]
I'd be ashamed if my C code were so incomprehensible and poorly documented.
We obviously have different ideas about what good programming really means. To almost quote Hoare: There are two ways to write programs. One can make them so simple that there obviously are no defects, or one can make them so complicated that there are no obvious defects. The former is much more difficult.
Mike
Mike McCarty wrote:
John Summerfied wrote:
Mike McCarty wrote:
Which is why, my friends, when I need a quickie one-off I *never* write a script. My longest scripts are no more than 20 lines or so. As soon as I need an "if" I switch to C and write in a language which is documented, understandable, and portable between systems.
When I left the IBM mainframe world in 1981 I left JCL behind,
You could have been using Jol, which is much nicer.
In the early 70s I wrote a set of assembler macros to generate JCL (similar to sysgen). Way better than catalogued procedures.
My boss thought it a great joke when I submitted a job that submitted 50 or so jobs to copy tapes, then went off to college. It seems the computer centre staff got excited at having to do some work, and he took the call.
You could also have bene using TSO command procedures. Note to others; imagine JCL as assembler-like, and TSO (with MVS, before MVS was different) command procedures as akin to a well-structured third-generation language compled with do/end blocks. Statements looked like this: allocate file(fred) dataset(good.stuff) new - space (1000 100) block(4096) round
and have never looked back. Writing long involved scripts is a throw-back to the Jurassic age. Join the 21st Century and abandon shell scripts.
Just my $0.02 worth.
Way overpriced.
How many lines of C is this worth: for f in $(find unix/ common/ -type f -name *.h -o -name *.cxx \ |xargs grep -lw secTypeVncAuth); do vim -c /secTypeVncAuth $f; done
I have no idea, since it is essentially incomprensible goop.
Ah, there's your real problem: you no spika da language!
I'd not expect anyone who's made an effort to learn about the shell, simple scripting, and the standard *x commandline utilities to have a problem with it.
That's the sort of thing I type at the commandline.
Well, I don't want to waste the brain cells.
How long would this take in C?
Nobody would claim that all programming languages are equally suited to all tasks.
[rest of horrible example cut as unworthy of reasonable individual line by line comment]
I'd be ashamed if my C code were so incomprehensible and poorly documented.
We obviously have different ideas about what good programming really means. To almost quote Hoare: There are two ways to write programs. One can make them so simple that there obviously are no defects, or one can make them so complicated that there are no obvious defects. The former is much more difficult.
and nobody does the latter.
If you don't understand the language, you're not qualified to judge the quality or qualities of the code.
I grant you the regular expressions in the second can be a little daunting, but the shell script isn't the place to document how regular expressions work, and of you know how they work then understanding those isn't difficult.
Expecting annotations in such a script is like expecting a French poet to provide English annotations.
From: "John Summerfied" debian@herakles.homelinux.org
Mike McCarty wrote:
John Summerfied wrote:
Mike McCarty wrote:
I'd be ashamed if my C code were so incomprehensible and poorly documented.
We obviously have different ideas about what good programming really means. To almost quote Hoare: There are two ways to write programs. One can make them so simple that there obviously are no defects, or one can make them so complicated that there are no obvious defects. The former is much more difficult.
and nobody does the latter.
If you don't understand the language, you're not qualified to judge the quality or qualities of the code.
Negative. Undocumented code is "a bad thing." Sadly, we all seem to commit to much of it. We presume the next poor sod who gets to play with the code will understand the subtleties of the language and see what we're doing instantly. We discover, when we are the next poor sod some years down the line that we've forgotten that language after picking up 7 others.
Regular expressions are a feature that could use more documentation than they usually get.
{o.o}
jdow wrote:
Negative. Undocumented code is "a bad thing." Sadly, we all seem to
An overview of the program and its basic algorirthms is good. It's relatively static, less inclined to become out of date as bugs are fixed.
A detailed description of the syntax and semantics of the language are a separate matter.
commit to much of it. We presume the next poor sod who gets to play with the code will understand the subtleties of the language and see what we're doing instantly. We discover, when we are the next poor sod some years down the line that we've forgotten that language after picking up 7 others.
I tend to ignore comments when bug-hunting as, while they may describe that author's intent, they are likely to mislead in the debugging process.
Sun (in Java) recommends an overview at the start of the file, and a description of each function's purpose, inputs and outputs.
Regular expressions are a feature that could use more documentation than they usually get.
But every place they're used is not the place to document them. If you want to know about them,
man 7 regex
On Sun, 2006-01-01 at 17:33 +0800, John Summerfied wrote:
Sun (in Java) recommends an overview at the start of the file, and a description of each function's purpose, inputs and outputs.
That was part of our basic computer training, too. Your overview first described the purpose of the program (with no technical details), then elaborated on the methodology that it would use, technical details, variables, etc.
John Summerfied wrote:
Mike McCarty wrote:
John Summerfied wrote:
Mike McCarty wrote:
Which is why, my friends, when I need a quickie one-off I *never* write a script. My longest scripts are no more than 20 lines or so. As soon as I need an "if" I switch to C and write in a language which is documented, understandable, and portable between systems.
When I left the IBM mainframe world in 1981 I left JCL behind,
You could have been using Jol, which is much nicer.
In the early 70s I wrote a set of assembler macros to generate JCL (similar to sysgen). Way better than catalogued procedures.
My boss thought it a great joke when I submitted a job that submitted 50 or so jobs to copy tapes, then went off to college. It seems the computer centre staff got excited at having to do some work, and he took the call.
You could also have bene using TSO command procedures. Note to others; imagine JCL as assembler-like, and TSO (with MVS, before MVS was different) command procedures as akin to a well-structured third-generation language compled with do/end blocks. Statements looked like this: allocate file(fred) dataset(good.stuff) new - space (1000 100) block(4096) round
and have never looked back. Writing long involved scripts is a throw-back to the Jurassic age. Join the 21st Century and abandon shell scripts.
Just my $0.02 worth.
Way overpriced.
How many lines of C is this worth: for f in $(find unix/ common/ -type f -name *.h -o -name *.cxx \ |xargs grep -lw secTypeVncAuth); do vim -c /secTypeVncAuth $f; done
I have no idea, since it is essentially incomprensible goop.
Ah, there's your real problem: you no spika da language!
Untrue.
for f in creates a loop over selected files find standard UNIX utility to traverse the directory structure unix/ ... list of directory tree tops to work upon -type f restrict search to ordinary files -name globbed name, I'd use '*.h' rather than *.h -o sorry, not familiar with this option | pipe to another program xargs not familiar with this program, sorry but looking at it, it looks like it's essentially the same as -exec do ends the file selection list and starts the body vim sorry, not familiar with vim done ends the body of the for loop
I'd not expect anyone who's made an effort to learn about the shell, simple scripting, and the standard *x commandline utilities to have a problem with it.
I have a problem with calling this a "program".
That's the sort of thing I type at the commandline.
Well, I don't want to waste the brain cells.
How long would this take in C?
Nobody would claim that all programming languages are equally suited to all tasks.
[rest of horrible example cut as unworthy of reasonable individual line by line comment]
I'd be ashamed if my C code were so incomprehensible and poorly documented.
We obviously have different ideas about what good programming really means. To almost quote Hoare: There are two ways to write programs. One can make them so simple that there obviously are no defects, or one can make them so complicated that there are no obvious defects. The former is much more difficult.
and nobody does the latter.
Huh? I've encountered *lots* of code in my career which I characterize, not as "it works", but "it no longer fails". The circumstances in which the defects become manifest are very obscure.
And writing long scripts (or indeed longish programs in any language) without commentary is edging into the latter.
If you don't understand the language, you're not qualified to judge the quality or qualities of the code.
Oh, yes I am. When I see lots of code with *no* commentary, I don't have to know the language intimately. All programming languages have some similarities which allow them to be partially understood by anyone who has more than three under his belt. I know very little about Forth or Lisp, but I sure can tell the difference between well-written Forth and badly-written Forth. (Ditto for Lisp.)
I grant you the regular expressions in the second can be a little daunting, but the shell script isn't the place to document how regular expressions work, and of you know how they work then understanding those isn't difficult.
I'm very familiar with GREs.
Expecting annotations in such a script is like expecting a French poet to provide English annotations.
As I said, you seem to be of the sort who writes programs and has a secret (or even not so secret) feeling of superiority when others have difficulty understanding the "clever" methods used in them.
God, please save us from "clever" programmers.
Mike
On Mon, 2006-01-02 at 12:26, Mike McCarty wrote:
| pipe to another program xargs not familiar with this program, sorry but looking at it, it looks like it's essentially the same as -exec
It's much more efficient than exec for programs that accept multiple filenames on the command line. It takes a list from stdin and puts reasonably-sized bunches on the command line of the specified program so you don't have to start the program for every file or worry about exceeding command line size limits.
vim sorry, not familiar with vim
It's an enhanced vi. But sed or ed could probably do this job.
God, please save us from "clever" programmers.
Famous quote: "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." -- Kernighan
Some other interesting comments on the topic of simplicity and not re-inventing old mistakes: http://en.wikipedia.org/wiki/Unix_philosophy
On Friday 30 December 2005 05:21, Gene Heskett wrote:
Paragraph after paragraph of explanation of this option and that option in a quite verbose manner, and not a single actual example of a command line, and the results it should return.
Have you looked at your documentation folder for bash? You should have a file:
/usr/share/doc/bash-3.0/bashref.html
which is the bash reference manual which may help.
Also the bash home page is:
http://cnswww.cns.cwru.edu/~chet/bash/bashtop.html
where you can find the FAQ and links to the bash mailing list etc.
Regards, Mike Klinke
On Fri, 2005-12-30 at 05:21, Gene Heskett wrote:
Often the man pages have examples of the way the author expected the program to be used. However, there's still a good chance that isn't exactly what you want to do with it.
I submit to you all the manpages for bash.
Paragraph after paragraph of explanation of this option and that option in a quite verbose manner, and not a single actual example of a command line, and the results it should return.
Bash is kind of unusual because it is normally the 'calling' program, not the one being executed on a command line - or if you do execute it intentionally as a command the purpose is to start some other program in a subshell. What you need to know about bash is what it does to your command lines (splitting on IFS, expanding variables and wildcard filenames, redirection i/o etc.) before starting any other program. What those other programs do or return is their own business but they probably are the real reason you are issuing a shell command.
That makes writing even a 10 line bash script into an extended reading and re-reading session with heavy use of the manpages builtin grep because its so poorly organized that the complete answer may be in 3 or more places scattered through it.
That 10 line bash script might execute 20 different external commands, none of which the bash author anticipated. That's why the system is powerful - whenever anyone adds a new tool you are able to combine it's operations with all the others but it also makes it impossible to document all the possibilities.
On Fri, 2005-12-30 at 10:29 -0600, Les Mikesell wrote:
On Fri, 2005-12-30 at 05:21, Gene Heskett wrote:
Often the man pages have examples of the way the author expected the program to be used. However, there's still a good chance that isn't exactly what you want to do with it.
I submit to you all the manpages for bash.
Paragraph after paragraph of explanation of this option and that option in a quite verbose manner, and not a single actual example of a command line, and the results it should return.
Bash is kind of unusual because it is normally the 'calling' program, not the one being executed on a command line - or if you do execute it intentionally as a command the purpose is to start some other program in a subshell. What you need
Not entirely true. Many of us use shell scripts to do a significant amount of work that would otherwise be tedious and repetitive.
to know about bash is what it does to your command lines (splitting on IFS, expanding variables and wildcard filenames, redirection i/o etc.) before starting any other program. What those other programs do or return is their own business but they probably are the real reason you are issuing a shell command.
Sure, you need to know *how* to use it and the programming features that often function in the background. Bash is a genuine programming environment, as well as a command interpreter.
What most people see is the ability to call other programs. What is actually there is *much* more and extremely versatile.
That makes writing even a 10 line bash script into an extended reading and re-reading session with heavy use of the manpages builtin grep because its so poorly organized that the complete answer may be in 3 or more places scattered through it.
That 10 line bash script might execute 20 different external commands, none of which the bash author anticipated. That's why the system is powerful - whenever anyone adds a new tool you are able to combine it's operations with all the others but it also makes it impossible to document all the possibilities.
-- Les Mikesell lesmikesell@gmail.com
--- Jeff Vian jvian10@charter.net wrote:
On Fri, 2005-12-30 at 10:29 -0600, Les Mikesell wrote:
On Fri, 2005-12-30 at 05:21, Gene Heskett wrote:
Often the man pages have examples of the way
the author expected
the program to be used. However, there's still
a good chance
that isn't exactly what you want to do with it.
I submit to you all the manpages for bash.
Paragraph after paragraph of explanation of this
option and that option
in a quite verbose manner, and not a single
actual example of a
command line, and the results it should return.
Bash is kind of unusual because it is normally the
'calling'
program, not the one being executed on a command
line - or if
you do execute it intentionally as a command the
purpose is
to start some other program in a subshell. What
you need Not entirely true. Many of us use shell scripts to do a significant amount of work that would otherwise be tedious and repetitive.
Very true! Shell scripts save time and run very efficiently. There are many examples of these, using lame to convert wav's to mp3's/ogg's among others.
to know about bash is what it does to your command
lines
(splitting on IFS, expanding variables and
wildcard filenames,
redirection i/o etc.) before starting any other
program.
What those other programs do or return is their
own business
but they probably are the real reason you are
issuing a
shell command.
Sure, you need to know *how* to use it and the programming features that often function in the background. Bash is a genuine programming environment, as well as a command interpreter.
What most people see is the ability to call other programs. What is actually there is *much* more and extremely versatile.
That makes writing even a 10 line bash script into an extended
reading and re-reading
session with heavy use of the manpages builtin
grep because its so
poorly organized that the complete answer may be
in 3 or more places
scattered through it.
That 10 line bash script might execute 20
different external
commands, none of which the bash author
anticipated. That's
why the system is powerful - whenever anyone adds
a new tool
you are able to combine it's operations with all
the others
but it also makes it impossible to document all
the possibilities.
-- Les Mikesell lesmikesell@gmail.com
-- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
This list is amazing. There are many great individuals that go out of their way to help users in need. I would like to thank all the users but that is very hard to do. Many people have very interesting points to make. But to say that people are not helpful is not a good one. If one does not know the answer to a certain question, we continue on, why give out information that will not help the users out. Someone that has been there generally comes through and helps out.
Best Regards,
Antonio
__________________________________________ Yahoo! DSL – Something to write home about. Just $16.99/mo. or less. dsl.yahoo.com
On Fri, 2005-12-30 at 06:21 -0500, Gene Heskett wrote:
Often the man pages have examples of the way the author expected the program to be used. However, there's still a good chance that isn't exactly what you want to do with it.
I submit to you all the manpages for bash.
<snip>
I rest my case.
Man pages are *not* intended, nor should they be relied upon, to learn something new. They are there as reference pages - you go to the man page to look up details or finer points.
In the case of bash, I would look at http://www.tldp.org/LDP/Bash- Beginners-Guide/html/ followed up with http://www.tldp.org/LDP/abs/html/.
As with pretty much any complex piece of software, there is usually a "getting started" guide and a reference guide. You should not start with the reference guide, you should look over the "getting started" docs first.
Thomas
Gene Heskett wrote:
On Thursday 29 December 2005 22:36, Les Mikesell wrote:
On Thu, 2005-12-29 at 21:07, Gene Heskett wrote:
It would greatly help if most of the man pages included examples of usage.
Hear hear!!
Often the man pages have examples of the way the author expected the program to be used. However, there's still a good chance that isn't exactly what you want to do with it.
I submit to you all the manpages for bash.
Paragraph after paragraph of explanation of this option and that option in a quite verbose manner, and not a single actual example of a command line, and the results it should return. That makes writing even a 10 line bash script into an extended reading and re-reading session with heavy use of the manpages builtin grep because its so poorly organized that the complete answer may be in 3 or more places scattered through it. And the chances of it doing what you wanted on the first execution are slim to zip. Bash scripts can be made to do litterally anything you need them to do, but... So I come to one of these lists and ask for help, finally getting acceptable results in 3-4 days, often using a method thats not at all clear in the manpages. The help I have received on one list or another has often been far more clearly and concisely stated than the manpages for bash that I have printed out and bound, and read from end to end probably 30 times now.
I rest my case.
I reckon your expectations are a little steep.
I don't think you will find the kind of information you desire comes with any implementation of any programming language, certainly for peecees. Have you noticed the proliferation of Windows books?
Back when OS/2 was at its peak there were not a lot of books around, partly because the documentation that came with it was quite complete, though with a technical orientation that probably would have defeated you. I had quite a busy little website for a while, explaining how I'd done things.
Back then, I got daily email thanking me for doing such a good job. Much nicer than the daily spam I get now:-
If you want to master bash, perl, python, ldpa, sendmail, postfix, cyrus imap or any other complex topic, then Tim Oreilly has a book for you. Maybe several.
The man page for bash is quite good (especially for one coming from the FSF), but it's reference material, not tutorial.
John Summerfied wrote:
I reckon your expectations are a little steep.
I don't think you will find the kind of information you desire comes with any implementation of any programming language, certainly for peecees. Have you noticed the proliferation of Windows books?
Au contraire, mon ami. Borland C, for example, comes with a nice tutorial on the C programming language.
[snip]
Mike
Pardon my ignorance, but during the install process I wasn't given an option to create a boot floppy for FC4.
Not that I think I need one, but with all distros I have tried ealier, (years ago...) this always was an option...
If I had to create one now, how would I do it ?
Thank you for your help
Lorenzo
On Sat, 2005-12-31 at 00:49 +0200, Lorenzo Sandini (Sonera) wrote:
Pardon my ignorance, but during the install process I wasn't given an option to create a boot floppy for FC4.
Not that I think I need one, but with all distros I have tried ealier, (years ago...) this always was an option...
If I had to create one now, how would I do it ?
You would make a boot cd. The image is too large for a floppy. mkbootdisk --iso --device boot.cd.img 2.x.xx-x.xxxx_FCx. --gary
On Sat, 2005-12-31 at 00:49 +0200, Lorenzo Sandini (Sonera) wrote:
Pardon my ignorance, but during the install process I wasn't given an option to create a boot floppy for FC4.
Not that I think I need one, but with all distros I have tried ealier, (years ago...) this always was an option...
If I had to create one now, how would I do it ?
You can't. The kernel is too large for a floppy. You can make a boot CD, download the rescue CD from Fedora, or boot to rescue mode from the first install CD.
Because there are several options I simply use the rescue CD since I thus only have to download it and burn the CD from the downloaded image.
Thank you for your help
Lorenzo
On Fri, 2005-12-30 at 20:16 -0600, Jeff Vian wrote:
You can't. The kernel is too large for a floppy.
But you can make a GRUB boot disk (google for this, someone will explain how to do this better than I could). This contains enough to boot from a drive in most circumstances.
For cases where you're trying to recover a system that's failed, the rescue disc is probably what you want (the smaller Fedora ISO file).
Tim wrote:
On Fri, 2005-12-30 at 20:16 -0600, Jeff Vian wrote:
You can't. The kernel is too large for a floppy.
But you can make a GRUB boot disk (google for this, someone will explain how to do this better than I could). This contains enough to boot from a drive in most circumstances.
For cases where you're trying to recover a system that's failed, the rescue disc is probably what you want (the smaller Fedora ISO file).
This is what I meant, sorry for asking in a confusing way. The GRUB boot disk. :)
Lorenzo
Jeff Vian wrote:
On Sat, 2005-12-31 at 00:49 +0200, Lorenzo Sandini (Sonera) wrote:
Pardon my ignorance, but during the install process I wasn't given an option to create a boot floppy for FC4.
Not that I think I need one, but with all distros I have tried ealier, (years ago...) this always was an option...
If I had to create one now, how would I do it ?
You can't. The kernel is too large for a floppy. You can make a boot CD, download the rescue CD from Fedora, or boot to rescue mode from the first install CD.
Because there are several options I simply use the rescue CD since I thus only have to download it and burn the CD from the downloaded image.
If your system's not actually stuffed, a grub floppy can be handy. Some time ago I stuffed up a system running RHL 7.0 (needed a 2.2 kernel), trying to install Debian on the other hard drive, and nearly got it right. Thereafter, the FC2 rescue disk didn't work - could't fix either the RHL 7.0 or the Debian system, Knoppix du jour didn't work, but a grub floppy let me type the commands I needed to boot one of them.
Mike McCarty wrote:
John Summerfied wrote:
I reckon your expectations are a little steep.
I don't think you will find the kind of information you desire comes with any implementation of any programming language, certainly for peecees. Have you noticed the proliferation of Windows books?
Au contraire, mon ami. Borland C, for example, comes with a nice tutorial on the C programming language.
and the price of Borland C would go far to getting a nice book on bash, This google will help find one:
http://www.google.com/search?q=oreilly+bash+cameron&ie=UTF-8&oe=UTF-...
And despite your "nice tutorial," if I go down to any good bookstore I will find more books on Borland C.
John Summerfied wrote:
Mike McCarty wrote:
John Summerfied wrote:
I reckon your expectations are a little steep.
I don't think you will find the kind of information you desire comes with any implementation of any programming language, certainly for peecees. Have you noticed the proliferation of Windows books?
Au contraire, mon ami. Borland C, for example, comes with a nice tutorial on the C programming language.
and the price of Borland C would go far to getting a nice book on bash, This google will help find one:
http://www.google.com/search?q=oreilly+bash+cameron&ie=UTF-8&oe=UTF-...
And despite your "nice tutorial," if I go down to any good bookstore I will find more books on Borland C.
I didn't say otherwise. I don't understand your motive for replying in this way. You made a sweeping statement, which has a definite counterexample. You don't refute the counterexample, yet somehow you seem to think that you have vindicated your statement.
Mike
Mike McCarty wrote:
John Summerfied wrote:
Mike McCarty wrote:
John Summerfied wrote:
I reckon your expectations are a little steep.
I don't think you will find the kind of information you desire comes with any implementation of any programming language, certainly for peecees. Have you noticed the proliferation of Windows books?
Au contraire, mon ami. Borland C, for example, comes with a nice tutorial on the C programming language.
and the price of Borland C would go far to getting a nice book on bash, This google will help find one:
http://www.google.com/search?q=oreilly+bash+cameron&ie=UTF-8&oe=UTF-...
And despite your "nice tutorial," if I go down to any good bookstore I will find more books on Borland C.
I didn't say otherwise. I don't understand your motive for replying in this way. You made a sweeping statement, which has a definite counterexample. You don't refute the counterexample, yet somehow you seem to think that you have vindicated your statement.
Mike
Well, I can't/shouldn't speak to your desires, but the presence of so many books suggests that a) Publishers see a market b) Writers agree c) Consumers don't find the standard information meets their desires and buy alternative documentation.
If you find the counter example filled your needs, that's fine, but there are many who don't find it fills their needs and who purchase alternatives.
It happens I used to use Turbo Pascal, and I found it hard going, and I was already a competant programmer in several languages, even to the extent of presenting training courses on one of them.
John Summerfied wrote:
Mike McCarty wrote:
[snip]
And despite your "nice tutorial," if I go down to any good bookstore I will find more books on Borland C.
I didn't say otherwise. I don't understand your motive for replying in this way. You made a sweeping statement, which has a definite counterexample. You don't refute the counterexample, yet somehow you seem to think that you have vindicated your statement.
Mike
Well, I can't/shouldn't speak to your desires, but the presence of so many books suggests that a) Publishers see a market b) Writers agree c) Consumers don't find the standard information meets their desires and buy alternative documentation.
If you find the counter example filled your needs, that's fine, but there are many who don't find it fills their needs and who purchase alternatives.
I wasn't making that claim. I learned C long before I had a copy of Borland C. I was reacting to the claim that no programming language comes with a tutorial on the language.
It happens I used to use Turbo Pascal, and I found it hard going, and I was already a competant programmer in several languages, even to the extent of presenting training courses on one of them.
I have fond memories of Turbo Pascal, having written an add-on symbolic source-level debugger and sold a few copies. A great language. Had no problems learning the language from the TP 3.01a manual. I learned C from K&R.
Mike
On Fri, 2005-12-30 at 16:44, Mike McCarty wrote:
John Summerfied wrote:
I reckon your expectations are a little steep.
I don't think you will find the kind of information you desire comes with any implementation of any programming language, certainly for peecees. Have you noticed the proliferation of Windows books?
Au contraire, mon ami. Borland C, for example, comes with a nice tutorial on the C programming language.
But that doesn't tell you anything about the existing system utilities or how to use them. Most of the things you might want to do are already handled nicely by programs included with the system. If you only know a low-level tool like C, you are doomed to re-invent a lot of things unnecessarily.
-- Les Mikesell lesmikesell@gmail.com
Les Mikesell wrote:
On Fri, 2005-12-30 at 16:44, Mike McCarty wrote:
John Summerfied wrote:
I reckon your expectations are a little steep.
I don't think you will find the kind of information you desire comes with any implementation of any programming language, certainly for peecees. Have you noticed the proliferation of Windows books?
Au contraire, mon ami. Borland C, for example, comes with a nice tutorial on the C programming language.
But that doesn't tell you anything about the existing system utilities or how to use them. Most of the things you might want to do are already handled nicely by programs included with the system. If you only know a low-level tool like C, you are doomed to re-invent a lot of things unnecessarily.
Not at all. I just don't glue them together with long complicated shell scripts.
I'm not against anyone learning how to use all the tools available to do the things they do best. And not all languages are equally suited to any given task. Using the shell as a programming language is undesirable for a number of reasons, among them are (1) it unnecessarily complicates the command line parser. Since the CLI gets sooo much use it is desirable to make it simple, hence correct (2) Shell scripts are inherently less portable between systems than languages designed with portability in mind, like C. (3) Each part of a system should do the things it does best. I find that when I need something relatively complicated, but not enormously complicated, often a program written in more than one language is best. I use the shell to process the directory tree, and use the tools available where I can, but if I need special processing then I write a one-off C program to do the specialized processing, which gets called perhaps like this:
$ find /path/to/somewhere -name "file*globbing*stuff*" -print | my_special_program ;
I might even use a loop or two in the shell stuff. But I do *not* do the complicated logic using the shell.
Mike
On Fri, 2005-12-30 at 18:52, Mike McCarty wrote:
Most of the things you might want to do are already handled nicely by programs included with the system. If you only know a low-level tool like C, you are doomed to re-invent a lot of things unnecessarily.
Not at all. I just don't glue them together with long complicated shell scripts.
I'm not against anyone learning how to use all the tools available to do the things they do best. And not all languages are equally suited to any given task. Using the shell as a programming language is undesirable for a number of reasons, among them are (1) it unnecessarily complicates the command line parser. Since the CLI gets sooo much use it is desirable to make it simple, hence correct
The same things are equally useful for all command line operations. Scripting isn't a special case.
(2) Shell scripts are inherently less portable between systems than languages designed with portability in mind, like C.
I think portability means something different to you than it does to me. I don't expect to have a compiler everywhere I might want to execute a sequence of commands. I do expect: program & and program1 | program2 | program3 >file_or_device to work on all the machines I'm likely to use and to be a lot simpler than figuring out how to do that in C on various platforms.
(3) Each part of a system should do the things it does best. I find that when I need something relatively complicated, but not enormously complicated, often a program written in more than one language is best. I use the shell to process the directory tree, and use the tools available where I can, but if I need special processing then I write a one-off C program to do the specialized processing, which gets called perhaps like this:
$ find /path/to/somewhere -name "file*globbing*stuff*" -print | my_special_program ;
That's a reasonable approach, especially if my_special_program does something no one else has needed to do. On the other hand, if it is a text substitution or similar operation, you'd find an assortment of tools already available.
I might even use a loop or two in the shell stuff. But I do *not* do the complicated logic using the shell.
In many cases where complicated logic would be required, programs already exist to perform it, so you can base the shell operations on that program's results.
On Wed, 2005-12-28 at 21:37 -0600, Charles Howse wrote:
I don't mean to step on any toes, just want to start some discussion. Does anyone else have any thoughts on why questions don't get the respectful treatment they deserve?
I think some do themselves harm by the way they post. Three common things spring immediately to mind.
There's the obvious things about not starting a new thread for a new topic, just replying to someone else's completely different thread. Such lost messages get ignored/deleted by anybody ignoring the original thread. I do this a lot (ignore/delete threads I'm not following).
And huge long posts, with little or no snippage (whether replies are top or bottom posted, or interspersed). I hit delete on messages that are just masses of verbage, where we're supposed to find the salient parts buried somewhere extremely inconvenient. I'm sure lots of others do, too.
Hideously mangled messages that are difficult to read.
On Fri, 30 Dec 2005, Tim wrote:
On Wed, 2005-12-28 at 21:37 -0600, Charles Howse wrote:
I don't mean to step on any toes, just want to start some discussion. Does anyone else have any thoughts on why questions don't get the respectful treatment they deserve?
I think some do themselves harm by the way they post. Three common things spring immediately to mind.
then there's posts for which the subject field is essentially meaningless, as in:
"need help" "newbie question" (no subject)
all of which inspire an immediate "d".
rday
Charles Howse wrote:
I'd like to start a calm, respectful, reasonable discussion of the reasons that we tell people to RTFM, or reasons that people don't get their questions answered on mailing lists and usenet groups.
FLAME BAIT!
Sorry, couldn't resist :-)
Google for
+how +ask +question
turns up a very good site.
[snip]
I don't really know where to start, so here are some random thoughts...
Maybe I got told to RTFM because I missed something in it? Well, could you just politely point me to the section I missed, please? Or give me a link to a howto or some html page where it is explained?
That's the job of "apropos". You might need to pipe into "grep".
Maybe the question has been answered in the FAQ for the list? Just point me to it, you don't have to say anything else.
That's a whole separate issue. One should first lurk. If one cannot find the pointer to the FAQ using Google, or lurking, then a quick request for a pointer to the FAQ doesn't get bad results. Asking questions which are in the FAQ w/o having looked for it is bad manners.
I've seen lots of posts to this list and others with no subject or a subject that has nothing to do with the question, but the question was answered respectfully. So, when I post with a good subject, one that will show up in a Google search, help me out.
I normally delete entire threads if they don't have a subject or a subject of "(none)". The only question more stupid than an unasked one is one with a subject of "(none)", IMO.
[snip]
I think the members of this list are mostly doing things the way I would like to see them done, but I also think we could all do better, eh?
I don't mean to step on any toes, just want to start some discussion. Does anyone else have any thoughts on why questions don't get the respectful treatment they deserve?
Hmm? Very rare here, I think.
Mike
-
Antonio Olivares -
Arthur Pemberton -
Charles Heselton -
Charles Howse -
Craig McLean -
Craig White -
David L. Gehrt -
gary -
Gene Heskett -
James Wilkinson -
jdow -
Jeff Vian -
Jeremy Thompson -
John Summerfield -
Kam Leo -
Les Mikesell -
Lorenzo Sandini -
Michael A. Peters -
Mike Klinke -
Mike McCarty -
Neil Cherry -
Ow Mun Heng -
Patrick W. Barnes -
Rahul Sundaram -
Robert P. J. Day -
thomas cameron -
Tim -
Tom Pangborn