Hey.
Sorry coming back on this so late, but I got a bit distracted with other stuff. I still wonder whether the idea presented by Harald van Dijk (see his mail below) is actually covered by POSIX (in the sense that compliant shells are expected to work like that). A short summary: My question was basically, how one can portably do redirections that take effect for some executed utility, while still being able to determine whether there was a redirection error or whether the utility exited with a non-zero exit status. Assuming of course, that there's at least one known exit status which the utility doesn't make use of itself (which I think is actually not unrealistic in practise). The motivation is, that there are tools like grep, diff, etc. where a non-zero exit status actually indicates a non-error condition. The original idea was then a construct like: ( command exec <some redirections> || exit 125; utility ) With 125 assumed as an exit status not used by utility, and the (…) subshell merely being made to get rid of all those redirections afterwards. With #1879 being clarified, command exec <someRedirections> wouldn't cause the shell to abort in case of a redirection error. The remaining problem was that exec doesn't necessarily pass on FDs > 2. Now Harald's intriguing idea was to extend the construct like so: ( command exec <some redirections> || exit 125; utility n<&n... m>&m... ) With n<&n respectively m>&m being a series of all the FDs from <some redirections>, intended to make sure they *are* passed on. My questions back then were: a) Does that behaviour even follow from POSIX (in an obvious way where it's really clear that shells should behave like this, not just some wobbly way) b) Does it even solve the original problem, or could e.g. such a n<&n respectively m>&m fail itself (not e.g. because a file doesn't exist, but because of something like resource exhaustion, etc.) By coincidence, a few days ago Herbert Xu (dash maintainer) posted[0] that for the sake of dash he considers 0<&0 a no-op, which doesn't really sound as if the above behaviour would be considered as required by POSIX, because if it were - and as shells *can* choose not to pass on FDs > 2 - it couldn't considered to be a no-op?! Anyway, I'd be happy if someone can answer the above questions from a POSIX PoV. Also, if POSIX doesn't specify any of this, would people be open to have it do so? Obviously I don't want to break any compatibility, but all shells I could test so far (which are not all, and especially no older versions) seem to either use n<&n as described above or pass on FDs > 2 anyway and at least consider n<&n a no-op. So it would be nice if either this could be defined in a way to allow for the above, if it doesn't break anything, or at least be specified that n<&n and m>&m are undefined. If no one disagrees, I'd open a ticket in Mantis about this in a few days. Thanks, Chris. [0] https://lore.kernel.org/dash/[email protected]/T/#t On Sun, 2025-01-12 at 23:11 +0000, Harald van Dijk wrote: > On 11/01/2025 00:50, Christoph Anton Mitterer via austin-group-l at > The > Open Group wrote: > > Not sure what’s the intention of not passing on FDs > 2, because > > one > > could always just close such FDs via redirection specifically for > > the > > utility. > > Likewise, when any FD > 2 needs to be passed to an external utility, > one > could always just duplicate such FDs via redirection specifically for > the utility. > > $ mksh -c "exec 8</dev/null; ls /proc/self/fd/8" > ls: cannot access '/proc/self/fd/8': No such file or directory > > $ mksh -c "exec 8</dev/null; ls /proc/self/fd/8 8<&8" > /proc/self/fd/8 > > $ ksh -c "exec 8</dev/null; ls /proc/self/fd/8" > ls: cannot access '/proc/self/fd/8': No such file or directory > > $ ksh -c "exec 8</dev/null; ls /proc/self/fd/8 8<&8" > /proc/self/fd/8 > > > Any other means to get the desired goal (in a portable way)? > > As Lawrence Velázquez rightly replied, your example should already > work > in all shells. For other examples where the utilities need to access > those FDs themselves, the above should be enough to make all shells > work > the same way. > > Cheers, > Harald van Dijk
