Re: Making "cmd< <(...)" useful (reliable)

[Gotmy Nick]

Hello,

I can not help too much on the "bug" side, but I would like to give a
tip regarding the situation you describe.

Often I've the same caveats about how my code will be used in a future
without my control...

If you know for sure, what makes the code unreliable, in this example
the /proc subsystem status in the platform, then just check for it at
the beginning of the program, and cancel the execution gracefully.
Something like (just an example)...

    [ -e /proc/vmstat ] || {
        printf '%s\n' "ERROR: this program needs /proc" >&2
        exit 1
    }

That may not be the best or more elegant fix, but it will allow you to
relax about such unreliable behavior and go on.

Of course, there will be dragons... maybe in a future /proc/vmstat
disappears in the kernel changelog, or some new security feature makes
the issue appear again if the nested construct involves different
users, or... etc).

I agree regarding your request for reliability, but sometimes is not
easy at all, or you will need to support bash versions without the
fix...

I suspect this maybe related to the code in subst.c, but in 2 minutes
I did not see the exact portion bothering you. There are some comments
regarding nested process substitution, shell options, etc. No
references to /proc in that file.

Good luck !



On 30 June 2014 01:47, Linda Walsh <bash@tlinx.org> wrote:
> Right now, I just noticed myself steering away from the "cmd< <(xx)"
> construct, in a normal runtime script where it would likely be safe, but
> in the back of my mind, a little voice says "but you don't know how this
> might be re-used", and if it gets re-used w/o proc mounted or present,
> then this will mysteriously break".
> Grrr..I get frustrated at not being able to use features that
> could greatly simplify code because they don't work "reliably"
> (i.e. I don't always know where a piece of code I write will end up
> being called from, since if I put it in a library, and it's called
> from another routine,  which might be called from another...(etc...)
> kaboom.
>
> Is it possible to make that feature work, by default, w/o the unreliable
> part?  I.e. in < <(xxx).  Can't the part in (xxx) be forked into a child
> that has it's output fed into the parent?
>
> Right now we have (case 1):
> xxx|yyy|zzz for running "xxx" and "yyy" in children with "zzz" in a parent.
>
> So is there a reason for not doing similar for < <()?
>
> I.e. (case 2):
> zzz < <(yyy< <(xxx)) would very similar to the above.  xxx runs
> as a child feeding its output into 'yyy' and 'yyy' would run as a child of
> zzz feeding its output into the input of 'zzz'.
> If it can be done w/ in the first case, _reliably_ (works w/o special
> file systems mounted), why not the 2nd case?
>
> Could someone point out what I am missing or why they think it wouldn't
> work?
>
> Thanks!
> 𝓛𝓲𝓷𝓭𝓪
>
>



-- 
Iñigo Tejedor Arrondo