On Jun 22, 2012, at 2:33 PM, Marc Espie wrote: >>> A shell is one of the most complicated pieces of C code to get right, >>> between the fucked-up parser, the lazy evaluation, the arcane shit you >>> have to do to various file descriptors, and the signal handling. >>> >>> Among other things. >>> >> >> That's because you think the goal is to write a perfect shell. >> The goal is to use fork, exec, signals, process groups, etc... > > yeah, right... and do it without any proper courses either. > > So that, afterwards, when I quizz students, they don't even understand > how wait() works or anything about signal semantics. > > Yet they validated that specific project...
Doing coursework is like a good introduction, but cannot help grasp every concept and titbit of what you are doing. You'll do just as much as you need to in order to pass, and half of the code is probably wrong or simply not needed. I used to fix other semesters' coursework just for fun, and most of the time I wondered how they ever passed in the first place. The real enlightenment comes with the longer projects, when you can look at the same codebase day in, day out. You see the stuff you did half a year ago and shrug. You see other people doing unspeakable things (good and bad). And from time to time you realize the full potential of subtle bugs doing all kinds of crazy things. Sometimes it makes you laugh, sometimes you'll wonder who's going to get fired for it. But in the end you learn so much every day and you'll never be the same again. It really doesn't matter what you do, but if you are not going to use what you write you should think twice about doing it. Maybe you can also focus on adding that feature you always wanted to your favorite software and learn how to deal with revision control tools. Learn debugging unknown (and maybe complex) code, and even learn how hard it can be to avoid code regressions. Franco
