Terminal Lines – How to See More Lines in the Terminal

The terminal output will be colored if the content of the file will be sent "as-is" to the terminal, without any modifications. However, vim and some other editors will escape meta characters in the text and instead maybe add some other color codes for their syntax highlighting, so this doesn't work.

Try dumping the file to the terminal with cat, this should work. Some simple editors or pagers like less might also work.

Edit: I have not found a way to let vim "pass-through" all the escape codes, but I have found this answer which links to this vim script, which parses the escape codes and uses the vim syntax highlighting to recreate the color codes in the output. According to its description, it should do exactly what you want (but I have not tested it).

lsof "$(tty)" does what you ask, by listing what has your terminal open for read or write.

You can check what has been writing to your terminal if it still has your terminal open, which is usually the case, at least if it is still running. It is possible for it to have output an error message to your terminal, closed the file descriptor for it, but kept running. But the more likely reason you wouldn't be able to check is if the process itself runs only intermittently.

• jobs shows your background jobs. If you've run the process yourself with & so it runs asynchronously--or suspended it with Ctrl+Z--and it is still running, then the jobs builtin will show it unless you have disowned it.
• In case that's not enough, lsof "$(tty)" lists everything that has your terminal open for reading or writing. This works even in the rare case of something that writes to your terminal without ever having been started from it or being descended from some other process that was.
• But for your specific situation, I do recommend reading the part at the end of this answer that addresses that error message.

It is possible that you have many graphical programs that have your terminal open for write:

• This can happen if you're running a major part of your desktop environment (that launches many other programs) from your terminal, such as Unity or another graphical shell.
• In particular, if you have run a command like unity --replace & from your terminal, that would explain unexpected errors from applications appearing in it.
• Then if your goal is to silence the messages, you should either not run it or run it in a different way (or from a different terminal). The best approach there would depend on why you're running it.
• You can run pstree to see your process tree, which may help.

Your terminal device is a "file" and you can pass its filename to lsof.

You can get a list of processes that have the current terminal--the terminal in which you run the command--open for reading or writing, by passing the path to its device node to the lsof command. Since tty outputs that path, you can run it and then run lsof with what it shows you, or you can use any of the following:

lsof "$(tty)"        # "$(tty)" may expand to /dev/tty1, /dev/pts/0, /dev/pts/1, etc.

lsof $(tty)          # bad form, but device names rarely have whitespace/globbing characters

lsof `tty`           # same as above, just with the old disfavored backtick syntax

lsof /proc/$$/fd/1   # the shell expands $$ to its own process ID (fd/0, fd/1, or fd/2 work)

The output will usually look something like this, if the only programs you're running in your terminal are your shell and--of course--lsof itself:

lsof: WARNING: can't stat() tracefs file system /sys/kernel/debug/tracing
      Output information may be incomplete.
COMMAND   PID USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
bash    27763   ek    0u   CHR  136,0      0t0    3 /dev/pts/0
bash    27763   ek    1u   CHR  136,0      0t0    3 /dev/pts/0
bash    27763   ek    2u   CHR  136,0      0t0    3 /dev/pts/0
bash    27763   ek  255u   CHR  136,0      0t0    3 /dev/pts/0
lsof    29311   ek    0u   CHR  136,0      0t0    3 /dev/pts/0
lsof    29311   ek    1u   CHR  136,0      0t0    3 /dev/pts/0
lsof    29311   ek    2u   CHR  136,0      0t0    3 /dev/pts/0

If you have more things running that read from or write to your terminal, they should be shown. Note that the commands shown above must be run from the terminal where you see the annoying messages. You can do this from a separate terminal, too, but you must give lsof a path to the terminal you're interested in. For example, you can run tty in the terminal you want to know about, then use the path it shows you as the argument to lsof in the terminal you want to run it from.

Regarding access and permissions, you may be wondering:

• The tracefs warning may or may not appear for you. Either way, you probably needn't worry. Usually it's from the debug filesystem being altogether unavailable rather than being restricted to you, so...
• It's possible you would benefit from running lsof as root with sudo, but probably not. Usually you can view information about all processes, and even if your system is configured not to allow that, whatever is doing this is probably running as you anyway.

Some processes appear more than once, because they have your terminal open more than once. I don't really recommend trying to show only processes that have your terminal open for write, though, because:

• When the same process appears multiple times, they are shown together, so the extra entries should not be confusing.
• It's rare anything but your shell and programs you run from it are reading from your terminal. You can usually view these with jobs anyway, which gives one line (or fewer) per process. If you're using lsof, you want details.
• Processes that appear just once have your terminal open only for write (or only for read), and those are of special interest.

An lsof example: cating from one terminal to another.

You don't have to do this--it's really just a demonstration. This section exists only because:

• You may see nothing that explains your problem in the output of lsof and want some kind of confirmation that it really is showing you processes that write to your terminal, even if they were not started from it.
• You may be interested in how this works and want to try it out in a situation that you control.
• Other readers who are interested in this topic for different reasons may want more explanation than appears in the preceding section, so they can figure out how to use this to solve their own different problems.

If you just run tty in your terminal, by itself, it prints the path to your terminal's device node:

ek@Io:~$ tty
/dev/pts/0

This will not always be /dev/pts/0. You can open another terminal and run tty and the path will be different. Go ahead and do that.

In the second terminal, run cat but redirect its output to the first terminal. To do that, run this but replace /dev/pts/0 with whatever tty showed you when you ran it in the first terminal:

cat >/dev/pts/0

Type text in the second terminal and press Enter. It will appear in your first terminal.

In the first terminal, run any of the lsof commands shown above.

ek@Io:~$ lsof "$(tty)"
lsof: WARNING: can't stat() tracefs file system /sys/kernel/debug/tracing
      Output information may be incomplete.
COMMAND   PID USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
bash    27763   ek    0u   CHR  136,0      0t0    3 /dev/pts/0
bash    27763   ek    1u   CHR  136,0      0t0    3 /dev/pts/0
bash    27763   ek    2u   CHR  136,0      0t0    3 /dev/pts/0
bash    27763   ek  255u   CHR  136,0      0t0    3 /dev/pts/0
cat     29476   ek    1w   CHR  136,0      0t0    3 /dev/pts/0
lsof    29479   ek    0u   CHR  136,0      0t0    3 /dev/pts/0
lsof    29479   ek    1u   CHR  136,0      0t0    3 /dev/pts/0
lsof    29479   ek    2u   CHR  136,0      0t0    3 /dev/pts/0

Your terminal won't highlight the line with cat--I just did that to show the difference.

(In the second terminal where cat is running, you can quit it by pressing Ctrl+D at the beginning of a line, or just by pressing Ctrl+C. If you type text on a line and then press Ctrl+D, that will flush the input buffer even though you haven't pressed Enter, and you will see the text on the first terminal.)

Debugging "Failed to open VDPAU backend" Errors

Although that's a general answer to the question of how to find what's writing to your terminal and it may well help you, there are other approaches you should consider, for the particular problem you've described here. Aside from kernel messages on virtual consoles--which this is not--messages shown in your terminal usually come from some program you have run from your terminal, or some program that one of those programs has run, etc.

As NickTh's answer says, if you're not manually running anything from your terminal that seems like it could produce those messages, check the files your shell may run commands from when it starts, especially .profile and .bashrc (as NickTh mentions) because those are the ones you're likely to have modified.

The error you are seeing probably isn't a bug in MPlayer itself, but instead in a library it uses, which is used by many other programs. If you are running any graphical programs from your terminal--especially if you have placed them in the background with &, so they run asynchronously with your shell--then one or more of them is almost certainly the reason you're seeing these messages. Web browsers are particularly likely to produce them, mainly because they may run plugins, such as Adobe Flash, that use the affected library.

There are a number of bugs reported on Launchpad about error messages like this one. Bug 808254 is particularly similar to what you have described. Bug 1300215 is especially prominent, though it involves an Intel video driver. You can search Launchpad for text from the message to find more bugs. You may find workarounds--either just for silencing the messages or for doing more about the bug--in such bug reports and their comments. In addition, while the other question linked to in NickTh's answer is about the problem is it occurs in MPlayer and has several MPlayer-specific workarounds as answers, the currently top-voted answer is not specific to MPlayer and may work for you.

If you're running many programs from your terminal, you may have seen many entries in the output of lsof (if you decided to use that method in your troubleshooting). One way to figure out which program is producing the output is to run your programs from separate terminals. This works even if your separate terminals are started from each other--a GUI terminal emulator like GNOME Terminal does not pass the error messages or other text that it displays up to the terminal from which it was itself run (if any). Similarly, one way to stop being bothered by this problem--assuming the annoying messages are the only real problem--is to not run things from your terminal that you don't want output from in your terminal. Normally you can achieve this by using your graphical menus instead. But please see the top of this answer for why you might be running more from your terminal than you need or intend.