Re: vi horizontal split screen

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:
I'm an old ksh hacker, but bash will do fine.
I have always heard great things about Ksh; but, I have not used it as it
was never readily available when I was learning. I avoided Csh because of
I started on the SysV R2 Bourne shell, and used csh for a better

I have never actually worked on a SysV system. All of my experience is
either BSD and later Linux. I worked on VMS for a short period of time at
one school where they primary system was a couple of VMS machines clustered
together. I have, of course, worked with DOS and Windows.

interactive interface. But when ksh became available, I grabbed it with
both hands. Command line recall and edit, which I had on DOS, was worth
the price of admission by itself. Other features, like built-in integer
arithmetic and the "print" command were icing on a tasty cake. For

IIRC, ksh was not widely available on free systems do to issues of free
software etc. I am not a free software activist; but, I was always working
on free systems. BSD was popular with the Universities on mini-computers
and Linux became popular for desktops. I could not have afforded a system
V license for the desktop assuming one might have been available. If it
was, then I believe it must have been really expensive. BSD used Csh as
its default interactive shell and Linux would use Bash.

IIRC, when a free'er version of ksh was released (1988?) it had some
considerable problems and was not widely used. The 1993 release is the one
available now; but, it is still not widely available across the free systems
that I use and I have developed a massive set of bashrc files that I would
be loath to have to port. In the end, learning Ksh just seemed too much
work for too little gain.

I think recent versions of bash do allow some integer arithmetic but I must
confess that I don't use it. bc or dc is almost always available for any
kind of mathematical operation. I am not sure about how Ksh print works?k
I would be more interested in any advances in branching or flow control
constructs.

Csh got bad press because of parser bugs that made serious scripting in
it a questionable idea. The script language was designed to look like C
for the benefit of C programmers working on *nix, but you still needed
to know Bourne syntax, because all the scripts that controlled Unix
itself were in the Bourne shell language. I've spent time on various
systems rewriting csh scripts in Bourne syntax for maintainability.

Yea, the mantra always seemed to be interact with Csh but script in Sh. I
just never liked having to learn two tools to do what I considered to be
one job and by the time I got into it, Bash was becoming a reality. Csh
did have the virtue of developing great history expansion -- the ideas of
which would become incorporated into bash. It is too bad most Bash users
never really learn to use Bashes history capabilities.

Bash, meanwhile, was trying to marry the Bourne/C shell flavors and
include the best aspects of both. I suppose it did, but the result is
big enough that some things call ash to process scripts to avoid the
overhead.

There is no doubt that Bash is a huge complex beast; but, over time I
have learned to put most of its features to good use. It did take a *long*
time to learn it in any near complete compacity. I don't mind spending the
resources if I get the extra functionality in return.

I dislike when people try too hard turn Unix into Windows. There are a
great many things that I like from the Windows platform COM, .net,
powershell/monad, WSH, WSUS, GPOs, etc. that I think would would be useful
you mention Powershell. You can create scripts with pipelines in
Powershell, but what gets passed around in the pipelines are fully
qualified .NET objects, rather than ASCII strings. I suspect the
surface of that capability has just been scratched.

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.
Where the objects are available, they are not usually well enough
documented to be usable. For example, I wanted to make creative use of a
web cam. I even found some available COM objects using the object viewer
in Visual Studio; but, the interfaces where complex enough that I could not
infer the datatypes being passed between the methods. No documentation was
available and in the end, I ended up dropping the project.

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.

when translated the Unix environment; however, Unix is a separate
environment with its own strengths. It has been around a long time
directly because of those strenghts and those strengths stem from its
central philosophies. They should not be forgotten or we will end up with
a poorly implemented version of Windows.
I don't think we need to worry about that very hard.

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.

GUI applications where I make extensive use of "hot keys."
I learned Unix back before X and GUIs were common, and got accustomed to
the command line as well, so I pretty much always have an X-term open.
I wish I had the room for multiple screens here, but my computer desk at
home hasn't space for two 19" monitors.

Poor fellow. I *love* having multiple screens when I am programming.
I can have several files, references, etc. open and view them without
having to use any actions or having to cover up something else. I feel
very constrained when using single head computers or notebooks. For other
usage, it isn't quite as useful. I purchased an old military/teacher
style metal desk. I love it; but, it is extremely heavy.

The "one tool for one job" philosophy is easiest to apply when all the
tools work on the same underlying data format. I'd call the philosophy
an outgrowth of history. Unix was developed by programmers wanting a
better environment for the task of doing software development than the
one provided by the system they were using. They needed to be able to
create, manipulate, and transform source code, and that was stored as
ASCII text. So if your data is ASCII text, Unix offers all manner of
handy tools to massage it. If not, things get a bit more complicated.

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.

Working with text based applications also has the benefit that they are
easy to work with remotely. I make extensive use of ssh. VNC and RDP are
good tools as well; but, I can get an SSH link working in environments
where VNC and RDP will not.
I've used all of the above, and agree. Unfortunately, not everything
you might want to use *is* text based.

No, but as I said, it is just an added advantage.

I prefer "best of breed" myself, but I understand the attraction of
performing edits, reading and replying to email and newsgroups,
interacting with the shell, and compiling and debugging from within a
single environment, with no need to switch programs or command sets to
do it.
I do understand why people prefer unified environments and I suppose that I
would learn to like it if I ever found one good enough. Emacs is not it.
Depending upon what you do, there may not be one.

If there is, I have not found it.

The most popular integrated environment I know of these days is IBM's
Eclipse programmers IDE. There are lots of IDEs about, but it's hard to
justify paying for one when Eclipse is free, open source, and cross
platform.

I have seen Eclipse. It is no doubt a good environment and like Emacs is
is more of a platform then a single application and can be used to do
anything. I find it overly complex. I have no doubt that it is a good
system; but, it is not for me.

But the power is a two-edged sword. I saw commentary by one developer
who deliberately reverted to a standard text editor to really learn
Java, because things in Eclipse like auto-complete were relieving him of
the need to really understand how to construct things like templates.
Once he felt he had learned Java properly, he was willing to use Eclipse
again because the features were time-savers, but he understood what was
being done for him.

I have much the same notion. At some point the programming becomes overly
abstracted. You see bits and pieces of the code but never really get the
big picture about how it is all hooked together.

My main complaint about Emacs is that you largely *have* to customize it
to make it truly useful, and learning enough to be *able* to customize
it is a non-trivial task.
Very true. That is why I consider it a shell and application environment
rather then an editor. You can do virtually anything with it including
recreating what I like about vi. It is partially an apples and oranges
comparison when trying to compare it against any text editor. Therefore,
the only way I can compare Emacs as an editor is to compare its default
editing mode.
Okay. I understand the feeling, but I'm not sure I agree. If you
compare editors based only on the defaults they come with, and ignore
the ability to customize them using whatever facilities they provide,
you essentially ignore most of what makes a particular editor desirable
to those who use it,

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.

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.

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.

For instance, Vim has an enormous number of features. But for the uses
I put it to, I seldom if ever use them. For what I need to do, plain vi
is quite adequate, and the way I use Vim, it might as well *be* vi.

Vim is somewhat of an acception. Partially because vi is so well designed
in the first place and partially because I use different vi clones on
different systems where Vim features are not present. I have never
bothered to learn Vim script; but, I do make heavy use of Vim's extended
editing features and I do have Python scripts written to use within Vim
using Vim's python-interp interface.

I like using the best tool for the job, but that doesn't equate to the
most powerful. My philosophy is the tool to *fit* the job. So I won't

Quite so, albeit in my case, the most powerful solution will usually win.
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.
.

Relevant Pages

  • Re: csh programing book
    ... Is there a good programming book for csh as for example for bash (free ...
    (freebsd-questions)
  • Re: Put html-tags on..
    ... Of course it is well known that bash is a pretty sluggish shell, ... It's clearly a programming job, ... awk) might be more appropriate. ... otherwise I'd use a shell loop. ...
    (comp.unix.shell)
  • Re: cshrc to bashrc??
    ... into a bash RC file?After decades, I'm giving up on the csh stuff. ... there is no automatic converter for csh -> sh ... executed for login shells ...
    (freebsd-questions)
  • Re: csh programing book
    ... Is there a good programming book for csh as for example for bash? ... For shell programming you should consider using an alternative shell ... I've seen lots of csh books, now and then, I have several here, but there are certainly more sh books. ...
    (freebsd-questions)
  • 2006 results for debian-users favourite FLOSS
    ... Last year I asked debian-user which of the ... audio editor: ... desktop OR window manager: ... Bash, ls, su, locate,sed ...
    (Debian-User)