I have to program a simple shell on UNIX in C. It has to cover pipes, 
redirection and background operation etc...

Can anyone tell me where I can find an example I can follow to achieve 
this? I am really stumped!

Alternatively, can someone give me a good algorithm so I can understand 
what's going on?

Thanks

J Peterman wrote:
> I have to program a simple shell on UNIX in C. It has to cover pipes, 
> redirection and background operation etc...
> 
> Can anyone tell me where I can find an example I can follow to achieve 
> this? I am really stumped!

Take a look at chapter 6 of Marc Rochkind's _Advanced Unix Programming_.

> 
> I have to program a simple shell on UNIX in C. It has to cover pipes,
> redirection and background operation etc...
> 

Sounds like B310 assignment 1 at mudrock. Ahh, memories..

> Can anyone tell me where I can find an example I can follow to achieve
> this? I am really stumped!
> 
> Alternatively, can someone give me a good algorithm so I can understand
> what's going on?

Most of the work is in the parsing routine. Understanding
the basics of a shell is the first hurdle:-

  How do you tell a command from its arguments? How can you tell if 
   there's more than one command per line (eg, a "pipeline")?
   (Remember `ls & who' is a valid command line)

  How do you know when it's valid to run a pipeline, or redirect 
    input/output? (Think of where arguments are relative to the 
    redirection/pipe operator)

  How do you know when to run a program in the background?


There might also be "shell builtins" to implement, as well as 
exec()ing of external programs. These modify the current
process, rather than starting a new one.

Think about how you're going to represent the parsed command
line as data structures. See the exec*() manpage for details 
on how processes like their arguments. You might also want
to store information on what you need to do - fork()/exec*()
a single process, or run a pipeline of 2 processes, or run
one process in the background, or...


If you're not familiar with the C library string manipulation 
functions, you soon will be.  `man string' lists a bunch of 
routines which you'll find essential, assuming you're using C,
which most people do (at least, i've never seen anyone use C++).


I haven't seen the Rochkind book; i reckoned it was heresy for them
to drop Rich Steven's _Advanced Programming in the UNIX Environment_ 
in the first place. A copy should be in the library, or on your 
bookshelf if you're serious about Unix. [RIP, Rich. 3 years already?]


Oh, go and grab the comp.unix.programmer FAQ - there's a couple of
sections you should find useful there (namely, the processes part).

Follow the KISS principle, get the basics working and maybe THEN get 
fancy (handling escape chars, etc etc). The time/credit ratio 
probably isn't worth it though.. voice of experience. Spend the time
drinking instead.

Obviously, DON'T LEAVE THIS 'TIL THE LAST MINUTE or you'll find 
yourself screwed - in the bad way... 

--

> > I have to program a simple shell on UNIX in C. It has to cover pipes,
> > redirection and background operation etc...
> >
>
> Sounds like B310 assignment 1 at mudrock. Ahh, memories..

Hey! Actually, it's the 2nd assignment...It seems like it's actually a very
common OS unit assignment, except this one goes into a lot more detail with
the inclusion of pipes, redirection and built in functions, which other
people don't seem to have to do. I would have thought it would be easy to
find some code, but it's proving frustrating.

> > Can anyone tell me where I can find an example I can follow to achieve
> > this? I am really stumped!
> >
> > Alternatively, can someone give me a good algorithm so I can understand
> > what's going on?
>
> Most of the work is in the parsing routine. Understanding
> the basics of a shell is the first hurdle:-

We've been given the parser (which was the first assignment).

>   How do you tell a command from its arguments? How can you tell if
>    there's more than one command per line (eg, a "pipeline")?
>    (Remember `ls & who' is a valid command line)

I can break up a command line into tokens, and identify the command. And I
can break up different commands based on the special symbols > < | &.

>   How do you know when it's valid to run a pipeline, or redirect
>     input/output? (Think of where arguments are relative to the
>     redirection/pipe operator)

Haven't looked at pipes yet (will be soon). I'm pretty sure I can tell a
valid command line from an invalid one.

>   How do you know when to run a program in the background?

If a command (plus parameters) ends with a &.

> There might also be "shell builtins" to implement, as well as
> exec()ing of external programs. These modify the current
> process, rather than starting a new one.

These shell builtins are a bit of a worry for me. For example, I have to
implement my own version of "cd", but I don't quite understand how my shell
will interact with the existing files.

> Think about how you're going to represent the parsed command
> line as data structures. See the exec*() manpage for details
> on how processes like their arguments. You might also want
> to store information on what you need to do - fork()/exec*()
> a single process, or run a pipeline of 2 processes, or run
> one process in the background, or...

At the moment, this sounds like gibberish to me...... :(

> If you're not familiar with the C library string manipulation
> functions, you soon will be.  `man string' lists a bunch of
> routines which you'll find essential, assuming you're using C,
> which most people do (at least, i've never seen anyone use C++).

Yep, doing it in C.

> I haven't seen the Rochkind book; i reckoned it was heresy for them
> to drop Rich Steven's _Advanced Programming in the UNIX Environment_
> in the first place. A copy should be in the library, or on your
> bookshelf if you're serious about Unix. [RIP, Rich. 3 years already?]

I don't think I'm serious about unix programming....just struggling to get
through. Although got a bit of good news in the form of 98% for the first
assignment (command line parser). Dunno how I managed that though.

> Oh, go and grab the comp.unix.programmer FAQ - there's a couple of
> sections you should find useful there (namely, the processes part).

Wicked, will look into that.

> Follow the KISS principle, get the basics working and maybe THEN get
> fancy (handling escape chars, etc etc). The time/credit ratio
> probably isn't worth it though.. voice of experience. Spend the time
> drinking instead.
> Obviously, DON'T LEAVE THIS 'TIL THE LAST MINUTE or you'll find
> yourself screwed - in the bad way...

Yep, trying to tie it up over the next week and a bit. Concentrating on
learning what all the fidly bits do (lab exercises), then will hopefully
have a better idea on what to do with this shell.