Hi Connie,

> On Sat, Mar 23, 2002 at 05:30:25AM +0800, Connie Chan wrote:
> > 1. When I open a text file with *lines, however, I just want to read the
> > first line, would this be a good idea ? open (FILE, "textfile.txt");
> > $firstline = <FILE>; close (FILE); would this process run till EOF, or
> > terminated after read $firstline ?


        Short, oversimplified answer:

        - In scalar context, <FILE> will read everything up to the next
newline.
        - In array context, <FILE> will read all the entire file and
return a list.  First first element in the list will be the first line in
the file, the second list element will be the second line, and so on.


        Answer-that-is-probably-more-complete-than-you-need:

        When I said that it would read "up to the next newline", that was
a fib.  In actuality it will read everything up to and including the next
input record separator.  The input records separtor (IRS), is stored in a
variable called $/ (or $IRS, or $INPUT_RECORD_SEPARATOR, if you are using
the English module), and by default it is newline ("\n" on Unix, which
is automatically translated into "\r\n" on Win32).


> > 2. I am using Win32 system , would you tell when is \n apprear and when is
> > \r\n apprear ? What about this when dealing with binary files ?

        Perl is a helpful language, it tries to DWYM (Do What You Mean)
whenever possible.  So, this line of code:
                print "\n";
        will print a newline on any platform...on Unix, it will print a
single LF (Linefeed, ASCII character 10).  On Mac, it will print a CR
(Carriage Return, ASCII code 13).  On Win32, it will print a CR followed
by a LF.

        As to what about binary files...

        If you are writing out a binary file, first open it, then, call
'binmode(FILE)', and then just write to it normally.  The conversion of \n
to \r\n will not happen at this point--which is what you want.

        If you are reading a binary file, you probably want the "read()"
function (perldoc -f read for details).  \n conversions are not done


> > 4. Is that reading binary data faster then reading text file ?

        Your question is a little vague, but I think the answer is "no".
If you read 100 bytes from a file, it shouldn't make any difference
whether that file in binary or text.  The limiting factor is the speed of
the disk, not anything about your OS or about perl.


> > 6. Is that any syntax for local call about  'use' and 'require', so as
> > something like 'not require', 'not use' expressions ?

        I think what you're asking here--correct me if I'm wrong--is
whether or not 'use' and 'require' can be turned off within a certain
scope.

        Short answer:  you cannot turn off 'require', but you can turn off
'use', as long as what you were using was a pragma.  You do this by saying
                no strict;
        or whatever the pragma name is that you want to turn off.  The
pragma remains off until the end of the current lexical scope.



        Long answer:
        First, let's talk about what these constructs do.

        'require' does one of two things:

        1) "require 5.005"    mandates that the interpreter be at least
version 5.005, or it should stop right here.

        2) "require Foo::Bar"   tells the interpreter to go read and eval
the contents of the file Foo/Bar.pm, which are to be found somewhere on
one of the paths listed in @INC.


        Clearly, you can't 'no require' something.  Once you have done a
"require 5.005", your interpreter either measures up (and keeps running)
or it doesn't (and it exits with an error message).  Alternatively, once
you have read in a file, there is no (quick/easy) way to get rid of it.


        'use', on the other hand, does the following.

        1) "use 5.005"    means exactly the same as the "require" version.
Again, there is no way to turn this off after the fact.

        2) "use Foo::Bar"    the same as require (mostly *).  Again,
cannot be turned off after the fact.

        3) "use strict"      activates a pragma, which controls how
the Perl interpreter does things.  For example, "strict" makes it a fatal
error to use symbolic references, to use variables without declaring them,
and to call subroutines without prefacing them with '&' or suffixing them
with ().  You can turn off a pragma as described above.  It works like
this:

        use strict 'vars';   # using an undeclared variable causes error

        $foo = 7;  # this would be an error

        {
                no strict 'vars';
                $bar = 8;  # this would NOT be an error
                some_func();
        }

        $baz = 9;  # this would be an error

        sub some_func {
                $jaz = 9;  # this would be an error
        }



        Note that the 'no {pragma}' only works in the lexical scope, not
the dynamic scope--that means that 'strict' is turned off when you are
dealing with $bar, but that that "turned-off" state does not propogate
down into some_func().


> > 7. Would you give me some short examples for //e, and //g ? I am confused
> > for their usuage.

        I'm not sure if you are asking how these switches apply to
matching, or to substitution.  They are more commonly applied to
substitution, so I will address that.

        The /g switch just means "do it to all instances that you can
find, instead of stopping after the first one":

        ------------------------------
        $foo = "foo foo foo";
        $foo =~ s/foo/bar/;
        print "$foo\n";

        This prints:   bar foo foo
        ------------------------------

        ------------------------------
        $foo = "foo foo foo";
        $foo =~ s/foo/bar/g;
        print "$foo\n";

        This prints:   bar bar bar
        ------------------------------

        The /e switch just means "instead of treating the replacement as a
literal string (which is the norm), treat it as a piece of Perl code and
use the results of that code for the replacement string".

        ------------------------------
        $foo = "Perl is adjective.";
        $bar = "fun";
        $foo =~ s/adjective/$bar/;
        print "$foo\n";

        This prints:   Perl is $bar.
        ------------------------------

        ------------------------------
        $foo = "Perl is adjective.";
        $bar = "fun";
        $foo =~ s/adjective/$bar/e;
        print "$foo\n";

        This prints:   Perl is fun.
        ------------------------------

        Note that you can have multiple /e switches; each one represents
an extra level of evaluation.  So, for example:

        ------------------------------
        sub func { return 'nifty!'; }

        $foo = "Perl is adjective";
        $bar = "func()";
        $foo =~ s/adjective/$bar/ee;
        print "$foo\n";

        This prints:   Perl is nifty!
        ------------------------------


> > 8. Any modules can help to check connecting threats for a certain page ?

        I'm afraid I don't understand this question.  Are you asking
how to tell if other pages are linking to your page?


> > or if I run $alive = `ping $ip` a good idea ?

        If you mean 'is this secure', then it depends (as a previous
poster implied), on a lot of other factors that you haven't specified.

        If you mean, will it work...that depends on what you want it to
do.  Your ping program will attempt to connect to $ip.  Whatever your ping
program outputs will end up in $alive; you could then part $alive to find
out if you got through successfully.


        Hope this helps!

Dave


-- 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to