out of space on /root

[Joel Rees]

On Mon, Mar 13, 2017 at 6:49 PM, Xen <list at xenhideout.nl> wrote:
> Joel Rees schreef op 13-03-2017 9:50:
>>
>> Ah, yes, this conversation recalls me the days when cat was a shell
>> built-in.
>
>
> Ah, yes, I keep wondering why it's not :p.

It was in certain shells in certain Unix-like OSses at one time.

> I mean, that would almost completely defeat the entire purpose of doing it
> differently :p.
>
> Although perhaps that would be odd, but you could of course easily transform
> "cat |" into "<" internally if you did it internal to the shell, but perhaps
> that would defeat the entire dicussion as well (and the purpose of
> separating these things semantically) :p.

... which was part of the reason for doing it that way.

There were some context issues where not having an executable to refer
to when invoking cat caused problems, as I recall, which may be part
of the reason Linux shell generally don't do it that way. (The other
part being the tendency, when we rely on a large community, that good
ideas fail to circulate. Or the may have been "intellectual property"
involved.

> Regards.
>
>> Now, I, personally, would tend to use less, and "g" and "G", or vim,
>> and "gg" and "G". And the cursor keys.
>
>
>
> For the reader:
>
> "G" in Vim goes to the last line of the file, and "gg" goes to the first
> line. To me that's all very confusing and ever since I started using "gg" I
> started mixing them up ;-).
>
> "g" then, in less, also goes to the first line, and "G" also goes the the
> last line, so perhaps it is easier to remember for me that way :p.
>

Well, I'm glad that didn't turn into a flame war. 8-) I didn't intend
to start a long discussion, but it looks like useful information
getting shared. So I won't apologize.

But I was intending to point out that the less solution and the vi
solution both have the advantage of not having to have the whole file
in RAM at once.

That circumvents the necessity of splitting extremely large logs
files, and helps when it's hard to guess how far into the log to take
a head or tail.

gedit cannot edit a log file of a megabyte in length on any machine I
have. (I should try it on my sons machine. He has a notebook with 8G
RAM, at my insistance. ... And his UI of choice for source code is vim
at the core of a custom collection of tools that manage the multiple
window paradigm for him. I need to get him to show me how he set that
up.)

I'm pretty sure most of the editors that have been mentioned will try
to work on large files all-in-RAM, which means they essentially choke
like gedit does when trying to work on the really large log files.

But my memory is that at least one of the editors mentioned may edit
on-disk, to avoid the problems of using too much RAM (among other
things). So it would potentially work on large log files. (joe?)

When working on MS-DOS, I liked to use an editor called qedit or
another one called brief.

Heh. I also found myself editing source code with wordperfect
(specifically for the capability of italics and other formatting in
comments). At one time wordperfect had a nice editor of its own, as I
recall. And virtually killing wordperfect with illegal marketing
practices is one of the sins of Microsoft that I have a really hard
time forgiving. But that's way off-topic. ... Except that Microsoft's
attitude about the marketplace is precisely one of the major sources
of entropic pressure on software design.

But don't use less on a binary log file like lastlog. ;-p

-- 
Joel Rees

I'm imagining I'm a novelist:
http://joel-rees-economics.blogspot.com/2017/01/soc500-00-00-toc.html
More of my delusions:
http://reiisi.blogspot.jp/p/novels-i-am-writing.html