Re^3: RFC: beginner level script improvement (various comments)

[georgecarlin]

First of all thank you very much for taking the time to read through and comment on the script.

I was very unhappy with the locally disabling warnings thing to begin with but failed to come up with a better solution and the entire loop construct is required so the different device output cases are tested and responded accordingly, with respective timeouts and further actions.
Using the return value of the expect method itsself hadn't occured to me at all, which is very sad considering how obvious it should have been (always is in hindsight when someone else did the thinking for you). Thank you very much for this hint. I will change that section and remove the ugly warnings thing.

I like some of the "useless" \%{$} and a-like constructs (as long as they don't constitute mistakes) as well as captitalization of some vars because it helps me keep track of where what comes from and why, what it contains and who accesses it, purely by naming and how it is referred to. However I still haven't fixed all inconsistency mistakes in the system.

The config-hash related changes you propose make a lot more sense than what I'm doing and I'll change the respective parts. Thank you very much for the pointers.
Same goes for the tempfile part.

regarding the unpacking a sub argument part
I read the unshift and sub documentation again and I still don't understand your hint.
As far as I understand the @_ is a list that contains all arguments the sub was called with and consequently $_[x] would contain the element of that array with index x. I would understand using any of the three below because they produce the identical result in regards to $bar_ref, (while I think shift only makes sense if something might or might not be present at a specific index after 0)

foo(\%bar);

sub bar {
    my $bar_ref = $_[0]; #I know what is at index 0 and that's what I 
+want
    my ($bar_ref) = @_; #same as above but I can not process anything 
+else from the list
    my $bar_ref = shift; # same as #1 but I want to continue processin
+g @_ and am unsure about indexes and/or presence
}

But the unshift thing I don't understand at all.

[smls]

"I read the unshift and sub documentation again and I still don't understand your hint."

Ah I meant shift of course, apologies for the confusion.




As far as I understand the @_ is a list that contains all arguments the sub was called with and consequently $_[x] would contain the element of that array with index x.

Correct.




while I think shift only makes sense if something might or might not be present at a specific index after 0
...
I want to continue processing @_ and am unsure about indexes and/or presence

Not sure what you mean by that. shift removes the first value off the list, so all remaining elements of the list move one index to the left (that's why it's called "shift"):

my @array = (2, 4, 6, 8);

my $first = shift @array;
# $first is 2
# @array is (4, 6, 8)

my $second = shift @array;
# $second is 4
# @array is (6, 8)
# $array[0] is 6
# $array[1] is 8

It works exactly the same when used on @_ (which is the default when shift is called without argument).




my ($bar_ref) = @_; #same as above but I can not process anything else from the list

Not sure what you mean by that, either. Unlike shift, the assignment does not modify @_. Its effect is identical to that of:
my $bar_ref = $_[0];
It's just a more "stream-lined" way of writing it.

When both sides of an assignment are lists, Perl goes from left to right, assigning the first element of the RHS ("right-hand-side") to the first element of the LHS, then the second RHS element to the second LHS element, and so on, for as many elements as there are on the LHS:

my ($first) = (2, 4, 6, 8);
my ($first, $second) = (2, 4, 6, 8);

# an array on the LHS will "eat up" all remaining elements:
my ($first, $second, @remaining) = (2, 4, 6, 8);

# undef can be used to "skip" elements you don't want to assign
# to anything:
my (undef, undef, $third) = (2, 4, 6, 8);

[georgecarlin]

As I said, I'm a self-taught perl user and best considered beginner level =)


I tried explaining my reasoning behind how I accessed the args in subs.
I've been looking into oop because in this script there's a lot of expect usage and I want to create re-uasable and well structured subs. (currently that'snot the case)
Below is a case where I have used shift.

sub set_timeout {
    my $self = shift;

    my $to = $self->{timeout};

    if (@_){
        $self->{timeout} = shift;
        
    }

    return $to;    
}

In this case shift makes sense imo, although it could have just as well been written like this.


sub set_timeout {
    my $self = $_[0];

    my $to = $self->{timeout};

    if ($_[1]){
        $self->{timeout} = $_[1];
        
    }

    return $to;    
}

The reason I didn't use the index based assignment is that shift feels better here and in the documentation I read about oop they exclusively used shift accessing. However in a different scenario like below I don't think using shift in the if clause makes sense.


sub set_stuff {
    my $self = shift;
    
    if (@_){    
        $self->{stuff1} = shift;    #3 lines for one task
        $self->{stuff2} = shift;
        $self->{stuff3} = shift;
        ($self->{stuff1},$self->{stuff2},$self->{stuff3}) = @_; #1 lin
+e, same result regardless of stuff presence
    }

    return 1;    
}

So what I'm saying is I used shift when I felt like it without having a clue whether it's faster or better than index based assignment. =)

[smls]

Yes, you should of course use whatever you feel most comfortable with.

FYI, here are two even shorter ways to write that if clause... ;)

# using a loop:

if (@_) {
    $self->{$_} = shift for qw(stuff1 stuff2 stuff3);
}


# using a hash slice (probably the fastest alternative):

@$self{qw( stuff1 stuff2 stuff3 )} = @_ if @_;

(The @ sigil in front of the $self hashref is not a typo - see Slices for more info on that.)