It even works when you write a temp script and execute it in /dev/fd/...
However since you can't control the file name in that case you cannot control argv[0] for such temp executables which may be a problem for BusyBox-style tools.
Have you encountered other issues with using that approach for named but auto-cleaned files?
Example: suppose I am testing a program which reads in a directory tree. I have my test driver program create a temporary directory, with multiple files and subdirectories in it. I can’t use /dev/fd for that, since it doesn’t support directories
Related example: testing a program which expects a file name to match a certain pattern; can’t do that because /dev/fd file names are just numbers
Well if you can call a syscall you don't need a named file. You can call execfd.
One case where I need an executable named temp file is when I need to pass that named file to another process which in turn will call that file (so I don't have control on how that other process will call exec)
> Well if you can call a syscall you don't need a named file. You can call execfd.
Sadly you can’t exec an fd on macOS.
I don’t think Apple is going to change that, because I think it causes difficulties for their security/codesigning/sandboxing infrastructure, and I think they don’t see the difficulty and risk of making it work with that as being worth the rather limited benefit
It even works when you write a temp script and execute it in /dev/fd/...
However since you can't control the file name in that case you cannot control argv[0] for such temp executables which may be a problem for BusyBox-style tools.
Have you encountered other issues with using that approach for named but auto-cleaned files?