The body language is quite distinctive - tentatively pressing keys with an outstretched index finger as if the keyboard might jump up and bite them, pushing around the mouse with their fingertips rather than grasping it with their whole hand, leaning away from the screen as if it might explode in their face.
Some older people just can't internalise the idea of looking at the screen for clues as to how to proceed. No matter how many times they're told and shown, they just don't get the idea that computing is interactive. They try to memorise every interaction as a series of rote steps, so if something unexpected happens they're completely lost. They are completely incapable of navigating a UI without very explicit instruction, even if it's broadly similar to UIs they know how to navigate. Something as trivial as accidentally scrolling down a few lines on a website is a complete showstopper. I don't understand it, but I find it endlessly fascinating.
I wonder how much it would help these people if you framed it more as an interaction with a person. Which it is. For example, telling them things like "OK so the programmer who wrote this told the computer to grab that bit you just typed, and display it for you over here [point, point] for your reference." In other words I wonder whether knowing a little about what's going on inside the thing, and the fact that it was just some silly ordinary dufus that wrote the software, helps a person like that be a better end-user.
Oh, and when you ask them to "look at the screen", they're only mentally able to process a 2-square-inch "window area" at any given moment. So you first have to direct their gaze, very specifically, before you can actually expect them to read and process anything. (Of course it doesn't help that many of them used bifocals that made it difficult to actually see anything up close, except maybe a book, without squinting at a weird angle. Not sure if that's still an issue today.)
The same thing happens to my kids when I present them with a bash shell. They don't understand how to read the instructions, and they're uncomfortable with text commands. They don't want to type 'man' or 'help', and they give up very quickly. Everything they use on computers and game consoles are GUIs, most of them extremely easy to use by the standards of text interfaces like bash & vi.
This is a familiarity problem. You have years and years of experience with your OSes, which is what allows you to see outside the 2-inch window when you use a new application. You know exactly what you can ignore, and exactly what you need to pay attention to. They don't. Being unfamiliar with all of it and not having any idea how any of it works is what makes it seem like they're not learning quickly, but it's more because they're trying to learn everything at once, and are overwhelmed, not because they're not learning at all.
Uhm, the issue here is squarely on Bash's end, not your kid's. Even the Windows command prompt is far more intuitive to learn. I know because I vividly remember how much more confused I got when learning the former.
In Windows, when you type "help", it actually gives you helpful commands: COPY, MOVE, DEL, REN/RENAME, etc. and at least the basic commands are actually what you'd expect. At least you have a foothold somewhere that you can ground yourself, and you start learning a bit more every time.
Try that in Bash, and good luck learning out how to do anything in Bash on your own. Oh, you want help? I gotchu! I'm guessing you're looking for job_spec, bg, compopt, coproc, disown, shopt, or trap? Oh I'm so sorry, you said all you wanted was to just copy a file? Haha I'm just a shell! You can't expect me to know how know what it means to "copy" a file! I can't even find that command! But if you need help, type "man -k" (what kind of a name is that??) to find out more about other commands. Oh, so you typed "man -k"? Okay, "apropos what?"??? (You, thinking to yourself: is 'apropos' even an English word?? I literally just typed in man -k like they told me to, and I got back a question I don't understand...) And on and on and on, until weeks later you realize the darn command was helpfully named 'cp' and not 'copy'...
But, my point is that my kids lose all their confidence and all their patience, and they become tentative and fearful. They show all the same symptoms that were mis-attributed to age in the above comments.
On a game console, my kids are not afraid to explore every menu and push every button. In a text interface, they are lost and they don't try things. They seem to learn slowly and they don't seem to listen to instruction because of how different text UIs are from the GUIs they know. When I get a new text interface, I know all kinds of things to try, and I do so without much fear.
Yes, this. I recall back in the MS-DOS days that I frequently used a text-GUI help menu that showed all the commands you could do and what each one did.
Personally, this is what I struggle with on *nix shells - I can do the very basics but there's little guidance showing you a broad overview of what is possible. Granted, the world is bigger now but if you asked me how to do a random task I'd probably google it first instead of reading a man page.
Once you learn the 8000 or so commands, it becomes incredibly intuitive.
It's not just the shells! ;)
Yes, MS-DOS was easy to learn. XCOPY worked in MS-DOS.
"copy doesn't copy directory structures, it will only copy the files, hence the error message you're encountering. To do a deep copy such as this you can enlist either the tar command and use the construct tar cvf - --files-from=... | (cd /home/tmp/test/files/; tar xvf -) or you can just use rsync."
That's so much better..
The issue in the question is that the person has expanded, into the cp command line, a bunch of full paths, effectively like "cp a/b/c/file1 a/b/d/file2 .... dest" and wants those relative paths to be re-created under dest as dest/a/b/c/file1 and so on. Indeed, cp does not do that; it simply puts the specified objects file1 file2 ... into dest.
An option to create each object's relative path under dest would be useful, but it would be a pretty awful default behavior.
GNU cp has this option:
Form the name of each destination file by appending to the target
directory a slash and the specified name of the source file. The
last argument given to `cp' must be the name of an existing
directory. For example, the command:
cp --parents a/b/c existing_dir
copies the file `a/b/c' to `existing_dir/a/b/c', creating any
missing intermediate directories.
If you lack that basic curiosity and courage, I don't really know how "intuitive" anything can be. Isn't "intuition" driven by understanding concepts behind things? The best way to get that intuition is through a bit of instruction and a lot of experimentation.
Now, you might answer that you can't really break anything that badly with software, but I'd say that's not right. I could delete documents I needed with no way to recover them, or end up with ransomware, or end up putting my credit card number somewhere I shouldn't have, or whatever, and I'll likely be bewildered and unsure what happened, if I don't know anything about computers.
This is the exact same problem I've always had many times when tinkering with electronics, so I can wholeheartedly understand it. Fortunately with computers you can pretty much promise laymen that any problem they cause fixable with no cost (except time), but in the case of electronics I find it much more difficult to overcome the fear that I might actually physically fry something and need to buy a new one. Anyone have tips for that?
A few tips:
- Do not touch anything you cannot afford to lose.
- Buy at least twice as many components as needed for a project, if this is too expensive, that's a good sign you might want to get more experience with more simple projects before taking on this one.
- Avoid soldering as much as possible, at least at the beginning.
- If you want to learn how to solder do it with very simple circuits like those that only include LEDs and resistors. Practice a lot and then use your skills on a project you like.
- If possible, measure components before installing, do not trust your knowledge of color codes or nomenclature or pins configurations in the case of diodes and transistors.
- When tinkering with digital circuits try to use only 5V level components, avoid 3.3V components. Of course you can use converters to interface but it's nice to avoid that complexity at the beginning.
Hope this helps.
Set yourself a learning budget and accept that blowing things up is part of the experience. It's not terribly expensive to buy a large stock of basic components. Sellers like Banggood offer assortments of resistors, capacitors, diodes and transistors for a few bucks. Arduino Nano clones are about $2 each on Aliexpress, so buy half a dozen. The Aneng AN8008 multimeter is more than good enough for student use and costs less than $25; a Daniu DT832 is perfectly usable for basic measurements and costs about $5, so it's no tragedy if you blow it up. You can find an old analog oscilloscope on eBay for about $50.
If you're getting into repair, ask your local thrift stores for broken electronics or buy a job lot of cheap broken stuff on eBay. If you can't fix it, you can always scavenge it for components.