[26052] in Perl-Users-Digest
Perl-Users Digest, Issue: 8260 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Tue Jul 19 11:05:33 2005
Date: Tue, 19 Jul 2005 08:05:10 -0700 (PDT)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Tue, 19 Jul 2005 Volume: 10 Number: 8260
Today's topics:
Re: "Can't return a temporary from lvalue subroutine... <nobull@mail.com>
Re: "Can't return a temporary from lvalue subroutine... (Anno Siegel)
Re: "Can't return a temporary from lvalue subroutine... (Anno Siegel)
Re: copy contructor (Anno Siegel)
foreach with two arrays <webriderabc@gmx.de>
Help with mail2news perl script <news@amigo.co.uk>
Re: Help with mail2news perl script <noreply@gunnar.cc>
Re: How to call an internal CGI subroutine? <jwxxxxx@yahoo.com>
Unable to correct typing mistake from the console. <ChoowieWITHOUT_SPAM@free.fr>
Re: Unable to correct typing mistake from the console. <someone@example.com>
Re: Unable to correct typing mistake from the console. <ChoowieWITHOUT_SPAM@free.fr>
Re: Unable to correct typing mistake from the console. <ChoowieWITHOUT_SPAM@free.fr>
Re: using passwd in a perl script <joe@inwap.com>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Tue, 19 Jul 2005 12:36:38 +0100
From: Brian McCauley <nobull@mail.com>
Subject: Re: "Can't return a temporary from lvalue subroutine..."
Message-Id: <dbiok6$hii$1@redhat2.bham.ac.uk>
Anno Siegel wrote:
> J Krugman <jkrugman345@yahbitoo.com> wrote in comp.lang.perl.misc:
>
>>sub var : lvalue {
>> my $self = shift;
>> $self->{_var_};
>>}
>
> I, too would have expected the construction to work. I'm not sure what's
> wrong, but then lvalue subs are still (permanently?) experimental, so
> irregularities must be expected.
>
> For a workaround, instead of tying the whole hash, you can tie each
> hash value to a scalar. That works without the error. Like a good
> workaround, it has serious disadvantages.
Another work-round is not to have any persitant ties and to have the
accessor create a tied scalar on the fly. This approach can put the
validation inside the accessor method which I think aids redability.
use Tie::OneOff;
sub var : lvalue {
my $self = shift;
Tie::OneOff->lvalue({
FETCH => sub { $self->{_var_} },
STORE => sub {
my $newval = shift;
# validate $newval
$self->{_var_} = $newval;
},
});
}
>
> For one, you must either pre-tie all fields in the ->new method of
> My_Class, in which case you can't add fields dynamically. If you must
> do that, the ->var method(s) must do the tying on the fly when a new
> key is generated.
>
> Another problem is that the STORE method of a tied scalar doesn't know
> about the hash key the value is stored under. Since each tied scalar
> belongs to a fixed key, it would be possible to store the hash key in
> the tying object (the one in Tie::Scalar...). But that's extra work,
> and it means you can't use Tie::StdScalar as is, because it has no
> provisions for extra values.
>
> I suppose your motivation is that you like the idea of lvalue methods,
> but need more control over what gets stored by careless users in your
> sensitive objects. A similar problem exists with objects that expose
> (parts of) their interior though overloading a dereference operator,
> say %{}. Like lvalues, it gives you pretty syntax, but leaves your
> objects wide open. I have used tied hashes to correct this (that is,
> returned a reference to a tied hash in response to %{ $obj}, and haven't
> encountered the particular difficulty you're seeing. That may be
> an alternative approach.
>
> Anno
------------------------------
Date: 19 Jul 2005 13:00:03 GMT
From: anno4000@lublin.zrz.tu-berlin.de (Anno Siegel)
Subject: Re: "Can't return a temporary from lvalue subroutine..."
Message-Id: <dbitgj$2v3$1@mamenchi.zrz.TU-Berlin.DE>
J Krugman <jkrugman345@yahbitoo.com> wrote in comp.lang.perl.misc:
> In <dbgjls$l1e$1@mamenchi.zrz.TU-Berlin.DE>
> anno4000@lublin.zrz.tu-berlin.de (Anno Siegel) writes:
>
> >J Krugman <jkrugman345@yahbitoo.com> wrote in comp.lang.perl.misc:
>
> >> I give the relevant code below.
>
> >The code is reasonable, I would have written it similarly, except for
>
> >> sub var : lvalue {
> >> my $self = shift;
> >> $self->{_var_} = shift if @_;
>
> >This line is now redundant, or it would be if the code worked as expected.
> >You're assigning through the lvalue now. It isn't exactly wrong to have
> >it, but it distracts from the purpose of the lvalue-method.
>
> My thought was to give users the option setting through the lvalue
> *or* through the more conventional
>
> $self->var(1);
>
> ...but maybe this is not such a hot idea...
Oh, okay. I was wondering why it's there because the purpose of
the exercise was to replace that kind of assignment.
> >For a workaround, instead of tying the whole hash, you can tie each
> >hash value to a scalar.
>
> That's good to know. I was under the mistaken impression that only
> "simple" scalar variables (i.e. like $foo, as opposed to $foo{bar})
> could be tied to scalars.
>
> >For one, you must either pre-tie all fields in the ->new method of
> >My_Class, in which case you can't add fields dynamically. If you must
> >do that, the ->var method(s) must do the tying on the fly when a new
> >key is generated.
>
> You lost me there, Anno. I don't see how, in general, an lvalue
> method could do any on-the-fly tying, since all but the last
> statement of the method are ignored when it is used as an lvalue.
> (Yes, it could do it if it is being used as a non-lvalue method,
> but that imposes a strange API).
The statements of an lvalue sub aren't ignored, it's just that the
return value *must* be specified as the last statement of the code.
So you could just write
sub var : lvalue {
my $self = shift;
tie $self->{ _var_}, 'Tie::StdScalar' unless tied $self->{ _var_};
$self->[ _var_];
}
> >Another problem is that the STORE method of a tied scalar doesn't know
> >about the hash key the value is stored under. Since each tied scalar
> >belongs to a fixed key, it would be possible to store the hash key in
> >the tying object (the one in Tie::Scalar...). But that's extra work,
> >and it means you can't use Tie::StdScalar as is, because it has no
> >provisions for extra values.
>
> (A bit over my head, but that's OK: I know have a lot to learn.)
What I mean is this: Your original STORE method (for a tied hash)
sub STORE {
my ($self, $key, $value) = @_;
warn "storing value $value under key $key\n";
$self->{$key} = $value;
}
makes use of (prints out) the hash key the value is stored under.
The STORE method of a scalar doesn't have the $key parameter (what
for?), so you won't have it when you do the extra stuff the print()
stands for.
If you really need the hash key at that time, you could use an
extra field in the tie object to store the key at creation time:
tie $self->{ _var_}, 'Tie::NonStdScalar', '_var_';
would tie the variable as usual, but also squirrel away the value
"_var_" somewhere in the object. An extra method in the
Tie::NonStdScalar class, say ->key would retrieve it. Then the
STORE method could go
sub STORE {
my ($self, $value) = @_;
my $key = $self->key;
warn "storing value $value under key $key\n";
$self->{$key} = $value;
}
and function as before.
I suppose your motivation is that you like the idea of lvalue methods,
> >but need more control over what gets stored by careless users in your
> >sensitive objects.
>
> Exactly! Very clairvoyant of you.
No clairvoyance involved. I know the place, I've been there. Many
people have, look at all the footprints and litter :)
> >A similar problem exists with objects that expose
> >(parts of) their interior though overloading a dereference operator,
> >say %{}. Like lvalues, it gives you pretty syntax, but leaves your
> >objects wide open. I have used tied hashes to correct this (that is,
> >returned a reference to a tied hash in response to %{ $obj}, and haven't
> >encountered the particular difficulty you're seeing. That may be
> >an alternative approach.
>
> I'm having a hard time picturing what you describe here. It seems
> to imply that $obj somehow knows when it's being dereferenced (and
> responds accordingly by "returning" a tied hash???), which I find
> hard to understand.
You have described it correctly and succinctly.
> Is this something you do in any published code
> that I could study?
No. In the particular case, the support code went to to overgrow
the actual content of the class, and I threw it all out again.
However, there is a module on CPAN that does exactly this combination
of dereference overloading and returning tied values. Unfortunately I've
lost the reference. The module author (a well known name I have also
forgotten) has published an article on the module in either TPJ or TPR
(I forget) under a title I don't remember.
The module itself would be of little use for study, it is expressly
*not* written with readability in mind, but the article would. Maybe
someone with a better memory can help out.
Anno
--
If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers.
------------------------------
Date: 19 Jul 2005 13:17:05 GMT
From: anno4000@lublin.zrz.tu-berlin.de (Anno Siegel)
Subject: Re: "Can't return a temporary from lvalue subroutine..."
Message-Id: <dbiugh$3k6$1@mamenchi.zrz.TU-Berlin.DE>
Brian McCauley <nobull@mail.com> wrote in comp.lang.perl.misc:
> Anno Siegel wrote:
> > J Krugman <jkrugman345@yahbitoo.com> wrote in comp.lang.perl.misc:
> >
> >>sub var : lvalue {
> >> my $self = shift;
> >> $self->{_var_};
> >>}
> >
> > I, too would have expected the construction to work. I'm not sure what's
> > wrong, but then lvalue subs are still (permanently?) experimental, so
> > irregularities must be expected.
> >
> > For a workaround, instead of tying the whole hash, you can tie each
> > hash value to a scalar. That works without the error. Like a good
> > workaround, it has serious disadvantages.
>
> Another work-round is not to have any persitant ties and to have the
> accessor create a tied scalar on the fly. This approach can put the
> validation inside the accessor method which I think aids redability.
>
> use Tie::OneOff;
>
> sub var : lvalue {
> my $self = shift;
> Tie::OneOff->lvalue({
> FETCH => sub { $self->{_var_} },
> STORE => sub {
> my $newval = shift;
> # validate $newval
> $self->{_var_} = $newval;
> },
> });
> }
Ah, you're handing in the FETCH and STORE methods as run time parameters
to tie(). They could even be closured. That's crazy, and I like it.
Anno
--
If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers.
------------------------------
Date: 19 Jul 2005 14:00:23 GMT
From: anno4000@lublin.zrz.tu-berlin.de (Anno Siegel)
Subject: Re: copy contructor
Message-Id: <dbj11n$57m$1@mamenchi.zrz.TU-Berlin.DE>
Abigail <abigail@abigail.nl> wrote in comp.lang.perl.misc:
> Anno Siegel (anno4000@lublin.zrz.tu-berlin.de) wrote on MMMMCCCXXXIX
> September MCMXCIII in <URL:news:dbhc62$53b$1@mamenchi.zrz.TU-Berlin.DE>:
> :) Abigail <abigail@abigail.nl> wrote in comp.lang.perl.misc:
> :) > Anno Siegel (anno4000@lublin.zrz.tu-berlin.de) wrote on MMMMCCCXXXIX
> :) > September MCMXCIII in <URL:news:dbfv8r$88k$1@mamenchi.zrz.TU-Berlin.DE>:
> :) >
> :) > [ Snip ]
> :) >
> :) > && In my opinion, class design around accessors does solve the attribute
> :) > && problem. Whether the solution is satisfactory (generally, or for a
> :) > && specific problem) is another question.
> :) >
> :) >
> :) > Just one question: how are you storing your attributes?
> :)
> :) Any old way. The standard hash-as-a-record, its equivalent for
> :) arrays, whatever the base type has to offer. The derived class
> :) doesn't know, that's why it *has* to override all accessors.
> :) If these are few and well known, the effort is expendable. The
> :) rest of the class follows suit. You can well have an array class
> :) inherit in this way from a hash class, and other combinations.
> :)
> :) I'll give an example. In the code below, a class Parent has two
> :) fields (attributes), alpha and beta. It also has the method total
> :) which returns the sum of alpha and beta. It is implemented as
> :) an array of two elements.
> :)
> :) A class Client, implemented as the usual hash, wants to keep the role
> :) of alpha, but split the field beta into the sum of its other fields
> :) gamma and delta. It wants to inherit the ->total method from Parent,
> :) which should thus be the sum of alpha, gamma and delta.
> :)
> :) My point is that the method ->total, written to form the sum of a
> :) two-element array, now forms the sum of a three-element hash.
> :)
> :) Anno
> :)
> :) #!/usr/local/bin/perl
> :) use strict; use warnings; $| = 1;
> :)
> :) my $c = Client->new( 5, 6, 7);
> :) print "$_ -> ", $c->$_, "\n" for qw( alpha beta gamma delta total);
> :)
> :) ##########################################################################
> :)
> :) package Parent;
> :)
> :) sub new {
> :) my $class = shift;
> :) my ( $alpha, $beta) = @_;
> :) bless [ $alpha, $beta], $class;
> :) }
> :)
> :) sub alpha { $_[ 0]->[ 0] }
> :) sub beta { $_[ 0]->[ 1] }
> :)
> :) sub total { $_[ 0]->alpha + $_[ 0]->beta }
> :)
> :)
> :) package Client;
> :) BEGIN { our @ISA = 'Parent' }
> :)
> :) sub new {
> :) my $class = shift;
> :) my ( $alpha, $gamma, $delta) = @_;
> :) bless {
> :) alpha => $alpha,
> :) gamma => $gamma,
> :) delta => $delta,
> :) }, $class;
> :) }
> :)
> :) sub alpha { $_[ 0]->{ alpha} }
> :) sub gamma { $_[ 0]->{ gamma} }
> :) sub delta { $_[ 0]->{ delta} }
> :)
> :) sub beta { $_[ 0]->gamma + $_[ 0]->delta }
> :)
> :) __END__
>
>
> Well, that "works", but that kind of defeats the purpose of using OO:
> reusing code.
Well, you *can't* reuse accessors and be implementation-independent.
Rule of the game, no two ways about it.
> You will have to redefined *every* method of a parent class.
Only those methods that de-reference their object. This example
class has only one non-accessor ->total, but that's only an example.
In a real class the balance will be far more in favor of non-accessors,
especially if the class is written with this in mind.
> Take for instance the above example - since you aren't going to break
> encapsulation, you don't know how the class is implemented. It might as
> well be:
>
>
> package Parent;
>
> sub new {
> my $class = shift;
> my ( $alpha, $beta) = @_;
> bless [ $alpha, $beta, $alpha + $beta ], $class;
> }
>
> sub alpha { $_[ 0]->[ 0] }
> sub beta { $_[ 0]->[ 1] }
>
> sub total { $_[ 0]->[ 2] }
>
>
> It has the same interface, but if you now create your Client class
> as presented, calling the method 'total' results in "Not an ARRAY reference".
Same interface, but now you have made ->total is an accessor and yes,
that means it must be overridden.
> You have to redefine any method that touches an attribute directly - and
> you either have to peek inside (breaking encapsulation) to know which
> methods touch an attribute - or redefine every method.
That's why I'm preaching that accessors must be documented. An inheriting
class must know what they are and how to override them.
> But if you redefine every method, what's the point of inheritance?
That's why carelessly written classes that access their objects all over
the place are useless for inheritance. A good class defines a handful
of accessors and then never touches the object again. Then most of the
useful stuff *can* be inherited.
If the inheriting class has an object of the base class a component,
(so the is-a relation is based on a has-a relation), even accessors
can be made inheritable with a little trick the base class must provide.
I'll post a rewrite of my example a little later.
Anno
--
If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers.
------------------------------
Date: Tue, 19 Jul 2005 14:35:12 +0200
From: "Thomas P." <webriderabc@gmx.de>
Subject: foreach with two arrays
Message-Id: <dbis21$g7o$1@seebuck.freinet.de>
Hello,
I have two arrays and I want to use the foreach loop with both arrays
simultaneously, that means the loop should take one value from both arrays
at one run.
I tried something like this but it does not work :
@a=("12","14");
@b=("7","9");
foreach $value1 $value2 (@a,@b)
Regards
Thomas
------------------------------
Date: Tue, 19 Jul 2005 12:28:05 +0100
From: David Mahon <news@amigo.co.uk>
Subject: Help with mail2news perl script
Message-Id: <9djrraQFPO3CFwNH@earth.amigo.co.uk>
I'm having a bit of trouble with a mail2news perl script that I've
hacked about to try and get it to do what I want it to do. It is called
with no arguments - mail is piped directly to it.
Presently it takes the mail, checks for important headers and copies
certain headers across, followed by the message.
I am having difficulty with headers that may be split over multiple
lines (like References: headers). How can I make it include those?
Unfortunately I can't tell it to just include lines starting with
whitespace because I don't want it to include parts of other headers
split over multiple lines (like Received: headers).
A better way may have been to have a list of headers to exclude, but
that was more difficult and still resulted in the problem with headers
split over multiple lines.
Secondly, I would like to grab the IP address in the first Received
header to use as X-Trace or some such header. Any ideas?
Here is the script so far:
#!/usr/bin/perl
($program = $0) =~ s%.*/%%;
$news_poster_program = "/usr/bin/rnews";
$news_poster_options = "-r localhost";
# in case inews dumps core or something crazy
$SIG{'PIPE'} = "plumber";
sub plumber { die "$program: \"$news_poster_program\" died
prematurely!\n"; }
open (INEWS, "| $news_poster_program $news_poster_options") ||
die "$program: can't run $news_poster_program\n";
# header munging loop
while (<STDIN>) {
last if /^$/;
s/(?i)^Date/Date/;
s/(?i)^From/From/;
s/(?i)^Reply-To/Reply-To/;
s/(?i)^Subject/Subject/;
s/(?i)^Newsgroups/Newsgroups/;
s/(?i)^Message-Id/Message-ID/;
s/(?i)^References/References/;
s/(?i)^X-No-Archive/X-No-Archive/;
s/(?i)^X-Complaints-To/X-Complaints-To/;
s/(?i)^X-Trace/X-Trace/;
print INEWS
if
/^(Date|From|Reply-To|Subject|Newsgroups|Message-ID|References|X-No-Archi
ve|X-Complaints-To|X-Trace):/i;
$saw_subject |= ( $+ eq 'Subject' );
$saw_msgid |= ( $+ eq 'Message-ID' );
$saw_newsgroup |= ( $+ eq 'Newsgroups' );
$saw_date |= ( $+ eq 'Date' );
$saw_from |= ( $+ eq 'From' );
$saw_x_no_archive |= ( $+ eq 'X-No-Archive' );
}
die "$program: didn't get newsgroup from headers\n"
unless $saw_newsgroup;
die "$program: didn't get from from headers\n"
unless $saw_from;
die "$program: didn't get date from headers\n"
unless $saw_date;
($sec,$min,$hour,$mday,$mon,$year)=localtime(time);
$madeupid = "\<$year$mon$mday.$hour$min$sec.$$\@my.domain\>";
print INEWS "Subject: Untitled\n" unless $saw_subject;
printf INEWS "Message-ID: %s\n", $madeupid unless $saw_msgid;
print INEWS "X-Mail-To-News-Contact: abuse\@my.domain\n";
print INEWS "X-No-Archive: Yes\n" unless $saw_x_no_archive;
print INEWS "Organisation: mail2news\@my.domain\n";
print INEWS "Path: mail2news\n";
print INEWS "\n";
print INEWS while <STDIN>; # gobble rest of message
close INEWS;
exit ( ( $? & 0xff ) == 0 ? ( $? >> 8 ) & 0xff : 70 );
--
David Mahon
------------------------------
Date: Tue, 19 Jul 2005 15:16:08 +0200
From: Gunnar Hjalmarsson <noreply@gunnar.cc>
Subject: Re: Help with mail2news perl script
Message-Id: <3k4cosFsf4loU1@individual.net>
David Mahon wrote:
> I am having difficulty with headers that may be split over multiple
> lines (like References: headers).
<snip>
> Secondly, I would like to grab the IP address in the first Received
> header to use as X-Trace or some such header.
Search CPAN. The module Mail::Header comes to mind.
--
Gunnar Hjalmarsson
Email: http://www.gunnar.cc/cgi-bin/contact.pl
------------------------------
Date: Tue, 19 Jul 2005 08:31:31 -0400
From: James White <jwxxxxx@yahoo.com>
Subject: Re: How to call an internal CGI subroutine?
Message-Id: <pan.2005.07.19.12.31.30.874418@yahoo.com>
>
> Sure: have the action refer to the original script, have the
> script test for the existence of a save_file parameter key, and
> if it exists, call someroutine() (and otherwise do a default
> action, like presenting the form). Read perldoc CGI for some
> help on doing this.
>
Thanks, Keith. I finally made myself stop hacking around last night,
turned off the computer and relaxed on the sofa with my pile of books
and google printouts for some more careful rereading. Finally found the
info (and somewhat of an example) that if you have just a vanilla <form>
tag with no action, it will call itself. It says just about what you have
indicated. So I will have a new direction to try tonight.
I am in that part of learning a new language that I hate - where I am
below the knowledge level where even beginner books assume that
"everybody" knows, and not far enough along to be able to hack out a
non-working procedure because of total lack of a building foundation. And
where any question is bound to be really dumb:-)
Thanx again
JW
------------------------------
Date: Tue, 19 Jul 2005 12:39:24 +0200
From: "Choowie" <ChoowieWITHOUT_SPAM@free.fr>
Subject: Unable to correct typing mistake from the console.
Message-Id: <42dcd85d$0$13356$626a14ce@news.free.fr>
Hi there,
I have a Perl script which I launch from a serial port console. The scripts
asks for a bunch of questions and then modifies configuration scripts. I use
the <STDIN> functionnality to read what the user typed in.
The problem is, when in serial console, I must not do any typing mistake.
The Delete of Ctrl-H key do not operate.
What should I do to have these keys working?
Thanx for your help.
--
Choowie
------------------------------
Date: Tue, 19 Jul 2005 13:07:17 GMT
From: "John W. Krahn" <someone@example.com>
Subject: Re: Unable to correct typing mistake from the console.
Message-Id: <9W6De.164537$on1.10412@clgrps13>
Choowie wrote:
> Hi there,
>
> I have a Perl script which I launch from a serial port console. The scripts
> asks for a bunch of questions and then modifies configuration scripts. I use
> the <STDIN> functionnality to read what the user typed in.
>
> The problem is, when in serial console, I must not do any typing mistake.
> The Delete of Ctrl-H key do not operate.
>
> What should I do to have these keys working?
You need to set the erase character correctly for your terminal using stty.
man stty
John
------------------------------
Date: Tue, 19 Jul 2005 16:00:05 +0200
From: "Choowie" <ChoowieWITHOUT_SPAM@free.fr>
Subject: Re: Unable to correct typing mistake from the console.
Message-Id: <42dd0766$0$19847$626a14ce@news.free.fr>
John W. Krahn wrote:
> Choowie wrote:
>> Hi there,
>>
>> I have a Perl script which I launch from a serial port console. The
>> scripts asks for a bunch of questions and then modifies
>> configuration scripts. I use the <STDIN> functionnality to read what
>> the user typed in.
>>
>> The problem is, when in serial console, I must not do any typing
>> mistake. The Delete of Ctrl-H key do not operate.
>>
>> What should I do to have these keys working?
>
> You need to set the erase character correctly for your terminal using
> stty.
>
> man stty
IMHO, the stty is set correctly. The Delete or Ctrl-H key work perfectly in
shell. It just doesn't work anymore within the Perl script. Do you think I
would still need to investigate on stty?
--
Choowie
------------------------------
Date: Tue, 19 Jul 2005 16:08:25 +0200
From: "Choowie" <ChoowieWITHOUT_SPAM@free.fr>
Subject: Re: Unable to correct typing mistake from the console.
Message-Id: <42dd095a$0$14047$626a14ce@news.free.fr>
Choowie wrote:
> John W. Krahn wrote:
>> Choowie wrote:
>>> Hi there,
>>>
>>> I have a Perl script which I launch from a serial port console. The
>>> scripts asks for a bunch of questions and then modifies
>>> configuration scripts. I use the <STDIN> functionnality to read what
>>> the user typed in.
>>>
>>> The problem is, when in serial console, I must not do any typing
>>> mistake. The Delete of Ctrl-H key do not operate.
>>>
>>> What should I do to have these keys working?
>>
>> You need to set the erase character correctly for your terminal using
>> stty.
>>
>> man stty
>
> IMHO, the stty is set correctly. The Delete or Ctrl-H key work
> perfectly in shell. It just doesn't work anymore within the Perl
> script. Do you think I would still need to investigate on stty?
I did investigate further more. You were right
The trick is to have a "stty -F /dev/ttyS0 erase ^h"
Thanks.
--
Choowie
------------------------------
Date: Tue, 19 Jul 2005 03:37:07 -0700
From: Joe Smith <joe@inwap.com>
Subject: Re: using passwd in a perl script
Message-Id: <CKOdnV45GvpYSkHfRVn-1A@comcast.com>
yo wrote:
> solved the problem with
>
> @cryptpasswd = ("echo $password | passwd $username --stdin");
> system("@cryptpasswd");
That's not right. The last line should be without quotes:
system(@cryptpasswd);
Better yet, a simple scalar fits your needs:
$cryptpasswd = "echo $password | passwd $username --stdin";
system $cryptpasswd;
-Joe
------------------------------
Date: 6 Apr 2001 21:33:47 GMT (Last modified)
From: Perl-Users-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Digest Administrivia (Last modified: 6 Apr 01)
Message-Id: <null>
Administrivia:
#The Perl-Users Digest is a retransmission of the USENET newsgroup
#comp.lang.perl.misc. For subscription or unsubscription requests, send
#the single line:
#
# subscribe perl-users
#or:
# unsubscribe perl-users
#
#to almanac@ruby.oce.orst.edu.
NOTE: due to the current flood of worm email banging on ruby, the smtp
server on ruby has been shut off until further notice.
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
#To request back copies (available for a week or so), send your request
#to almanac@ruby.oce.orst.edu with the command "send perl-users x.y",
#where x is the volume number and y is the issue number.
#For other requests pertaining to the digest, send mail to
#perl-users-request@ruby.oce.orst.edu. Do not waste your time or mine
#sending perl questions to the -request address, I don't have time to
#answer them even if I did know the answer.
------------------------------
End of Perl-Users Digest V10 Issue 8260
***************************************
