OSDev.org

I have quite some troubles to understand the concept behind standard input and standard output in the correct way.

Until now, I do Input and output by having the processes talk directly to the console driver. This is of course not a really appreciated solution for it requires lots of hacks and ugly kludges - and it doesn't faciliate spawning off processes at different consoles.

I am thinking about the following: The file service keeps the file descriptor lists- a list for each process. So it is plain and clear, that fs service needs to be notified, if a process is forked - to register it and create the file descriptors for standard input and standard output. These two are by default also known to the process - as Defines or entries in the fd array it keeps in some library. So they would be fd 1 and fd 2.

Upon fork, fs service instantiates a new object of kind fs_proc and attaches these two standard files to it.

Am I wrong with this?

Well ... that's it for now, I need to do some thinking to get a solution for it. Some sketch will help, thats for sure. And as soon as I get round this, it will maybe faciliate redirecting of stdinput and stdoutput. Well, lets see.

stay safe

afaik, when a unix process is forked, it automatically reuses STDIN and STDOUT (as well as all other file descriptors) from its parent. If you want to start a process and hook its output for your own (in unix world), you need a part of your own program that will make things between the 'fork' and the 'exec' calls, like closing the file #0 (stdout) and then duplicate (dup2, iirc) the file descriptor for the pipe (created before fork'ing) on stdout ...

Pype.Clicker wrote: afaik, when a unix process is forked, it automatically reuses STDIN and STDOUT (as well as all other file descriptors) from its parent.

Actually, this behavior is specifically controllable on a per-descriptor basis. See fcntl(2) and F_SETFD.

If you want to start a process and hook its output for your own (in unix world), you need a part of your own program that will make things between the 'fork' and the 'exec' calls, like closing the file #0 (stdout) and then duplicate (dup2, iirc) the file descriptor for the pipe (created before fork'ing) on stdout ...

Or you can do it before the fork and put everything back afterwards. There are usually a couple options for how to do everything, after all.

hmm .. that "fnctl" seems to hold much of unix's magic about file. Thanks for mentionning it ...

First, thanks for your input, lads!

Ok, I give a short resumee here of what I've achieved during hard hacking sessions over the weekend:

If opening a file, the name is first checked in the list of devices - say "console1" is a device for terminal input/output - no Inodes are fetched for it but a file pointer and the two file descriptors are handed out - STDIN,STDOUT.

If reading from "console1" the fsservice just informs the terminal driver, that from console1 Input is to be fetched. As soon as the user hits enter (or a max amount of char's is entered) terminal informs fsservice about end of file and fsservice fetches the input stream and delivers it to the process requesting it.

That's it for the moment. I'll drop some lines whilst the adventure continues ... *ggg* Have I said already, that this kind of stuff is cool?