SiriusHardware wrote:Not just kids, actually, but anyone who wasn't born speaking Linux!
Few people are...when I was born, not only did Linux not exist, but the "stored program concept" hadn't been published. Somehow...I still cope.
Unless I'm mistaken much of what appears in these forums is pitched way above the level of most kids and adults who have never used Linux before. If you gave a Raspberry Pi, straight out of the box, to a child, and this website was their first point of contact then I could not blame them if they gave up. The info they need ito get started is here, but it is swamped by all the other stuff.
It varies quite a bit, mostly depending on which Forum section you're in. There are beginners/new Linux users help sections. There is the Quick Start section of the web site as well.
Although a direct query about a problem will often a receive a literal answer which may solve the problem, for which I am always grateful, the logic behind / meaning of the solution is only rarely explained.
Believe me...it could be worse. In fact, it could be *far* worse. In environments where people are expected to do at least some basic research to *try* to solve their own problems, a very common response to question is "RTFM", which is "Read the [Fine] Manual"...that is: look it up yourself. The closest the Pi Forums come to that is when someone simply posts a link to the Wiki, stating that the answer is there.
How much explanation I give when answering questions depends on how much knowledge the person asking shows initially coupled with *where* the question is asked. For instance, it I answer a question in the New to Linux Forum, I am far more likely to expand the answer and give some history as to why the answer is what it is, why that is the answer and--possibly--how to arrive at such an answer on ones own in the future. I do that as gently as I can. In the Power Users Forum, if it was a question I could answer at all, I'd probably just give the answer as anyone posting there ought to have the background to figure out the rest on their own already.
It will often be a convoluted line of Linux command, the meaning of which - because of the generally shorthand and often non-logical choice of keywords for Linux - will not be in the least bit obvious.
For example, 'grep'. Just from looking at that word, who could possibly guess what it does?
Well.... At the risk of giving a useless answer ("grep" is "general regular expression print"), detailed answers to questions like that are, in fact in the (programmers) manual that comes with any Linux or unix installation. The way to get that is to enter "man <commandname>" at a CLI prompt. In this case..."man grep" will tell you all about it. Now I will grant you that doing that with grep will give a new Linux/unix user information overload, but the data *is* there. Tutorials for the more...expansive...commands are all over the web and can be easily searched for...or you can ask if someone know of a particularly *good* tutorial given subject. (Or a particularly good *book* if you want to retain a local reference work.)
Beyond that, if a command appears to be overly complex, you can either break it down into its component parts, ask what each part does, or ask for an explanation of *why* the command is structured the way it is.
So the OP who posts a query types in the command they have been given and, wonder of wonders, it works.. but they are often left with no idea of what it was they just did, or what it meant, and will be unlikely to remember it the next time.
That's why I prefer to give some background when dealing with a naive user. To that end I'm going to give you an example....
I have a Pi set up as a rudimentary "alarm clock". I use the system feature that allows one to initiate a command at specified times and dates. For instance, I have a regular Monday to Saturday wake up time, and a different one on Sunday. What my wife and I wake up to is an audio stream over the internet from the local Classical music radio station.
Now....I said this is "rudimentary" because, while I use the system feature to "turn on" the "radio" every morning, I don't turn it off.
So how do I turn it off when I want to?
The *method* to do so is to use the "kill" command to stop the processes that the streaming audio is running on. But kill works on the IDs of the processes...and I don't know what those are...so I have to find out. To do that, I use "ps" (process), specifically, "ps -C mplayer", which tells ps that I only want to see process information about anything named "mplayer". That will give me the process IDs (and some headers) and I can then use kill to stop mplayer. So the command used would be...
Code: Select all
ps -C mplayer
kill <process1. <process2>
But suppose I want to do it all one line and not need to type in the process IDs to kill? This is where two more commands come in.
One command is "grep", which will return all lines from a file (or, as I'm going to use it, the output from another command), and "cut" which will trim each line of a file based on what it is told to cut out.
So I could do this...
Code: Select all
ps -C mplayer > tempfile1
grep mplayer tempfile1 > tempfile2
cut -d ' ' -f 1 tempfile2
rm tempfile*
Now...packing that all together to make a single command (using the "|" --pipe construct), I get...
Code: Select all
ps -C mplayer | grep mplayer | cut -d ' ' -f 1 | kill
Is that a clear enough explanation for someone new to Linux?
)
