The version of csh from Aminet (csh550.lha) compiles using SAS/C on Classic or OS4. It runs OK, once you realise that the prompt is "highlighted" using pen colour 7 - this appears to be hard-coded.
I have bodgied a version that ignores the highlight formatting for the prompt. This version runs on Classic (OS3.9), OS4/68k and OS4/PPC in emulation. I'll provide a copy for anyone that wants it.
I have not yet tried to compile it with gcc.
It does not seem to have dependencies of its own (no ixemul, works emulated on OS4/PPC). It does need some SAS libs, though.
Paths are Amiga-specific, it does not recognise volume names in the form /name.
I'd put all this in the Wiki but I can't seem to find the "Edit" button on that page.
cheers
Hello Tony
On 14/01/2005, you wrote:
The version of csh from Aminet (csh550.lha) compiles using SAS/C on Classic or OS4. It runs OK, once you realise that the prompt is "highlighted" using pen colour 7 - this appears to be hard-coded.
Great job Tony!
I have bodgied a version that ignores the highlight formatting for the prompt. This version runs on Classic (OS3.9), OS4/68k and OS4/PPC in emulation. I'll provide a copy for anyone that wants it.
I just created an account for you on dev.amigaopenoffice.org, you could upload it there for now, your login will be mailed to you in a minute ;)
I have not yet tried to compile it with gcc.
It does not seem to have dependencies of its own (no ixemul, works emulated on OS4/PPC). It does need some SAS libs, though.
Paths are Amiga-specific, it does not recognise volume names in the form /name.
I'd put all this in the Wiki but I can't seem to find the "Edit" button on that page.
It's that little icon of a paper & pen ;)
Regards
Hi,
Tony Wyatt wrote:
I have not yet tried to compile it with gcc.
That is the hard part. It tires to access the C library's array of file pointers (to get stdout/stdin into a newly spawned process). This will be difficult...
Regards,
Hi Thomas,
On 14/01/2005, you wrote:
I have not yet tried to compile it with gcc.
That is the hard part. It tires to access the C library's array of file pointers (to get stdout/stdin into a newly spawned process). This will be difficult...
Do you mean at compile time or at run time? If at run time, are you saying that it can get wrong values for stdin and stdout?
Maybe I have been lucky that it runs on the A1?
cheers
Hi,
Tony Wyatt wrote:
That is the hard part. It tires to access the C library's array of file pointers (to get stdout/stdin into a newly spawned process). This will be difficult...
Do you mean at compile time or at run time? If at run time, are you saying that it can get wrong values for stdin and stdout?
At compile time, of course... Try to compile comp3.c, and you'll see...
Maybe I have been lucky that it runs on the A1?
At runtime, there's no problem since it's actually using the C library of SAS/C...
Regards,
Hi Thomas,
On 14/01/2005, you wrote:
At compile time, of course... Try to compile comp3.c, and you'll see...
Maybe I have been lucky that it runs on the A1?
At runtime, there's no problem since it's actually using the C library of SAS/C...
Maybe when I try to compile it with gcc, I'll understand what you are saying. Right now, compiling with SAS/C is not a problem.
cheers
Hi,
Tony Wyatt wrote:
At runtime, there's no problem since it's actually using the C library of SAS/C...
Maybe when I try to compile it with gcc, I'll understand what you are saying. Right now, compiling with SAS/C is not a problem.
It's actually very simple: You know that some functions like open return an integer as the file descriptor ? Normally, the C library keeps an array of structures that describe open files, and the int returned by open is used as an index into that array. The array keeps the "real" file handles, for example, it could be an array of BPTRs for DOS with the DOS file handles.
The csh code uses this array, copying stdin and stdout (which are normally index 0 and 1). Of course, this is nor portable, since every C library names this array differently, and uses a different layout of the array and structures. So basically, it's accessing internal data structures of the C library, which can't be easily ported over...
Regards,
Hi Thomas,
On 15/01/2005, you wrote:
It's actually very simple: You know that some functions like open return an integer as the file descriptor ? Normally, the C library keeps an array of structures that describe open files, and the int returned by open is used as an index into that array. The array keeps the "real" file handles, for example, it could be an array of BPTRs for DOS with the DOS file handles.
The csh code uses this array, copying stdin and stdout (which are normally index 0 and 1). Of course, this is nor portable, since every C library names this array differently, and uses a different layout of the array and structures. So basically, it's accessing internal data structures of the C library, which can't be easily ported over...
I see, so this version of csh depends on internal SAS runtime library structures. That doesn't sound too hard to fix (is that being naive?).
Anyway, we have a working binary at the moment, so making the source more portable does not seem like an urgent problem.
cheers
Hi,
Tony Wyatt wrote:
I see, so this version of csh depends on internal SAS runtime library structures. That doesn't sound too hard to fix (is that being naive?).
No, just optimistic ;)
Anyway, we have a working binary at the moment, so making the source more portable does not seem like an urgent problem.
The problem is getting the thing to accept unix path names...
Regards,
On 2005-01-15, Thomas Frieden wrote:
Hi,
Tony Wyatt wrote:
<SNIP>
Anyway, we have a working binary at the moment, so making the source more portable does not seem like an urgent problem.
The problem is getting the thing to accept unix path names...
As a quick hack, why not just wrap open(), chdir(), fopen() etc.? Would be fairly trivial with a quick header hack I think. E.g.:
static int my_chdir(char *path) { char apath[MAX_PATH_LEN]; PathTranslate(apath,path); return(chdir(apath)); } #define chdir(x) my_chdir(x)
Function with a variable number of arguments like open() could be more problematic with SAS/C (gcc supports both its own and C99 style variadic macros) but should be doable.
Just a quick suggestion, anyway.
-Peter aka. Archprogrammer
Reality is for people who cannot face ScienceFiction. Only lefthanded people are in their right minds.
-
Christophe Ochal -
Peter Bengtsson -
Thomas Frieden -
Tony Wyatt