 | | annnnd on March 31, 2015 | next [–]
From sysop standpoint there is a huge difference: 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). | |
| | notfoss on March 31, 2015 | parent | next [–]
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 ;) | |
| | pjungwir on March 31, 2015 | root | parent | next [–]
Ha ha, this reminds me of the days I had sudo access to `vi` but not a lot of other commands, on a box that IT didn't really want to support. . . . | |
| | annnnd on April 7, 2015 | root | parent | prev | next [–]
> The assumption is that you deal with non-malicious users... | |
| | notfoss on April 7, 2015 | root | parent | next [–]
It was there previously? Sorry I missed it. In any case, I wouldn't call the action I mentioned malicious. There is no hack involved, no improvisation either. Simply using a built-in feature of `less`. | |
| | pjungwir on March 31, 2015 | parent | prev | next [–]
Thanks for your reply! Since I do a lot of devops I've tried over the years to formulate a mental model of how a sysadmin thinks and what they care about. I'd never have thought about this auditability concern, so it's something to add to my list! :-) | |
| | vbezhenar on March 30, 2015 | prev | next [–]
On large files less fires up immediately and vim is quite slow. I think that vim is loading an entire file in the memory while less just loads visible chunk. May be other vi implementations are more efficient with large files. Besides — vim really shouldn't be used on log files. It's editor, not viewer. | |
| | pjungwir on March 30, 2015 | parent | next [–]
> 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. | |
| | kragen on March 30, 2015 | root | parent | next [–]
You can save a part of the file, pipe a range of lines, or switch between files in less, too, and the commands are mostly the same as in vi. It'd sure be nice to be able to split the screen, though! | |
| | EdiX on March 30, 2015 | parent | prev | next [–]
> I think that vim is loading an entire file in the memory while less just loads visible chunk No, vim also only keeps part of the file loaded, however it will try to count how many lines the file has. | |
| | robmil on March 30, 2015 | parent | prev | next [–]
Vim ships with a command called `view` that will start it in read-only mode, and makes it very much a viewer —not just an editor. | |
| | dredmorbius on March 31, 2015 | root | parent | next [–]
True, and I like using this for syntax-colored views of files. But it's got an annoying tendency to switch to edit mode with very little fuss. Sometimes I want a viewer to just be a viewer. Speaking of which: are there any Linux/Unix viewers that do have generalized syntax highlighting support? | |
| | notfoss on March 31, 2015 | root | parent | next [–]
You can give vimpager a try. It even supports vimrc. But I have felt it to be considerably slower than less. | |
| | sukilot on March 31, 2015 | root | parent | prev | next [–]
| |
| | dredmorbius on April 2, 2015 | root | parent | next [–]
It took me way too long to grok that. | |
| | oimaz on March 30, 2015 | parent | prev | next [–]
With vim, I usually use 'vim -u NONE <file-name>' which skips the startup file and makes loading zippy | |
| | ryen on March 30, 2015 | parent | prev | next [–]
It may also try to do syntax highlighting and other formatting stuff, taking up even more resources and cpu time. | |
| | sliverstorm on March 30, 2015 | parent | prev | next [–]
And an editor should not be used on log files? 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... | |
| | blueblob on March 30, 2015 | prev | next [–]
I think your idea of `vi -R` or `vim -R` is a good idea. `less` uses less memory and may load faster but looking at logs for things like valgrind vim will give you syntax highlighting that I am not sure you can get with `less`. | |
| | dcohenp on March 30, 2015 | parent | next [–]
| |
| | blueblob on March 31, 2015 | root | parent | next [–]
I have used `view` but it didn't give me syntax highlighting. On my system (archlinux) view is actually a symlink to ex (which must change its behavior based on its name?). readlink /usr/bin/view ex
| |
| | hrktb on March 30, 2015 | prev | next [–]
I think Edix's answer is the most pragmatic.Also, someone at work actually crashed a service by opening the log files in vim. 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. | |
| | dexxtreme on March 30, 2015 | prev | next [–]
If I'm logging into a server later to resolve an issue, one thing I will probably check is the command history. If you open a file with "vi", how do I know that you only looked at it, and did not make any changes to it? When I see "less" in the command history, I know for certain that it was a read-only operation. | |
| | sukilot on March 31, 2015 | parent | next [–]
Why do you let revs login to production machines. That's your first problem. | |
| | cstoner on March 30, 2015 | prev | next [–]
It's a good practice for sure, but your sysadmin was probably a little over-hash. I'm generally in the habit of using `view` to do read-only vim. `less` works as well. | |
| | dTal on March 31, 2015 | prev | next [–]
| |
| | _ondq on March 30, 2015 | prev | next [–]
I would never "yell" at anybody for using vi vs less, but I might curiously ask their reasoning behind it. I'm generally for less bikeshedding and cargo cultism when possible. Whatever works to get the job done. | |
| | nodata on March 30, 2015 | prev | next [–]
Yes, but cpu is normally the problem. vim is very inefficient with long lines, combine that with all of vim's features (syntax highlighting, etc.) and you have the potential to make a problem worse. | |
| | freehunter on March 30, 2015 | prev | next [–]
I don't know his exact reasoning, but the biggest thing I can think of you already touched upon: there's more of a danger that you can write to a file accidentally with vi vs with less. 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. | |
| | sukilot on March 31, 2015 | prev [–]
The sysadmin was low knowledge. 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. | |
