After installing gcc-3.4.0 and configuring it to use clib2 (with a severely kludged specs file), I have now tried to compile every source file in the tcsh source distribution as a quick way to determine the feasibility of porting it.
I am happy to write that with a few exception it seems the tcsh source is _relatively_ portable. The main areas which seem to need a bit of work are the following:
* termios * missing signals * resource limits * multi-user support * fork()/vfork()
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).
The ixemul-compiled tcsh binary is extremely unstable on my machine and crashes randomly, usually in less than 15 seconds. It does, however, appear to handle csh scripts - which the older csh implementation did not (it only handled a subset).
Unfortunately, this still does not indicate if it would be easier to write our own intepreter or not.
-Peter aka. Archprogrammer, still investigating.
PS: If this is uninteresting, just tell me and I will stop posting status updates here.
Reality is for people who cannot face ScienceFiction. Only lefthanded people are in their right minds.
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,
Hello Thomas
On 22/01/2005, you wrote:
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...
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 will stop posting status updates here.
No, definitely a good idea...
Regards,
Regards
Hi,
Christophe Ochal wrote:
Also remember that tcsh has a different syntax to bourne shell, so it might be easier or harder than bourne shell.
In general, a parser for such a simple language (i.e. one token look-ahead) is a no-brainer... The actual functionality is of course something else, but I don't think it's too problematic either (trust me, 2 years of compiler construction at university at least tought me that ;) ... and how to sleep without anybody noticing, but that's a different story...)
Regards,
Hi Thomas,
On 22/01/2005, you wrote:
In general, a parser for such a simple language (i.e. one token look-ahead) is a no-brainer... The actual functionality is of course something else, but I don't think it's too problematic either (trust me, 2 years of compiler construction at university at least tought me that ;) ... and how to sleep without anybody noticing, but that's a different story...)
Do we really need the "fork()" functionality? Surely we don't need to duplicate the entire volatile memory of the current shell in order to run another - all we need to do is "run" another shell with the same Env and local variables, right? We could send the daughter shell a message containing the current variable settings.
Surely the use of "fork()" is an overkill for a shell?
cheers
Hi,
Tony Wyatt wrote:
Do we really need the "fork()" functionality? Surely we don't need to duplicate the entire volatile memory of the current shell in order to run another - all we need to do is "run" another shell with the same Env and local variables, right? We could send the daughter shell a message containing the current variable settings.
What if the shell uses internal data structure to store state ?
Surely the use of "fork()" is an overkill for a shell?
No, absoultely not. In fact, shells are one of two cases where fork is actually not absolutely horrendously braindead (the other is demon processes).
Regards,
Thomas Frieden said:
Hi,
Tony Wyatt wrote:
Do we really need the "fork()" functionality? Surely we don't need to duplicate the entire volatile memory of the current shell in order to run another - all we need to do is "run" another shell with the same Env and local variables, right? We could send the daughter shell a message containing the current variable settings.
What if the shell uses internal data structure to store state ?
Surely the use of "fork()" is an overkill for a shell?
No, absoultely not. In fact, shells are one of two cases where fork is actually not absolutely horrendously braindead (the other is demon processes).
Personally, I prefer pthreads for daemon processes. But for shells... Yeah, fork works there.
Hi,
Olegil at home wrote:
Personally, I prefer pthreads for daemon processes. But for shells... Yeah, fork works there.
Did I mention that fork _SUCKS_ ?
Regards,
Thomas Frieden said:
Hi,
Olegil at home wrote:
Personally, I prefer pthreads for daemon processes. But for shells... Yeah, fork works there.
Did I mention that fork _SUCKS_ ?
Repeatedly :-P
But what can you do? Is there a good way in AmigaOS to say "I want to run this application, and this file descriptor (which I have open for writing) will be the stdin, and THESE file descriptors (which I have open for reading) will be stdout/stderr". And if so, does it port well into POSIX? If you don't get what I'm hinting at here, I'm actually suggesting writing a shell from scratch, AND making it portable :-P
Oh, but there IS a way, it's called C++ ;-p
----- Original Message ----- From: "Olegil at home" olegil@samfundet.no To: openoffice-os4@samfundet.no Sent: Sunday, January 23, 2005 7:44 AM Subject: Re: [OO.org-OS4] Re: CSH status update.
Thomas Frieden said:
Hi,
Olegil at home wrote:
Personally, I prefer pthreads for daemon processes. But for shells... Yeah, fork works there.
Did I mention that fork _SUCKS_ ?
Repeatedly :-P
But what can you do? Is there a good way in AmigaOS to say "I want to run this application, and this file descriptor (which I have open for writing) will be the stdin, and THESE file descriptors (which I have open for reading) will be stdout/stderr". And if so, does it port well into POSIX? If you don't get what I'm hinting at here, I'm actually suggesting writing a shell from scratch, AND making it portable :-P -- We'll jump off that bridge when we get there.
Openoffice-os4 mailing list Openoffice-os4@samfundet.no https://lists.samfundet.no/mailman/listinfo/openoffice-os4
Finally back after the weekend.
On 2005-01-23, Olegil at home wrote:
<SNIP>
But what can you do? Is there a good way in AmigaOS to say "I want to run this application, and this file descriptor (which I have open for writing) will be the stdin, and THESE file descriptors (which I have open for reading) will be stdout/stderr".
The closest in 3.x would be dos.library/System() which specifies a command to run and a taglist which can specify e.g. stdin, stdout and the shell under which to execute the process.
Unfortunately, this seems to be a bit like implementing the C system() call using the C system() call....
It would probably work under AmigaOS by passing all programs to the built-in shell - but it would be a bit of a kludge.
All in all I think the dos.library/CreateNewProc() call would be more appropriate for a shell.
And if so, does it port well into POSIX?
Kind of - it is probably quite easy to write a _small_ wrapper to get the same functionality under a posix system.
If you don't get what I'm hinting at here, I'm actually suggesting writing a shell from scratch, AND making it portable :-P
Not a bad idea, but I think we should focus on writing an intepreter first.
(Ok, what I really mean is that we should not spend any time now on handling command completion, history management etc. - an intepreter can probably work as a shell with no command-line features)
-Peter aka. Archprogrammer
Reality is for people who cannot face ScienceFiction. Only lefthanded people are in their right minds.
Hi,
Olegil at home wrote:
But what can you do? Is there a good way in AmigaOS to say "I want to run this application, and this file descriptor (which I have open for writing) will be the stdin, and THESE file descriptors (which I have open for reading) will be stdout/stderr". And if so, does it port well into POSIX? If you don't get what I'm hinting at here, I'm actually suggesting writing a shell from scratch, AND making it portable :-P
As Peter proposed, you can use dos/System. The three tags, SYS_Input, SYS_Output and SYS_Error define the input, output, and error streams for the command you run.
Plus, you can also use the pipe handler: Just open pipe:xxx twice, and give the input handle to the new process... if you write into the write handle, the other program will get that as input...
It's portable in the sense that it always boils down to something like this...
Regards,
Hello Peter
On 24/01/2005, you wrote:
If you don't get what I'm hinting at here, I'm actually suggesting writing a shell from scratch, AND making it portable :-P
Not a bad idea, but I think we should focus on writing an intepreter first.
(Ok, what I really mean is that we should not spend any time now on handling command completion, history management etc. - an intepreter can probably work as a shell with no command-line features)
Actually, the csh thing shouldn't be done untill we get far enough with the dependencies & OOo itself, there's no hurry in implementing our own shell or interpreter at this point.
The reason why i asked people to investigate tcsh & csh is because we had older versions available, if it now seems that fixing these would be more work then it should be, then i suggest we freeze this untill we get to a point where we have a need for it.
Regards
Hi Peter,
How goes it with csh? There is a new release of Kaffe out and I would like to try building it under OS4 if I can.
cheers
Hi Peter,
On 4/04/2005, you wrote:
In what way does Kaffe depend on csh?
Only for building it. You need a fairly extensive *nix development structure to run the configuration scripts. More or less like that for OO or any other big build. The sort of stuff that was part of GeekGadgets (editors, utilities, etc).
cheers
On 2005-04-04, Tony Wyatt wrote:
Hi Peter,
How goes it with csh? There is a new release of Kaffe out and I would like to try building it under OS4 if I can.
Well, I am working on NAS (albeit slowly) - so I really have no idea of the status of csh. When I investigated it, I found that it:
1) Depended on clib/compiler internals. 2) Was an incomplete implementation.
The consensus at the time was that it would be easier to write a small csh-script intepreter than to update the old csh or trying to use the ixemul-dependant tcsh port.
In what way does Kaffe depend on csh?
-Peter aka. Archprogrammer
Reality is for people who cannot face ScienceFiction. Only lefthanded people are in their right minds.
On 04/04/2005, you wrote:
Hi Peter,
How goes it with csh? There is a new release of Kaffe out and I would like to try building it under OS4 if I can.
cheers
Tony,
Juergen is now working on CSH and is progressing well (although an update would be good about now ;-) ) and Andy and hnl_dk are part of the abc-shell team which is a bash compatible shell which is also almost ready for release I believe.
Regards
Mark
Mark Bond wrote:
On 04/04/2005, you wrote:
Hi Peter,
How goes it with csh? There is a new release of Kaffe out and I would like to try building it under OS4 if I can.
cheers
Tony,
Juergen is now working on CSH and is progressing well (although an update would be good about now ;-) ) and Andy and hnl_dk are part of the abc-shell team which is a bash compatible shell which is also almost ready for release I believe.
It is not "our" Andy, it is Andy Broad.
Andy is fixing the "last" issues while he is finishing (making the fork emulation working) his Perl port.
PS: It should be possible to make use of abc-shell to port csh/tcsh. Andy made use of it for his Perl port :-)
Regards
Mark
Hello Henning,
It is not "our" Andy, it is Andy Broad.
Yes I realise that, didnt know "we" had an Andy ;-) just couldnt remember his surname.
Andy is fixing the "last" issues while he is finishing (making the fork emulation working) his Perl port.
:-) good
PS: It should be possible to make use of abc-shell to port csh/tcsh. Andy made use of it for his Perl port :-)
:-) also good :-)
Mark
On 5/4/05 3:08 pm, "Mark Bond" mark@icestarmedia.com wrote:
Hello Henning,
It is not "our" Andy, it is Andy Broad.
Yes I realise that, didnt know "we" had an Andy ;-) just couldnt remember his surname.
I guess that would be me :-) Once I get my Java crap out of the way, I'll try to do something more useful than lurking and confusing people with my name (2nd time that's happened :-D)
Andy Hall wrote:
On 5/4/05 3:08 pm, "Mark Bond" mark@icestarmedia.com wrote:
Hello Henning,
It is not "our" Andy, it is Andy Broad.
Yes I realise that, didnt know "we" had an Andy ;-) just couldnt remember his surname.
I guess that would be me :-) Once I get my Java crap out of the way, I'll try to do something more useful than lurking and confusing people with my name (2nd time that's happened :-D)
I guess they only know You as Uncharted ;-)
-
Andy Hall -
Christophe Ochal -
Henning Nielsen Lund -
Mark Bond -
Olegil at home -
Peter Bengtsson -
stephane richard -
Thomas Frieden -
Tony Wyatt