Re: error print on closed file handle

[John W. Krahn]

Rajeev Prasad wrote:

plz. advice why am i getting this error?


Because the filehandle OUT_FH has NOT been opened correctly!



I have checked:
varilable outfile has proper path/filename


How have you checked that?



array allrecords has data


How have you checked that?



open(OUT_FH,">","$outfile");


You shouldn't quote variables:

perldoc -q quoting

You should verify that open() worked correctly before trying to use a 
possibly invalid filehandle:


open OUT_FH, '>', $outfile or die "Cannot open '$outfile' because: $!";



print OUT_FH "@allrecords";


Did you really want to interpolate that array?

perldoc -q "Why do I get weird spaces when I print an array of lines?"



close OUT_FH;

error:
print() on closed filehandle OUT_FH at /...




John
--
Any intelligent fool can make things bigger and
more complex... It takes a touch of genius -
and a lot of courage to move in the opposite
direction.   -- Albert Einstein

--
To unsubscribe, e-mail: beginners-unsubscr...@perl.org
For additional commands, e-mail: beginners-h...@perl.org
http://learn.perl.org/

Re[2]: running perl script from inside another script & collecting output in array

[Jeff Pang]

15 сентября 2011, 08:38 от Rajeev Prasad :
> I am now using:
> 
> my @outfiles = `thecalledscript.pl $filename`;
> 
> i am getting right results.
> 
> now question is: is this the best method in terms of efficiency?
> 

Not the good way.
It's better to write the called script as a module, then use or require this 
module in main script and call the methods in the module.

--
  Jeff Pang
  jeffp...@mail.ru

Re: running perl script from inside another script & collecting output in array

[Brandon McCaig]

On Thu, Sep 15, 2011 at 12:07 AM, Rajeev Prasad  wrote:
> here is how i am calling it from a thecalling_script:
*snip*
>     require "thecalledscript.pl";
*snip*
> issue is, the called script prints some filenames after completion to STDOUT. 
> how can i collect them into an array variable?

You could always make an external call to perl to invoke this program.
For example, using exec or system. E.g.,

  exec('perl', 'thecalledscript.pl', $filename);

It depends on just what thecalledscript.pl does and whether or not
your program needs to do anything in response. I'm unfamiliar with
best practices regarding invoking a Perl script with require, but my
intuition says that it looks like abuse. :)

I've sort of begun to think that nearly any program that you write
should be mostly implemented in a library of sorts to optimize the
software-to-software communication between programs. Then you'd just
basically interface that library with the user and standard
input/output mechanisms. If you control thecalledscript.pl then
perhaps you could consider moving the guts into a Perl module, leaving
only the necessary glue in thecalledscript.pl to interface with the
user and/or standard input/output mechanisms.


-- 
Brandon McCaig  
V zrna gur orfg jvgu jung V fnl. Vg qbrfa'g nyjnlf fbhaq gung jnl.
Castopulence Software  

--
To unsubscribe, e-mail: beginners-unsubscr...@perl.org
For additional commands, e-mail: beginners-h...@perl.org
http://learn.perl.org/

Re: running perl script from inside another script & collecting output in array

[Rajeev Prasad]

I am now using:

my @outfiles = `thecalledscript.pl $filename`;


i am getting right results.

now question is: is this the best method in terms of efficiency?





From: Rajeev Prasad 
To: Perl Beginners 
Sent: Wednesday, September 14, 2011 11:07 PM
Subject: running perl script from inside another script & collecting output in 
array



i am doing like below:

thecalledscript.pl needs a filename as argument.

here is how i am calling it from a thecalling_script:



{
    local @ARGV;
    @ARGV = ("$filename");
    require "thecalledscript.pl";
}

issue is, the called script prints some filenames after completion to STDOUT. 
how can i collect them into an array variable?

running perl script from inside another script & collecting output in array

[Rajeev Prasad]

i am doing like below:

thecalledscript.pl needs a filename as argument.

here is how i am calling it from a thecalling_script:



{
    local @ARGV;
    @ARGV = ("$filename");
    require "thecalledscript.pl";
}

issue is, the called script prints some filenames after completion to STDOUT. 
how can i collect them into an array variable?

Re: error print on closed file handle

[Rajeev Prasad]

thx. Shawn that fixed the issue.




From: Shawn H Corey 
To: beginners@perl.org
Sent: Wednesday, September 14, 2011 8:40 PM
Subject: Re: error print on closed file handle

On 11-09-14 08:38 PM, Rajeev Prasad wrote:
> plz. advice why am i getting this error?
> 
> 
> I have checked:
> varilable outfile has proper path/filename
> array allrecords has data
> 
> 
> open(OUT_FH,">","$outfile");
> print OUT_FH "@allrecords";
> close OUT_FH;

# You should test all your opens; your problem probably lies there.
# You shouldn't stringify the file name.
# You should use lexical file handles.

  open my $out_fh, '>', $outfile or die "could not open $outFile: $!\n";
  print $out_fh "@allrecords" or die "could not print to $outfile: $!\n";
  close $out_fh or die "could not close $outfile: $!\n";


-- Just my 0.0002 million dollars worth,
  Shawn

Confusion is the first step of understanding.

Programming is as much about organization and communication
as it is about coding.

The secret to great software:  Fail early & often.

Eliminate software piracy:  use only FLOSS.

"Make something worthwhile."  -- Dear Hunter

-- To unsubscribe, e-mail: beginners-unsubscr...@perl.org
For additional commands, e-mail: beginners-h...@perl.org
http://learn.perl.org/

Re: Help, About Global variable.

[Uri Guttman]

> "BM" == Brandon McCaig  writes:

  BM> [1] I personally find it very petty when Uri mentions his work as a
  BM> Perl "recruitment agent" (for lack of a better description right now)
  BM> and implies that he'll never consider you as a potential candidate
  BM> with regards to that because of your opinion on a subjective topic.
  BM> That's not even a relevant qualification, IMHO; I bet there are a few
  BM> thousands, if not millions, of people doing that job that don't even
  BM> know the first thing about software development. Go consult
  BM> http://thedailywtf.com/ for some fun stories about people being hired
  BM> in senior programming roles without even knowing the very basics of
  BM> programming. :-X

and you're not being petty bringing that up? :)

my point there is that i do judge perl and other skills
professionally. not a hobby, not on this list, etc. i get paid for my
opinions about the quality of candidates. i review their code, talk the
them about it, listen to what they say, how they take the critique,
etc. it all factors in. my views on coding style and rules are mine but
developed over 38 years of coding. i beat linus on that and i have done
things he hasn't done so that isn't a useful comparison (a silly one
IMO). so getting back to this. if i suggest something or offer an idea
here, you can take it or leave it. you can discuss it in a logical way
or attack me directly or my posting style. i choose to say that one way
is more how i want to see and i support in candidates i recommend. the
other is not something that i want my clients to see in their
developers. that is my job, separating the professionals from the
kiddies. and if you act like a kiddie and get all hurt because i
disagree with your ideas, that is your issue and i won't be helping you
out as much. you need to separate ideas from the person. i do that all
the time. if you can't see that, i can't help there either. i will
attack your ideas if i think they deserve it. i will not attack the
person unless they attack me or other people.

and getting back to the subject at hand, single letter var names. you
and rob seem to keep forgetting i didn't say never use single letter
names. i said the vast majority of vars don't want them so focus on
those. and try to keep away from single char names. get it? try to keep
away from the is the idea. you want to convey information to the reader
of the code. single letter names convey no information unless they are
cultural standards like $i. and those are not used as often as you all
seem to think. as i said think about the thousands of names you need to
pick and use - how many are $i and related? a tiny fraction. so why even
support their use except for the few allowable cases? the logic railed
against this is weak and emotional and not in the interest of good
coding. that is my goal, better coding for all. single letter names IN
GENERAL are a bad coding idea. i yelled again for emphasis. no one seems
to get that point.

and i am off this thread. all replies will be redirected to
/dev/null. let's move on.

uri

-- 
Uri Guttman  --  uri AT perlhunter DOT com  ---  http://www.perlhunter.com --
  Perl Developer Recruiting and Placement Services  -
-  Perl Code Review, Architecture, Development, Training, Support ---

-- 
To unsubscribe, e-mail: beginners-unsubscr...@perl.org
For additional commands, e-mail: beginners-h...@perl.org
http://learn.perl.org/

Re: Help, About Global variable.

[Brandon McCaig]

On Wed, Sep 14, 2011 at 8:57 PM, Uri Guttman  wrote:
> it was topical as your (self admitted) blowup happened here. and it
> caused a small ruckus until you calmed down.

I'd say you're both out to lunch on this. I don't even recall this
subject so if I even read the affected threads then I obviously didn't
think it was worth acknowledging or remembering. Sometimes people put
their foot in their mouth (or on their keyboard, as the case may be).
It sounds like a private matter so I see little reason to bring it up
now (especially repeatedly, if my memory is correct that it's not the
first thread that I've seen it re-surface on). and if it persists then
all you can really do is ignore that person's posts.

> my good engrish is fine very well!

Personally I agree that it's very sloppy to write without capitals.
It's lazy and annoying to read. Capitals are a part of the English
language syntax. I don't claim to write perfect English, but I do try.
Something as simple as capitalizing the first letter of a sentence is
primary! You learn it in like the first or second grade. It's not like
the shift key is overly difficult for you to reach for either. It's
something a Perl programmer obviously must cope with unless they've
somehow found a special Perl-oriented keyboard or special OS
configuration that makes $ and @ and & (and all of the other shifted
characters common in Perl) possible to type with a single key...
Somebody so pedantic about code should certainly apply himself more in
typing human language for public consumption, IMHO.

> it isn't a crude filter. it is a solid rule of thumb. a useful
> guideline. where did i say once that all single letter vars are out? i
> said there are exceptions but few and very localized. my bigger point
> which you are ignoring is that by far the larger number of vars need
> proper names so using single letter names is an exception. the point is
> to notice that single letter names are not useful in general. in
> specific cases they could be. you haven't addressed the scope of the
> number of names out there.

Rob did a very good job of describing this. The amount of detail
required for a variable name is proportional to the scope that the
variable is visible to. A two line subroutine usually does not require
a 10 or 20 character lexical variable. The variable's purpose is
usually obvious. It serves no practical purpose and only serves to
waste limited human memory and processing power to use a descriptive
name. With self-describing code it's often obvious what the variable
represents. At least in the code that I write. Adding detail to that
is just redundant and verbose. There's a reason a --verbose option is
the norm versus a --brief option. :) We normally don't need or want
extra information. We can get by with the bare minimum most of the
time, especially when we're already familiar with what we're dealing
with. We'll let you know if we need more detail, thanks. :) If we do
need more detail then we only need it the once. We don't need you to
bring it up every time we come across something. Or if we do then
you've already Done Something Wrong(tm).

As elite as Uri may or may not be within the Perl community[1], you
can search online for references of Linus Torvalds[2] suggesting very
terse variable names whenever a more descriptive name isn't necessary.
Whether or not you subscribe to elitism, I think most can agree that
Mr. Torvalds is probably universally considered more elite than Uri.
So I guess that's a trump. I don't stalk Linus so unfortunately I'm
unaware if he has since changed his mind, but if he had I think it
would only serve to demonstrate that such a topic is very subjective
and people do indeed change their minds on the subject over time,
sometimes even going back and forth. There is no definite right or
wrong answer. It's not black and white.

I'm perfectly open to discussing such a topic and actually find it
rewarding to do so. It's both fun and often educational to learn of
other people's experiences and possibly expand your own horizons with
regards to a subject, whether subjective or not. What completely ruins
the discussion though is when somebody joins in, insisting to have The
One True Answer(tm), without being able to provide an unquestionable
proof for it, and insisting that they're right and you're wrong. You
might get away with this if the discussion is taking place on your own
personal mailing list or discussion board, or for a project thereof,
but if it's just a public discussion and you're not universally
considered "god" by the community then I think it's only fair to add a
little bit of humility to your posts and try to remain friendly and
open to discussion.[3] It may well be true that in your own personal
experience single-character variable names are difficult to
understand, but then in my experience it may be exactly the opposite.
So then which one is universally right? Perhaps neither.

So that it's clear I have no interest in having an

Re: error print on closed file handle

[Shawn H Corey]

On 11-09-14 08:38 PM, Rajeev Prasad wrote:

plz. advice why am i getting this error?


I have checked:
varilable outfile has proper path/filename
array allrecords has data


open(OUT_FH,">","$outfile");
print OUT_FH "@allrecords";
close OUT_FH;


# You should test all your opens; your problem probably lies there.
# You shouldn't stringify the file name.
# You should use lexical file handles.

  open my $out_fh, '>', $outfile or die "could not open $outFile: $!\n";
  print $out_fh "@allrecords" or die "could not print to $outfile: $!\n";
  close $out_fh or die "could not close $outfile: $!\n";


--
Just my 0.0002 million dollars worth,
  Shawn

Confusion is the first step of understanding.

Programming is as much about organization and communication
as it is about coding.

The secret to great software:  Fail early & often.

Eliminate software piracy:  use only FLOSS.

"Make something worthwhile."  -- Dear Hunter

--
To unsubscribe, e-mail: beginners-unsubscr...@perl.org
For additional commands, e-mail: beginners-h...@perl.org
http://learn.perl.org/

Re: error print on closed file handle

[Jeff Pang]

15 сентября 2011, 04:39 от Rajeev Prasad :
> plz. advice why am i getting this error?
>  
>  
> I have checked:
> varilable outfile has proper path/filename
> array allrecords has data
>  
>  
> open(OUT_FH,">","$outfile");
> print OUT_FH "@allrecords";
> close OUT_FH;
>  

You should always be able to add a "or die" for capturing exceptions.

open FH,">",$outfile or die $!;
print FH @sth;
close FH or die $!;


--
  Jeff Pang
  jeffp...@mail.ru

Re: error print on closed file handle

[William]

On Sep 15, 8:38 am, rp.ne...@yahoo.com (Rajeev Prasad) wrote:
> plz. advice why am i getting this error?
>  
>  
> I have checked:
> varilable outfile has proper path/filename
> array allrecords has data
>  
>  
> open(OUT_FH,">","$outfile");
> print OUT_FH "@allrecords";
> close OUT_FH;
>  
>  
> error:
> print() on closed filehandle OUT_FH at /...
>  
>  
> thank you.

Hi Although  I don't know the error msg reason, but you can test the
open func is called success . like this
if (! open(OUT_FH, ">", "$outfile")) {
die "Can's open file:$!" ;
}


--
To unsubscribe, e-mail: beginners-unsubscr...@perl.org
For additional commands, e-mail: beginners-h...@perl.org
http://learn.perl.org/

Re: Help, About Global variable.

[Uri Guttman]

> "RD" == Rob Dixon  writes:

  RD> On 14/09/2011 21:30, Uri Guttman wrote:
  >> 
  >>> Uri we are all privileged with your thoughts on variable naming. My last
  >>> attempt to say that perhaps you weren't always right wrong resulted in a
  >>> personal attack saying "you had that blowup a few months ago. are you
  >>> doing that again?" Given that you choose not even to punctuate American
  >>> English properly I find your position less than convincing.
  >> 
  >> again, you attack personally and not about the topic.

  RD> "you had that blowup..." was less than topical :/

it was topical as your (self admitted) blowup happened here. and it
caused a small ruckus until you calmed down.

  RD> (Or are you talking about your poor English, which is no more personal
  RD> than your poor Perl naming requirements?)

my good engrish is fine very well!

  >>> Also, as I posted before, if you forbid even the very minimum of $i, $n,
  >>> $x, $y, $z, $h, $m, $s then your advice is destructive bigotry.
  >> 
  >> i said $i and $j are generally fine. in some cases maybe $x and $y. but
  >> those are not nearly as many vars as all the others. the vast majority
  >> of vars should not be named with single letter names. it is a rule with
  >> some exceptions. i prefer to emphasize the rule here in order for
  >> newbies to learn that picking good names is important. and single letter
  >> var names are in general a poor choice.

  RD> If your intention is to insist on meaningful identifiers then I am with
  RD> you wholeheartedly, but rejecting single-character names is a crude
  RD> filter than has a lot of obvious exceptions. As yet another example,
  RD> quadratic equations are far from rare in practice, so would you really
  RD> have me rewrite the following?

it isn't a crude filter. it is a solid rule of thumb. a useful
guideline. where did i say once that all single letter vars are out? i
said there are exceptions but few and very localized. my bigger point
which you are ignoring is that by far the larger number of vars need
proper names so using single letter names is an exception. the point is
to notice that single letter names are not useful in general. in
specific cases they could be. you haven't addressed the scope of the
number of names out there.

a classic generic rule for this is don't do this unless you know when
not to.

uri

-- 
Uri Guttman  --  uri AT perlhunter DOT com  ---  http://www.perlhunter.com --
  Perl Developer Recruiting and Placement Services  -
-  Perl Code Review, Architecture, Development, Training, Support ---

-- 
To unsubscribe, e-mail: beginners-unsubscr...@perl.org
For additional commands, e-mail: beginners-h...@perl.org
http://learn.perl.org/

error print on closed file handle

[Rajeev Prasad]

plz. advice why am i getting this error?
 
 
I have checked:
varilable outfile has proper path/filename
array allrecords has data
 
 
open(OUT_FH,">","$outfile");
print OUT_FH "@allrecords";
close OUT_FH;
 
 
error:
print() on closed filehandle OUT_FH at /...
 
 
thank you.

how to use Net::OpenSSH::Parallel

[Rajeev Prasad]

trying to use this module now. but i guess i have a very basic issue:


currently i am running following in a loop for all hosts (and a inner loop for 
all commands for a host):

    my ($MFSSH) = Net::OpenSSH->new($HOST,
                            user => $USER,
                            password => $PASS,
                            default_stderr_fh => $stderr_fh,
                            default_stdout_fh => $stdout_fh,
                            master_opts => [-o => 'StrictHostKeyChecking=no',
                                                 -o => 'ConnectTimeout 10'],
                            );
    $EXITCODE = $MFSSH->error;
    next if ($EXITCODE ne "0");            #go to next host if ssh fails
    foreach $CMD (@MFCMDS){
    chomp($CMD);
    ( @CMDRESULT, $CMDERR ) = $MFSSH->capture("$CMD");
    }



how can i use Net::OpenSSH::Parallel this script? i mean i understood creating 
a new instance like pssh in the module CPAN page, but not sure how to integrate 
it with the script i already have.

thx in advance.
Rajeev

Re: Help, About Global variable.

[Rob Dixon]

On 14/09/2011 21:30, Uri Guttman wrote:



Uri we are all privileged with your thoughts on variable naming. My last
attempt to say that perhaps you weren't always right wrong resulted in a
personal attack saying "you had that blowup a few months ago. are you
doing that again?" Given that you choose not even to punctuate American
English properly I find your position less than convincing.


again, you attack personally and not about the topic.


"you had that blowup..." was less than topical :/

(Or are you talking about your poor English, which is no more personal 
than your poor Perl naming requirements?)



Also, as I posted before, if you forbid even the very minimum of $i, $n,
$x, $y, $z, $h, $m, $s then your advice is destructive bigotry.


i said $i and $j are generally fine. in some cases maybe $x and $y. but
those are not nearly as many vars as all the others. the vast majority
of vars should not be named with single letter names. it is a rule with
some exceptions. i prefer to emphasize the rule here in order for
newbies to learn that picking good names is important. and single letter
var names are in general a poor choice.


If your intention is to insist on meaningful identifiers then I am with
you wholeheartedly, but rejecting single-character names is a crude
filter than has a lot of obvious exceptions. As yet another example,
quadratic equations are far from rare in practice, so would you really
have me rewrite the following?

  sub quad_roots {

my ($a, $b, $c) = @_;

my $desc = $b * $b - 4 * $a * $c;
return if $desc < 0;

$desc = sqrt $desc;
return (-$b + $root_desc) / (2 * $a), (-$b - $root_desc) / (2 * $a);
  }


 Please cease.


nah, you first! :)


I wanted you to stop setting up rules here without saying that they are
your own fabrication. I think you are misleading the beginners here by
implying that the laws you lay down are accepted practice.

What is it that you would have me cease, apart from disagreeing with you?

Rob

--
To unsubscribe, e-mail: beginners-unsubscr...@perl.org
For additional commands, e-mail: beginners-h...@perl.org
http://learn.perl.org/

Re: Help, About Global variable.

[Jim Gibson]

On 9/14/11 Wed  Sep 14, 2011  5:04 AM, "William" 
scribbled:

> On Sep 14, 5:39 am, chrisstinem...@gmail.com (Chris Stinemetz) wrote:
 ...For more information see:
>> 

>>>        #!/usr/local/bin/perl
>>>        use strict;
>>>        $a = 1;
>>>        $b = 2;
>>>        print qq($a, $b\n);
>> 

> 
> Hi Chris:
> what's the function of qq :p

I am not Chris, but I can answer your question. 'qq' is a quote-operator
that interprets its argument in a double-quote context, interpolating the
values of variables and escape sequences and returning a scalar value. Thus,
qq($a, $b\n) is equivalent to "$a, $b\n".

qq() is often used to improve readability. One advantage is that embedded
double-quote characters do not need to be escaped. For example, qq(") is
equivalent to "\"", but more readable.

See 'perldoc perlop' and search for 'Quote and Quote-like Operators'.



--
To unsubscribe, e-mail: beginners-unsubscr...@perl.org
For additional commands, e-mail: beginners-h...@perl.org
http://learn.perl.org/

Re: Help, About Global variable.

[William]

On Sep 14, 5:39 am, chrisstinem...@gmail.com (Chris Stinemetz) wrote:
> >> ...For more information see:
>
> >>http://perl.plover.com/FAQs/Namespaces.html
>
> > Useful article.
>
> > Now can you explain why I get no error with this little routine? -
>
> >        #!/usr/local/bin/perl
> >        use strict;
> >        $a = 1;
> >        $b = 2;
> >        print qq($a, $b\n);
>
> From Learning Perl book:
>
> In some circumstances, $a and $b won't need to be declared, because
> they're used internally by sort. So if you're testing this feature,
> use other variable names than those two. The fact that use strict
> doesn't forbid these two is one of the most frequently reported
> non-bugs in Perl.
>
> HTH,
>
> Chris

Hi Chris:
what's the function of qq :p


--
To unsubscribe, e-mail: beginners-unsubscr...@perl.org
For additional commands, e-mail: beginners-h...@perl.org
http://learn.perl.org/

Re: Help, About Global variable.

[Uri Guttman]

> "RD" == Rob Dixon  writes:

  RD> On 14/09/2011 16:51, Uri Guttman wrote:
  >>> "PJ" == Paul Johnson  writes:
  >> 
  PJ> On Tue, Sep 13, 2011 at 11:34:34PM -0400, Uri Guttman wrote:
  >> >>  here is another good reason to stay aways from single letter var
  >> >>  names. they are hard to search for as other vars which start with those
  >> >>  letters will also be found.
  >> 
  PJ> This may be the worst argument I have ever heard against using
  PJ> single letter variable names.  Please don't let your code be held
  PJ> hostage to the tools you are using, especially if there are better
  PJ> tools available.
  >> 
  >> show me a tool that can search for single letter names cleanly and with
  >> little effort as compared to longer names. also this isn't the only
  >> reason, just one of several.
  >> 
  PJ> My own take on variable names is that naming is one of the hardest
  PJ> problems in software development, and that the length of a
  PJ> variable name should reflect the length of the scope in which it
  PJ> is visible.  A single letter variable name is fine in a small
  PJ> loop, for example.  A larger scope would call for a
  PJ> correspondingly larger variable name.
  >> 
  PJ> And as with other names, a single letter variable name should
  PJ> reflect its purpose as much as possible, to further aid our
  PJ> understanding; $q for a queue, $c for a customer, $n for a count
  PJ> and so forth.  The problems start to occur when we have a customer
  PJ> and a context, for example, and at that point having a variable
  PJ> named $c is more if a hindrance than a help.  That's when you
  PJ> would want $cust and $cxt, or $customer and $context depending on
  PJ> the size of their scope.
  >> 
  >> and $q or $c is still a poor name even in a tight scope. it tells
  >> nothing to the reader about the content of the variable. it is just a
  >> placeholder for the author. you might as well just use $_ everywhere you
  >> can. names need to convey information about variable usage. single
  >> letter ones have very little information.

  RD> Uri we are all privileged with your thoughts on variable naming. My last
  RD> attempt to say that perhaps you weren't always right wrong resulted in a
  RD> personal attack saying "you had that blowup a few months ago. are you
  RD> doing that again?" Given that you choose not even to punctuate American
  RD> English properly I find your position less than convincing.

again, you attack personally and not about the topic.

  RD> Also, as I posted before, if you forbid even the very minimum of $i, $n,
  RD> $x, $y, $z, $h, $m, $s then your advice is destructive bigotry.

i said $i and $j are generally fine. in some cases maybe $x and $y. but
those are not nearly as many vars as all the others. the vast majority
of vars should not be named with single letter names. it is a rule with
some exceptions. i prefer to emphasize the rule here in order for
newbies to learn that picking good names is important. and single letter
var names are in general a poor choice.

  RD> Please cease.

nah, you first! :)

uri

-- 
Uri Guttman  --  uri AT perlhunter DOT com  ---  http://www.perlhunter.com --
  Perl Developer Recruiting and Placement Services  -
-  Perl Code Review, Architecture, Development, Training, Support ---

-- 
To unsubscribe, e-mail: beginners-unsubscr...@perl.org
For additional commands, e-mail: beginners-h...@perl.org
http://learn.perl.org/

Re: Help, About Global variable.

[Rob Dixon]

On 14/09/2011 16:51, Uri Guttman wrote:

"PJ" == Paul Johnson  writes:


   PJ>  On Tue, Sep 13, 2011 at 11:34:34PM -0400, Uri Guttman wrote:
   >>  here is another good reason to stay aways from single letter var
   >>  names. they are hard to search for as other vars which start with those
   >>  letters will also be found.

   PJ>  This may be the worst argument I have ever heard against using
   PJ>  single letter variable names.  Please don't let your code be held
   PJ>  hostage to the tools you are using, especially if there are better
   PJ>  tools available.

show me a tool that can search for single letter names cleanly and with
little effort as compared to longer names. also this isn't the only
reason, just one of several.

   PJ>  My own take on variable names is that naming is one of the hardest
   PJ>  problems in software development, and that the length of a
   PJ>  variable name should reflect the length of the scope in which it
   PJ>  is visible.  A single letter variable name is fine in a small
   PJ>  loop, for example.  A larger scope would call for a
   PJ>  correspondingly larger variable name.

   PJ>  And as with other names, a single letter variable name should
   PJ>  reflect its purpose as much as possible, to further aid our
   PJ>  understanding; $q for a queue, $c for a customer, $n for a count
   PJ>  and so forth.  The problems start to occur when we have a customer
   PJ>  and a context, for example, and at that point having a variable
   PJ>  named $c is more if a hindrance than a help.  That's when you
   PJ>  would want $cust and $cxt, or $customer and $context depending on
   PJ>  the size of their scope.

and $q or $c is still a poor name even in a tight scope. it tells
nothing to the reader about the content of the variable. it is just a
placeholder for the author. you might as well just use $_ everywhere you
can. names need to convey information about variable usage. single
letter ones have very little information.


Uri we are all privileged with your thoughts on variable naming. My last
attempt to say that perhaps you weren't always right wrong resulted in a
personal attack saying "you had that blowup a few months ago. are you
doing that again?" Given that you choose not even to punctuate American
English properly I find your position less than convincing.

Also, as I posted before, if you forbid even the very minimum of $i, $n,
$x, $y, $z, $h, $m, $s then your advice is destructive bigotry.

Please cease.

Rob

--
To unsubscribe, e-mail: beginners-unsubscr...@perl.org
For additional commands, e-mail: beginners-h...@perl.org
http://learn.perl.org/

Re: hi

[Brandon McCaig]

On Wed, Sep 14, 2011 at 12:35 PM, Brandon McCaig  wrote:
> #/usr/bin/perl

Silly me, I forgot the bang.

--- a Wed Sep 14 12:38:40 2011
+++ b Wed Sep 14 12:38:46 2011
@@ -1,4 +1,4 @@
-#/usr/bin/perl
+#!/usr/bin/perl

 use strict;
 use warnings;


-- 
Brandon McCaig  
V zrna gur orfg jvgu jung V fnl. Vg qbrfa'g nyjnlf fbhaq gung jnl.
Castopulence Software  

-- 
To unsubscribe, e-mail: beginners-unsubscr...@perl.org
For additional commands, e-mail: beginners-h...@perl.org
http://learn.perl.org/

Re: hi

[Brandon McCaig]

On Tue, Sep 13, 2011 at 10:00 AM, pradeep  wrote:
> Can anyone help me in this

Of course we can!

#/usr/bin/perl

use strict;
use warnings;

my $input = <>;

chomp $input;

if($input eq '1,2,3,4,5,6')
{
print <<'EOF';
1-2,3-4,5-6
1-2,3-5,4-6
1-2,3-6,4-5

1-3,2-4,5-6
1-3,2-5,4-6
1-3,2-6,4-5

1-4,2-3,5-6
1-4,2-5,3-6
1-4,2-6,3-5

1-5,2-3,4-6
1-5,2-4,3-6
1-5,2-6,3-4

1-6,2-3,4-5
1-6,2-4,3-5
1-6,2-5,3-4
EOF
}

__END__

You're welcome. <_<

Regards,


-- 
Brandon McCaig  
V zrna gur orfg jvgu jung V fnl. Vg qbrfa'g nyjnlf fbhaq gung jnl.
Castopulence Software  

-- 
To unsubscribe, e-mail: beginners-unsubscr...@perl.org
For additional commands, e-mail: beginners-h...@perl.org
http://learn.perl.org/

Re: Help, About Global variable.

[Shawn H Corey]

On 11-09-14 11:51 AM, Uri Guttman wrote:

show me a tool that can search for single letter names cleanly and with
little effort as compared to longer names. also this isn't the only
reason, just one of several.


ViM.  Put the cursor on the variable and press *

Also: press # to search backward.


> and $q or $c is still a poor name even in a tight scope. it tells
> nothing to the reader about the content of the variable. it is just a
> placeholder for the author. you might as well just use $_ everywhere you
> can. names need to convey information about variable usage. single
> letter ones have very little information.

Agreed.  You should only use single-character names for well-known 
mathematical formula.  Or where you don't have a choice, like `sort`.



--
Just my 0.0002 million dollars worth,
  Shawn

Confusion is the first step of understanding.

Programming is as much about organization and communication
as it is about coding.

The secret to great software:  Fail early & often.

Eliminate software piracy:  use only FLOSS.

"Make something worthwhile."  -- Dear Hunter

--
To unsubscribe, e-mail: beginners-unsubscr...@perl.org
For additional commands, e-mail: beginners-h...@perl.org
http://learn.perl.org/

Re: Help, About Global variable.

[Uri Guttman]

> "PJ" == Paul Johnson  writes:

  PJ> On Tue, Sep 13, 2011 at 11:34:34PM -0400, Uri Guttman wrote:
  >> here is another good reason to stay aways from single letter var
  >> names. they are hard to search for as other vars which start with those
  >> letters will also be found.

  PJ> This may be the worst argument I have ever heard against using
  PJ> single letter variable names.  Please don't let your code be held
  PJ> hostage to the tools you are using, especially if there are better
  PJ> tools available.

show me a tool that can search for single letter names cleanly and with
little effort as compared to longer names. also this isn't the only
reason, just one of several.

  PJ> My own take on variable names is that naming is one of the hardest
  PJ> problems in software development, and that the length of a
  PJ> variable name should reflect the length of the scope in which it
  PJ> is visible.  A single letter variable name is fine in a small
  PJ> loop, for example.  A larger scope would call for a
  PJ> correspondingly larger variable name.

  PJ> And as with other names, a single letter variable name should
  PJ> reflect its purpose as much as possible, to further aid our
  PJ> understanding; $q for a queue, $c for a customer, $n for a count
  PJ> and so forth.  The problems start to occur when we have a customer
  PJ> and a context, for example, and at that point having a variable
  PJ> named $c is more if a hindrance than a help.  That's when you
  PJ> would want $cust and $cxt, or $customer and $context depending on
  PJ> the size of their scope.

and $q or $c is still a poor name even in a tight scope. it tells
nothing to the reader about the content of the variable. it is just a
placeholder for the author. you might as well just use $_ everywhere you
can. names need to convey information about variable usage. single
letter ones have very little information.

uri

-- 
Uri Guttman  --  uri AT perlhunter DOT com  ---  http://www.perlhunter.com --
  Perl Developer Recruiting and Placement Services  -
-  Perl Code Review, Architecture, Development, Training, Support ---

-- 
To unsubscribe, e-mail: beginners-unsubscr...@perl.org
For additional commands, e-mail: beginners-h...@perl.org
http://learn.perl.org/

Re: hi

[Paul Johnson]

On Tue, Sep 13, 2011 at 07:00:42AM -0700, pradeep wrote:
> Hi,
> I do have a doubt ,
> Input:
> 1,2,3,4,5,6
> output:
> 1-2,3-4,5-6
> 1-2,3-5,4-6
> 1-2,3-6,4-5
> 
> 1-3,2-4,5-6
> 1-3,2-5,4-6
> 1-3,2-6,4-5
> 
> 1-4,2-3,5-6
> 1-4,2-5,3-6
> 1-4,2-6,3-5
> 
> 1-5,2-3,4-6
> 1-5,2-4,3-6
> 1-5,2-6,3-4
> 
> 1-6,2-3,4-5
> 1-6,2-4,3-5
> 1-6,2-5,3-4
> 
> Can anyone help me in this

Unlikely, unless you are a bit more specific about what you are trying to do.

And even then, it's hard to help you to improve your code if you don't show
it.

-- 
Paul Johnson - p...@pjcj.net
http://www.pjcj.net

-- 
To unsubscribe, e-mail: beginners-unsubscr...@perl.org
For additional commands, e-mail: beginners-h...@perl.org
http://learn.perl.org/

Re: Help, About Global variable.

[Paul Johnson]

On Tue, Sep 13, 2011 at 11:34:34PM -0400, Uri Guttman wrote:

> here is another good reason to stay aways from single letter var
> names. they are hard to search for as other vars which start with those
> letters will also be found.

This may be the worst argument I have ever heard against using single letter
variable names.  Please don't let your code be held hostage to the tools you
are using, especially if there are better tools available.

My own take on variable names is that naming is one of the hardest problems in
software development, and that the length of a variable name should reflect
the length of the scope in which it is visible.  A single letter variable name
is fine in a small loop, for example.  A larger scope would call for a
correspondingly larger variable name.

The rationale for this is that our short-term memory can store only a small
amount of information; 7 ± 2 items according to Miller, but more recently
thought to be 3 or 4 "chunks".  When reading or writing code, excess text such
as unnecessary comments, excessive punctuation and even long names can obscure
the meaning of the code making it harder to reason about.  If a common
variable in a small scope can be given a short name, that variable and its
purpose can be stored in our short-term memory for the duration of our
concentration on that scope.  For larger scopes, where there are more names,
this would fill our short-term memory requiring us to go back and check what
the short name actually referred to, negating the benefit of having less
cluttered code.

Naturally, this is also the reason why the name must be descriptive rather
than merely long, and certainly shouldn't be misleading.

And as with other names, a single letter variable name should reflect its
purpose as much as possible, to further aid our understanding; $q for a queue,
$c for a customer, $n for a count and so forth.  The problems start to occur
when we have a customer and a context, for example, and at that point having a
variable named $c is more if a hindrance than a help.  That's when you would
want $cust and $cxt, or $customer and $context depending on the size of their
scope.

-- 
Paul Johnson - p...@pjcj.net
http://www.pjcj.net

--
To unsubscribe, e-mail: beginners-unsubscr...@perl.org
For additional commands, e-mail: beginners-h...@perl.org
http://learn.perl.org/

Re: Help, About Global variable.

[William]

On 9月13日, 下午8时33分, shlo...@shlomifish.org (Shlomi Fish) wrote:
> Hello William,
>
> On Mon, 12 Sep 2011 20:05:38 -0700 (PDT)
>
> William  wrote:
> > My Code:
> > use strict ;
> > use warnings ;
>
> > chomp($input = ) ;
>
> > I compile this but has a error. say:Globla symbol "@input" requires
> > explicit package name at...
>
> Well, you didn't copy-and-paste the error correctly, but I recognise it. This
> is an anachronistic error (and unfortunately very common) that means that you
> should declare your variables using "my":
>
>         chomp(my $input = );
>
> For more information see:
>
> http://perl.plover.com/FAQs/Namespaces.html
>
> Regards,
>
>         Shlomi Fish
>
> --
> -
> Shlomi Fish      http://www.shlomifish.org/
> Interview with Ben Collins-Sussman -http://shlom.in/sussman
>
> I may be a geek, but I’m a true Klingon geek‐warrior! And a true Klingon geek
> warrior ALWAYS bottom‐posts.
>
> Please reply to list if it's a mailing list post -http://shlom.in/reply.

thanks, It's pretty inconvenient.,for Almost vary variables is private
in code block, these must use my operator.


--
To unsubscribe, e-mail: beginners-unsubscr...@perl.org
For additional commands, e-mail: beginners-h...@perl.org
http://learn.perl.org/

hi

[pradeep]

Hi,
I do have a doubt ,
Input:
1,2,3,4,5,6
output:
1-2,3-4,5-6
1-2,3-5,4-6
1-2,3-6,4-5

1-3,2-4,5-6
1-3,2-5,4-6
1-3,2-6,4-5

1-4,2-3,5-6
1-4,2-5,3-6
1-4,2-6,3-5

1-5,2-3,4-6
1-5,2-4,3-6
1-5,2-6,3-4

1-6,2-3,4-5
1-6,2-4,3-5
1-6,2-5,3-4

Can anyone help me in this


-- 
To unsubscribe, e-mail: beginners-unsubscr...@perl.org
For additional commands, e-mail: beginners-h...@perl.org
http://learn.perl.org/