On 22/01/2005, you wrote:
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
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...
Also remember that tcsh has a different syntax to bourne shell, so it might
be easier or harder than bourne shell.
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
posting status updates here.
No, definitely a good idea...
Hoge Buizemont 168
9500 Geraardsbergen, Belgium
Mobile: 0032 (0)479/46 45 74