Hi I am planning to solve the Kernighan and Pike Exercises on the book " The Unix Programming Environment".
I would like to validate my responses if anyone has already solved the exercises.

I would like to understand the basic difference between echo & ls?

Ls / echo /

Ls echo

Ls * Echo *

Ls '*' Echo '*'

Do you have a virtual machine for Linux?

Install it and see the difference.

Or just burn a live cd and boot from it.

1 members found this post helpful.

See man echo and man ls ...

1 members found this post helpful.

echo is a command that will print a string passed to it onto the command line. For example, echo hello prints hello. This is most useful in scripts. ls lists all of the files and folders in the directory you are currently in. The man command that scasey is referring to allows you to look up more detailed documentation for commands, but I honestly don't think that's a great place to start.

Where would you have newbies start if not with the documention?
Please explain how “read the manual” (RTM) is not good advice. Most here are not going to try to explain a command in a sentence, as you did, as that effort has a likelihood of not being complete or correct.

You did marginally OK with echo, but your “definition” of ls completely missed the boat, IMO.

Very basically, ls shows something, whilst echo produces something.

1 members found this post helpful.

scasey, I'm not trying to completely discourage them from reading the manual. I just don't find that to be the best place to start, in my experience. I usually just use a search engine and click the first few results I find. The documentation is good if you are looking for specific details of the command, and I often use it for that. However, in my opinion, it is often not organized in a way to make it an easy place to start with a new command. How about we recommend trying both methods and letting the original poster choose his/her own favorite.

1 members found this post helpful.

In response to the original question, I feel that web searching, viewing the manual pages for each, as well as trying them out, will be excellent help with determining an answer for their question.

At the very least, they'd get experience with seeing the outputs of those 4 forms of commands, and if they actually used a Linux system, they could easily obtain manual page information on each command.

I feel a lot of people don't like to hear this:

They absolutely do need to learn to read the Linux documentation.

Why? Mainly my background and experience, former and current.

I've searched for things on the web, and you find some answers, you find some opinions, you find a lot. Great. As problems grow in complexity, or difficulty, the simple first echelon of obtaining an answer becomes woefully insufficient.

I learned to view the man pages for C library functions or command line functions, maybe just to learn what they were really there for, what their actual synopsis was. That is an example of a first echelon answer in my humble opinion.

However as I progressed with reading more from the man pages, I learned that there are other references, I learned what .h files are needed for a certain library call, I learned what forms of returns and errno values I could expect for these calls, and I learned more information about the command or library call that I hadn't expected, or could not draw upon from general comments on the web unless I was fortunate enough to stumble across a comment from someone noting an unusual behavior. I also learned whether or not a command or library call had been deprecated and if there were replacement suggestions. I also learned that there were reentrant variations of many library functions. You also see things such as how memcpy() is not to be used for overlapping memory regions, but there is a recommended alternative.

Basically I learned how to "read" man pages and benefit from the total information available in them. I learned how to search very lengthy ones.

All of these techniques I use every day. I visited a few man pages in support of my comments here and just to verify what I said about memcpy(). I have been exposed to that information, but there's so much, that I'd not just write it out without at least checking the validity of it.

These are the types of "talents" which new users need to be steered towards. I feel it is fine to guide them with direct statements, however I also feel it is our responsibility to point out to people "how" they take their next steps and the formats where this information is very inclusively given. From there, I feel they stand a better chance of being someone who can self learn how to diagnose or debug their issues.

1 members found this post helpful.

@rmistler
Agree on your statement, most newbies/millennial like instant. Instant noodles, instant coffee and instant learning.

That's why most newbies don't care what's happening on the background, they just want what they want. They don't care how it was done.

Problem is, not everything goes smoothly. When troubleshooting comes on the way, that's it. Point here and there.

Gone is the era that you need to troubleshoot for hours, days or weeks. Now search engine, and forums like this comes in handy.

But still boils down, how an individual steer his/her strategy to get things done.

1 members found this post helpful.