&> output redirection operator incorrectly parsed

[timetoplatypus]

$> bin/osh
osh$ pushd /home &> /dev/null
Started background job with pid 19099
/home ~/Documents
osh$

I see that there's a spec test for this already (it's failing) so this is really just a feature request. The ampersand is being parsed as a "hey execute this stuff in a background job" instead of recognizing that I'm trying to redirect stdout and stderr.

I have a script that uses pushd in a similar manner as in the above example. It has this problem where instead of actually changing directories, it executes that pushd in a background job and when it exits the background job I'm left back in the directory I started. If you can fix this behavior, I'd be able to use my script in OSH which would be nice.

[timetoplatypus]

Natural follow-on question (I can move it to the mailing list if that would be better suited): are there plans to add a fg command to bring background jobs to the foreground?

[timetoplatypus]

Natural follow-on question (I can move it to the mailing list if that would be better suited): are there plans to add a fg command to bring background jobs to the foreground?

[andychu]

Thanks for the request -- I think &> should be pretty easy to implement. I haven't seen it used before!

As far as fg, yes we should have it. I don't quite understand the system calls you need to make to implement it. My understanding is that

$ sleep 1 &

does two things:

1. It doesn't wait until the sleep is done to continue running the script. That is, it does fork(), but not wait().
2. It detaches the process from the terminal (somehow)

Then fg somehow attached it back to the terminal. But my memory of how this happens is fuzzy.

But yes, there's no reason that fg can't be supported eventually.

One thing that is likely to push it to the back of the queue is that I'm a tmux user :) I don't use shell job control -- I just start a new shell in tmux. So if you or anyone else wants to help that would be nice :)

I'm also not sure if it's easier to do in C or in Python.

[andychu]

Thanks for the request -- I think &> should be pretty easy to implement. I haven't seen it used before!

As far as fg, yes we should have it. I don't quite understand the system calls you need to make to implement it. My understanding is that

$ sleep 1 &

does two things:

1. It doesn't wait until the sleep is done to continue running the script. That is, it does fork(), but not wait().
2. It detaches the process from the terminal (somehow)

Then fg somehow attached it back to the terminal. But my memory of how this happens is fuzzy.

But yes, there's no reason that fg can't be supported eventually.

One thing that is likely to push it to the back of the queue is that I'm a tmux user :) I don't use shell job control -- I just start a new shell in tmux. So if you or anyone else wants to help that would be nice :)

I'm also not sure if it's easier to do in C or in Python.

[andychu]

Oh also if you need fg, please make a separate issue for it -- otherwise it will get lose under &>.

[andychu]

Oh also if you need fg, please make a separate issue for it -- otherwise it will get lose under &>.

[timetoplatypus]

I don't need fg, I was just curious. I too am a heavy tmux (and wemux user) as well.

[timetoplatypus]

I don't need fg, I was just curious. I too am a heavy tmux (and wemux user) as well.

[andychu]

Hm this was easier than I thought, but unfortunately it didn't make it into the release. I'll think about doing another release before August.

Maybe I'll strip down the interpreter some more to make it worth it.

[andychu]

Hm this was easier than I thought, but unfortunately it didn't make it into the release. I'll think about doing another release before August.

Maybe I'll strip down the interpreter some more to make it worth it.