Re: vi horizontal split screen

On 2009-05-16, DMcCunney <plugh@xxxxxxxxx> wrote:
Tim Harig wrote:
On 2009-05-15, DMcCunney <plugh@xxxxxxxxx> wrote:
Tim Harig wrote:
On 2009-05-15, DMcCunney <plugh@xxxxxxxxx> wrote:
Tim Harig wrote:
On 2009-05-14, DMcCunney <plugh@xxxxxxxxx> wrote:
Several ksh improvements were designed to make it faster and more
efficient at processing scripts, and one way to do that was substitute
built-ins for external commands called from the script.

Modern versions of bash use this strategy as well.

The print command eliminates the need to call /bin/echo to write
something to the screen or elsewhere (and in ksh, echo is an alias to
print).

Echo is a builtin of modern bash. If you want to use the system echo, you
have to call it by path.

Ksh maintained the standard Bourne IF-THEN-ELSE, CASE, and WHILE
statements. It also provides local as well as global variables.

Local variables would be useful.

which would become incorporated into bash. It is too bad most Bash users
never really learn to use Bashes history capabilities.
Like any other software, people learn what they need to accomplish what
they are trying to do. So there may be large untouched areas because
there isn't a perceived benefit in diving into that particular pool.

This is one of those situations where something would benefit people but
few people know about it. If they did, then they would likely be using it.
It doesn't help that most Bash documentation on the web does not discuss
history expansion.

I now done quite a lot in powershell. In many ways it nearly rivals
languages like Perl or Python in its capabilities because of the .net/COM
interfaces available on Windows. The only problem with .net/COM is that
these kinds of objects must be made available by the developers of
applications. This is true for all Microsoft software which effectively
becomes a virtual toolkit; but, is not generally true of other venders.
We can hope vendors will gradually climb onto the bandwagon.

COM predates monad/powershell by a *long* time. COM originally grew out of
Microsoft's work for OLE in Windows 1x through 3x. It has been available
since win9x. .Net basically extends COM in some ways. The bottom line is
that most commercial software foundries never consider that you might want
to script around their applications.

Text applications can almost always be used for scripting whether or not
they were designed to be. Powershell is able to perform text processing as
a bottom line effort; but, there are not many text based applications
available on Windows.
I don't think Powershell was really intended for text processing. But
since it's a shell with a scripting facility, you could probably call
utilities intended for text processing from it.

Powershell was developed directly to remove the need for text based
scripting. Using the built in cmdlets, everything is essentially grouped
like a table with objects forming fields and object properties forming the
rows. It can work with XML data in the same way. Because a user might
need to work with data which doesn't come from XML or cmdlets, it does have
sufficient facilities for processing textual data.

The environment is very conformal. Most of the cmdlets use a long nameing
style with a verb-object style naming convention. There are usually
aliases for common cmd and Unix commands to make transitions easy.

Powershell/Monad's real power is its ability to manipulate .net objects.
This lets it use the entire Windows system as a library. Perl and Python
are so powerful, not always just because of their syntax, but because of
the massive libraries that are available for each. In general however,
they cannot use each other's libraries.

All .net languages are effectively equal an can run any assembly
registered to the Global Assembly Cache irregardless of the language it
was written in. .net can also marshal COM objects allowing it to make use
of programs which will act as COM servers. Powershell doesn't have any
libraries itself but it can make use of those libraries and programs that
are available on the system. It doesn't have an HTTP library; but, it can
just create an internet explorer object if it needs to download something.

Altogether, Powershell/Monad, .net, COM/DCOM, is an awesome system from top
to bottom*. It is extremely powerful for programmers on the Windows
platform. It also should be great for scripters. It gives developers an
easy way to add scriptability to their applications; but, they have make
that consideration for the sytem to be effective. That is where the system
breaks down. Most Windows developers never give thought that their users
might want more power over their applications.

<tangent>
* I love much of Microsoft's software even while I tend to hate their
operating systems. I often wonder if the company might not have actually
benefitted from being split in three ways as was proposed during the
original anti-trust ruling. It would have let the Office/middleware
division focus on its great products without having to worry about the
operating system division.
</tangent>

I have seen Windows replacement style Linux distrobutions that where barely
usable as Linux. I worked with one that had almost all of the normal shell
utilities removed.
Which one? I have seen Linux implementations designed to look like
Windows to ease the transition for folks coming from the Windows
environment, but that was mostly a matter of the window manager and theming.

I don't remember off hand exactly which was that bad; but, I do remember
working on somebody's system only to find that the command environment had
been effectively castrated. The startup scripts were largely re-written in
Python. Even sed was missing. Awk was available and I was able to use
it to replace sed, dd, grep, tr, etc to get my work done. I think even
that, may have been the busybox replacement.

As more and more users come to Linux who have no desire for command line
usage, it becomes more a liability to maintain. Most distros still boot
using bourne shell init scripts but that is changing as some are starting
to experiment with using Perl or Python. Once they have replaced the init
scripts, there will be no reason to keep the shell and standard utilities
around. Effectively, the Linux kernel just becomes a platform on which to
launch a desktop environment.

usage, it isn't quite as useful. I purchased an old military/teacher
style metal desk. I love it; but, it is extremely heavy.
How often do you need to move it?

Thankfully, not often.

One thing I'm playing with a bit is virtual desktops, and putting
logically related operations in their own desktop.

I did that when I first started using X with the fvwm window manager. It
works; but, it is no replacement for multiple screens.

I still essentially do the same thing with screen. I run all of the
processes for a given task within one screen session. The side effect
is that I end up with a lot of screen sessions left in the background
with different things that I am working on concurrently. I have a bad
habit of leaving many of my sessions open under all grades of completion.
At one point I had to pipe the listing of my screen sessions into a pager
to find the name of one that I had forgotten. After that, I wrote a
completion definition that allows me to tab complete my session names when
re-attaching:

function ls_screen_session_names
{
echo $(screen -ls | awk '/^\t[0-9]*/ {
gsub(/^\t[0-9]*\./, ""); printf($1" ")}')
}
complete -W '$(ls_screen_session_names)' screen

I would say the vast majority of data that people work with is still text
based in the end. This is changing for home users; but, doesn't need to be
a problem where software producers stick to standardized formats -- it just
needs tools which understand those formats. ImageMagick for instance
where dealing with image based data.
Agreed, but I think we have a way to go in being able to deal with
things like image data in a scripted manner, especially when piplines
are involved.

Probably, but is that a limitation of the text system or a limitation that
we have for processing image data in general. I can do an awesome amount
of scripting using ImageMagick for images and I have even used mencoder for
automate splicing and joining bits and pieces of movies for the automated
creation of animated films. What I would tend to find missing is the
artificial intelligence of pattern matching. There is no regex that can
define a face in series for frames so that it can be centered in the frame.
This is not necessarily a limitation of text commands as it is a
limitation of the tools. I haven't seen many better ways of automating this
graphically. In the end, most of this kind of work is done interactively,
even in a graphical environment.

Again, it is not really possible to compare an application against what is
effectively a programming environment. You are effectively comparing a
Lisp interpeter against a text editor. On such a basis, the programming
language is always going to have more potential. Therefore, I can only
compare the text editor against the modes already written for the
interpreter.
I guess my point is "foo fails as an editor compared to bar because the
command assignments suck" doesn't really hold water if foo lets you
remap command assignments as you like, and that seems to be the core
objection to Emacs.

The problem that I have is that I cannot consider a programming language to
be an editor. I can conceivably compare an editor to another editor that is
programmed in the programming language. It is true that I can be
relatively happy using Viper; but, can you really consider that to be
Emacs? I may not be logical in my determination but I don't. I doubt that
it is what most people think of when they think of Emacs. I suppose that
you could compare Emacs vs. vi on the terms of philosophy just as I have
made a comparison of Unix vs. Mac philosophy. It is possible to use a
command line on OS X; but, would that be consided very Mac like? Sure, you
can implement vi on Emacs; but, is that very Emacs like?

But what else is Emacs any better then other applications at doing?
Not "better". Say rather "As good as" or "good enough". A
I have never accepted mediocre solutions.
If the solution does what you need it to do, in a robust and efficient
fashion, and is easy to integrate into your workflow, is it "mediocre"
because it lacks features in other solutions that you may never use?

An ox is capable of pulling a plow and does what a farmer needs it to do.
He will be perfectly happy with his ox as long as he never learns about the
existance of a tractor. When he sees the tractor, he is quite likely to
want to replace his ox. Is it wrong, when I have seen something that I
find better, and which does its job with gusto, that I would want to use it
rather then the solution that is good enough?

best-of-breed application may have an assortment of features not present
in competitors, but if you never have occasion to *use* those features,
you may not *care* that Emacs (or whatever else you use) lacks them.
I tend to make use of most features eventually. Sometimes it takes me a
while. I don't always know everything I want when I start using an
application any better then I may know the intrecate deals of the
application itself. Once I have started to develope my usage habits then
my needs will grow.
Okay. Assume you are embarking on a project that will require you to
use a new application, as nothing you currently use addresses the
particular problem domain. There are several possible candidates you
could standardize on. What determines which you try first? Go for the
most powerful, assuming you'll grow into it?

Generally yes. There are still a number of domains where I have found an
application to suit me and where I have not yet written my own application.
I am still hoping that somebody will write a jabber client that will work
the way I do. I never did find organization software that suited my needs
and I ended up writing my own. I can be extremely demanding of my
applications. More powerful applications also have the advantage that they
may give me ideas to improve my workflow based on the opportunities that it
presents. Weaker applications would tend to focus my thoughts into the
envelope that they have provided for doing things.

Vi is an acception. I admit that it is a less powerful solution to Emacs
which is essentially a programming language. I find vi to be the better
text editor (and also much smaller) and therefore the right tool for
the job.
I largely concur. I'm a sysadmin. Most of what I do in an editor
involves changes to files that control one or another thing, or the
creation of scripts. I don't need interfaces to compilers, debuggers,
class browsers, source code repositories and the like.
So Emacs would be overkill, even though it *could* do the job.

I program and require these things. I still prefer vi for most of my
editing. I have used IDEs before; but, I still don't feel constrained in
using separate components for each function. It is true that I probably
spend more time learning to use different tools. I will always spend an
hour learning something today that will save me ten hours down the road.
.

Relevant Pages

  • Re: executing a configure script from a tcl scrip
    ... When working on windows I get the "can't find ... I never compiled Tcl on windows but I do know that configure scripts ... what program you run a Command Window will popup. ...
    (comp.lang.tcl)
  • Re: executing a configure script from a tcl scrip
    ... I am having problem to launch the configure script from tcl. ... When working on windows I get the "can't find ... I never compiled Tcl on windows but I do know that configure scripts ... what program you run a Command Window will popup. ...
    (comp.lang.tcl)
  • Re: How to alter DNS with CMD command?
    ... > I know how to set the DNS server adress in the GUI interface. ... > I want to know whether there is any command in command line mode. ... There are many ways to do it for Windows 2000, ... You can also search the numerous VB scripts at either ...
    (microsoft.public.win2000.dns)
  • Re: Cron to email notification of ftp file upload?
    ... or traceroute and getting "command not found" messages and then trying to ... >use sudo command when you need to make root privileged changes, ie, ... [ohmster@ohmster scripts]$ sudo crontab -l ... $ cat ftpwatch ...
    (alt.os.linux)
  • First skirmishes with Safe Tcl interps, pluginmgr, Tablelist and homespun package...
    ... I am trying to create a plugin environment for my application which ... will allow simple user written scripts to be run. ... the list command doesn't show plugins that are created using the ... Inside the slave I can package require "oow", ...
    (comp.lang.tcl)