10 ms·

2013 Resolutions: a man page a day makes the newb go away

37 points by sobering 14y ago

SoftwareMaven 14y ago
Naturally, this is the time of year to make goals and attempt to change. What a person feels like they need to change and whether that is a "good change" or not is highly personal and probably doesn't require much comment. 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?
- sobering 14y ago
  I too, seem to struggle with the day to day tasks. I hope that by publicly announcing my goals, it will make it slightly easier. 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.
- DanBC 14y ago
  > The place where I struggle is the day-to-day tasks, and I still haven't found the answer. 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.
- antidoh 14y ago
  Some tasks contribute directly to goals, other tasks just get you through the day. 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.
seanwoods 14y ago
How will you know which man page to read "next"?
- sobering 14y ago
  So far the plan is to start with "man" and then go through the man pages of my most commonly used commands: cd, ls, grep, cat, sed, etc. After that, I may write a little shell script that simply opens one at random for me.
  - aleprok 14y ago
    Please share that script when you do it. It might be fancy to read man pages when one is bored instead of watching something as the randomness might dig some cool facts of the system for you which you did not know before hand.
    - sobering 14y ago
      Just found this little snippet via a quick Google search: dir="/bin"; man $(ls $dir |sed -n "$(echo $(( $RANDOM % $(ls $dir |wc -l | awk "{ print $1; }" ) + 1 )) )p") I think I may write my own version as well. Just to gain a bit more experience with shell scripting.
      - ciupicri 14y ago
        Unfortunately there are a couple of commands that don't have a man page, e.g. mpplu (from argyllcms-1.4.0-2.fc17.x86_64) or showchar (from psutils-1.17-38.fc17.x86_64).
        npsimons 14y ago
        I know the OP said he was a VIM guy, but here's my first approximation to a random manual page script for emacs; it doesn't strip out directories (like man1) or specify different sections of the manual, but it indexes manual pages, so you not only won't try opening pages for commands that don't have them, but you'll get other pages too (eg, the TCL library man pages): ;; Taken from http://emacswiki.org/emacs/ElispCookbook#toc57 (defun directory-dirs (dir) "Find all directories in DIR." (unless (file-directory-p dir) (error "Not a directory `%s'" dir)) (let ((dir (directory-file-name dir)) (dirs '()) (files (directory-files dir nil nil t))) (dolist (file files) (unless (member file '("." "..")) (let ((file (concat dir "/" file))) (when (file-directory-p file) (setq dirs (append (cons file (directory-dirs file)) dirs)))))) dirs)) ;; Taken from ;; http://stackoverflow.com/questions/3815467/stripping-duplicate-elements-in-a-list-of-strings-in-elisp (defun strip-duplicates (list) (let ((new-list nil)) (while list (when (and (car list) (not (member (car list) new-list))) (setq new-list (cons (car list) new-list))) (setq list (cdr list))) (nreverse new-list))) ;; Display a random manual page (defun open-random-man-page () (interactive) ;; Get manual page paths from the environment. (setq man-paths (parse-colon-path (getenv "MANPATH"))) (setq man-dirs ()) (dolist (man-path man-paths) (setq man-dirs (append man-dirs (directory-dirs man-path)))) ;; Get a list of files in manual page paths. (setq files ()) (dolist (man-dir man-dirs) (setq files (append files (directory-files man-dir nil "^[^\.].*")))) ;; Fixup the files to be a list of man pages. (setq man-pages ()) (dolist (file files) (setq man-pages (cons (car (split-string file "\\." t)) man-pages))) (setq man-pages (strip-duplicates man-pages)) (random t) (man (nth (random (length man-pages)) man-pages))) Be aware that Emacs lisp is still something I'm learning; I'm sure the above could be improved.
g2e 14y ago
Instead of man pages, I'm doing it with books. Goodreads.com makes it pretty easy (and fun) to manage everything. My goal is to get through all the classics this year and of course, like you said, apply that knowledge to my everyday programming.
- sobering 14y ago
  Best of luck to you! I think it's really important to actually apply new knowledge to your everyday workflow. It's far too easy to go and read a book, blog post, or article and then just let that information go to waste.
WinnyDaPoo 14y ago
Neat! You should keep track of your man page reading and share your experience! I'm anticipating your homepage growing into a wonderful electronic flower of information.
- sobering 14y ago
  Hah! 'electronic flower of information'. Awesome. p.s. I'm from Winnipeg, the city Winnie the Pooh is named after.
thinkling 14y ago
More than worrying about what to read next, I'd worry about fully understanding how a command is used in practice. It's one thing to read (say) the xargs man page and another thing to have a sense where it'll come in handy. Similarly, some commands have dozens of options, while you only need to understand a few for most of the common uses. 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'. :)
- sobering 14y ago
  The StackExchange idea is excellent. I'll get a sense of how the command should be used in real environments. I'll definitely check out 'apropos'. :)
temp453463343 14y ago
While I think it's a neat idea - I think in the end it's gunna be a case of in-one-ear out-the-other. 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.
- sobering 14y ago
  Agreed. I've had the same demoralizing experience with books and manuals in the past. What I really hope to do after reading each manual page is use it throughout the day wherever I can. Someone else also suggested reading some StackExchange questions on each command. I think that will be beyond valuable, and provide some real world uses that I can add to my toolbelt.
- npsimons 14y ago
  This is why I try to focus on books with exercises and force myself to finish all the exercises - "Thinking in C++" (volumes 1 and 2) was especially good for this. If nothing else, typing in examples helps. Also, try slowing down and forcing yourself to think of better/alternate ways to do something. Just having read the docs, your mind will be more open to using different options, and by forcing yourself to do it differently (even if you have to look it up again), will help to reinforce.
  - tinym 14y ago
    "Don't just read it; fight it! Ask your own questions, look for your own examples, discover your own proofs. Is the hypothesis necessary? Is the converse true? What happens in the classical special case? What about the degenerate cases? Where does the proof use the hypothesis?"
rickdale 14y ago
I recommend starting with one task and adding to it as the year goes on. Learning the man pages could potentially make you a better programmer without reading K&R. Set K&R aside until February and achieve your first goal. It's important to change one behavior at a time and expect and plan for failure. Shoot for 5-6 days a week with 1 day review, or 3 with 2 days review, and just do what you feel with the extra day. Review or move forward. Good luck. New Years Resolutions are great, stay motivated.
- sobering 14y ago
  Thanks for the advice. I've already gone through K&R, but I just got the C Answer Book in the mail a couple months back and wanted to go through all the exercises again. I'll just have to really pace myself and not take in more information than I can handle in a single day.
  - deleted 14y ago
    [deleted]
pacomerh 14y ago
May I ask why your desire to learn C?, I'd just like to know what are you targeting specifically.
- sobering 14y ago
  Don't laugh. 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 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.
  - codezero 14y ago
    This is a pretty reasonable goal. I suggest you also consider learning FORTRAN (starting with 77) and a solid scripting language like Python or the more niche IDL (used extensively in space research) 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/ 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?
    - sobering 14y ago
      Thank you for the advice, you've definitely given me some stuff to thing about, and I'm glad to hear from somebody who's worked in a field similar to what I'd like to get into. As for the man pages, I'm starting off with 'man', then will move onto my most commonly used commands for general Linux use and server administration. After that, I'll be using a shell script to give me a random man page.
npsimons 14y ago
This is such a good idea, I've added it to my goals, under my "Invest in Knowledge Portfolio" category. One thing that scares me a bit though is that some man pages are enormous, possibly more than can be digested in one sitting.
Jbudone 14y ago
I hope this works out for you. I've taken up learning vim this year, but my main problem is forgetting the things I've learned. I tried cue cards but they fill up far too quickly; so my answer was to store my notes on a wiki: http://wiki.jbud.me/index.php?title=Vim http://wiki.jbud.me/index.php?title=Vim
- antidoh 14y ago
  Vim is too big to learn. Eventually you'll muscle-memory a set of actions, for the way that you uniquely use vim, that you don't even know how to explain without thinking about it. 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.
- johncoltrane 14y ago
  I second taking notes as you go, here are mines (from 2 years ago, in french): https://github.com/romainl/dotvim/wiki/Notes https://github.com/romainl/dotvim/wiki/Notes Bram Moolenaar's seven habits has great insights about this subject: http://www.moolenaar.net/habits.html http://www.moolenaar.net/habits.html
georgeorwell 14y ago
Some preemptive advice: pick a small (tiny!) project and do it with C and/or sh and other command line tools (don't forget about awk and sed). Often you can do something quickly in a shell script that would be a pain to implement in C, but the reimplementation can still be a good learning experience. Once complete, repeat. You will learn far more like that than by trying to memorize man pages and doing programming exercises out of a book. I mean, did you try "man gcc"? 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...
tsahyt 14y ago
The ultimate goals section lists mainly things I've done in 2012. I've benefited hugely from every single one and can only recommend those things to anyone (especially becoming a better C programmer).
antidoh 14y ago
In addition to randomly generating a man page from /bin, consider mining your command line history and randomly selecting anything whose man page you haven't yet read. You'll want to keep a file of man pages that you've read, to help with that. 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
ismiseted 14y ago
Good plan. I've started to print out man pages and using them for learning / reference. This post: http://macgeekery.com/tips/cli/pretty-print_manual_pages_as_ps_pdf_or_html http://macgeekery.com/tips/cli/pretty-print_manual_pages_as_... got me set up using groff to pretty-print the good stuff.
malandrew 14y ago
One thing I'd love to see if you embark and stick to this new year's resolution is creating a blog post per man page with all the exercises and examples you tried out by applying what you've learned from each man page. It'd be great if each post included something like: (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.
- sobering 14y ago
  That's what I had planned. Thanks for creating an outline for me. ;)
  - malandrew 14y ago
    Also check out the many posts by catonmat (peteris krumins) about linux commands and scripting. I find that they are good examples of blog posts on how to use standard command line utilities.
bdreadz 14y ago
Off topic: I love how this was just typed up in a text file. I love using my text editor for writing and I wish more people I worked with did too.

37 points by sobering 14y ago

Naturally, this is the time of year to make goals and attempt to change. What a person feels like they need to change and whether that is a "good change" or not is highly personal and probably doesn't require much comment. 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?

sobering 14y ago
I too, seem to struggle with the day to day tasks. I hope that by publicly announcing my goals, it will make it slightly easier. 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.
DanBC 14y ago
> The place where I struggle is the day-to-day tasks, and I still haven't found the answer. 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.
antidoh 14y ago
Some tasks contribute directly to goals, other tasks just get you through the day. 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.

seanwoods 14y ago

How will you know which man page to read "next"?

sobering 14y ago
So far the plan is to start with "man" and then go through the man pages of my most commonly used commands: cd, ls, grep, cat, sed, etc. After that, I may write a little shell script that simply opens one at random for me.
- aleprok 14y ago
  Please share that script when you do it. It might be fancy to read man pages when one is bored instead of watching something as the randomness might dig some cool facts of the system for you which you did not know before hand.
  - sobering 14y ago
    Just found this little snippet via a quick Google search: dir="/bin"; man $(ls $dir |sed -n "$(echo $(( $RANDOM % $(ls $dir |wc -l | awk "{ print $1; }" ) + 1 )) )p") I think I may write my own version as well. Just to gain a bit more experience with shell scripting.
    - ciupicri 14y ago
      Unfortunately there are a couple of commands that don't have a man page, e.g. mpplu (from argyllcms-1.4.0-2.fc17.x86_64) or showchar (from psutils-1.17-38.fc17.x86_64).
      - npsimons 14y ago
        I know the OP said he was a VIM guy, but here's my first approximation to a random manual page script for emacs; it doesn't strip out directories (like man1) or specify different sections of the manual, but it indexes manual pages, so you not only won't try opening pages for commands that don't have them, but you'll get other pages too (eg, the TCL library man pages): ;; Taken from http://emacswiki.org/emacs/ElispCookbook#toc57 (defun directory-dirs (dir) "Find all directories in DIR." (unless (file-directory-p dir) (error "Not a directory `%s'" dir)) (let ((dir (directory-file-name dir)) (dirs '()) (files (directory-files dir nil nil t))) (dolist (file files) (unless (member file '("." "..")) (let ((file (concat dir "/" file))) (when (file-directory-p file) (setq dirs (append (cons file (directory-dirs file)) dirs)))))) dirs)) ;; Taken from ;; http://stackoverflow.com/questions/3815467/stripping-duplicate-elements-in-a-list-of-strings-in-elisp (defun strip-duplicates (list) (let ((new-list nil)) (while list (when (and (car list) (not (member (car list) new-list))) (setq new-list (cons (car list) new-list))) (setq list (cdr list))) (nreverse new-list))) ;; Display a random manual page (defun open-random-man-page () (interactive) ;; Get manual page paths from the environment. (setq man-paths (parse-colon-path (getenv "MANPATH"))) (setq man-dirs ()) (dolist (man-path man-paths) (setq man-dirs (append man-dirs (directory-dirs man-path)))) ;; Get a list of files in manual page paths. (setq files ()) (dolist (man-dir man-dirs) (setq files (append files (directory-files man-dir nil "^[^\.].*")))) ;; Fixup the files to be a list of man pages. (setq man-pages ()) (dolist (file files) (setq man-pages (cons (car (split-string file "\\." t)) man-pages))) (setq man-pages (strip-duplicates man-pages)) (random t) (man (nth (random (length man-pages)) man-pages))) Be aware that Emacs lisp is still something I'm learning; I'm sure the above could be improved.

g2e 14y ago

Instead of man pages, I'm doing it with books. Goodreads.com makes it pretty easy (and fun) to manage everything. My goal is to get through all the classics this year and of course, like you said, apply that knowledge to my everyday programming.

sobering 14y ago
Best of luck to you! I think it's really important to actually apply new knowledge to your everyday workflow. It's far too easy to go and read a book, blog post, or article and then just let that information go to waste.

WinnyDaPoo 14y ago

Neat! You should keep track of your man page reading and share your experience! I'm anticipating your homepage growing into a wonderful electronic flower of information.

sobering 14y ago
Hah! 'electronic flower of information'. Awesome. p.s. I'm from Winnipeg, the city Winnie the Pooh is named after.

thinkling 14y ago

More than worrying about what to read next, I'd worry about fully understanding how a command is used in practice. It's one thing to read (say) the xargs man page and another thing to have a sense where it'll come in handy. Similarly, some commands have dozens of options, while you only need to understand a few for most of the common uses. 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'. :)

sobering 14y ago
The StackExchange idea is excellent. I'll get a sense of how the command should be used in real environments. I'll definitely check out 'apropos'. :)

temp453463343 14y ago

While I think it's a neat idea - I think in the end it's gunna be a case of in-one-ear out-the-other. 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.

sobering 14y ago
Agreed. I've had the same demoralizing experience with books and manuals in the past. What I really hope to do after reading each manual page is use it throughout the day wherever I can. Someone else also suggested reading some StackExchange questions on each command. I think that will be beyond valuable, and provide some real world uses that I can add to my toolbelt.
npsimons 14y ago
This is why I try to focus on books with exercises and force myself to finish all the exercises - "Thinking in C++" (volumes 1 and 2) was especially good for this. If nothing else, typing in examples helps. Also, try slowing down and forcing yourself to think of better/alternate ways to do something. Just having read the docs, your mind will be more open to using different options, and by forcing yourself to do it differently (even if you have to look it up again), will help to reinforce.
- tinym 14y ago
  "Don't just read it; fight it! Ask your own questions, look for your own examples, discover your own proofs. Is the hypothesis necessary? Is the converse true? What happens in the classical special case? What about the degenerate cases? Where does the proof use the hypothesis?"

rickdale 14y ago

I recommend starting with one task and adding to it as the year goes on. Learning the man pages could potentially make you a better programmer without reading K&R. Set K&R aside until February and achieve your first goal. It's important to change one behavior at a time and expect and plan for failure. Shoot for 5-6 days a week with 1 day review, or 3 with 2 days review, and just do what you feel with the extra day. Review or move forward. Good luck. New Years Resolutions are great, stay motivated.

sobering 14y ago
Thanks for the advice. I've already gone through K&R, but I just got the C Answer Book in the mail a couple months back and wanted to go through all the exercises again. I'll just have to really pace myself and not take in more information than I can handle in a single day.
- deleted 14y ago
  [deleted]

pacomerh 14y ago

May I ask why your desire to learn C?, I'd just like to know what are you targeting specifically.

sobering 14y ago
Don't laugh. 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 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.
- codezero 14y ago
  This is a pretty reasonable goal. I suggest you also consider learning FORTRAN (starting with 77) and a solid scripting language like Python or the more niche IDL (used extensively in space research) 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/ 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?
  - sobering 14y ago
    Thank you for the advice, you've definitely given me some stuff to thing about, and I'm glad to hear from somebody who's worked in a field similar to what I'd like to get into. As for the man pages, I'm starting off with 'man', then will move onto my most commonly used commands for general Linux use and server administration. After that, I'll be using a shell script to give me a random man page.

npsimons 14y ago

This is such a good idea, I've added it to my goals, under my "Invest in Knowledge Portfolio" category. One thing that scares me a bit though is that some man pages are enormous, possibly more than can be digested in one sitting.

Jbudone 14y ago

I hope this works out for you. I've taken up learning vim this year, but my main problem is forgetting the things I've learned. I tried cue cards but they fill up far too quickly; so my answer was to store my notes on a wiki: http://wiki.jbud.me/index.php?title=Vim http://wiki.jbud.me/index.php?title=Vim

antidoh 14y ago
Vim is too big to learn. Eventually you'll muscle-memory a set of actions, for the way that you uniquely use vim, that you don't even know how to explain without thinking about it. 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.
johncoltrane 14y ago
I second taking notes as you go, here are mines (from 2 years ago, in french): https://github.com/romainl/dotvim/wiki/Notes https://github.com/romainl/dotvim/wiki/Notes Bram Moolenaar's seven habits has great insights about this subject: http://www.moolenaar.net/habits.html http://www.moolenaar.net/habits.html

georgeorwell 14y ago

Some preemptive advice: pick a small (tiny!) project and do it with C and/or sh and other command line tools (don't forget about awk and sed). Often you can do something quickly in a shell script that would be a pain to implement in C, but the reimplementation can still be a good learning experience. Once complete, repeat. You will learn far more like that than by trying to memorize man pages and doing programming exercises out of a book. I mean, did you try "man gcc"? 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...

tsahyt 14y ago

The ultimate goals section lists mainly things I've done in 2012. I've benefited hugely from every single one and can only recommend those things to anyone (especially becoming a better C programmer).

antidoh 14y ago

In addition to randomly generating a man page from /bin, consider mining your command line history and randomly selecting anything whose man page you haven't yet read. You'll want to keep a file of man pages that you've read, to help with that. 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

ismiseted 14y ago

Good plan. I've started to print out man pages and using them for learning / reference. This post: http://macgeekery.com/tips/cli/pretty-print_manual_pages_as_ps_pdf_or_html http://macgeekery.com/tips/cli/pretty-print_manual_pages_as_... got me set up using groff to pretty-print the good stuff.

malandrew 14y ago

One thing I'd love to see if you embark and stick to this new year's resolution is creating a blog post per man page with all the exercises and examples you tried out by applying what you've learned from each man page. It'd be great if each post included something like: (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.

sobering 14y ago
That's what I had planned. Thanks for creating an outline for me. ;)
- malandrew 14y ago
  Also check out the many posts by catonmat (peteris krumins) about linux commands and scripting. I find that they are good examples of blog posts on how to use standard command line utilities.

bdreadz 14y ago

Off topic: I love how this was just typed up in a text file. I love using my text editor for writing and I wish more people I worked with did too.