Magius_AR has asked for the wisdom of the Perl Monks concerning the following question:

OK, my most recent school project involved writing our own limited shell.

I've basically coded everything except the |,<, and > operators.

These are a bitch, because I hate dealing with pipes that refuse to be bi-directional. I think the solution has something to do with something called "dup"ing, though I haven't a clue how.

To explain more specifically, say I'm trying to code the "<" operator...I have to get something like

wc < sometext

to output the right thing, but I can't use the "<" opeartor in my code itself. Thus here's my attempt so far:

open (PIPE,"| $path/$command >&RESULT"); print PIPE @data; close(PIPE); @result = <RESULT>;

This is course doesn't work at all, but maybe it gives u an idea of what I need. I have to be able to pass @data (like sometext) in a given command (like wc) and capture the result in an array (@result). I've tried soooooo many different things and keep failing. I am at your mercy :)

Replies are listed 'Best First'.
Re: Dup & redirecting filehandles
by Adam (Vicar) on Oct 22, 2000 at 21:10 UTC
    You are not that far off me-thinks. You need to open the RESULT filehandle before you can read from it (or write to it.) And is not clear where you do that. Also, your open line, open (PIPE,"| $path/$command >&RESULT"); doesn't redirect the output of the command to the result file handle. You will need to try a slightly different approach to get bidirectional pipes.
Re: Dup & redirecting filehandles
by AgentM (Curate) on Oct 22, 2000 at 21:53 UTC
    Thanx for the homework alert! I don't see why you need to dup() your pipes when the shell's pipes are uni-directional. When you do something like this "echo test>one.txt, the string "test" is thrown into a outputed /created one.txt (stdout2file), erasing any previous contents of the file. The less-than sign goes in the opposite direction, piping stuff from a file to the program (file2stdin). The pipe operator sends the stdout from the first program to the stdin of the second. Remember to implement the stderr pipe! For the pipe operator, all you need to do is fork, pipe the stdout to the parent, exec(); fork the parent again, pipe the stdin to the parent and link the pipes in the parent. To visualize this, try "man perlfunc|less". This is exactly the system used in all UNIX shells. For more detailed information, you can look up the whole procedure in W. Richard Stevens' "Advanced Programming in the UNIX Environment". I think this program is mentioned and implemented on his website. if you need more info, /msg me. have fun! Update: Just thought of it- you'll probably get errors if you leave do your buffering poorly. try to buffer only in the parent of the two porcesses.
    AgentM Systems nor Nasca Enterprises nor Bone::Easy nor Macperl is responsible for the comments made by AgentM. Remember, you can build any logical system with NOR.
Re: Dup & redirecting filehandles
by Fastolfe (Vicar) on Oct 24, 2000 at 18:50 UTC
    A stock open call should be able to do most of the simple stuff natively. Where you get into things like bi-directional file handles, etc., you will want to either use fork in conjunction with, say, pipe or socketpair. Alternatively, you can use open2 or open3 to get open-style functionality with multiple file handles (stdout, stdin and optionally stderr).

    You should give perlipc a read. Lots of interesting documentation and examples about communicating between processes, which is effectively the functionality you'll need to use here. Good luck.

Re: Dup & redirecting filehandles
by Anonymous Monk on Oct 22, 2000 at 21:37 UTC
    Could I possibly get any sample code out of you? I've spent literally hours trying things myself (and ran across many of the same pages on google over and over trying to get it to work)...i've also tried throwing in an open(RESULT); before reading from it, but it still doesn't work. -w tells me its trying to read from a closed filehandle (even with the open there)...i'm basically clueless at this point.
      Are you checking the return values of things like open? Just because you have an open statement in your code does not necessarily mean you will have an opened file handle right after it. Be sure open succeeded.