Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • Have you have a look at mugwump's IO::Plumbing [cpan.org]? Maybe with a little more syntactic sugar it could do the kind of thing you're talking about.

    • Thanks for the pointer. That looks mostly like what I was thinking of, indeed, just with a far clumsier API. Getting the API right is the tricky part – the implementation isn’t very exciting.

  • When I had the need for that, I used IPC::Run. It has a few weirdnesses in the API, though, I'm not sure if you'd like it.
    • I saw it when it was first released and got really excited. The API just doesn’t feel natural, though. It’s almost purely function-based, has this pumping concept which is an obvious use case cast into a weird API shape, and its use of strings as faux operators is at once too much and too little syntactic sugar: because it deals in strings, it requires a lot of noise characters and leaves the user responsible to account for the lack of operator precedence. So the clarity advantage of special sy

  • Maybe you could write a Text::Pipe [cpan.org] plugin that does what you need? See this test file [perl.org] for an example using syntactic sugar of how text pipes are stackable.

    • The API in Text::Pipe is nice. However, the module addresses a much simplified problem to begin with. There are no cases like connecting the stdout from one process to the stdin of another process but fd3 of the first process to the stdin of a third – to cater to such use cases, an Unix piping module will need a solid object model for use by desugared code doing more complicated things. Text::Pipe’s design does not fit this bill.

      Then there is also the need to provide amenities for real IPC stuf

  • I looked into doing something very much along those lines some time ago (during OSCON::EU 2006 in Brussels, I think).

    One of the problems is that callers which do use warnings will get lots of “Useless use of bitwise or (|) in void context” warnings. I considered whether this sort of thing would alleviate the problem:

    package Whatever::Name::It::Gets;

    use strict;
    use warnings;

    sub import {
        warnings->unimport(qw<void>);
    }

    It would, through the surprising scope of *^H, but ther

    • I wouldn’t particularly care about the redirection operators. I would rather let the desugared API handle the more complex cases than try to stuff them all into symbols.

      The warning is an annoyance, I agree.