Writing already opened file with shell

[jazzbiker]

Hi shell experts!
One more noob complain. Let's imagine some program opens the file with open() and the assigns its descriptor to some environmental variable, for example

Code: [Select]

char buf[80];
int fd = open(name, O_CREAT | O_WRONLY, 0666);
snprintf(buf, sizeof buf, "%d", fd);
setenv("MY_FD", buf, 1)
Then it spawns some script with fork() + execl().
Script writes the file with

Code: [Select]

echo hello >&"MY_FD"

This trick plays nice in busybox ash in TC. But another boxes with bash refuse to do so. What am I doing wrong?

Thanks in advance.

[CardealRusso]

Good morning. This seems inappropriate.
If sh works, then you should use sh. You are mixing C with ash and bash. This will eventually create confusion.

Why not use just ash or just bash or just C?

[jazzbiker]

Hi CardealRusso,

This seems inappropriate.

I don't see anything inappropriate. And ash see nothing inappropriate too.

You are mixing C with ash and bash. This will eventually create confusion.

Linux distro builders will appreciate this advice.

Why not use just ash or just bash or just C?

What I described as the shell chunk should be in some way external and easily modifiable. Otherwise what for I would pass the file descriptor somewhere outside? It must not be filename. It must be file descriptor, because sometimes it may appear to be 1 or 2.

By the way bash error message souds as:

Code: [Select]

Syntax error: Bad fd number.

So it is not runtime error. bash doesn't allow to use file descriptors other but the minimal standard ones.

[GNUser]

Code: [Select]

echo hello >&"MY_FD"


Hi, Andrey. It should be

Code: [Select]

echo hello >&"$MY_FD"
But maybe that's just a typo because without the $ it wouldn't work in any shell.

Another thought is variable scope. If the C utility that is setting and exporting the MY_FD variable is running in a shell, only that shell's subshells will be able to access MY_FD. That shell's parent shell does not have access to the variable. Exported/environmental variables in shells are like genes in living things: Parents can give them to their children, but children cannot give them to their parents.

[GNUser]

Both considerations I mentioned above (missing $, variable scope) would affect your experiment on any shell running in any distro. I don't have a good explanation for why your experiment works in TCL+ash but not in SomeOtherDistro+bash.

[jazzbiker]

Hi GNUser,
Sure there was

Code: [Select]

echo hello >&"$MY_FD"
Otherwise it had no chances at all to work. Sorry for the typo.
This issue is not related to the visibility rules, bash issues syntax error. It doesn't tries to run the code. I've tried dash - the same as with bash. Only ash, only TinyCore.

[jazzbiker]

The last resort is /proc/$$/fd I guess.

[GNUser]

What value does MY_FD hold when it fails to work in bash? It would be interesting to see the output of echo $MY_FD

[jazzbiker]

Usual file descriptor, something like 4, 5 or so.
/proc/$$/fd didn't help. :-(
Only ash, only HardTinyCore. Or TinyHardCore.

[GNUser]

Maybe in bash the file descriptor must be explicitly opened with exec before it can be used (more information here).

Try reserving a number for bash to point towards your MY_FD. In my example below, let's reserve 9 for bash. So MY_FD can be 4 or 5 or whatever, but not 9.

If you run this in bash, does it work?

Code: [Select]

exec 9>&"$MY_FD"
echo hello >&9

[jazzbiker]

Once again - limitations, restrictions, workarounds. Feel yourself free with micropython or Lua.

[jazzbiker]

If you run this in bash, does it work?

Code: [Select]

exec 9>&"$MY_FD"
echo hello >&9

Thanks, I thought about it, will test later. But I bet for it won't help.

[GNUser]

Once again - limitations, restrictions, workarounds. Feel yourself free with micropython or Lua.

I'm with you, my friend. Shell has more than its share of warts and whiskers. It is baroque and ugly as heck. I think the only good thing I can say about shell is that it is universally present in *nix systems.

I won't judge you if you need to plug your nose when you use shell

P.S. I'm going through PIL now and I have to admit that Lua is beautiful. And not just in comparison with shell.

[GNUser]

Another idea is to export the name of the open file instead of the file descriptor. So if your C code exports MY_FILE instead of MY_FD, bash can simply do this:

Code: [Select]

exec 4>"$MY_FILE"
echo hello >&4
or, if you don't really need the custom fd, then the least complicated version:

Code: [Select]

exec hello >"$MY_FILE"


[jazzbiker]

Another idea is to export the name of the open file instead of the file descriptor. So if your C code exports MY_FILE instead of MY_FD, bash can simply do this:

Code: [Select]

exec 4>"$MY_FILE"
echo hello >&4
or, if you don't really need the custom fd, then the least complicated version:

Code: [Select]

exec hello >"$MY_FILE"


Thanks, it would be nice if sometimes i won't need to pass 1 or 2 to child :-(