Last year I wrote a replacement shell for the Tek4404 running Uniflex. The standard shell uses 440k whereas my shell uses 48k and has most of the features I need.
However. For reasons I cannot work out, if I run cc from my shell, it fails to create its /tmp files and exits saying it “cannot create Intermediate files”.
I had assumed it was just umask, but I’ve set that and still it fails. If I run the standard shell and then launch my shell and from there then launch cc, it works fine. So the standard shell is doing something that I am not…
Good points all. Danke. Permissions on /tmp look good
TD;LR When I implemented the telnet daemon, I just exec-ed a shell for each connection.
I know, I am a security nightmare!
But changing telnetd to exec login allows my shell to run cc without issue. The only thing I noticed is login sets the USERNAME environment variable… seems odd that that would make a difference but Hey Ho.
Can you post the exact command line that fails? Is it as simple as cc t.c ?
Try recompiling the driver (cc) and instead of having it run the compiler, like c1 or whatever, have it run a program you write that prints out the umask, uid, gid, arguments, and so on.
I wonder if it’s trying to create a file like $(USERNAME)/tmpx1234 and so in there is no $USERNAME then it’ll try to create it at root. Maybe the actions of tmpfile() (if that’s what cc is using) required $(USERNAME) ?
Unfortunately, no. I’m still reverse engineering ctask() (strace kernel call). So far I can see it takes a handle and operation:
0 sleep/pause task
1 wake/resume task
2 set TNOMAP iff TTRACP
3 execute
4 do userblk update + set TTRACP
5 clear signals
6 set TTRACP
7 freeze tasks
8 unfreeze tasks
Unclear what order you’re meant to call these to get a controlled execution of a task!
I’ve checked cc, cprep (cpp equiv) and cpass1 (cc1 equiv) and they have no mention of a string USERNAME, so don’t think thats the cause.
I agree, if I had strace and could see where it dies it would help a lot. There is a debugger but more often than not with a problem executable it just dies and exits itself
A maybe naive question: given the rather dramatic reduction in memory size, could it be that the system runs out of available file handles and thus can’t allocate the intermediate/temp file?