* page forward and backward, including using numeric prefixes to indicate a lineno or indicate "repeat 'n' times".
* launch vi if less(1) is working on a file (versus (eg) stdout of some process)
* search fwd/backward
* start examining a new file w/o leaving less(1)
* ...As a junior programmer I got chewed out by my IT department because I was examining a (production) log file in vi. The sysadmin told me I should use less (actually more---this was on Solaris in ~2001). To this day I only read log files with less, but I've never figured out his objection. Negatives to using vi I can imagine are:
- I might write to the log file. That seems like a real worry, although I could also say `vi -R` to prevent it.
- Starving the production system of memory. I'm pretty sure he expressed this concern. Any insight into whether it is legit? Is less actually any better?
Obviously you really should have a log shipping & aggregation service so you can read logs offline, etc, but not every project is large enough for that, nor every org organized enough. So for the sake of argument my premise is, "Assuming you want to read a log on production . . ."
1) for user: less chance (pun intended) to actually change the file when all you wanted was to read it
2) for sysadmin: if sysadmin sees "less somefile.log" in bash history, he knows the user just read the log. If he sees "vi somefile.log" then he doesn't know if the user has also changed the log file (maybe not even knowing it).
The assumption is that you deal with non-malicious users who just make mistakes (which is often the case).
for sysadmin: if sysadmin sees "less somefile.log" in bash history, he knows the user just read the log. If he sees "vi somefile.log" then he doesn't know if the user has also changed the log file (maybe not even knowing it).
In case you didn't know, you can invoke an editor from within less by pressing 'v'. And that wouldn't get registered in the shell history ;)Besides — vim really shouldn't be used on log files. It's editor, not viewer.
I think the two concerns I stated are probably legit, but this one is boring to me. Vim is nicer than less for reading files. I have more navigation commands. I can yank part of the file and save it somewhere else. I can pipe a range of lines through awk/etc. I can switch between files. I can split my screen. Etc. Some of these are probably available in less too (more than more(1) supported in 2001), but I doubt all, and I already know the commands in vim. I'm interested in not clobbering my logs and not crashing the server, but if you tell me vim is an editor not a viewer, I'll ask Why?
Btw re-reading my words I don't mean to sound combative. But the point of my original question was to understand. I've been cargo-culting "use less for logs" for 14 years already.
No, vim also only keeps part of the file loaded, however it will try to count how many lines the file has.
Frequently, frequently I am in the position that I need to manipulate an overly-verbose log file to condense out the information I want. I could spend a half hour concocting wizard-like shell invocations, OR I could do it interactively in five minutes with vi...
[0] http://vimdoc.sourceforge.net/htmldoc/starting.html#view
I think the problem was that the memory and processor were already getting stomped on (thus the need to look at the logs) and vim tried to do a lot of fancy stuffs to get more info on the file as a whole.
I'm generally in the habit of using `view` to do read-only vim. `less` works as well.
http://seclists.org/fulldisclosure/2014/Nov/74
Now I mostly use vi.
Beyond that, I would probably correct a junior employee as well. Even if there's nothing wrong with it, it's not the right tool for the job. When I first started I got 'yelled' at for checking to see if a machine was on the network using tracert instead of ping. It works, but it's not the right tool for the job.
You should download the log file and view it locally. You should never run ad hoc commands on a live production sytem.
And there is no reason that you should have edit privileges on the log file anyway.
yank 10 lines, open a new file, paste the 10 lines, save the file.
Is that possible? My Googling last week didn't find a good solution.
$ less /var/log/msgs
/pjungwlr^M
^G (note line informational line numbers)
v (launch vi)
[double check your line #s, etc]
:d1,. (delete from 1st line, to current line)
10j (go down 10 lines)
:d,$ (delete to EOF)
:w my_newfile
:qhttp://stackoverflow.com/questions/17908555/printing-with-se...
(Actually, there's probably more than one despite their really good duplication grooming, but this was the first hit.)
Display only lines which match the pattern; lines which do not match the pattern are not displayed. If pattern is empty (if you type & immediately followed by ENTER), any filtering is turned off, and all lines are displayed. While filtering is in effect, an ampersand is displayed at the beginning of the prompt, as a reminder that some lines in the file may be hidden.