Re: an effective script for grabbing and putting images from or to awebsite

Discussion in 'Perl Misc' started by Martijn Lievaart, Jun 13, 2012.

  1. On Tue, 12 Jun 2012 17:52:43 -0600, Cal Dershowitz wrote:

    > On 06/12/2012 05:05 PM, Ben Morrow wrote:


    >> You should be aware that, although many sites put conventional
    >> extensions on their URLs, there is no particular reason why they
    >> should.
    >> Unless you know the sites you are using do (and will continue to do
    >> so),
    >> you should rather look at the Content-Type header returned and map that
    >> to an appropriate extension. You can do the mapping with a simple hash,
    >> or with the MIME::Types module, and you will need to switch from
    >> LWP::Simple to the full LWP::UserAgent to get hold of the Content-Type
    >> response header.

    >
    > ok. So if I'm writing a perl script to grab an image, I do not make
    > decisions about it based first on the extension, but what the html says
    > about the image, right?


    Nitpick, what (the) HTTP (Content-Type header) says about the image.

    M4
    Martijn Lievaart, Jun 13, 2012
    #1
    1. Advertising

  2. Re: an effective script for grabbing and putting images from or toa website

    On 2012-06-13 10:46, Ben Morrow <> wrote:
    > Quoth Martijn Lievaart <>:
    >> On Tue, 12 Jun 2012 17:52:43 -0600, Cal Dershowitz wrote:
    >> > ok. So if I'm writing a perl script to grab an image, I do not make
    >> > decisions about it based first on the extension, but what the html says
    >> > about the image, right?

    >>
    >> Nitpick, what (the) HTTP (Content-Type header) says about the image.

    >
    > This is more than a nitpick, it's actually quite important. The header
    > which tells you what type of file the image is is not available until
    > *after* you've downloaded it. This means that if you want to save it in
    > a file with an appropriate extension, you need to put it in a temporary
    > file first and then rename it.


    No. The header is sent before the body, so the natural way to save a
    file downloaded via HTTP is:

    1) send request
    2) read response header (now we know the content-type)
    3) create/open file
    4) read body and write to file.

    Even if you can't for some reason do anything between reading the header
    and body, we are talking about images here which are small compared to
    RAM, so you can just:

    1) send request
    2) read entire response into memory
    3) create/open file
    4) save body to file

    The important (and sometimes annoying) part isn't about saving the
    resource. It's that you have to actually send a request! In general,
    HTML doesn't tell you whether the target of a link is an HTML or PDF
    document, a JPEG image or a ZIP archive. So even if you know that you
    are only interested in specific content-types, you still have to request
    all the resources and throw those away which you don't want (you can
    trade-off number of requests vs. band-width by using HEAD requests).

    hp


    --
    _ | Peter J. Holzer | Deprecating human carelessness and
    |_|_) | Sysadmin WSR | ignorance has no successful track record.
    | | | |
    __/ | http://www.hjp.at/ | -- Bill Code on
    Peter J. Holzer, Jun 13, 2012
    #2
    1. Advertising

  3. On Wed, 13 Jun 2012 14:45:11 +0100, Ben Morrow wrote:

    > This provides the additional advantage of following the proper
    > write-close-rename idiom for making a file available atomically
    > (probably not important in this case, but it never does any harm).


    Maybe not important in this case, but a good habit to get into.

    M4
    Martijn Lievaart, Jun 15, 2012
    #3
  4. Martijn Lievaart

    Jim Gibson Guest

    Re: an effective script for grabbing and putting images from or to a website

    In article <>, Cal
    Dershowitz <> wrote:

    > On 06/15/2012 03:56 PM, Martijn Lievaart wrote:
    > > On Wed, 13 Jun 2012 14:45:11 +0100, Ben Morrow wrote:
    > >
    > >> This provides the additional advantage of following the proper
    > >> write-close-rename idiom for making a file available atomically
    > >> (probably not important in this case, but it never does any harm).

    > >
    > > Maybe not important in this case, but a good habit to get into.

    >
    > There's a second part of the script that I can't quite seem to get
    > wrangled. I'll excerpt as opposed to making a full listing:
    >
    >
    > my @files = <$path*>;
    >
    > my $big_int = 1;
    > for my $name (@files) {
    > print "name is $name\n";
    > $name =~ m/.*\.(w+)/;


    You need \w instead of w.

    The '.*' would be unnecessary if you anchored the pattern, or if only
    one period ever occurred in your file names, and might be faster:

    $name =~ m/\.(\w+)$/;

    > my $ext = $1;
    > print "ext is $ext\n";
    >
    > }
    >


    --
    Jim Gibson
    Jim Gibson, Jun 16, 2012
    #4
  5. Re: an effective script for grabbing and putting images from or to a website

    Ben Morrow <> writes:
    > Quoth Jim Gibson <>:
    >> In article <>, Cal
    >> Dershowitz <> wrote:
    >>
    >> > my @files = <$path*>;
    >> >
    >> > my $big_int = 1;
    >> > for my $name (@files) {
    >> > print "name is $name\n";
    >> > $name =~ m/.*\.(w+)/;

    >>
    >> You need \w instead of w.

    >
    > ...and, you *also* need to check the match succeeded before you look at
    > $1:
    >
    > $name =~ m/.*\.(\w+)/ or die "'$name' has no extension";
    >
    > otherwise you run the risk of picking up $1 from some entirely other
    > pattern match. The $N variables are slightly strangely scoped, so this
    > is a little less likely than it might be, but it can and does happen and
    > causes *very* strange bugs when it does.


    [...]

    > As a general rule it's easier to avoid the $N variables where possible,
    > and instead use the return value of the match:


    What's so difficult with providing information instead of
    scaremongering?

    According to perlre(1),

    The numbered match variables ($1, $2, $3, etc.)

    [...]

    are all dynamically scoped until the end of the
    enclosing block or until the next successful match,

    Practically, this means the simple way to use $1 etc correctly is to
    avoid using them except if the match supposed to set them was
    successful, in this case (assuming that $ext is a hitherto untouched
    my variable)

    $name =~ m/.*\.(\w+)/ and $ext = $1;

    In more complicated cases,

    if (<some re match>) {
    # $1 etc valid here
    }

    or

    <some re match> && do {
    # also here
    };

    can be used.
    Rainer Weikusat, Jun 16, 2012
    #5
  6. Re: an effective script for grabbing and putting images from or to a website

    Rainer Weikusat <> writes:

    [...]

    > According to perlre(1),
    >
    > The numbered match variables ($1, $2, $3, etc.)
    >
    > [...]
    >
    > are all dynamically scoped until the end of the
    > enclosing block or until the next successful match,


    This text could do with an additional explanation: The way 'scoped' is
    used here doesn't really make sense. What this means is that $1,
    .... are always local (like local) to the enclosing block and that
    their values always correspond with whatever was or wasn't captured by
    the last successful match inside this block. Example demonstrating
    most of this:

    ----------------
    $a = 'Hallo';

    {
    $a =~ /(H)/;

    {
    $a =~ /(l)(l)/;
    print "$1, $2\n";

    $a =~ /(x)/;
    print "$1, $2\n";

    $a =~ /(a)/;
    print "$1, $2\n";
    }

    print "$1, $2\n";
    }

    print "$1, $2\n";
    Rainer Weikusat, Jun 16, 2012
    #6
  7. Re: an effective script for grabbing and putting images from or to a website

    Ben Morrow <> writes:
    > Quoth Rainer Weikusat <>:
    >> Ben Morrow <> writes:
    >> >
    >> > ...and, you *also* need to check the match succeeded before you look at
    >> > $1:
    >> >
    >> > $name =~ m/.*\.(\w+)/ or die "'$name' has no extension";
    >> >
    >> > otherwise you run the risk of picking up $1 from some entirely other
    >> > pattern match. The $N variables are slightly strangely scoped, so this
    >> > is a little less likely than it might be, but it can and does happen and
    >> > causes *very* strange bugs when it does.

    >>
    >> > As a general rule it's easier to avoid the $N variables where possible,
    >> > and instead use the return value of the match:

    >>
    >> What's so difficult with providing information instead of
    >> scaremongering?

    >
    > I did. I showed the OP how to use $N correctly, and also provided an
    > alternative I (at least) find easier to use. Where is the
    > scaremongering?


    You didn't write anything regarding how the $n actually behave, just
    asserted they would be 'strangely scoped' and that this could case
    'very strange bugs' in rarely occurring situations. That's about as
    sacry as it can get and nothing except scary.

    [...]

    >> Practically, this means the simple way to use $1 etc correctly is to
    >> avoid using them except if the match supposed to set them was
    >> successful,

    >
    > ...as I said...


    You didn't. You wrote that it would be necessary to 'check the
    success of the match', suggested to use die for tha,t and that -
    subject to the nameless but surely grave dangers - this feature
    shouldn't be used at all.

    >> in this case (assuming that $ext is a hitherto untouched
    >> my variable)
    >>
    >> $name =~ m/.*\.(\w+)/ and $ext = $1;

    >
    > Ugly and crude. Assigning the return value of the match is much
    > cleaner.


    Chances are that our aesthetic preferences also differ in other
    respects. In this case, however, a nice side effect of this construct
    is that nothing is assigned if there wasn't anything to assign. And it
    isn't necessary to hack around the fact that the match only returns
    the intended value in list context. Actually, I would write this as

    $name =~ /.*\.(\w+)/ and $ext = 1;

    but I purposely kept the m. If someone's preferred style of writing is
    different from mine, I can live with that without seeing a need to
    bash him into 'my idea of it'.

    >> In more complicated cases,
    >>
    >> if (<some re match>) {
    >> # $1 etc valid here
    >> }

    >
    > That is a useful construction sometimes, but it's usually clearer for
    > exceptional flow control ('match failed') to be the branch which diverts
    > from the normal flow.


    A failed match may well be not 'exceptional' at all. This will usually
    be the case for parsing something were multiple kinds of 'input
    trings' need to be recognized and analyzed.

    [...]

    >> <some re match> && do {
    >> # also here
    >> };

    >
    > God, that's ugly.


    Is this supposed to be some prayer for divine punishment of those
    dirty heathens who don't dress like we do, whose accent differs from
    our accent, whose haircut differs from ours, whose skin color is
    somehow different, who come from different villages and who are
    generally foreign scum, easily recognizable by their outlandish and
    filthy habits?
    Rainer Weikusat, Jun 16, 2012
    #7
  8. Regular Expression (WAS: an effective script for grabbing and putting images from or to a website)

    Cal Dershowitz <> wrote:
    > my ($ext) = $name =~ /([^.]*)$/;
    >
    >Can (anyone) talk me through why this captures an extension? The carat
    >anchors the regex at the beginning.


    No because see below!

    > $ at the end. parens return the
    >match. The asterisk is to quantify what's in brackets, but what's going
    >on with the brackets?


    The square brackets define a character class, and the leading carat
    negates this class. In other words this class captures anything that is
    not a literal dot. Together with the asterisk and the dollar anchor this
    becomes: as many characters from the end of the string until the first
    dot appears (from the end). Which pretty much describes what some people
    call a file name extension.

    jue
    Jürgen Exner, Jun 17, 2012
    #8
  9. Re: an effective script for grabbing and putting images from or to a website

    Ben Morrow <> writes:
    > Quoth Rainer Weikusat <>:
    >> Ben Morrow <> writes:
    >> > Quoth Rainer Weikusat <>:
    >> >> Ben Morrow <> writes:
    >> >> >
    >> >> > ...and, you *also* need to check the match succeeded before you look at
    >> >> > $1:
    >> >> >
    >> >> > $name =~ m/.*\.(\w+)/ or die "'$name' has no extension";
    >> >> >
    >> >> > otherwise you run the risk of picking up $1 from some entirely other
    >> >> > pattern match. The $N variables are slightly strangely scoped, so this
    >> >> > is a little less likely than it might be, but it can and does happen and
    >> >> > causes *very* strange bugs when it does.

    > <snip>
    >>
    >> You didn't write anything regarding how the $n actually behave, just
    >> asserted they would be 'strangely scoped' and that this could case
    >> 'very strange bugs' in rarely occurring situations. That's about as
    >> sacry as it can get and nothing except scary.

    >
    > You appear to be extremely easily scared. BOO!


    Writing about 'strange scoping' which may cause or prevent 'very
    strange bugs' makes the matter appear by far more serious and arcane
    than it actually is. That's why I referred to it as
    'scaremongering'. I didn't write that my assessment of the situation
    would be similar to your assesment and especially not that it was
    based on your text.

    [...]

    >> >> Practically, this means the simple way to use $1 etc correctly is to
    >> >> avoid using them except if the match supposed to set them was
    >> >> successful,
    >> >
    >> > ...as I said...

    >>
    >> You didn't. You wrote that it would be necessary to 'check the
    >> success of the match', suggested to use die for tha,t

    >
    > No, I suggested to use 'or' for that. The 'die' was the means of
    > diverting control away from the use of $1 if the match failed; I was
    > careful to mention that in this situation it may not be the most
    > appropriate way of doing so.


    This is a completely pointless attempt at confusing the issue by
    playing with words and absuing semantic ambiguities inherent in the
    way humans use language. It, however, enables me to ask a rethoric
    question:

    Assuming that

    $name =~ /deepfried (whole) elephant roll/ or die('Salatschrecke!')

    is 'sensible language use', according to your opinion, how come that
    the almost identical

    $name =~ /deepfried (whole) elephant roll/ and $quantity = $1;

    is 'crude and ugly'?

    >> and that - subject to the nameless but surely grave dangers - this
    >> featureshouldn't be used at all.

    >
    > The dangers were named


    Indeed. Their names were 'strange scopes' and 'very strange bugs'.
    But I'm tired of this weasel-wording exercise.

    [...]

    > <snip vaguely offensive nonsense>


    You could have snipped the 'vaguely offensive nonsense' from your
    original text and in this case, you wouldn't have provoked a reply which
    pointed out that you're condemning something without any reasons given
    because it was different from what you're accustomed to.

    In this case, I was actually thinking of something like

    test -n "$parameter" && {
    # do something with it
    Rainer Weikusat, Jun 17, 2012
    #9
  10. Re: Regular Expression

    Cal Dershowitz <> wrote:
    >On 06/16/2012 10:26 PM, Jürgen Exner wrote:
    >> Cal Dershowitz<> wrote:
    >>> my ($ext) = $name =~ /([^.]*)$/;

    >
    >> The square brackets define a character class, and the leading carat
    >> negates this class. In other words this class captures anything that is
    >> not a literal dot. Together with the asterisk and the dollar anchor this
    >> becomes: as many characters from the end of the string until the first
    >> dot appears (from the end). Which pretty much describes what some people
    >> call a file name extension.

    >
    >That one was super hard, with the carat not meaning what it usually does
    >and the . as well.


    Context matters!

    > Good reading here:


    Much better reading here:

    perldoc perlre

    >Ok, but why isn't the negated part returned along with the rest of what
    >is inside the parenthesis?


    But it is. Everything that is not a dot is captured.

    jue
    Jürgen Exner, Jun 18, 2012
    #10
  11. Regular expression (WAS: an effective script for grabbing and putting images from or to a website)

    Cal Dershowitz <> wrote:

    >... but I still don't understand why deleted material is not also
    >returned in this idiom:
    >
    > my ($ext) = $name =~ /([^.]*)$/;


    But there is no "deleted material" to begin with.

    A regular expression matches text. What text does this one match? From
    the end of the string forward anything that is not a dot. And that match
    is captured by the paranthesis and thus copied to $ext.

    There is nothing deleted at all. Just print $name and you will notice
    that it didn't change one bit.

    jue
    Jürgen Exner, Jun 18, 2012
    #11
  12. Re: Regular Expression

    Cal Dershowitz <> wrote:
    >On 06/16/2012 10:26 PM, Jürgen Exner wrote:
    >> Cal Dershowitz<> wrote:
    >>> my ($ext) = $name =~ /([^.]*)$/;

    >
    >That one was super hard, with the carat not meaning what it usually does


    Actually coming to think of it, no. Or rather sort of.
    The special meaning you seem to be thinking of as anchor at the
    beginning of the string happens only if the carat is the very first
    character in the RE. Otherwise it is a normal character with no special
    meaning except as first character in a character class (I hope I got
    that right from memory).

    >and the . as well. Good reading here:


    Most characters loose their special meaning in a character class

    jue
    Jürgen Exner, Jun 18, 2012
    #12
  13. Re: Regular Expression

    Cal Dershowitz <> wrote:
    >It's too hard for me, jue. At the risk of sounding glib about valuable
    >information, if I really don't get the ? character in regex'es,


    Well, that is yet another totally different can of worms. And again it
    has different meaing depending upon where it is used.

    jue
    Jürgen Exner, Jun 18, 2012
    #13
  14. Re: Regular Expression

    On 2012-06-18 04:41, Jürgen Exner <> wrote:
    > Cal Dershowitz <> wrote:
    >>On 06/16/2012 10:26 PM, Jürgen Exner wrote:
    >>> Cal Dershowitz<> wrote:
    >>>> my ($ext) = $name =~ /([^.]*)$/;

    >>
    >>That one was super hard, with the carat not meaning what it usually does

    >
    > Actually coming to think of it, no. Or rather sort of.
    > The special meaning you seem to be thinking of as anchor at the
    > beginning of the string happens only if the carat is the very first
    > character in the RE. Otherwise it is a normal character with no special
    > meaning except as first character in a character class (I hope I got
    > that right from memory).


    Nope. The ^ has this meaning independently of its position in the RE. Of
    course, if it isn't the first character it can only match if you use the
    /m modifier.

    #!/usr/bin/perl
    use warnings;
    use strict;
    use re 'debug';


    my $s = "aaa^bbb";

    if ($s =~ /a^b/) {
    print "<$&>\n";
    } else {
    print "no match\n";
    }
    __END__

    Compiling REx "a^b"
    Final program:
    1: EXACT <a> (3)
    3: BOL (4)
    4: EXACT <b> (6)
    6: END (0)
    anchored "ab" at 0 (checking anchored) minlen 2
    Guessing start of match in sv for REx "a^b" against "aaa^bbb"
    Did not find anchored substr "ab"...
    Match rejected by optimizer
    no match
    Freeing REx: "a^b"


    >>and the . as well. Good reading here:

    >
    > Most characters loose their special meaning in a character class


    Yes.

    hp


    --
    _ | Peter J. Holzer | Deprecating human carelessness and
    |_|_) | Sysadmin WSR | ignorance has no successful track record.
    | | | |
    __/ | http://www.hjp.at/ | -- Bill Code on
    Peter J. Holzer, Jun 18, 2012
    #14
  15. Re: Regular expression

    Cal Dershowitz <> wrote:
    >On 06/17/2012 10:35 PM, Jürgen Exner wrote:
    >> Cal Dershowitz<> wrote:
    >>
    >>> ... but I still don't understand why deleted material is not also
    >>> returned in this idiom:
    >>>
    >>> my ($ext) = $name =~ /([^.]*)$/;


    >Do I understand correctly that this is a "greedy" comparison?


    If you mean greedy match, then yes, the '*' operator is greedy by
    nature.

    jue
    Jürgen Exner, Jun 18, 2012
    #15
  16. Martijn Lievaart

    Jim Gibson Guest

    Re: an effective script for grabbing and putting images from or to a website

    In article <>, Cal
    Dershowitz <> wrote:


    >
    > my ($ext) = $name =~ /([^.]*)$/;
    >
    > Can (anyone) talk me through why this captures an extension? The carat
    > anchors the regex at the beginning. $ at the end. parens return the
    > match. The asterisk is to quantify what's in brackets, but what's going
    > on with the brackets?


    Brackets define a "character class", i.e., a set of characters, any one
    of which may match a character in the source string ($name).

    Character classes have their own syntax. Periods are not special and
    only match periods. The ^ character at the beginning means "invert the
    class," so [^.] will match any character /except/ a period, and
    m/([^.]*)$/ will capture any and all characters at the end of the
    string up to but not including the last period in the string. If the
    string is a file name, then that is the extension.

    If there is no period, the entire string will be captured. If there are
    one or more periods, everything to the right of the last period will be
    captured.

    See 'perldoc perlrecharclass' for details.

    --
    Jim Gibson
    Jim Gibson, Jun 18, 2012
    #16
  17. RegEx III (WAS: an effective script for grabbing and putting images from or to a website)

    Cal Dershowitz <> wrote:
    >One thing I didn't appreciate in such character
    >classes was that the order was being preserved, so you rely on it not
    >coming back "gpj."


    You are thinking about REs the wrong way. It is not the class or the RE
    that is "coming back". REs match (part of) a string. And the capture
    always contains that part of the original string that was matched, no
    matter how or which RE matched it.
    Therefore your mental model of "the character class is returning
    something" is very misleading and you should dump it asap.

    jue
    Jürgen Exner, Jun 20, 2012
    #17
  18. Martijn Lievaart

    Jim Gibson Guest

    Re: an effective script for grabbing and putting images from or to a website

    In article <>, Cal
    Dershowitz <> wrote:

    > On 06/19/2012 12:29 PM, Ben Morrow wrote:
    > >
    > > Quoth Cal Dershowitz<>:

    >


    > >
    > > I suspect that you don't want the inner for loop at all; that is, you
    > > want
    > >
    > > for my $name (@files) {
    > > my ($ext) = $name =~ /([^.]*)$/;
    > >
    > > my @matching = grep /\.$ext$/, @list;
    > > @matching = grep /image_\d+/, @matching;
    > > @matching = sort @matching;
    > >
    > > my $winner = pop @matching;
    > > }

    >
    > What is the precise roll of the second dollar sign above in the first
    > grep call?


    It anchors the match to the end of the string.


    > [snip]
    > >
    > > @matching = map /image_(\d+)/, @matching;
    > >
    > > This will leave @matching containing just a list of numbers, so then you
    > > can say
    > >
    > > my $newnum = $winner + 1;
    > > my $newfile = "image_$newnum.$ext";
    > >
    > > to build a new filename.

    >
    > This was all good till I hit 11. See below.


    [snip]

    > [Lots of output: I'll try to leave enough so that people can see my
    > problem when I hit ten in this script]


    [snip]

    > name is image_10.png


    I notice that this file name does not include a path ... (see below)

    > ext is png
    > matching is 2 3 4 5 6 7 8 9 10
    > newfile is image_10.png
    > # commenting on output HERE
    > Cannot open Local file image_10.png: No such file or directory
    > at upload14.pl line 59
    > put failed No such file or directory


    There is no file image_10.png in the current directory. What is your
    default directory when you execute the script?


    > $ cat upload14.pl
    > #!/usr/bin/perl -w
    > use strict;
    > use 5.010;
    > use Net::FTP;
    > my $domain = '';
    > my $username = '';
    > my $password = '';
    > my $ftp = Net::FTP->new( $domain, Debug => 1, Passive => 1 )
    > or die "Can't connect: $@\n";
    > $ftp->login( $username, $password ) or die "Couldn't login\n";
    > $ftp->binary();
    >
    > # get files from remote root that end in html:
    > my @remote_files = $ftp->ls();
    > # print "remote files are: @remote_files\n";
    > my @matching = map /lh_(\d+)\.html/, @remote_files;
    > print "matching is @matching\n";
    > push( @matching, 1 );
    > @matching = sort @matching;


    By default, sort will do an alphabetical sort, so '11' will come before
    '2'. This is likely the cause of your algorithm breaking down at 11.
    Try this:

    @matching = sort { $a <=> $b } @matching;

    which will do a numerical sort.

    > my $winner = pop @matching;
    > my $newnum1 = $winner + 1;
    > my $html_file = "lh_$newnum1.html";
    > print "html file is $html_file\n";
    >
    > # create file for html stubouts
    > open FH, ">$html_file";


    Obligatory advice:

    1. You should use lexical variables instead of globals for file handles.
    2. You should use the three-argument version of open.
    3. You should always check the return value of system calls.

    open( my $fh, '>', $html_file ) or
    die("Can't open $html_file for writing: $!");

    > print FH "<html>\n";
    > print FH "<head>\n";
    > print FH "<title>Lutherhaven Renovation</title>\n";
    > print FH "</head>\n";
    > print FH "<body bgcolor=white>\n";
    > print FH "<h1>My First Heading</h1>\n";
    > # more of this will be populated when I work the kinks out.
    > close FH;
    > $ftp->put($html_file) or die "put failed $@\n";
    >
    > # get files from Desktop/images/
    > my $path = '/home/dan/Desktop/upload_luther/';


    .... (continued from above) but this path contains a directory path.

    > my @files = <$path*>;
    >
    > # get ls from remote image directory
    > $ftp->cwd('/images/') or die "cwd failed $@\n";
    > my @list = $ftp->ls();
    >
    > # main control
    > for my $name (@files) {
    > print "name is $name\n";


    Why doesn't this file name contain a path?

    > my ($ext) = $name =~ /([^.]*)$/;
    > print "ext is $ext\n";
    >
    > @matching = map /image_(\d+)\.$ext$/, @list;
    > print "matching is @matching\n";
    > push( @matching, 1 );
    > @matching = sort @matching;


    You also need a numerical sort here.

    > $winner = pop @matching;
    > my $newnum = $winner + 1;
    > my $new_file2 = "image_$newnum.$ext";
    > print "newfile is $new_file2\n";
    > $ftp->put( $name, $new_file2 ) or die "put failed $!\n";
    > push( @list, $new_file2 );
    >
    > }


    --
    Jim Gibson
    Jim Gibson, Jun 20, 2012
    #18
    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. Saurabh
    Replies:
    6
    Views:
    4,486
    Chris Smith
    May 30, 2004
  2. chandan
    Replies:
    2
    Views:
    325
    chandan
    Jan 15, 2008
  3. Replies:
    2
    Views:
    340
  4. chandan
    Replies:
    2
    Views:
    108
  5. Alan Curry
    Replies:
    0
    Views:
    487
    Alan Curry
    Jun 17, 2012
Loading...

Share This Page