Programming

That makes sense.
Oh well I mean everything else looks correct, the myshell> printout is a little bit screwy when I use & BUT the & seems to be working correctly regardless (using the sleep 60 & thing to test it)

You may be fighting buffers because you're using printf(). This keeps it in memory until it decides it's convenient to print it(usually, whenever it finds a newline). And when you fork(), you get a close-to-identical copy... So if you fork while anything's in the buffer it could even get printed twice! You might want to fflush(stdout); after you print, and before you fork(), to guarantee nothing's left in the buffers.

You can also do fprintf(stderr, "hello world\n"); to avoid it, since stderr never buffers. (it might be better to print to stderr anyway.)

here's an example of what im talking about.
myshell> ls -a
. .. a.out fork.c Hello .hi shell shell.c
myshell> ls -l
total 36
-rwxr-xr-x 1 matt matt 8435 2010-09-26 20:43 a.out
-rw-r--r-- 1 matt matt 943 2010-09-26 20:44 fork.c
drwxr-xr-x 2 matt matt 4096 2010-09-27 02:13 Hello
-rwxr-xr-x 1 matt matt 8322 2010-09-28 16:21 shell
-rw-r--r-- 1 matt matt 1693 2010-09-28 16:21 shell.c
myshell> ls &
myshell> a.out fork.c Hello shell shell.c
ls -a
myshell> . .. a.out fork.c Hello .hi shell shell.c
<---- here is where the "pointer" ends up. i can still type commands, but it doesn't show "myshell>" anymore

I tried the fprintf(stderr, "hello world\n"); thing. but it didn't work, it only happens when the & happens for some reason...

Looking at my code it should go like this.


parse arg. which prints out myshell>
User inputs commands<---
parse arg parses it.

so we have myshell> ls -l
so we execute it. which goes on a newline (apparently) (since BG is 0) and we wait for it to finish.
we then go back in the loop and myshell is printed again.

But with &....it goes back to parse arg (since we can still type things in, and they work) but myshell> isn't printed....which makes zero sense. Im looking at my code, tracing through....and I just dont see why this is happening, even when we aren't "waiting" the the process to finish, it should still loop back around to the parsearg function which has the myshell> printout.

It seems like typing in the & for SOME reason....like...screws all my printouts up.


edit: I think I may know why now.....im not resetting the BG bool to false, so it's treating them all as "background" processes i think........

edit2: CRAP nevermind, i realize im never setting BG permanently, oh well there goes that theory.

Please don't PM me in the hope of a faster response. I am not on-call here.

On my system I get:

Code:

myshell> echo a
a
0DEBUG:Child Finished
myshell> echo a &
1myshell> a

It does print 'myshell' again. And then 'echo' stomps on it and moves to the next line. This is normal. Since we're not waiting for it, the background process can't be polite about when it prints what... Also watch where you're cout-ing BG, if the process is backgrounded it kind of just shoves it in there anyway.

In a real shell try

Code:

$ ( sleep 3 ; echo asdf ) &

Sorry, I just had a bunch of ideas was trying to figure stuff out.
also, i realize that is prints myshell again the first time, but if you try typing in another command, it'll just be a blank cursor (with no myshell printout)
like for instance the * is where the "blinking" cursor is.
myshell> ls
a.out fork.c Hello hello2 shell shell.c
myshell> ls &
myshell > a.out fork.c Hello hello2 shell shell.c
*
^ thats where the blinking cursor will be, i can still type in stuff....but there is no new myshell> printed out.

if I typed something else out again it's like....
ls
myshell>a.out fork.c Hello hello2 shell shell.c
ls &
myshell>a.out fork.c Hello hello2 shell shell.c
ls
myshell>a.out fork.c Hello hello2 shell shell.c


kinda weird...I guess it doesn't hurt anything, just thought it was a bit odd.

I think I've figured it out. Because you let the background process die without wait()-ing for it, there's more than one process left around to wait for, and you get the oldest first, i.e. the already-dead one. so wait() happens instantly, picking up the dead process, while the new process keeps going in the background and messes up your terminal again.

You could try waitpid instead of wait, in order to wait for a specific PID instead of any PID.

Ah that makes sense. I guess it's not a big deal, i might go back through and make some changes. I mean.....the way I have it isn't "wrong" is it? it's just I guess......messy (well the terminal is at least)