For instance I read all of "The Unix Programming Environment" by Kernighan and Pike. It's FULL of useful information (in fact I'd argue it's way better than reading man pages) and after I was done I felt like I was 10 times the Linux man I was. However unless you're fighting with Linux a lot on a daily basis you quickly forget 80-90% of what you read. For instance, I found it near impossible to remember what '@' does in bash scripts.
It's quite demoralizing - and I've had the same experience many many times with technical books. You not only have to read, but you also have to DO the things you read (strangely this isn't the case for history books, or books on the soft-sciences). This can be almost impossible for the more obscure (though still very useful) features like the zillions of cool-but-not-so-often-used flags you will come across in your man page reading.
When I have some spare time on my hands I like to skim manuals for those features. Vim for example, I have been learning continuously ever since I first used it and I dare to say that by now, I know a bit about it. However, I never sat down trying to memorize everything but kept skimming the help every now and then and when I found something cool I just tried to start using it. Some things I've forgot, others stuck.
I guess that's just the way I learn.
My ultimate goal in life is to write software for satellites, space probes or planetary rovers. I want my code in space. It's a pretty advantageous goal, but with hard work I can do it.
There is a Canadian company that is currently hiring for my dream position: http://www.mscinc.ca/about/MS-engineer.html
I'd like to help further Canada's contribution to space science.
I'm currently taking my first year of Computer Science. Getting really good at C is something I feel like I should start now. Then I'll need to get good at embedded C and eventually start looking at the VxWorks operating system since it seems like that's what most probes or satellites use. But that's for the future.
You can get your foot in the door with some more high level programs doing things like data processing and visualizations, and once you are there you will be able to find the opportunity to get your hands dirty with space code.
I worked in a group doing solar physics research and although my code didn't get pushed to a satellite, I did get to do a lot of awesome analysis on data sent back from the satellite.
You should browse sites like the AAS Job Register as well: http://jobregister.aas.org/
The Science Engineering and Support/Technical staff positions are often open to people without a PhD and offer a great opportunity to work on space science.
As an aside: How are you selecting your man pages? Do you have a specific group in your sights, or will you pick day by day?
Anyway, even in case you fall short of your goal, learning C can't be wrong. The language provides a very good abstract machine. Probably the best abstract Von-Neumann machine I've seen. Working with it is kind of mind expanding when it comes to understanding computers as well as problem-solving.
A quick suggestion since you said you were taking your first year of CS. Try to implement things you learn, especially algorithms and data structures. It will help you learn the material as well as coding and may give you a couple of insights.
After that, I may write a little shell script that simply opens one at random for me.
* Read your primary shell's manpage.
* Read alternative shell's manpages. Most particularly zsh, if you're not already using it.
* Look at your bash history and most frequently used commands. Read those manpages.
* Read manpages of language(s) you're looking to develop in.
* Read manpages for tools that are supplanting existing tools. E.g.: ip(8) vs. ifconfig(8).
* Read manpages for not just commands (1 & 8) but file formats (section 5), special files (4), and system and library calls (2 & 3).
* Follow references in manpages (the "SEE ALSO" section(s).
* Try reversing the process. Use apropos to find tools which accomplish a given task.
* On Debian or Ubuntu, install the dwww package and surf manpages locally at http://localhost/dwww/man/ within your web browser.
More interesting is how you go about making that change. What do you do (from types of goals you choose down to the daily implementation) to achieve your goals?
I always try to have a meaningful, measurable goal. I'm not going to lose weight, I'm going to lose 15 pounds in the next eight weeks. Then I break them down into tasks that can be followed daily, like measure all food consumed, exercise 45 minutes, etc.
The place where I struggle is the day-to-day tasks, and I still haven't found the answer. This can be especially hard for me on the winter as I deal with seasonal affective disorder (which is why I often wait until spring for my goals).
How do you manage your desire for growth and change?
One thing that worked for me (but I accept it might not work for everyone) that was given me by an occupational therapist was to break everything down into tiny tasks.
Thus, not "I will wash the dishes", but "I will gather everything that needs washing." then "I will scrape them off" and "I will clean the sink" then "I will put dishes in sink with hot hot water and dish soap" then "I will scrub them and let them drain" then "I will dry them" finally "I will put them away". Each task is small and easily achievable, even if it's a tough day. And doing one small task gives you a small sense of achievement, and gets you moving around. That might be enough for you to continue doing things, or you might decide that's enough for the day. But at least you've stopped things going backwards, and started making progress.
Another thing that helped me was having a rigid structure. Thus, Thursday is always "take the trash out". But don't overload each day with tasks. Just put 2 tasks per day, and make sure you include 1 thing for you each day.
I guess these are more useful when days are tough, rather than just everyday.
I also tried to break down my daily tasks into something that is actually manageable. I feel like many people, when breaking down their goals, tend to overload themselves or put themselves into a routine they simply can't manage or maintain for long periods of time.
Don't know what to make of that, other than to think that those two types of tasks are probably managed differently, and they probably give you different emotional payoff.
Rather than trying to go through one end of a tutorial or reference to the other (don't know if that's you), find a site or two of vim tips, and let them randomly trigger your mind. I think it's more interesting than going through anything beyond page/chapter 1 of a reference.
Coupled with that, whatever you find yourself doing in vim, take some time to understand what it is and the alternatives. Becoming familiar with :help's table of contents, rather than the contents of every chapter, is probably helpful here.
Similarly, when you do something accidentally, try to understand what happened. Sometimes you'll discover a feature. q: for example is discovered by accident by many people, including me.
Bram Moolenaar's seven habits has great insights about this subject: http://www.moolenaar.net/habits.html
(1) What is the command
(2) What kinds of things you can accomplish with it
(i.e. why should I learn this command? how will
it benefit me)
(3) Examples of the command applied by itself
(4) Examples of the command applied in conjunction with
commands you've previously written about via piping.Good luck. New Years Resolutions are great, stay motivated.
So I'd recommend doing a bit more than reading the man page. The best suggestion I can think of is to also read the top 3-5 questions on StackExchange that mention that command.
PS: after reading the man page for man itself, I recommend 'man apropos'. :)
I'll definitely check out 'apropos'. :)
p.s. I'm from Winnipeg, the city Winnie the Pooh is named after.
Of course, maybe the only way for you to realize this is by actually trying to memorize man pages and doing lots of programming exercises first. That's what it took in my case...
And since you're stocking up on C, don't forget that C's standard library is documented via man pages, e.g.
man -k sprintf
asprintf (3) - print to allocated string
sprintf (3) - formatted output conversion
vasprintf (3) - print to allocated string
vsprintf (3) - formatted output conversion
XtAsprintf (3) - memory management functions