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 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 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

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.