Sujet : Re: Create functional processing pipe (without eval)?
De : janis_papanagnou+ng (at) *nospam* hotmail.com (Janis Papanagnou)
Groupes : comp.unix.shellDate : 07. May 2025, 09:16:39
Autres entêtes
Organisation : A noiseless patient Spider
Message-ID : <vvf4t9$tfsu$1@dont-email.me>
References : 1 2
User-Agent : Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
On 07.05.2025 04:25, Kaz Kylheku wrote:
On 2025-05-07, Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:
I'm pondering about creating a functional processing pipe, depending
on program parameters, and whether that's possible to achieve without
using 'eval'.
>
Say, the program is called "filter" and may accept 0..N parameters and
depending on the set of parameters the respective pipe functionality
shall be defined like
>
filter => cat
filter p1 => cat | func p1
filter p1 p2 => cat | func p1 | func p2
filter p1 p2 ... pN => cat | func p1 | func p2 | ... | func pN
>
where "func" is working as filter and accepts exactly one parameter.
The problem is that the number of pipes on the right hand side
depends on the number of arguments.
The number of pipes in a command pipe is a property of syntax;
Yes, this is the key observation!
it is something that needs eval.
If you're interested in being able to make this kind of code
transformation, perhaps you should start a project to add macros to a
shell. (An educated guess informs me that you'd likely choose Korn).
Yes, Ksh is my standard shell.
But if there'd be (beyond 'eval') some sort of "meta-feature" in Bash
(or in other shell) I'd also be interested. Something safer and less
troublesome (quoting!) than 'eval'.
Macros avoid extra eval by taking advantage of the result of the
substitution being "naturally thrown into the path of the evaluator",
just like any other code that is not expanded by a macro.
Hmm.., yes, macros is a possible way to go. (Not sure I'd like to
take that path.) I'll think about that.
Thanks for the confirmation and for the suggestion!
Janis