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,
--
Thomas Frieden <ThomasF(a)hyperion-entertainment.biz>
Hyperion Entertainment
- Naur dan i-deryg lhuin