[pjungwir]

Another less-vs-vi question:

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 . . ."

[annnnd]

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]

  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]

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]

> The assumption is that you deal with non-malicious users...

[notfoss]

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]

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 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]

> 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]

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]

> 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]

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]

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]

You can give vimpager a try. It even supports vimrc. But I have felt it to be considerably slower than less.

[sukilot]

chmod :)

[dredmorbius]

It took me way too long to grok that.

[oimaz]

With vim, I usually use 'vim -u NONE <file-name>' which skips the startup file and makes loading zippy

[ryen]

It may also try to do syntax highlighting and other formatting stuff, taking up even more resources and cpu time.

[sliverstorm]

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]

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]

BTW, starting vim as "view" (through e.g. a symlink) is equivalent to "vim -R", precisely for this use case [0].

[0] http://vimdoc.sourceforge.net/htmldoc/starting.html#view

[blueblob]

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]

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]

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]

Why do you let revs login to production machines. That's your first problem.

[cstoner]

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]

Funny - I always used to use less, until this popped up on HN:

http://seclists.org/fulldisclosure/2014/Nov/74

Now I mostly use vi.

[bkeroack]

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]

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]

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]

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.