"Selling" Perl (i.e. getting the boss to let me install it)
P B
I'd like to install ActivePerl on a Windows XP machine specifically to
run a particular script. The "problem" is that the admins in charge of
the PC are very cautious about what is installed and the security
implications of everything (as they should be).
I thought I recalled seeing a perlfaq specifically regarding this issue,
but several `perldoc -q' searches and a perusal of the perlfaqs posted
here were fruitless. (Besides the sort of general "How do I convince
others to use Perl?")
Can anyone provide a link or perhaps a little narrative about why Perl
is safe and secure to install (I'm talking about the Perl interpreter,
specifically the ActivePerl build here, not any scripts that may be
run).
Also, the script that I'd like to run if I do get Perl installed uses
WWW::Mechanize. Are there any links, resources, opinions, or first-hand
experiences as to the security implications of this particular module?
Thanks,
PB
--
Electricians made popcorn in the power supply
John Bokma
> Hello,
>
> I'd like to install ActivePerl on a Windows XP machine specifically to
> run a particular script. The "problem" is that the admins in charge of
> the PC are very cautious about what is installed and the security
> implications of everything (as they should be).
You have limited access rights, and Perl will run with your rights. Hence
it doesn't provide you with any magic. If your admins don't get it, they
shouldn't admin computers in the first place.
That being said, you probably can just install Perl in your own directory,
one way or another.
--
John http://johnbokma.com/ - Hacking & Hiking in Mexico
Perl help in exchange for a gift:
http://johnbokma.com/perl/help-in-exchange-for-a-gift.html
A. Sinan Unur
news:Xns9B0E6551F4...@130.133.1.4:
> P B <newspo...@gmail.com.invalid> wrote:
>
>> Hello,
>>
>> I'd like to install ActivePerl on a Windows XP machine specifically
>> to run a particular script. The "problem" is that the admins in
>> charge of the PC are very cautious about what is installed and the
>> security implications of everything (as they should be).
>
> You have limited access rights, and Perl will run with your rights.
> Hence it doesn't provide you with any magic. If your admins don't get
> it, they shouldn't admin computers in the first place.
>
> That being said, you probably can just install Perl in your own
> directory, one way or another.
Ditto.
You can also pack the script into a self-sufficient exe using pp:
http://search.cpan.org/~smueller/PAR-0.982/lib/PAR/Tutorial.pod#Perl_Packager:_pp
The executable would not need any elevated privileges other
than being able to read/write your account's %TEMP%.
Sinan
--
A. Sinan Unur <1u...@llenroc.ude.invalid>
(remove .invalid and reverse each component for email address)
comp.lang.perl.misc guidelines on the WWW:
http://www.rehabitation.com/clpmisc/
l v
You "sell" the installation of Perl by tying it to a business need,
show it's value and how Perl allows you to meet the business need.
--
Len
a v i d . e v e r s o n @hp.com Dave Everson
installing Activestate Perl requires permission you probably aren't in a
place that will let you be successful.
--
Dave E.
John Bokma
IMNSHO that's quite an over the top statement.
cartercc
All languages are simply tools, nothing more. As such, you need to
relate a job and a tool. If all you do is pound in nails, you don't
need a wrench. If you fasten bolts, you need a wrench, not a hammer.
Your manager will probably tell you that you should use the 'best'
tool for the job. 'Best' can mean many things, e.g., the tools that
you have are better than the tools that you don't have, the tools that
are cheaper are better than the more expensive tools, the tools backed
by a big company (i.e., Microsoft) are better than those not backed by
a big company (i.e., Perl), and so on. I once had the experience of a
manager giving thumbs down on a Linux server because he didn't know
it, and I couldn't argue with the logic that a tool that you know how
to use is 'better' than a tool you don't know how to use.
Perl is very good for some jobs, passable for others, and horrible for
other jobs. If Perl is the 'best' tool for a particular job, you need
to make the case. If you can't make the case, use whatever other tool
you have.
As far as I know, an ordinary user can install Perl and run Perl
scripts without the permission or intervention of the administrative
user. If you are dealing with some kind of firewall, that raises
different issues. If push comes to shove, you can always grab the
sources and compile it. I assume that your sysadmin doesn't have a
problem with C?
CC
P B
> P B <newspo...@gmail.com.invalid> wrote:
>> I'd like to install ActivePerl on a Windows XP machine...
>> [snip]
> You have limited access rights, and Perl will run with your rights.
> Hence it doesn't provide you with any magic.
That's just the answer I was looking for. Thanks, that will do it.
> If your admins don't get it, they shouldn't admin computers in the
> first place.
They aren't technically admins (only in the sense that they're in charge
of the computers and network, in fact that is one of their minor
duties.) The organization in question is not an IT shop at all, but
rather a (very) small community-based non-profit organization. They're
just erring on the side of caution. (They even require a password to
access the web via Internet Explorer on this special use workstation I
want to install Perl on.) I realize that their caution is probably born
primarily of ignorance, but at least they know enough to be cautious.
In any case, armed with your concise response, I can enlighten them and
they will assuredly indulge my desire to install Perl.
--
REST:
P: Linus Torvalds
S: Buried alive in email
-- from /usr/src/linux/MAINTAINERS
P B
> P B wrote:
>> I'd like to install ActivePerl on a Windows XP machine ...
>> [snip]
> You "sell" the installation of Perl by tying it to a business need,
> show it's value and how Perl allows you to meet the business need.
Yeah, I got that much from `perlfaq -q convince' but I have already
successfully shown these people how Perl effectively meets a business
need. They agree, but they are still reserved when it comes to
installing things they're not familiar with. It's my job (in this case)
to make them familiar with the security implications of a Perl
installation.
Regards,
PB
--
You are not dead yet. But watch for further reports.
P B
>> Look for a new job. Seriously, if you work in an environment in
>> which installing Activestate Perl requires permission you probably
>> aren't in a place that will let you be successful.
> IMNSHO that's quite an over the top statement.
Agreed. See my followup upthread. While I (sort of) agree with Dave in
principle, we're talking about people who are simply not familiar with
Perl--or, for that matter, any sort of language or runtime--at all. I've
already said it elsewhere: they're just erring on the side of caution.
As soon as I'm able to allay their doubts and fears, they'll be fine
with it.
--
It's later than you think.
Ted Zlatanov
PB> Also, the script that I'd like to run if I do get Perl installed uses
PB> WWW::Mechanize. Are there any links, resources, opinions, or first-hand
PB> experiences as to the security implications of this particular module?
I have not heard of any issues with WWW::Mechanize. It's stable,
reliable, and does only the operations you ask for (except for redirects
IIRC).
Ted
nntpman68
> Hello,
>
> I'd like to install ActivePerl on a Windows XP machine specifically to
> run a particular script. The "problem" is that the admins in charge of
> the PC are very cautious about what is installed and the security
> implications of everything (as they should be).
>
Perhaps you could try to explain following:
Perl is 'just another interpreting language on your PC' and doesn't have
any specific security implications.
If they wanted to be safe, they had to forbid the execution of any
executable / script / macro not installed by them.
The damage you can do is done by the script you write and (rather)
independent of the language you implemented it in. (exceptions: the
script's runtime environment is a sandboxed or has other special
security features)
If you don't write servers and if you don't execute / eval anything
downloaded from unknown / external net works you're rather safe.
N
Tad J McClellan
> On 2008-09-03, l v <veat...@yahoo.com> wrote:
>> P B wrote:
>>> I'd like to install ActivePerl on a Windows XP machine ...
>>> [snip]
>
>> You "sell" the installation of Perl by tying it to a business need,
>> show it's value and how Perl allows you to meet the business need.
>
> Yeah, I got that much from `perlfaq -q convince' but I have already
> successfully shown these people how Perl effectively meets a business
> need. They agree, but they are still reserved when it comes to
> installing things they're not familiar with. It's my job (in this case)
> to make them familiar with the security implications of a Perl
> installation.
The proper place for fear is regarding the programs written in
Perl, not the installation of perl.
The probability of providing a "vector" in a Perl program is,
at least, thousands of times greater than the probability of
the perl program providing a vector.
Hopefully they don't know this much, or they'd really freak out... ;-)
--
Tad McClellan
email: perl -le "print scalar reverse qq/moc.noitatibaher\100cmdat/"
Ted Zlatanov
n> If you don't write servers and if you don't execute / eval anything
n> downloaded from unknown / external net works you're rather safe.
I've often mentioned here and elsewhere that treating configurations as
code is a sure way to subvert security. Configuration should only be
logical data, not code to be executed, or else you end up with an easy
attack vector as soon as the program's configuration can be modified.
Specifically, programs should use any combination of YAML, JSON,
AppConfig, XML, and Getopt (as fits the purpose and environment). None
of those are as easy as a simple do("file.conf") but they are much more
robust.
Ted
a v i d . e v e r s o n @hp.com Dave Everson
allow me to install recognized useful tools on my system. It is certainly
management's call as to what makes it into production environments but
developers should rightly be able to manage their own environments. In some
shops you can't install VI. Those aren't serious development organizations
and I would stay away.
--
Dave Everson
John Bokma
> OK -- maybe a little. But I would not care to work in a place that
> won't allow me to install recognized useful tools on my system. It is
> certainly management's call as to what makes it into production
> environments but developers should rightly be able to manage their own
> environments.
It was not clear to me if the OP was a developer.
As a freelancer I have been working on locations a few times (in the
beginning), and there was often a policy in place for installing new
software. It was not forbidden, but you had to motivate it.
> In some shops you can't install VI. Those aren't
> serious development organizations and I would stay away.
I can't see why. Over the years I have learned to be flexible.
Sherm Pendley
> In some
> shops you can't install VI. Those aren't serious development organizations
> and I would stay away.
Some developers believe that they can't possibly write a single line
of code without their favorite editor or IDE. Those aren't serious
developers and I would stay away.
sherm--
--
My blog: http://shermspace.blogspot.com
Cocoa programming in Perl: http://camelbones.sourceforge.net
Jürgen Exner
>"Dave Everson" <d a v i d . e v e r s o n @ h p . c o m> writes:
>> In some
>> shops you can't install VI. Those aren't serious development organizations
>> and I would stay away.
>
>Some developers believe that they can't possibly write a single line
>of code without their favorite editor or IDE. Those aren't serious
>developers and I would stay away.
Well, there is certainly a big difference in ease and convenience
(important to the developer) as well as productivity (should be
important to the employer) when using something very basic like ed,
edlin, or even Notepad compared to an editor with all the bells and
whistles like syntax highlighting, automated indentation, command
completion, ...
Once you got a sophisticated editor then indeed it shouldn't matter that
much which one you are using.
jue
Willem
) "Dave Everson" <d a v i d . e v e r s o n @ h p . c o m> writes:
)> In some
)> shops you can't install VI. Those aren't serious development organizations
)> and I would stay away.
)
) Some developers believe that they can't possibly write a single line
) of code without their favorite editor or IDE. Those aren't serious
) developers and I would stay away.
Some managers believe that the opinions of a developer, on issues such as
the correlation between editor familiarity and productivity, should not be
taken seriously. Those aren't serious managers and I would stay away.
SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT
John Bokma
> Sherm Pendley wrote:
> ) "Dave Everson" <d a v i d . e v e r s o n @ h p . c o m> writes:
> )> In some
> )> shops you can't install VI. Those aren't serious development
> organizations )> and I would stay away.
> )
> ) Some developers believe that they can't possibly write a single line
> ) of code without their favorite editor or IDE. Those aren't serious
> ) developers and I would stay away.
>
> Some managers believe that the opinions of a developer, on issues such
> as the correlation between editor familiarity and productivity, should
> not be taken seriously.
Wouldn't amaze me if those managers had in many cases a point. Sorry about
that news, it's probably not what you want to hear :-D
For the record, I am a freelance developer, and have learned a long time
ago that productivity is sooner limited by that gray stuff between the
ears than anything else. Probably because I had so often to make do what
was available.
I would have no problem with coding in Notepad. Of course I would miss
some things (and probably would write some small Perl scripts to fix
that), but most of my coding is typing out stuff. Thinking happens (here)
on paper :-).
John Bokma
> "Dave Everson" <d a v i d . e v e r s o n @ h p . c o m> writes:
>
>> In some
>> shops you can't install VI. Those aren't serious development
>> organizations and I would stay away.
>
> Some developers believe that they can't possibly write a single line
> of code without their favorite editor or IDE. Those aren't serious
> developers and I would stay away.
Amen to that :-). I do most my coding in TextPad, and several years back I
suddenly had to use vim. After a day or 2 I was used to it (I had used
vi/vim in the past but not that excessive).
Same with version control. I am used to subversion now, but that's just
because I like TortoiseSVN a lot. Doesn't mean that I suddenly would be
crippled if I have to use svn on the cli. The ideas are the same.
And if I miss something, I code it; I am a programmer :-).
Willem
) Wouldn't amaze me if those managers had in many cases a point. Sorry about
) that news, it's probably not what you want to hear :-D
s/news/opinion/ :-)
) For the record, I am a freelance developer, and have learned a long time
) ago that productivity is sooner limited by that gray stuff between the
) ears than anything else. Probably because I had so often to make do what
) was available.
)
) I would have no problem with coding in Notepad. Of course I would miss
) some things (and probably would write some small Perl scripts to fix
) that), but most of my coding is typing out stuff. Thinking happens (here)
) on paper :-).
Most of my work consists of working on existing code, finding out where to
make changes, finding out how things work, and then making small changes in
several places. In such cases, certain features are invaluable.
In any case, you're talking about 'problem coding on other than favourite
editor' while I'm talking about 'being faster in favourite editor'.
So if most of your work is typing out stuff then, yes, you won't be much
faster in another editor. But if most of your work is *editing* stuff,
then I *will* be much faster, in my opinion.
Charlton Wilbur
W> Some managers believe that the opinions of a developer, on issues
W> such as the correlation between editor familiarity and
W> productivity, should not be taken seriously. Those aren't
W> serious managers and I would stay away.
Indeed. On the other hand, this is what interviews are for: they are
just as much for the potential employee to evaluate the company as for
the company to evaluate the potential customer. I've turned down jobs
because they were needlessly restrictive about work environment and
development environment, because I know what I like and I know what I
find annoying, and I don't really want to spend 8 hours a day being
annoyed because my manager thinks my comfort level with the tools I'm
using is less important than a foolish consistency on everyone's desktop.
I mean, we're working with *text files*. "Standardizing" on a single
editor, or even on a single platform, is dim. The group I work in has
people on Macs, Windows, and Linux, and I couldn't tell you what most of
the people use for editors. This is a good thing.
Charlton
--
Charlton Wilbur
cwi...@chromatico.net
John Bokma
> John Bokma wrote:
> ) Wouldn't amaze me if those managers had in many cases a point. Sorry
> about ) that news, it's probably not what you want to hear :-D
>
> s/news/opinion/ :-)
>
> ) For the record, I am a freelance developer, and have learned a long
> time ) ago that productivity is sooner limited by that gray stuff
> between the ) ears than anything else. Probably because I had so often
> to make do what ) was available.
> )
> ) I would have no problem with coding in Notepad. Of course I would
> miss ) some things (and probably would write some small Perl scripts
> to fix ) that), but most of my coding is typing out stuff. Thinking
> happens (here) ) on paper :-).
>
> Most of my work consists of working on existing code, finding out
> where to make changes, finding out how things work, and then making
> small changes in several places. In such cases, certain features are
> invaluable.
Which ones?
> In any case, you're talking about 'problem coding on other than
> favourite
> editor' while I'm talking about 'being faster in favourite editor'.
I don't think that I am faster in my favourite editor TextPad, than in,
say for example Vim (I am learning Emacs, but if I have edited a few files
in it, I don't think I am faster or slower compared to TextPad).
Of course, if I have to switch from TextPad to, say Kate, today, I have to
get used to Kate. But after some time (a week or so), IMO I *should* be as
fast as with TextPad.
> So if most of your work is typing out stuff then, yes, you won't be
> much faster in another editor. But if most of your work is *editing*
> stuff, then I *will* be much faster, in my opinion.
I don't see why yet. The time I had to use vim a lot was on a huge (650+
inhouse Perl modules) code maintainance project. I was very used to
TextPad back then, but in no time I was splitting windows in vim, and
jumping to lines with issues.
Willem
) Willem <wil...@stack.nl> wrote:
)> Most of my work consists of working on existing code, finding out
)> where to make changes, finding out how things work, and then making
)> small changes in several places. In such cases, certain features are
)> invaluable.
)
) Which ones?
Search, replace, macro recording on the fly, diffing between split
windows, and all the syntax highlighting and autoindenting and such.
Plus the simple extensibility with a scripting language, which a vi
user already knows most of, because it's basically the same as the
editing commands.
Of course, most editors have that stuff, but if you use all of it, it
takes a lot more time to learn all the relevant keyboard shortcuts to
do the things you want to do.
)> In any case, you're talking about 'problem coding on other than
)> favourite
)> editor' while I'm talking about 'being faster in favourite editor'.
)
) I don't think that I am faster in my favourite editor TextPad, than in,
) say for example Vim (I am learning Emacs, but if I have edited a few files
) in it, I don't think I am faster or slower compared to TextPad).
The big advantage vim has over most other editors is that it can be
completely controlled from thust the basic alphanumeric keys, so you don't
have to lift your hands from the main part of the keyboard to do stuff.
Then there is the advantage that all the editing commands can be used
in conjunction with all the movement commands, making possible a lot
of advanced editing shortcuts that most other editors don't have.
Downside is the steep learning curve of having to memorize all the
commands, so switching *to* vim is usually not recommended.
) Of course, if I have to switch from TextPad to, say Kate, today, I have to
) get used to Kate. But after some time (a week or so), IMO I *should* be as
) fast as with TextPad.
I'm not familiar with Kate but I assume they are both quite similar.
Vim, on the other hand, is quite different as mentioned before. Of
course, ths modern versions have mouse menus and stuff, but it's the
keyboard commands that set it apart. Not using the mouse -> BIG speedup.
)> So if most of your work is typing out stuff then, yes, you won't be
)> much faster in another editor. But if most of your work is *editing*
)> stuff, then I *will* be much faster, in my opinion.
)
) I don't see why yet. The time I had to use vim a lot was on a huge (650+
) inhouse Perl modules) code maintainance project. I was very used to
) TextPad back then, but in no time I was splitting windows in vim, and
) jumping to lines with issues.
Were you using the keyboard commands, or the menu entries ?
John Bokma
> John Bokma wrote:
[..]
> Of course, most editors have that stuff, but if you use all of it, it
> takes a lot more time to learn all the relevant keyboard shortcuts to
> do the things you want to do.
Another thing a lot of editors share is the ability to redefine the
keyboard shortcuts (Although it's something I try to avoid).
> The big advantage vim has over most other editors is that it can be
> completely controlled from thust the basic alphanumeric keys, so you
> don't have to lift your hands from the main part of the keyboard to do
> stuff.
Only thing I can think off that requires the mouse in TextPad is moving
the splitter. But I don't mind to move my hands away from the keyboard
now and then, I have no problems with the mouse, and some things I do
faster with it.
> Downside is the steep learning curve of having to memorize all the
> commands, so switching *to* vim is usually not recommended.
Heh, I can't see why.
> ) Of course, if I have to switch from TextPad to, say Kate, today, I
> have to ) get used to Kate. But after some time (a week or so), IMO I
> *should* be as ) fast as with TextPad.
>
> I'm not familiar with Kate but I assume they are both quite similar.
Nor am I (on purpose, but I've used it a few times, some time ago), and
no idea how similar they are. But that was somewhat my point :-)
> Vim, on the other hand, is quite different as mentioned before.
I can't see why, or maybe I am too used to vi/vim :-).
> Of
> course, ths modern versions have mouse menus and stuff, but it's the
> keyboard commands that set it apart. Not using the mouse -> BIG
> speedup.
To me that depends on what I am doing, and I think that I am experienced
enough with my current editor that I automatically make the right
decision between keyboard and mouse.
> ) I don't see why yet. The time I had to use vim a lot was on a huge
> (650+ ) inhouse Perl modules) code maintainance project. I was very
> used to ) TextPad back then, but in no time I was splitting windows in
> vim, and ) jumping to lines with issues.
>
> Were you using the keyboard commands, or the menu entries ?
Keyboard. I don't use the mouse much while editing in TextPad except
when it works faster (or is the only way)
Charlton Wilbur
>> In such cases, certain
>> features are invaluable.
JB> Which ones?
Incremental search. Search & replace using regular expressions. Code
narrowing or folding (depending on what your editor calls it).
Parenthesis/brace/bracket matching.
Secondarily, Emacs keybindings for keyboard navigation. I imprinted
on them over a decade ago; they're in my muscle memory now.
Willem
) Another thing a lot of editors share is the ability to redefine the
) keyboard shortcuts (Although it's something I try to avoid).
Well okay, I'll concede that. But still you have to use key combinations
(ctrl-this, alt-that, I imagine ?)
)> The big advantage vim has over most other editors is that it can be
)> completely controlled from thust the basic alphanumeric keys, so you
)> don't have to lift your hands from the main part of the keyboard to do
)> stuff.
)
) Only thing I can think off that requires the mouse in TextPad is moving
) the splitter. But I don't mind to move my hands away from the keyboard
) now and then, I have no problems with the mouse, and some things I do
) faster with it.
Yes, but you have to use the *whole* keyboard, not just the alphanumeric
bits. That makes a bit of difference.
)> Vim, on the other hand, is quite different as mentioned before.
)
) I can't see why, or maybe I am too used to vi/vim :-).
Well, there is still the use of easy macro recording, the ease of
combining almost any edit command with almost any move command, and
the ease of adding custom scripts. Of course, emacs has the first
and the last as well, and probably the second too.
Downside of emacs is escape-meta-alt-control-shift :-P
In any case, perhaps I could get to comparable speed with another editor,
but I very much doubt it would take me only a week to do so, even if I were
to spend the whole week doing nothing but familiarize myself with the
editor. I tend to use *a lot* of more powerful functionality of vim,
learned from years of working with it. Perhaps all of that is also
available in other editors (although I actually doubt all of it is) but
that is *a lot* of stuff to relearn.
Peter J. Holzer
> P B <newspo...@gmail.com.invalid> wrote:
>> I'd like to install ActivePerl on a Windows XP machine specifically to
>> run a particular script. The "problem" is that the admins in charge of
>> the PC are very cautious about what is installed and the security
>> implications of everything (as they should be).
>
> it doesn't provide you with any magic.
On the other hand, "Perl will run with your rights" also means "Perl
will run with your full rights". Whatever you can do, any perl script
you execute can do, too.
So for a security-conscious admin that boils down to: "can I trust that
user not to download and execute potentially harmful scripts?" Of course
if an admin lets a user download and run exe files, he shouldn't worry
about perl scripts - the danger is exactly the same.
hp
John Bokma
> John Bokma wrote:
> ) Another thing a lot of editors share is the ability to redefine the
> ) keyboard shortcuts (Although it's something I try to avoid).
>
> Well okay, I'll concede that. But still you have to use key
> combinations (ctrl-this, alt-that, I imagine ?)
Since most editors are mode-less, yes.
> ) Only thing I can think off that requires the mouse in TextPad is
> moving ) the splitter. But I don't mind to move my hands away from the
> keyboard ) now and then, I have no problems with the mouse, and some
> things I do ) faster with it.
>
> Yes, but you have to use the *whole* keyboard, not just the
> alphanumeric bits. That makes a bit of difference.
I've know idea. I have to press Shift now and then as well. Doesn't
bother me that much. I never needed a high typing speed when coding.
Maybe I am a slow coder. Even when writing documentation I don't type
full speed (like for example while chatting, or posting to Usenet).
> )> Vim, on the other hand, is quite different as mentioned before.
> )
> ) I can't see why, or maybe I am too used to vi/vim :-).
>
> Well, there is still the use of easy macro recording, the ease of
> combining almost any edit command with almost any move command, and
> the ease of adding custom scripts. Of course, emacs has the first
> and the last as well, and probably the second too.
> Downside of emacs is escape-meta-alt-control-shift :-P
Emacs is entirely programmable, so if you don't like that, change it. Or
use vile. From what I understand features first in vile made it back to
vi(m).
> In any case, perhaps I could get to comparable speed with another
> editor, but I very much doubt it would take me only a week to do so,
> even if I were to spend the whole week doing nothing but familiarize
> myself with the editor.
I recently changed from a Latin American keyboard back to an US one (in
our house we have like 4 or even 5 different keyboard layouts), and it
took me about a week to get used to it. The two weeks (I think I
mentioned 2) was a guess, based on what I do when working on code. Maybe
I don't use my editors to the fullest, I don't know. But what I do most
while coding is typing characters part of the code.
> I tend to use *a lot* of more powerful
> functionality of vim, learned from years of working with it. Perhaps
> all of that is also available in other editors (although I actually
> doubt all of it is) but that is *a lot* of stuff to relearn.
I am going to use Emacs full time later this month, so maybe I'll come
back on "two weeks". And later on I want to extend my knowledge of vi as
well (I probably am just going to switch to vim for a few months).