What would stop a program creating files?

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…

Any ideas? Suggestions?

What does ls -ld /tmp say? If the permissions are not drwxrwxrwt, you may need to run chmod 1777 /tmp.

You may also wish to try simply creating a file in /tmp and making sure it succeeds.

Is it somehow an environment where you need TMPDIR to point to somewhere writeable?

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! :rofl:

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.

1 Like

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.

1 Like

Or possibly some other environment variable that the compiler uses for the artefacts…

Also worth experimenting with -v or some other option that would make the compiler tell more verbosely what is it trying to do.

1 Like

Do you have strace/ptrace or similar?

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

-Gordon

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

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?