On "Re: And something about less" Richard Adams said on Apr 27:
> I never said i did, however what you describe is hard to understand in the
> terms you use.
I can't comment on that. My problems seem less than usual.
And English is not my native language.
> 1) The file being viewed is an open file and will not get appended untill
> the file is closed, all changes are in memory and possably a tmp file.
> Only after closeing that file will the changes be readable to most all
> programs "including less".
That zero_lenght_soon_to_be_larger file is the output of
stdout or stderr of some programs. Not sure about closing. It's
something like sendmail -vq > file. I have no idea if the file is
closed after every line or after sendmail quits. But why does this
work fine if the file has one line, or any other number of lines, and
it doesn't if the file _initially_ is zero?
Take my example. If the file didn't exist, or it was created
let's say with touch, than less won't reread it. If the file had
something in it than ^R works just fine, no matter weather sendmail is
on or not.
> 2) less does not constanly read a file, it loads the complete file into
I know that. It would be a terrible waste of proc power and
it can reduce the hard drive output if there are more files opened in
different locations.
> memory, so changes to the file being read will NOT be seen by less,
> there is the f option (which i have never tyred), the man page says it
> works like 'tail -f', but as i see it if the file being read is opened
> by another program and constanly being changed, then the appended
> text will not be seen.
Actually, if I understand correctly what you mean - you are
wrong. That text would be seen.
> I said at the start, less loads a file into memory, if you want to
> constanly "monitor" a file thats being constanly appended, use 'tail -f'
> you can even go one beter, get syslog to redirect that particular logfile
> output to a tty as well as a logfile.
No. That would be stupid. I have tail to do just that. Why
use less which is bigger thus slower? I want to examine that file
during the time it is written. But I mean examine. And not just read
the last lines. Here are some inconvenients with tail. Because it
doesn't show the "above" screen lines - lines that were scrolled out.
Yea. I know. The way your advices sound, you will probably tell me
how the kernel can help me see the last few screens. I know that.
But you probably should know that _if_ something is written on the
screen, in our case a new line, I will be back at the end of file.
> NO not sarcasum, fact, i consider (if i now understabd properly) that you
> are expecting a child to do a mans work, by that i mean you are using the
> wrong program, why use less, do it another way, there are so many
> possablitys.
And what is that man that will do child's work?
> No one can solve a problem when there is not a problem to solve.
?!?
Um... you said you didn't understand the problem. How can you
say out loud that there is no problem if you did't understand my
problem? This is a problem of logic. Lack of it to be more specific.
> Everyone can create problems and blame it on software which has been in use
> for many years by "millions".
Errr... not really. This is a limitation of less. Which
isn't in those README files. tail can refresh one zero lenght file
that has growth. Less should too. I can't see your logic with that
mumbo jumbo about memory and open/close files. Normally less should
see that the file has changed and print that on screen.
> > Oh! My goodie... what is man? Is this another pacman game?
> I used to say "RTFM"
I would have apreciated it more. Although I read all
documentation before going forward with this. Eh. Maybe I missed
something. This is why I asked on the list. Because I don't want to
bore the authors with something that was already changed/solved. Or
maybe there was some security concern, or god knows what reason NOT to
do this.
> tail -f /var/log/filename > /dev/tty12 (for example)
Puhleeze. I know that... and the rest of the examples which I
cut.
Raider
--
``Liberate tu-temet ex inferis''
-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.linux-learn.org/faqs
