Re: [OT] sys call length limitation

Discussion in 'Perl Misc' started by gamo, Jan 24, 2014.

  1. gamo

    gamo Guest

    El 24/01/14 01:40, * Tong * escribió:
    > On Thu, 23 Jan 2014 14:59:47 +0000, Ben Morrow wrote:
    >
    >>> s,(x+),`echo $1 | wc -c`,eg

    >>
    >> . . . If it's just a Unix filter (input on stdin, output
    >> on stdout) then use tempfiles:
    >>
    >> use File::Slurp qw/read_file write_file/;
    >> use File::Temp qw/tempfile/;
    >>
    >> sub filter {
    >> my ($data) = @_;
    >>
    >> my ($IN, $in) = tempfile; my ($OUT, $out) = tempfile;
    >>
    >> write_file $IN, $data; system "wc -c <$in >$out"; return
    >> read_file $OUT;
    >> }
    >>
    >> s,(x+),filter $1,eg

    >
    > Nice, neat, clear & elegant. We have a winner.
    >
    > Thanks
    >


    Just to be a bit more elegant, don't forget to *unlink*
    that tempfiles or you would not like how /tmp looks.


    --
    http://www.telecable.es/personales/gamo/
    gamo, Jan 24, 2014
    #1
    1. Advertising

  2. gamo <> writes:
    > El 24/01/14 01:40, * Tong * escribió:
    >> On Thu, 23 Jan 2014 14:59:47 +0000, Ben Morrow wrote:
    >>
    >>>> s,(x+),`echo $1 | wc -c`,eg
    >>>
    >>> . . . If it's just a Unix filter (input on stdin, output
    >>> on stdout) then use tempfiles:
    >>>
    >>> use File::Slurp qw/read_file write_file/;
    >>> use File::Temp qw/tempfile/;
    >>>
    >>> sub filter {
    >>> my ($data) = @_;
    >>>
    >>> my ($IN, $in) = tempfile; my ($OUT, $out) = tempfile;
    >>>
    >>> write_file $IN, $data; system "wc -c <$in >$out"; return
    >>> read_file $OUT;
    >>> }
    >>>
    >>> s,(x+),filter $1,eg

    >>
    >> Nice, neat, clear & elegant. We have a winner.
    >>
    >> Thanks
    >>

    >
    > Just to be a bit more elegant, don't forget to *unlink*
    > that tempfiles or you would not like how /tmp looks.


    Or consider using Perl. It's not that difficult:

    ---------------
    sub filter
    {
    {
    my $fh = File::Temp->new();
    print $fh (@_);
    `wc -c < $fh`;
    }
    }
    ---------------

    The clumsy procedure of writing the input to a temporary file in order to
    "fix" the programmer ("Why do you tell me all this complicated stuff ! I
    friggin' don't care !! I have to prepare facking my exams to get a well
    paid developer job in the thec intusdry !!!") doesn't have to be
    implemented that clumsily.
    Rainer Weikusat, Jan 24, 2014
    #2
    1. Advertising

  3. gamo <> writes:
    > El 24/01/14 01:40, * Tong * escribió:
    >> On Thu, 23 Jan 2014 14:59:47 +0000, Ben Morrow wrote:
    >>
    >>>> s,(x+),`echo $1 | wc -c`,eg
    >>>
    >>> . . . If it's just a Unix filter (input on stdin, output
    >>> on stdout) then use tempfiles:
    >>>
    >>> use File::Slurp qw/read_file write_file/;
    >>> use File::Temp qw/tempfile/;
    >>>
    >>> sub filter {
    >>> my ($data) = @_;
    >>>
    >>> my ($IN, $in) = tempfile; my ($OUT, $out) = tempfile;
    >>>
    >>> write_file $IN, $data; system "wc -c <$in >$out"; return
    >>> read_file $OUT;
    >>> }
    >>>
    >>> s,(x+),filter $1,eg

    >>
    >> Nice, neat, clear & elegant. We have a winner.
    >>
    >> Thanks
    >>

    >
    > Just to be a bit more elegant, don't forget to *unlink*
    > that tempfiles or you would not like how /tmp looks.


    Or consider using Perl. It's not that difficult:

    ---------------
    sub filter
    {
    my $fh = File::Temp->new();
    print $fh (@_);
    `wc -c < $fh`;
    }
    ---------------

    The clumsy procedure of writing the input to a temporary file in order to
    "fix" the programmer ("Why do you tell me all this complicated stuff ! I
    friggin' don't care !! I have to prepare facking my exams to get a well
    paid developer job in the thec intusdry !!!") doesn't have to be
    implemented that clumsily.
    Rainer Weikusat, Jan 24, 2014
    #3
  4. Ben Morrow <> writes:
    > Quoth gamo <>:
    >> El 24/01/14 01:40, * Tong * escribió:
    >> > On Thu, 23 Jan 2014 14:59:47 +0000, Ben Morrow wrote:
    >> >
    >> >> my ($IN, $in) = tempfile; my ($OUT, $out) = tempfile;
    >> >>
    >> >> write_file $IN, $data; system "wc -c <$in >$out"; return
    >> >> read_file $OUT;
    >> >> }
    >> >>
    >> >> s,(x+),filter $1,eg

    >>
    >> Just to be a bit more elegant, don't forget to *unlink*
    >> that tempfiles or you would not like how /tmp looks.

    >
    > I had forgotten tempfile doesn't do that by default if you request a
    > filename.
    >
    > my $IN = File::Temp->new;
    > my $OUT = File::Temp->new;
    >
    > write_file $IN, $data;
    > system sprintf "wc -c <%s >%s", $IN->filename, $OUT->filename;
    > return read_file $OUT;


    Something it does by default is it stringifies to a
    filename. Considering that `` undergoes double-quote interpolation, the
    ->filename and read_file and actually, the output file altogether can be
    omitted via

    `wc -c < $IN`

    There's little point in making a copy of the first argument just so that
    a copy has been made and little reason why the subroutine should ignore
    all other arguments instead of dealing with them. And then, of course,
    the whole hullaballo of File::Slurp isn't really useful for anything
    here as the built-in print operator/ subroutine can do that as well, ie

    print $IN (@_);

    Should someone consider the overhead of funneling the input data through
    the perl I/O subsystem prohibitively expensive, there's always

    syswrite($fh, $_[0])

    when dealing only with the first argument or

    syswrite($fh, $_) for @_;

    That's 380 LOC (in a 1261 line text file) of a spurious, external
    dependency with no tangible effect save slowing down compilation of the
    code somewhat avoided at the clearly intolerable expense of having to
    write less code.
    Rainer Weikusat, Jan 24, 2014
    #4
  5. gamo

    Tim McDaniel Guest

    In article <>,
    Rainer Weikusat <> wrote:
    >Ben Morrow <> writes:
    >> my $IN = File::Temp->new;
    >> my $OUT = File::Temp->new;
    >>
    >> write_file $IN, $data;
    >> system sprintf "wc -c <%s >%s", $IN->filename, $OUT->filename;
    >> return read_file $OUT;

    >
    >Something it does by default is it stringifies to a
    >filename. Considering that `` undergoes double-quote interpolation,
    >the ->filename and read_file and actually, the output file altogether
    >can be omitted via
    >
    >`wc -c < $IN`


    In this example, yes. I don't remember the complete description of
    the actual task, but I thought it was some sort of filter where a
    large block of HTML (too large for the command line) was being passed
    to some filters, which would output a similarly large munged block.
    If I'm remembering right, `<$IN his | filter | stuff` would also fail.

    >That's 380 LOC (in a 1261 line text file) of a spurious, external
    >dependency with no tangible effect save slowing down compilation of
    >the code somewhat avoided at the clearly intolerable expense of
    >having to write less code.


    Oh, please hush up about that.

    --
    Tim McDaniel,
    Tim McDaniel, Jan 24, 2014
    #5
  6. (Tim McDaniel) writes:
    > In article <>,
    > Rainer Weikusat <> wrote:
    >>Ben Morrow <> writes:
    >>> my $IN = File::Temp->new;
    >>> my $OUT = File::Temp->new;
    >>>
    >>> write_file $IN, $data;
    >>> system sprintf "wc -c <%s >%s", $IN->filename, $OUT->filename;
    >>> return read_file $OUT;

    >>
    >>Something it does by default is it stringifies to a
    >>filename. Considering that `` undergoes double-quote interpolation,
    >>the ->filename and read_file and actually, the output file altogether
    >>can be omitted via
    >>
    >>`wc -c < $IN`

    >
    > In this example, yes. I don't remember the complete description of
    > the actual task, but I thought it was some sort of filter where a
    > large block of HTML (too large for the command line) was being passed
    > to some filters, which would output a similarly large munged block.


    It is read into a single Perl scalar either way. If it is too large to
    keep it in memory, neither of both approaches is suitable. But
    speculating about the differences between the posted 'contrived example'
    and the unknown 'real situation' is rather pointless since anyone is
    free to make up whatever seems suitable to him because the 'real
    situation' is unknown.

    >>That's 380 LOC (in a 1261 line text file) of a spurious, external
    >>dependency with no tangible effect save slowing down compilation of
    >>the code somewhat avoided at the clearly intolerable expense of
    >>having to write less code.

    >
    > Oh, please hush up about that.


    Sorry, but these are facts: File::Slurp doesn't provide a benefit here
    (or anywhere, for that matter) or at least I don't know what this
    benefit might be (Please feel free to argue that it does provide a
    benefit, even if only the benefit of "if I write it that way, I won't
    have to write it the other way"). But using it is not 'free', costing
    both developer time and computer time. While I'm convinced that I'm
    right, this doesn't mean I actually am. "Shut up if you don't just love
    Justin Bieber" is not a counterargument, though.
    Rainer Weikusat, Jan 24, 2014
    #6
  7. Rainer Weikusat <> writes:

    [...]

    > "Shut up if you don't just love Justin Bieber" is not a
    > counterargument, though.


    Interesting/ useful text touching this:

    http://www.paulgraham.com/disagree.html
    Rainer Weikusat, Jan 24, 2014
    #7
  8. gamo

    Tim McDaniel Guest

    In article <>,
    Rainer Weikusat <> wrote:
    > (Tim McDaniel) writes:
    >> In article <>,
    >> Rainer Weikusat <> wrote:
    >>>Ben Morrow <> writes:
    >>>> my $IN = File::Temp->new;
    >>>> my $OUT = File::Temp->new;
    >>>>
    >>>> write_file $IN, $data;
    >>>> system sprintf "wc -c <%s >%s", $IN->filename, $OUT->filename;
    >>>> return read_file $OUT;
    >>>
    >>>Something it does by default is it stringifies to a
    >>>filename. Considering that `` undergoes double-quote interpolation,
    >>>the ->filename and read_file and actually, the output file
    >>>altogether can be omitted via
    >>>
    >>>`wc -c < $IN`

    >>
    >> In this example, yes. I don't remember the complete description of
    >> the actual task, but I thought it was some sort of filter where a
    >> large block of HTML (too large for the command line) was being passed
    >> to some filters, which would output a similarly large munged block.

    >
    >It is read into a single Perl scalar either way. If it is too large to
    >keep it in memory, neither of both approaches is suitable.


    The problem wasn't that it was too large to keep in memory -- it was
    stated that the problem was with the shell command line length for
    `command "the data he was trying to process"`.

    Moreover, if it were too large for a Perl scalar, that code could be
    modified to read line-by-line, or block-by-block, or whatever. `...`
    cannot.

    >But speculating about the differences between the posted 'contrived
    >example' and the unknown 'real situation'


    As I recall, he wrote that he tried `...` and it didn't work because
    it was too large for the command line. It was diagnosed as being too
    large for the shell in particular: I got a problem with `...` with
    2000K data when a Perl scalar would have no problems with that size.

    --
    Tim McDaniel,
    Tim McDaniel, Jan 24, 2014
    #8
  9. (Tim McDaniel) writes:
    > In article <>,
    > Rainer Weikusat <> wrote:
    >> (Tim McDaniel) writes:
    >>> In article <>,
    >>> Rainer Weikusat <> wrote:
    >>>>Ben Morrow <> writes:
    >>>>> my $IN = File::Temp->new;
    >>>>> my $OUT = File::Temp->new;
    >>>>>
    >>>>> write_file $IN, $data;
    >>>>> system sprintf "wc -c <%s >%s", $IN->filename, $OUT->filename;
    >>>>> return read_file $OUT;
    >>>>
    >>>>Something it does by default is it stringifies to a
    >>>>filename. Considering that `` undergoes double-quote interpolation,
    >>>>the ->filename and read_file and actually, the output file
    >>>>altogether can be omitted via
    >>>>
    >>>>`wc -c < $IN`
    >>>
    >>> In this example, yes. I don't remember the complete description of
    >>> the actual task, but I thought it was some sort of filter where a
    >>> large block of HTML (too large for the command line) was being passed
    >>> to some filters, which would output a similarly large munged block.

    >>
    >>It is read into a single Perl scalar either way. If it is too large to
    >>keep it in memory, neither of both approaches is suitable.

    >
    > The problem wasn't that it was too large to keep in memory -- it was
    > stated that the problem was with the shell command line length for
    > `command "the data he was trying to process"`.


    That's not happening here because $IN will (in the given context)
    stringify to the name of the temporary file the data was writte to.

    Remark about File::Temp: It struck me that this is really a nice, simple
    example of 'an object' in the OOP sense, ie not just an overengineered
    way to (ab-)use Perl hashes in order to emulate C structs: A Temp::File
    object is 'the temporary file' insofar Perl code is concerned. It can be
    used as a file handle and behaves like a file handle in this case. It
    can also be used as a file name and then, it behaves like a file
    name. Lastly, when the object is destroyed, the file is automatically
    unlinked. There's no need to mess around with 'the mechanics' anywhere
    here.
    Rainer Weikusat, Jan 24, 2014
    #9
  10. gamo

    Tim McDaniel Guest

    In article <>,
    Rainer Weikusat <> wrote:
    > (Tim McDaniel) writes:
    >> In article <>,
    >> Rainer Weikusat <> wrote:
    >>> (Tim McDaniel) writes:
    >>>> In article <>,
    >>>> Rainer Weikusat <> wrote:
    >>>>>Ben Morrow <> writes:
    >>>>>> my $IN = File::Temp->new;
    >>>>>> my $OUT = File::Temp->new;
    >>>>>>
    >>>>>> write_file $IN, $data;
    >>>>>> system sprintf "wc -c <%s >%s", $IN->filename, $OUT->filename;
    >>>>>> return read_file $OUT;
    >>>>>
    >>>>>Something it does by default is it stringifies to a
    >>>>>filename. Considering that `` undergoes double-quote interpolation,
    >>>>>the ->filename and read_file and actually, the output file
    >>>>>altogether can be omitted via
    >>>>>
    >>>>>`wc -c < $IN`
    >>>>
    >>>> In this example, yes. I don't remember the complete description of
    >>>> the actual task, but I thought it was some sort of filter where a
    >>>> large block of HTML (too large for the command line) was being passed
    >>>> to some filters, which would output a similarly large munged block.
    >>>
    >>>It is read into a single Perl scalar either way. If it is too large to
    >>>keep it in memory, neither of both approaches is suitable.

    >>
    >> The problem wasn't that it was too large to keep in memory -- it was
    >> stated that the problem was with the shell command line length for
    >> `command "the data he was trying to process"`.

    >
    >That's not happening here because $IN will (in the given context)
    >stringify to the name of the temporary file the data was writte to.


    While I wasn't objecting to that, I was getting confused at times
    about what was too big. You're right.

    `...` would work as well (or as badly) as Ben's proposal. A command
    like `... <some_input` does not hit the command-line limit either.
    Both Ben's code above and `...` would both hit Perl memory
    limitations, or neither will hit. Since the example he provided was
    on the order of 200K, your solution `...` should be fine there on most
    modern systems.

    On the system I'm on right now, the knee of the curve starts bending
    way up at 0.5GB:

    $ time perl -e 'my $size = (1<<28); print "size $size\n"; my $x = "x" x $size'
    size 268435456

    real 0m1.379s
    user 0m0.111s
    sys 0m1.257s
    $ time perl -e 'my $size = (1<<29); print "size $size\n"; my $x = "x" x $size'
    size 536870912

    real 0m5.722s
    user 0m0.248s
    sys 0m2.444s
    $ time perl -e 'my $size = (1<<30); print "size $size\n"; my $x = "x" x $size'
    size 1073741824
    ^C

    real 1m43.568s
    user 0m0.334s
    sys 0m6.197s

    but of course Your System's Mileage May Vary.

    If one were ever faced with a problem too large for the system
    involved, neither `...` nor Ben's solution unmodified would work. At
    that point, `...` could not be helped. It'd have to be abandoned in
    favor of files or temp files being written to and/or read from record
    by record, or block by block, or something like that.

    Thank you for bearing with my confusion about what's too big.

    --
    Tim McDaniel,
    Tim McDaniel, Jan 24, 2014
    #10
  11. gamo

    gamo Guest

    El 25/01/14 01:59, * Tong * escribió:
    > On Fri, 24 Jan 2014 13:35:34 +0000, Rainer Weikusat wrote:
    >
    >> Or consider using Perl. It's not that difficult:
    >>
    >> ---------------
    >> sub filter {
    >> {
    >> my $fh = File::Temp->new();
    >> print $fh (@_);
    >> `wc -c < $fh`;
    >> }
    >> }
    >> ---------------

    >
    > Thanks. that works really well, with that extra pair of braces that I
    > didn't know what's for at the beginning.
    >


    Extra braces means scope, in particular to $fh.
    Outside this scope, $fh is like if you type 'undef $fh;'
    and since $fh is a file handle, this means that file
    handle is closed.

    You could replicate that without braces:

    sub filter{
    my $fh = File::Temp->new();
    print $fh (@_);
    my $ret = `wc -c $fh`;
    undef $fh;
    return $ret;
    }

    But it's a matter of economy, and style.

    > Although being poked fun of doesn't feel good. But anyway,
    >
    > Thanks
    >



    --
    http://www.telecable.es/personales/gamo/
    gamo, Jan 25, 2014
    #11
  12. gamo

    Tim McDaniel Guest

    In article <L%DEu.216375$>,
    * Tong * <> wrote:
    >On Fri, 24 Jan 2014 13:35:34 +0000, Rainer Weikusat wrote:
    >
    >> Or consider using Perl. It's not that difficult:
    >>
    >> ---------------
    >> sub filter {
    >> {
    >> my $fh = File::Temp->new();
    >> print $fh (@_);
    >> `wc -c < $fh`;
    >> }
    >> }
    >> ---------------

    >
    >Thanks. that works really well, with that extra pair of braces that I
    >didn't know what's for at the beginning.


    Rainer did not provide those empty braces. What reason did you have
    for adding them -- was there an error message, or different output, or
    something? They shouldn't be needed for anything. The braces on sub
    filter {...} delimit scope.

    --
    Tim McDaniel,
    Tim McDaniel, Jan 25, 2014
    #12
  13. gamo

    Tim McDaniel Guest

    In article <lc15g6$pmv$>, gamo <> wrote:
    >El 25/01/14 01:59, * Tong * escribi_:
    >> On Fri, 24 Jan 2014 13:35:34 +0000, Rainer Weikusat wrote:
    >>
    >>> Or consider using Perl. It's not that difficult:
    >>>
    >>> ---------------
    >>> sub filter {
    >>> {
    >>> my $fh = File::Temp->new();
    >>> print $fh (@_);
    >>> `wc -c < $fh`;
    >>> }
    >>> }


    Ooo, I just noticed what I think is a bug. $fh isn't flushed before
    calling wc. I like to close files when done with them, but the
    File::Temp man page says that some operating systems delete the file
    on close, so we can't do that to flush it (or we can, if we want to
    pass another argument to new() and handle the deletion ourselves,
    which I don't).

    I also prefer to do an explicit return statement. True, it's not
    necessary in this sort of case. But I prefer it to make it clear that
    I did intend to return at that spot (I won't absent-mindedly add code
    after it and trash the return value) and I did intend that to be the
    return value of the sub (that is, I didn't merely forget "return;" in
    cases when I want the caller to get no return value).

    File::Temp (on my machine's perl) says "The object isa 'IO::Handle'",
    so this should work (though I've not tested it):

    sub filter {
    my $fh = File::Temp->new();
    $fh->autoflush(1);
    print $fh (@_);
    return `wc -c < $fh`;
    }

    >>> ---------------

    >>
    >> Thanks. that works really well, with that extra pair of braces that
    >> I didn't know what's for at the beginning.

    >
    >Extra braces means scope, in particular to $fh.


    The braces in "sub filter {...}" delimit scope too. If the inner
    braces weren't there, $fh would still go out of scope when the sub
    returns.

    >Outside this scope, $fh is like if you type 'undef $fh;'


    You should always put "use strict;" at the top of each file. In that
    case, going out of scope isn't "undef" -- it's a compile-time error.

    Even without "use strict;", going out of scope isn't at all like
    "undef". Outside its scope, $fh refers to an entirely different
    variable. It might be undefined or it might not.

    my $a = 3;
    {
    my $a = 25;
    ...
    }
    # here, the outer $a is back in scope and its value is 3.

    >You could replicate that without braces:
    >
    >sub filter{
    > my $fh = File::Temp->new();
    > print $fh (@_);
    > my $ret = `wc -c $fh`;
    > undef $fh;
    > return $ret;
    >}


    There's no need for the "undef $fh": as I noted above, it's going out
    of scope anyway at the return, whether explicit or the implicit one
    when it hits the close curly brace on a sub. I think my version above
    should work.

    --
    Tim McDaniel,
    Tim McDaniel, Jan 25, 2014
    #13
  14. gamo

    Tim McDaniel Guest

    In article <>,
    Ben Morrow <> wrote:
    >
    >Quoth :
    >> File::Temp (on my machine's perl) says "The object isa 'IO::Handle'",
    >> so this should work (though I've not tested it):
    >>
    >> sub filter {
    >> my $fh = File::Temp->new();
    >> $fh->autoflush(1);
    >> print $fh (@_);
    >> return `wc -c < $fh`;
    >> }

    >
    >This needs a
    >
    > use IO::Handle;
    >
    >unless something else has loaded it already (which you shouldn't rely
    >on).


    I'm not at all familiar with inheritance and haven't done much with
    Perl OOP. Its statement that "The object isa 'IO::Handle'" isn't
    sufficient? Is there a way that a module can be isa something else
    without having its methods? The 5.14.2 version has
    use base qw/ IO::Handle IO::Seekable /;
    and "man base" indicates that that suffices.

    Also, I can call Foo::Bar::Baz::Quux({ FROG => 'croak' }) without
    "use Foo::Bar::Baz;" (though it's better style to do it). Why
    doesn't $fh->Quuz(...) work -- isn't it blessed into File::Temp and
    so shouldn't that isa-ing take care of it?

    --
    Tim McDaniel,
    Tim McDaniel, Jan 25, 2014
    #14
  15. gamo

    Tim McDaniel Guest

    In article <>,
    Ben Morrow <> wrote:
    >
    >Quoth :
    >> In article <L%DEu.216375$>,
    >> * Tong * <> wrote:
    >> >On Fri, 24 Jan 2014 13:35:34 +0000, Rainer Weikusat wrote:
    >> >
    >> >> Or consider using Perl. It's not that difficult:
    >> >>
    >> >> ---------------
    >> >> sub filter {
    >> >> {
    >> >> my $fh = File::Temp->new();
    >> >> print $fh (@_);
    >> >> `wc -c < $fh`;
    >> >> }
    >> >> }
    >> >> ---------------
    >> >
    >> >Thanks. that works really well, with that extra pair of braces that I
    >> >didn't know what's for at the beginning.

    >>
    >> Rainer did not provide those empty braces.

    >
    >Yes he did. Tong's newsreader appears to have messed up the
    >threading, but the message being replied to is
    ><>, which has the
    >extraneous braces in.


    [rummage rummage]

    Ah, I don't have that article. I have an article that includes header
    lines

    Message-ID: <>
    Supersedes: <>

    So I suspect Rainer posted, realized "wait, I don't need the inner
    braces" (maybe they were left over after some previous changes),
    superceded the article ... and on my system the superceding was
    actually obeyed.

    --
    Tim McDaniel,
    Tim McDaniel, Jan 25, 2014
    #15
  16. with <> Ben Morrow wrote:

    *SKIP*

    > ...in fact, I've just tested some things, and this is no longer a
    > problem in any case. I wonder when that changed?


    5.11.3

    *CUT*

    --
    Torvalds' goal for Linux is very simple: World Domination
    Stallman's goal for GNU is even simpler: Freedom
    Eric Pozharski, Jan 26, 2014
    #16
  17. with <> Eric Pozharski wrote:
    > with <> Ben Morrow wrote:


    >> ...in fact, I've just tested some things, and this is no longer a
    >> problem in any case. I wonder when that changed?

    > 5.11.3


    My bad. That's the version when that started. It was sorted out in
    5.13.8.

    --
    Torvalds' goal for Linux is very simple: World Domination
    Stallman's goal for GNU is even simpler: Freedom
    Eric Pozharski, Jan 26, 2014
    #17
  18. (Tim McDaniel) writes:
    > In article <lc15g6$pmv$>, gamo <> wrote:
    >>El 25/01/14 01:59, * Tong * escribi_:
    >>> On Fri, 24 Jan 2014 13:35:34 +0000, Rainer Weikusat wrote:
    >>>
    >>>> Or consider using Perl. It's not that difficult:
    >>>>
    >>>> ---------------
    >>>> sub filter {
    >>>> {
    >>>> my $fh = File::Temp->new();
    >>>> print $fh (@_);
    >>>> `wc -c < $fh`;
    >>>> }
    >>>> }

    >
    > Ooo, I just noticed what I think is a bug. $fh isn't flushed before
    > calling wc.


    Except when I explicitly say so, I don't post code which hasn't been
    tested and it is being flushed on the system/ with the perl version I
    was using. Which is the behaviour I expected considering that

    Beginning with v5.6.0, Perl will attempt to flush all files
    opened for output before forking the child process, but this may
    not be supported on some platforms (see perlport).
    (perldoc -f fork)

    According to perlport (5.10.1 - 5.18.0) fork

    Does not automatically flush output handles on some platforms.
    (SunOS, Solaris, HP-UX)

    If this was of concern, the obvious alternative would be

    syswrite($fh, $_) for @_;

    But I generally don't care if "something doesn't work on Solaris"
    (especially not if it is related to fork which only "works on Solaris"
    for a very peculiar definition of "working", anyway ...).

    > I also prefer to do an explicit return statement. True, it's not
    > necessary in this sort of case.


    Me too. But since this was (necessarily) partially on exercise in "text
    reduction", I omitted it here.
    Rainer Weikusat, Jan 26, 2014
    #18
  19. gamo <> writes:

    >> On Fri, 24 Jan 2014 13:35:34 +0000, Rainer Weikusat wrote:
    >>
    >>> Or consider using Perl. It's not that difficult:
    >>>
    >>> ---------------
    >>> sub filter {
    >>> {
    >>> my $fh = File::Temp->new();
    >>> print $fh (@_);
    >>> `wc -c < $fh`;
    >>> }
    >>> }
    >>> ---------------

    >>
    >> Thanks. that works really well, with that extra pair of braces that I
    >> didn't know what's for at the beginning.
    >>

    >
    > Extra braces means scope, in particular to $fh.
    > Outside this scope, $fh is like if you type 'undef $fh;'
    > and since $fh is a file handle, this means that file
    > handle is closed.
    >
    > You could replicate that without braces:
    >
    > sub filter{
    > my $fh = File::Temp->new();
    > print $fh (@_);
    > my $ret = `wc -c $fh`;
    > undef $fh;
    > return $ret;
    > }
    >
    > But it's a matter of economy, and style.


    The inner block was left-over from a previous version and was supposed
    to force $fh to go out of scope and hence, being flushed and closed,
    before executing the command because I originally thought this was
    necessary. When I noticed this, I did a supersede of the original
    article with the superfluous {} removed but "some servers" (in
    particular, the Google-servers) don't honour any "author control of
    erronously published text" commands.
    Rainer Weikusat, Jan 26, 2014
    #19
  20. Ben Morrow <> writes:
    > Quoth :
    >> In article <>,
    >> Ben Morrow <> wrote:
    >> >
    >> >This needs a
    >> >
    >> > use IO::Handle;
    >> >
    >> >unless something else has loaded it already (which you shouldn't rely
    >> >on).

    >>
    >> I'm not at all familiar with inheritance and haven't done much with
    >> Perl OOP. Its statement that "The object isa 'IO::Handle'" isn't
    >> sufficient? Is there a way that a module can be isa something else
    >> without having its methods? The 5.14.2 version has
    >> use base qw/ IO::Handle IO::Seekable /;
    >> and "man base" indicates that that suffices.

    >
    > Hmm. Yes, you may be right that File::Temp's documentation that it
    > inherits from IO::Handle allows you to assume that loading File::Temp
    > will load IO::Handle.


    The relevant text is actually 'The object isa "IO::Handle" and isa "IO::Seekable"
    so all those methods are available'. Consequently, if those methods
    weren't available, this would be a bug in File::Temp.
    Rainer Weikusat, Jan 26, 2014
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Tim McDaniel

    Re: sys call length limitation

    Tim McDaniel, Jan 22, 2014, in forum: Perl Misc
    Replies:
    0
    Views:
    69
    Tim McDaniel
    Jan 22, 2014
  2. George Mpouras

    Re: sys call length limitation

    George Mpouras, Jan 22, 2014, in forum: Perl Misc
    Replies:
    0
    Views:
    57
    George Mpouras
    Jan 22, 2014
  3. Rainer Weikusat

    Re: sys call length limitation

    Rainer Weikusat, Jan 22, 2014, in forum: Perl Misc
    Replies:
    0
    Views:
    58
    Rainer Weikusat
    Jan 22, 2014
  4. Rainer Weikusat

    Re: sys call length limitation

    Rainer Weikusat, Jan 22, 2014, in forum: Perl Misc
    Replies:
    2
    Views:
    59
    Peter J. Holzer
    Jan 23, 2014
  5. Rainer Weikusat

    Re: [OT] sys call length limitation

    Rainer Weikusat, Jan 24, 2014, in forum: Perl Misc
    Replies:
    1
    Views:
    79
    Rainer Weikusat
    Jan 24, 2014
Loading...

Share This Page