http://www.perlmonks.org?node_id=301473


in reply to Re: I don't use printf enough
in thread I don't use printf enough

The absence of a newline, is because i always have -l enabled.

I like -l but wish that there was a way to selectively counter-act it, as I occasionally (but not often) want to print a newline-less line. How do you handle these situations?

bbfu
Black flowers blossom
Fearless on my breath

Replies are listed 'Best First'.
Re: Re2 (-l): I don't use printf enough
by BrowserUk (Patriarch) on Oct 23, 2003 at 12:56 UTC

    That's when I use printf:)

    With -L enabled, print 'Prompt: '; adds the newline but printf 'Prompt: '; $resp = <STDIN>; doesn't. The distinction is very useful.


    Examine what is said, not who speaks.
    "Efficiency is intelligent laziness." -David Dunham
    "Think for yourself!" - Abigail
    Hooray!

Re: Re2 (-l): I don't use printf enough
by jmcnamara (Monsignor) on Oct 23, 2003 at 13:38 UTC

    I like -l but wish that there was a way to selectively counter-act it

    Here is one way:

    #!/usr/bin/perl -wl print "aaa"; { local $\; print "bbb"; } print "bbb"; print "ccc"; __END__ Prints: aaa bbbbbb ccc

    --
    John.

Re: Re2 (-l): I don't use printf enough
by bart (Canon) on Oct 23, 2003 at 13:40 UTC
    I like -l but wish that there was a way to selectively counter-act it, as I occasionally (but not often) want to print a newline-less line. How do you handle these situations?
    Localize $\.
    $\ = "\n"; # as perl -l print "before"; { local $\; print "continued"; } print "after"; print "heh!";
    which prints
    before
    continuedafter
    heh!
    
    In fact, you can set $\ to anything, and with local, it's safe — or at least, as safe as using $\.

    IMO, every module that uses print in a hidden fashion, should use

    local $\;
    and not rely on $\ being empty at the time its functions are called.

    Note that printf ignores the settings of $\.

      every module that uses print in a hidden fashion, should use local $\;

      No way. Anybody who sets $\ should set it in a localized block when they do so. -l is there for one liners not real code. I _refuse_ to try to work around other people setting $\ stupidly. And for that matter simply localizing $\ in the module will not work. You'd have to do it in every single subroutine. And that means that every single subroutine that uses print is going to do an unecessary piece of work just to workaround somebody setting $\ stupidly. In essence I refuse to pay the price for somebody elses foolishness. And I dont see it as being reasonable to expect people to do so. Going down that road means that eventually somebody is going to argue that every single subroutine should localize all the global variables because of similar reasons.

      Blech.


      ---
      demerphq

        First they ignore you, then they laugh at you, then they fight you, then you win.
        -- Gandhi


        Going down that road means that eventually somebody is going to argue that every single subroutine should localize all the global variables because of similar reasons.

        Personally, I think there should be a switch, similar to strict, that will do this for you within a scope. Most modules shouldn't be depending on the globals anyway. It just causes craziness. Is there a use localize_globals; or some such? Ideally, one would add a use line at the top of the module and that would be it. Could this work? (Untested)

        package Filter::LocalizeGlobals; use Filter::Simple; # Add things to be localized here. my $locals = 'local (' . join ',', qw( $_ $\ $/ ); FILTER_ONLY code => sub { s/(\bsub\b\s*\w+{)/$1 $locals /g; }; 1;

        ------
        We are the carpenters and bricklayers of the Information Age.

        The idea is a little like C++ templates, except not quite so brain-meltingly complicated. -- TheDamian, Exegesis 6

        ... strings and arrays will suffice. As they are easily available as native data types in any sane language, ... - blokhead, speaking on evolutionary algorithms

        Please remember that I'm crufty and crochety. All opinions are purely mine and all code is untested, unless otherwise specified.