[29294] in Perl-Users-Digest
Perl-Users Digest, Issue: 538 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Wed Jun 20 09:09:57 2007
Date: Wed, 20 Jun 2007 06:09:09 -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 Wed, 20 Jun 2007 Volume: 11 Number: 538
Today's topics:
Net::SSH::Perl -> OpenSSH on Windows Server? <blah@blahblah.co.uk>
Re: package filename mismatches ? <bugbear@trim_papermule.co.uk_trim>
Re: package filename mismatches ? <mritty@gmail.com>
Re: Passing hash to another script via commandline <blah@blahblah.co.uk>
Re: Passing hash to another script via commandline <ts@dionic.net>
Re: Passing hash to another script via commandline <noreply@gunnar.cc>
Re: Passing hash to another script via commandline <wyzelli@yahoo.com>
Re: Passing hash to another script via commandline <ts@dionic.net>
Reference syntax tim_milstead@yahoo.co.uk
Re: Reference syntax <ts@dionic.net>
Re: Reference syntax anno4000@radom.zrz.tu-berlin.de
Re: Reference syntax <purlgurl@purlgurl.net>
Re: The Modernization of Emacs <borud-news@borud.no>
Re: The Modernization of Emacs: terminology buffer and <borud-news@borud.no>
Re: The Modernization of Emacs: terminology buffer and <borud-news@borud.no>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Wed, 20 Jun 2007 12:01:11 +0100
From: "IanW" <blah@blahblah.co.uk>
Subject: Net::SSH::Perl -> OpenSSH on Windows Server?
Message-Id: <f5b1cm$kma$1$8302bc10@news.demon.co.uk>
Hi
Has anyone tried connecting from a Linux box using Net::SSH::Perl to a
Windows server running OpenSSH?
That is, I am testing using this script:
use Net::SSH::Perl;
my $host = "10.10.10.10";
my $user = "username";
my $pass = "password";
my $ssh = Net::SSH::Perl->new($host, (debug => 1));
$ssh->login($user, $pass);
my $cmd = 'dir';
my($stdout,$stderr,$exit) = $ssh->cmd($cmd);
print "stdout=$stdout \nstderr=$stderr \nexit=$exit\n";
The debug lines I get seem to indicate a successful connection (not copied
all the lines as there are alot):
timberwindows.com: channel 1: new [client-session]
timberwindows.com: Requesting channel_open for channel 1.
timberwindows.com: Entering interactive session.
timberwindows.com: Sending command: dir > c:\TW.com\zzzzzz.txt
timberwindows.com: Requesting service exec on channel 1.
timberwindows.com: channel 1: open confirm rwindow 0 rmax 32768
timberwindows.com: input_channel_request: rtype exit-status reply 0
timberwindows.com: channel 1: rcvd eof
timberwindows.com: channel 1: output open -> drain
timberwindows.com: channel 1: rcvd close
timberwindows.com: channel 1: input open -> closed
timberwindows.com: channel 1: close_read
timberwindows.com: channel 1: obuf empty
timberwindows.com: channel 1: output drain -> closed
timberwindows.com: channel 1: close_write
timberwindows.com: channel 1: send close
timberwindows.com: channel 1: full closed
stdout=
stderr=
exit=255
As one can see $stdout contains nothing.. it works fine if I Putty into the
Linux box and use the ommandline ssh utility to connect to the Windows
servers. I guess this is not really a Perl issue but maybe it's something to
do with the module? Any ideas?
Thanks
Ian
------------------------------
Date: Wed, 20 Jun 2007 12:24:15 +0100
From: bugbear <bugbear@trim_papermule.co.uk_trim>
Subject: Re: package filename mismatches ?
Message-Id: <46790e5f$0$8750$ed2619ec@ptn-nntp-reader02.plus.net>
Uri Guttman wrote:
>>>>>> "b" == bugbear <bugbear@trim_papermule.co.uk_trim> writes:
>
> b> Commonly, when I make a file Utils/Edit.pm
> b> (intended to be used via use Utils::Edit;)
> b> I have a good chance of putting
>
> i wouldn't use such generic module names as they may conflict with cpan
> names. if these are company (even your own) or project specific modules,
> it is a good idea to use a prefix name for them like MyFoo::
Agreed - my example names were purely expository.
>
> b> Now I understand that "use blah"
> b> is equivalent to:
> b> BEGIN { require Module; import Module LIST; }
>
> yep.
>
> b> Is there a way to make the import fail
> b> if the package has not supplied it,
> b> so that if I've made my usual bone head mistake,
> b> perl will tell me?
>
> not with use by itself. it will silently ignore a failure to find an
> import method. also if your module doesn't export anything (typical of
> OO and some other modules), then just the module is loaded.
>
> i see two solutions. first, learn to name and store your modules properly
> according to their package and file names. this is the proper answer.
>
> the other solution is for you to test if the module was loaded correctly
> by accessing something in it or checking the symbol tables, etc. this is
> clunky as it has to be done in the using code and each time if you really
> want this sort of checking.
>
> the rule about package names and file names is simple. there is NO
> REQUIRED RELATIONSHIP between a package name and a file (path) name of a
> module. you can have multiple package commands in one file and you can
> have multiple files with the same package namespace. only use commands
> associate the two by the calling of the import method of a module.
yeah - I understand that many things are both possible and allowed in Perl;
I just wondered wether I could use/create a "typical use" command
that checked and enforced a "common but not compulsory convention".
Thanks for your comments and help.
BugBear
------------------------------
Date: Wed, 20 Jun 2007 06:07:25 -0700
From: Paul Lalli <mritty@gmail.com>
Subject: Re: package filename mismatches ?
Message-Id: <1182344845.843756.165140@q75g2000hsh.googlegroups.com>
On Jun 19, 9:38 am, bugbear <bugbear@trim_papermule.co.uk_trim> wrote:
> I've often made the mistake of getting the
> package name "wrong" when making a module.
>
> Commonly, when I make a file Utils/Edit.pm
> (intended to be used via use Utils::Edit;)
> I have a good chance of putting
>
> package Edit;
>
> In the code.
>
> Now I understand that "use blah"
> is equivalent to:
> BEGIN { require Module; import Module LIST; }
>
> Is there a way to make the import fail
> if the package has not supplied it,
> so that if I've made my usual bone head mistake,
> perl will tell me?
I agree with Uri that the real solution is just to train yourself
better, but I think you might be able to do something with the sybmol
table, like:
sub my_use {
my $pack = shift;
require "$pack.pm";
import $pack;
warn "No $pack package found after \"use $pack\"\n"
unless defined %{"${pack}::"};
}
I'm sure that's rife with bugs and won't work in all situations, but
it might get you started at least?
Paul Lalli
------------------------------
Date: Wed, 20 Jun 2007 12:03:16 +0100
From: "IanW" <blah@blahblah.co.uk>
Subject: Re: Passing hash to another script via commandline
Message-Id: <f5b1gk$on6$1$830fa7a5@news.demon.co.uk>
"Tim Southerwood" <ts@dionic.net> wrote in message
news:4678efd1$0$645$5a6aecb4@news.aaisp.net.uk...
> IanW wrote:
>
>> Thanks also for the other responses. One thing I noticed from the
>> different replies is that there seem to be 3 ways to call another Perl
>> script - the backticks that I used, 'system', and 'do' - are there any
>> real differences between them?
>>
>> Ian
>
> I would *always* use the "system (@)" method unless I really needed the
> shell to do expansions or the convenience of capturing output via
> backticks.
I do quite often like to get the output. "do" seems to do this aswell - is
there a difference between "do" and backticks? (I suppose "do" is easier to
spot than backticks when reviewing the script!)
Thanks
Ian
------------------------------
Date: Wed, 20 Jun 2007 12:10:20 +0100
From: Tim Southerwood <ts@dionic.net>
Subject: Re: Passing hash to another script via commandline
Message-Id: <46790b1d$0$646$5a6aecb4@news.aaisp.net.uk>
IanW wrote:
>
> "Tim Southerwood" <ts@dionic.net> wrote in message
> news:4678efd1$0$645$5a6aecb4@news.aaisp.net.uk...
>> IanW wrote:
>>
>>> Thanks also for the other responses. One thing I noticed from the
>>> different replies is that there seem to be 3 ways to call another Perl
>>> script - the backticks that I used, 'system', and 'do' - are there any
>>> real differences between them?
>>>
>>> Ian
>>
>> I would *always* use the "system (@)" method unless I really needed the
>> shell to do expansions or the convenience of capturing output via
>> backticks.
>
> I do quite often like to get the output. "do" seems to do this aswell - is
> there a difference between "do" and backticks? (I suppose "do" is easier
> to spot than backticks when reviewing the script!)
>
> Thanks
> Ian
do() only works for executing lumps of perl in the same process as the
caller of do(), whereas system() spawns a subprocess and can execute any
binary that the underlying OS can.
They are quite different - though if you had been accustomed to calling a
second perl program, then do() will have worked for you, but possibly not
quite in the way that you thought.
Cheers
Tim
------------------------------
Date: Wed, 20 Jun 2007 13:32:20 +0200
From: Gunnar Hjalmarsson <noreply@gunnar.cc>
Subject: Re: Passing hash to another script via commandline
Message-Id: <5dshnhF3634tvU1@mid.individual.net>
Tim Southerwood wrote:
> IanW wrote:
>> "Tim Southerwood" wrote:
>>> IanW wrote:
>>>> Thanks also for the other responses. One thing I noticed from the
>>>> different replies is that there seem to be 3 ways to call another Perl
>>>> script - the backticks that I used, 'system', and 'do'
Also require(), use() and exec().
>>>> - are there any real differences between them?
Yes. See "perldoc perlfunc".
>>> I would *always* use the "system (@)" method unless I really needed the
>>> shell to do expansions or the convenience of capturing output via
>>> backticks.
Always system() to call another Perl script??
>> I do quite often like to get the output. "do" seems to do this aswell - is
>> there a difference between "do" and backticks? (I suppose "do" is easier
>> to spot than backticks when reviewing the script!)
>
> do() only works for executing lumps of perl in the same process as the
> caller of do(),
Which makes it fit well for the OP's problem, don't you think?
--
Gunnar Hjalmarsson
Email: http://www.gunnar.cc/cgi-bin/contact.pl
------------------------------
Date: Wed, 20 Jun 2007 12:01:21 GMT
From: "Peter Wyzl" <wyzelli@yahoo.com>
Subject: Re: Passing hash to another script via commandline
Message-Id: <lG8ei.16557$wH4.13454@news-server.bigpond.net.au>
"Tim Southerwood" <ts@dionic.net> wrote in message
news:4677fa0a$0$644$5a6aecb4@news.aaisp.net.uk...
> IanW wrote:
>
>>
>> "Jürgen Exner" <jurgenex@hotmail.com> wrote in message
>> news:XoRdi.7443$u65.1117@trndny07...
>>
>>> It might be easier to use Data::Dumper to convert the hash into a
>>> textual
>>> representation that can readily loaded into perl again
>>
>> Hi Jue
>>
>> Thanks for the reply.
>>
>> If I understand it correctly, doesn't Data::Dumper just convert the hash
>> into a string representing the hashes structure? In which case, if I
>> tried
>> to pass that via the command line, the spaces (amongst some other
>> characters like double quotes) would cause probs when the string is
>> pulled
>> into @ARGV at the receiving script?
>>
>> Eg:
>>
>> use Data::Dumper;
>> my $d = Dumper(\%data);
>> my $result = `perl z:/interface.pl $d`;
>>
>> That would result in only $ARGV[0] only containing "$VAR1". One could put
>> $d in double quotes, but if there were double quotes in one of the hash
>> values then it would presumably mess things up again.
>>
>> Regards
>> Ian
>
> I think there is a simple point being missed here.
>
> Why not use Data::Dumper to serialise the data (because that's what it
> does), print the result to STDOUT, have the called program read it in from
> STDIN to a scalar, then eval the scalar.
>
> In other words, pipe the serialised version of the hash between the two
> programs. Very much the "unix way" (TM).
>
> Another way to do it would be to use IPC::Shareable and tie the hash to a
> blob of shared memory. All that the callee program needs to know is the
> shared memory key id which is trivially passed as an argument.
>
> Probably not a lot efficiency wise as the latter method has to serialise
> the
> data anyway, but it's neat, and potentially bi-directional - ie the callee
> can modify the data and have the caller see it.
The Storable module can also serialise data and then retrieve it via the
freeze and thaw methods. Might be worth an investigation.
use Storable qw(freeze thaw);
# Serializing to memory
$serialized = freeze \%table;
%table_clone = %{ thaw($serialized) };
P
------------------------------
Date: Wed, 20 Jun 2007 13:21:19 +0100
From: Tim Southerwood <ts@dionic.net>
Subject: Re: Passing hash to another script via commandline
Message-Id: <46791bc2$0$645$5a6aecb4@news.aaisp.net.uk>
Gunnar Hjalmarsson wrote:
> Tim Southerwood wrote:
>> IanW wrote:
>>> "Tim Southerwood" wrote:
>>>> IanW wrote:
>>>>> Thanks also for the other responses. One thing I noticed from the
>>>>> different replies is that there seem to be 3 ways to call another Perl
>>>>> script - the backticks that I used, 'system', and 'do'
>
> Also require(), use() and exec().
>
>>>>> - are there any real differences between them?
>
> Yes. See "perldoc perlfunc".
>
>>>> I would *always* use the "system (@)" method unless I really needed the
>>>> shell to do expansions or the convenience of capturing output via
>>>> backticks.
>
> Always system() to call another Perl script??
Quite frankly, yes, in the general case. Without knowledge of what the
callee script does, it is natural to expect to call it as a sub process
where it cannot interfere with the caller's environment in any way.
Also, the subject of this message is "Passing hash to another script via
commandline" which implies an exec() at some point. I would suggest reading
the original post again where the example code uses backticks.
I agree that there are special cases where it is fine to do() or eval() a
script - but then the OP's problem can be handled by allowing the callee
script to access the hash directly as it is running in the same process,
providing the hash is declared "our".
>>> I do quite often like to get the output. "do" seems to do this aswell -
>>> is there a difference between "do" and backticks? (I suppose "do" is
>>> easier to spot than backticks when reviewing the script!)
>>
>> do() only works for executing lumps of perl in the same process as the
>> caller of do(),
>
> Which makes it fit well for the OP's problem, don't you think?
With respect, no.
Personally, I would not run a foreign script via a do() except in very
special cases. I know there is lexical separation of the callee from the
caller, but not everything in the caller's space is protected from the
actions of the script (package globals, filehandles, signal handlers etc).
If the script is not foreign to the caller, then I probably would have
integrated it's code into the caller (as a module or subroutine) anyway.
Perhaps the OP needs to clarify a bit more - the subject line is
inconsistent with where this discussion is going, too much is at
cross-purposes now.
Cheers
Tim
------------------------------
Date: Wed, 20 Jun 2007 03:42:59 -0700
From: tim_milstead@yahoo.co.uk
Subject: Reference syntax
Message-Id: <1182336179.240772.109290@k79g2000hse.googlegroups.com>
Is this:
my $arg_ref = \@_;
the same as this:
my ($arg_ref) = @_;
What is the correct way of reading the latter in English, pseudo code?
Thanks in advance.
Tim.
------------------------------
Date: Wed, 20 Jun 2007 11:48:36 +0100
From: Tim Southerwood <ts@dionic.net>
Subject: Re: Reference syntax
Message-Id: <46790604$0$644$5a6aecb4@news.aaisp.net.uk>
tim_milstead@yahoo.co.uk wrote:
> Is this:
>
> my $arg_ref = \@_;
>
> the same as this:
>
> my ($arg_ref) = @_;
>
> What is the correct way of reading the latter in English, pseudo code?
>
> Thanks in advance.
>
> Tim.
No, they aren't the same.
The first makes $arg_ref contain a reference to \@_, so that
$_[0] equiv $arg_ref->[0]
$_[1] equiv $arg_ref->[1]
etc.
The second statement causes $arg_ref to hold a copy of the first element of
@_ so that
$arg_ref "contains a copy of" $_[0] and could have been written:
$arg_ref = $_[0];
More generally, one might do:
($a, $b, $c, @w) = @_;
which means:
$a = $_[0];
$b = $_[1];
$c = $_[2];
@w = rest of @_
HTH
Tim
------------------------------
Date: 20 Jun 2007 10:53:03 GMT
From: anno4000@radom.zrz.tu-berlin.de
Subject: Re: Reference syntax
Message-Id: <5dsf8fF35llcvU1@mid.dfncis.de>
<tim_milstead@yahoo.co.uk> wrote in comp.lang.perl.misc:
> Is this:
>
> my $arg_ref = \@_;
>
> the same as this:
>
> my ($arg_ref) = @_;
No. The first assigns a reference to @_ to $arg_ref. The second
assigns the first element of @_ ($_[0]) to $arg_ref. Entirely
different.
You may have been thinking of
my $arg_ref;
@$arg_ref = @_;
That has superficially the same effect as your first statement, but
it creates an anonymous copy of @_ and stores *that* in $arg_ref,
not a reference to @_,
> What is the correct way of reading the latter in English, pseudo code?
Huh?
Anno
------------------------------
Date: Wed, 20 Jun 2007 03:59:19 -0700
From: Purl Gurl <purlgurl@purlgurl.net>
Subject: Re: Reference syntax
Message-Id: <29CdnYfjsfwWleTbnZ2dnUVZ_h6vnZ2d@giganews.com>
tim_milstead wrote:
> Is this:
> my $arg_ref = \@_;
> the same as this:
> my ($arg_ref) = @_;
A real Jim Dandy way of learning is to test various syntax.
#!perl
@_ = qw (Purl Gurl);
$arg_ref = \@_;
print $arg_ref;
print "\n";
$arg_ref = @_;
print $arg_ref;
print "\n";
($arg_ref) = @_;
print $arg_ref;
print "\n";
$arg_ref = "@_";
print $arg_ref;
PRINTED RESULTS:
ARRAY(0x182f07c)
2
Purl
Purl Gurl
--
Purl Gurl
--
"Then again what can you expect from a fat-assed, champagne swilling,
half-breed just off the Rez?"
- Joe Kline
------------------------------
Date: 20 Jun 2007 13:48:20 +0200
From: Bjorn Borud <borud-news@borud.no>
Subject: Re: The Modernization of Emacs
Message-Id: <m3d4zqlud7.fsf@borud.not>
[Xah Lee <xah@xahlee.org>]
|
| ----------------------------------------
| SIMPLE CHANGES
if I were to suggest improvements to Emacs, the things you mention are
probably among the last things I'd even consider. the problem with
Emacs is not really the nomenclature or the keybindings. the problem
is that it needs to do what it already does better.
My frustration with Emacs has mostly been that Emacs-Lisp is a bit too
limiting. It is too slow and the codebase is a bit messy. or at
least it was the last time I tried to do something in Emacs-Lisp a
couple of years ago. it would also be beneficial if there was a more
proper and well-organized standard library for Emacs to make
developing Emacs applications easier.
for programmers, Emacs is a pretty good editor already, but there is a
bit of a threshold for extending Emacs.
-Bjørn
------------------------------
Date: 20 Jun 2007 14:30:08 +0200
From: Bjorn Borud <borud-news@borud.no>
Subject: Re: The Modernization of Emacs: terminology buffer and keybinding
Message-Id: <m37ipylsfj.fsf@borud.not>
[Xah Lee <xah@xahlee.org>]
to be quite honest, your proposal seems to largely be based on
ignorance.
| A: The terminology ÒbufferÓ or ÒkeybindingÓ, are technical terms
| having to do with software programing. The term ÒkeybindingÓ refers to
| the association of a keystroke with a command in a technical, software
| application programing context. That is to say, a programer ÒbindÓ a
| keystroke to a command in a software application. The term ÒbufferÓ
| refers to a abstract, temporary area for storing data, in the context
| of programing or computer science.
the term "buffer" is used extensively outside the computer science
domain, so it is not a CS only term. in an editor it is actually a
quite sensible name since it abstracts things a bit. for instance a
buffer need not be associated with a file. nor does it make any
assumptions about the way it is displayed (as opposed to "window" or
"tab").
| These terms are irrelevant to the users of a software application.
they are very relevant to me, and I am very much a user of Emacs. and
again, they provide good abstractions.
| As a user of a text editor, he works with files.
learn Emacs before you criticize it. your assumption is wrong. in
emacs you work on _buffers_. buffers often do not have files
associated with them.
| The terms Òopened fileÓ or Òuntitled fileÓ are more appropriate than
| ÒbufferÓ. Since emacs is also used for many things beside reading
| files or writing to files, for example, file management, ftp/sftp,
| shell, email, irc etc., the proper term can be ÒpanelÓ, ÒwindowÓ, or
| Òwork areaÓ.
"panel" and "window" refer to UI-elements. the buffer concept does
not map 1:1 to any of these. substituting "work area" for "buffer"
doesn't seem like a better abstraction. especially not if you see it
in the context of how Emacs relates to buffer contents.
| And, the term Òkeyboard shortcutÓ refers to typing of a key-
| combination to activate a command. It is also more appropriate than
| ÒbindingÓ or ÒkeybindingÓ.
why? if anything the term "shortcut" seems to imply that there is a
primary route to executing the function in question -- which more
often than not isn't the case. "keybinding" is a more precise term.
| Although concepts like ÒbufferÓ and ÒkeybindingÓ are seemingly
| interchangeable with ÒpanelÓ or Òkeyboard shortcutÓ, but their
| contexts set them apart.
they are interchangeable only if you have no idea what you are talking
about. you obviously have not bothered to have a proper look at Emacs
and think these things through properly.
| This is why in all modern software application's user
| documentations, terms like ÒbufferÓ or ÒkeybindingÓ are not to be
| seen but Òwindows, panes, and keyboard shortcutsÓ.
most "modern" editors are built on different premises than Emacs and
many have a far simpler view of the world. extremely few of them even
come close to Emacs in defining what is in practice an operating
environment for applications. it makes sense to refer to "windows"
when in fact you are referring to windows. it doesn't make sense to
call buffers "windows" in Emacs; because they are not.
| The reason emacs uses the technical terminologies throughout is
| because when emacs started in the 1970s, there really isn't any other
| text editors or even software applications.
the abstractions you mention are sensible ones independently of when
they were concieved. just because other people came along later and
used different abstractions, doesn't mean that the ones used in Emacs
are wrong, inferior or inappropriate. if you had bothered to
understand Emacs properly, you would have found that some of the
abstractions used make a lot of sense in an editor.
| Changes in society are always resisted by old timers, but it is also a
| main element behind progress.
I've been in the computer industry long enough to have seen quite a
few cycles of re-invention. each cycle you learn something about
which inventions were good and which were bad. a common thread if you
look at the survival rate of products and ideas is that it isn't
always the best product or idea that wins.
often something new comes along to replace something old. sometimes
it is better than what you had before, but often it is not really
better, just different.
a good example is the web and the applications we implement in terms
of the web. take forums for instance. in a strict technical sense,
web-based forums are inferior to NNTP-based forums. (I am sure you can
make the comparison yourself). yet NNTP-based discussion is not
growing at the same rate as web forums. the net has chosen its
preferred technology, and it wasn't because the web-based discussion
forums were so much more technically refined that the majority chose
them.
for my uses, web forums are a huge step back from NNTP.
| This terminology issue may seem trivial, but its importance lies in
| making emacs palpable to the vast number of people who ever need to
| use a computer to write.
why? Emacs is a tool. if you don't like it: use something else. it
is that simple.
-Bj¿rn
------------------------------
Date: 20 Jun 2007 14:52:30 +0200
From: Bjorn Borud <borud-news@borud.no>
Subject: Re: The Modernization of Emacs: terminology buffer and keybinding
Message-Id: <m31wg6lre9.fsf@borud.not>
[Giorgos Keramidas <keramida@ceid.upatras.gr>]
|
| Educating the user to avoid confusion in this and other cases of made
| up, 'user-friendly' descriptions is not a good enough answer.
there are two types of "user friendly". there's "user friendly" and
then there is "beginner friendly" which is often mislabeled. the
latter is more important for applications which are to be used
casually. like utilities you only use once or twice per year -- those
need to be "beginner friendly".
for applications you are likely to use for prolonged periods of time
(like programming, video editing, music production etc), it does not
make sense to optimize for "beginner friendly". at least not at the
cost of making the application less "user friendly".
applications you spend a lot of time using are worth an investment in
learning how to use them. what creates friction in an application you
know reasonably well is when common tasks are fiddly. for instance,
while menus are often good for casual use and lower the initial
threshold for absolute beginners, depending heavily on menu navigation
becomes too fiddly if you are performing a certain task 2-3 times per
minute. it is not _user_ friendly.
Emacs is rather "user friendly", but not very "beginner friendly".
when I was first confronted with it, the sort of text editors I was
used to were Wordstar and derivatives of it. I was rather annoyed
that it didn't do what I expected, so I just used a different editor.
a few years later I bemoaned the fact that Emacs was so hard to use
during a conversation with a friend. he asked me if I had actually
made an effort to learn Emacs, which of course I hadn't. so I figured
I might as well give it a shot.
following the tutorial that comes with Emacs (and which is referred to
in the startup message) I spent a couple of hours one afternoon
learning the basics. already the next day I started using Emacs for
programming. the week after I had progressed to using it as my
newsreader (which I still do to this day) and eventually I started
reading my email in Emacs. perhaps two months after I had sat down to
learn Emacs I wrote my first Emacs extensions in Emacs Lisp. mostly
simple stuff to make common programming tasks easier.
I found Emacs to be user friendly, but in a different sense than the,
IMHO faulty definition, "beginner friendly". Emacs let me, as a user,
do more with less effort and provides a lot less friction than many
other developer tools I've used. at work I use it extensively, and we
have lots of neat extensions that really save a lot of time.
-Bjørn
------------------------------
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 V11 Issue 538
**************************************
