Hi,
Peter Bengtsson wrote:
Of these, only the missing signals and fork()/vfork() appears to pose any significant problem and as a positive side-effect, we might contribute further to the development of clib2 (just an idea).
Which signals are missing ? Remember that we don't need it as an interactive shell, so it might not be necessary to do the signals if they only correspond to user interaction...
Unfortunately, this still does not indicate if it would be easier to write our own intepreter or not.
The problem is that these fork dependencies will be _very_ hard to overcome, since the whole architecture of shells is always tied to them.
On the abc-shell list, we recently found a way to "emulate" fork via something similar to vfork, but it's very specific to abc-shell, and might not work here...
I had a look at the bourne shell language, and the language itself is dead easy; with flex/bison it should be possible to have an interpreter in a jiffy, but the shell also supports a large number of built-in commands and variables...
Overall, I _think_ writing an interpreter would be easier than getting around the fork issues...
PS: If this is uninteresting, just tell me and I will stop posting status updates here.
No, definitely a good idea...
Regards,