> > I wouldn't explain pipes much except to say that we can capture output > instead of sending it to the screen, for example: > > grep foo file | less > > Then we have to do stuff like > > sort file | head > Ohh, that makes sense. The pipe is pretty central to stuff we normally do, so they need that. > Subshell can wait, but this is the kind of thing I do a lot, when a flat db > text file has a header line with field names: > > ( head -1 file ; tail -n+2 file | sort ) > outfile > That sorts the file except for the header line and preserves the header. > I think that might be a good way to approach something like this, at least for the non-superuser type people. I mean, people who want the functionality, but lack the background experience/knowledge. Learning out of necessity is great to learn(sometimes). It might help to present a problem, find a solution, prove the solution does *exactly* what you want it to do, and in the end explain why the solution works. We're using Torque PBS, so they have to learn that, too. > That's pretty neat. What are you guys doing with Tourque? -> Jake On Thu, Mar 21, 2013 at 10:03 AM, Mike Miller <mbmiller+l at gmail.com> wrote: > On Thu, 21 Mar 2013, Jake Vath wrote: > > or an explanation of pipes, or how to use the semi-colon on the command >>> line, or parentheses to make subshells, but some of those are even a little >>> advanced. >>> >> >> Yeah, subshells and an actual explanation of pipes and how they work is >> quite advanced... >> > > I wouldn't explain pipes much except to say that we can capture output > instead of sending it to the screen, for example: > > grep foo file | less > > Then we have to do stuff like > > sort file | head > > The pipe is pretty central to stuff we normally do, so they need that. > Subshell can wait, but this is the kind of thing I do a lot, when a flat db > text file has a header line with field names: > > ( head -1 file ; tail -n+2 file | sort ) > outfile > > That sorts the file except for the header line and preserves the header. > We might not get to that in the first class, which is 1 hour 15 mins. > > > > The biggest questions I have are about the best order to teach things in. >>> What's best -- explain the concept of a shell, or just start typing >>> commands? Probably the former, then go to the kernel/shell concept, then >>> back to commands. >>> >> >> I think you're right. >> I'd start out with a little history on the shell, this doesn't have to be >> Bash specific. >> Just touch on the conception of, "The Shell". >> > > I think I will do that. "Everyone log in. OK, now each of you is in your > own shell..." It sounds appealing. "When you type a command, your shell > interprets it and decides what to do." Then I can talk about personalizing > the experience for different accounts. > > > Maybe mention some stuff about how a shell is a command interpreter. >> It's another layer of abstraction between the operating system and the >> user. >> Mention something to the affect of shell scripting is *really* just a way >> >> of gluing together system calls, tools, utilities, and other programs. >> Why do we need a shell? What you can do/should do/ should not do with the >> shell. >> Mention shell limitations. >> >> How much time do you have with these students? One day? >> > > There will be 2.5 hours total in two classes, but almost all of this basic > stuff needs to be in the first class, so it will be good to direct them to > online resources. The second class has to focus more on a particular kind > of statistical analysis job that they will often run. We're using Torque > PBS, so they have to learn that, too. > > Mike > > ______________________________**_________________ > TCLUG Mailing List - Minneapolis/St. Paul, Minnesota > tclug-list at mn-linux.org > http://mailman.mn-linux.org/**mailman/listinfo/tclug-list<http://mailman.mn-linux.org/mailman/listinfo/tclug-list> > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mailman.mn-linux.org/pipermail/tclug-list/attachments/20130321/d6a9668e/attachment-0001.html>