Some of the output redirected to /dev/null appears on the screen while 'scripting'
 

I wrote a script that plays a video using mplayer. Let's call it 'a' The script works perfectly, but I don't want to see the messages on the screen

I typed: ./a>/dev/null

I still got a few lines on my screen:

I tried: ./a>log.txt.

I opened log.txt and found the usual messages I get while playing the file using mplayer from the command line. Ok, so my output is being directed. The strange thing is -- what I put in the QUOTE above was not found in log.txt

I typed: ./a

I found everything in log.txt and also what I've shown in the quotes-- on my terminal as expected.

How do you prevent any message from appearing on your terminal?

Also, how do you play the file in the background. ./a& does not work as the entire process will be sent to the background. I want to run it from the terminal in the same way as it runs when you double click on it; without displaying any messages, and allowing you to work peacefully on the terminal.

There are two ways for programs to output to the screen/terminal: stdout and stderr. When you redirect a command with '>' alone, you redirect stdout only. Any messages sent to stderr (usually error messages) will still be displayed. To redirect both stdout and stderr to /dev/null, do this:
I don't have any idea about your second question. At least, not without seeing the contents of the script. It would be most likely that you'll need to background processes within your script to get the effect you want. Again, that's speculation without seeing our script.

Yes, that worked. I understood what you said, but I have no idea of what 2>&1 actually means. Can you give me a link, or tell me which man page should I refer to, so that I can learn more about that?

You wanted the contents of my script. Here is my masterpiece:

I can run the script by double-clicking the file. It opens a window and plays the video, and shuts down when the script is done playing it. I want to have the same effect by invoking the script from the command line.

./a& will give you this message:

If I want to play the file, I'll have to type: fg

I don't know how to invoke the file in the same manner as I do in GUI.

Thanks for the help.

Using "2>" is equivalent to saying "redirect stderr to . . .". You redirect stdout with "1>" or with just ">". So, this sequence: "> /dev/null 2>&1" can be translated (roughly) as

Redirect stdout (">") to /dev/null ("/dev/null"), and then redirect stderr ("2>") to the same location as stdout ("&1"). So both stdout and stderr are both sent to /dev/null.The same thing could be accomplished with: "> /dev/null 2> /dev/null"

Redirection is discussed in your shell's man page (probably man bash).

As for your second question...

As I recall, the GUI version of mplayer is invoked as "gmplayer" and not "mplayer." Perhaps you should give that a try by replacing mplayer with gmplayer in your script. If that doesn't work, then you might consider reading xterm's man page. I believe you can start a new xterm, have it start up minimized, and pass a command to execute on xterm's command line. For instance:
Try executing that command in your terminal, and if it works, then put it in your script and give it a shot.

Thanks for the explanation.

Substituting gmplayer opens an additional window with the play buttons, track name etc.

The second command apparently does not do anything-- no error, no output; it just returns the prompt.

When I run the script by double-clicking it, I'm not sure... but does it open some sort of a child shell to execute the commands? If yes, all I need to do is figure out how to open a child shell.

There are two options to shut up mplayer. I don't remember what they are, something like -quiet and -reallyquiet. Look in the manpage. Mplayer expects input from the keyboard so it will stop if you send it to the background. You might be able to use "screen" or "nohup" to get it to run in the background.

Thanks for the response, jschiwal.

mplayer -quiet file.flv displays everything except the last line which usually looks like this:

Mplayer did not recognise the reallyquiet option. You're right about the fact that it won't show keyboard interrupts on the screen.

nohup ./a directs the output to nohup.out, but does not return the prompt.

nohup ./a& sends it to the background and does not play the file; it's exactly like ./a&, except the output is sent to nohup.out and the rest of the problems are as described in my first post.

screen ./a opens a new instance which shows the messages and closes when the file is done playing displaying the message [screen is terminating] at my prompt. I cant use my prompt in the meantime.

screen ./a& has almost the same problem as described above.


Note:

Try running the script after pointing it to any of your media files in two ways:

1. Double click the script.
2. Execute the script through the command line.

You'll see the difference immediately.

Here's the script again:


P.S. When you double click a script, how does Linux execute the command? You can simply type that command in the terminal, right?

surrogate terminals
 

mplayer wants to interact with the terminal. If you don't want it to interact with the terminal you started it with, you need to provide a substitute. Screen works and I think expect could also be useful, if you want a non-interactive script.

The correct way to use screen for this would be to start screen, start mplayer in one window and then use a different one for whatever else you want to do.

start example:
$screen
Screen version 4.00.02 ...
...
[Press Space or Return to end.]
$mplayer <file>
{lots of mplayer output appears}
{ctrl-a, ctrl-c - for the default screen keybindings}
$
end example:

some additional material:
screen:
http://www.gnu.org/software/screen/screen.html
http://en.wikipedia.org/wiki/GNU_Screen
http://jmcpherson.org/screen.html

expect:
http://expect.nist.gov/
http://www.linuxjournal.com/article/3065

Thanks for the reply, nmh. I understood what you said, but I want to run the script the way it runs when you double click it. From my previous post:



Try running the script after pointing it to any of your media files in two ways:

1. Double click the script.
2. Execute the script through the command line.

You'll see the difference immediately.

Here's the script again:

P.S. When you double click a script, how does Linux execute the command? You can simply type that command in the terminal, right?

I don't have a fancy desktop environment on my computer. I know you said what you want before, but maybe if you explain what you want it to do, things will make sense. I thought what you were asking, was how you could run mplayer from the command line without seeing all the output. If that is what you want, you can probably use expect to make a script that does that for you. If that is not what you want, please describe what you do want.

As for "when you double click" something - that depends on the desktop environment and other software that is not just the linux kernel. It also varies from system to system.

When I double click the script, all I see is a window containing the video. It's basically the window that pops up when you run mplayer from the command line, the difference being -- there is no terminal on the screen. All you see is a window and nothing else.

I want to know how do you make *only* the window appear when you run it through a script, and by not using some mplayer option, like the way described in the above paragraph.

In that case you want to use expect. man expect to find out all the bells and whistles, but basically you can do something along the lines of:
and after putting the file in your path and making it executible, you can run it with:
this assumes you are using bash. But the basic idea is to run the expect script in the background and redirect output to /dev/null. Bash will let you know when a background process exits, and I don't think there is any easy way to avoid that.

FYI, the even less noisy option is -really-quiet. So you can use "nohup mplayer -really-quiet &
The video will play, and after pressing return in the console, you can use it normally.

I tried it out on a Hummer commercial. Don't ask.

nmh, I tried what you said, but all I got was :

[1] 4901

and the video did not play.

jschiwal, nohup mplayer -really-quiet file.flv

gives me:


If I press Enter, I get :

The video plays when I type fg, but then all the messages are sent to the terminal. I don't know why it works for you. Do you use bash?

How does KDE execute a script, when you double click it?

Okay, can you tell me what happens when you do:
Do you get video, and what output do you get on the terminal?

I got:
I logged on as root and did the same. I still got the same error. Permission denied? On root? :confused:

When I ran it using the previous command you supplied, I forgot to tell you that, after getting that job number, when I pressed Enter I got:

Did you

No, I didn't need to, as these were its permissions:
rwxr-xr-x

I just found an interesting thing-- Open any link on your desktop using a text editor. You will see an option called TERMINAL=false.
That explains why I don't see any terminal and can see only the video while running the script. If you can figure out how KDE executes TERMINAL=false, the problem will be solved. I don't know how KDE executes such commands.

I tried it again on my desktop and it worked.

nohup mplayer -really-quiet <video> &

This also worked in the virtual terminal vt/1:
nohup mplayer -vo fbdev2 -really-quiet <video> &

I tried both your commands jschiwal, but neither of them work. Stupid RH9 :cry:

But still, do you know how to do the TERMINAL=false thing I mentioned in my previous post.

kde dcop urls
 

I will assert that it is better to use a portable solution, but if you want to figure out all sorts of KDE internals, you might do well to start looking at the KDE docs:

http://developer.kde.org/documentati...lo/khello1.htm
http://developer.kde.org/documentati...ion/index.html
http://developer.kde.org/documentati...interface.html
http://developer.kde.org/documentati...als/index.html
http://www-128.ibm.com/developerwork...kdeml01KDEDCOP

You would use the terminal=false entry if you are linking to a gui program and terminal=true if you are linking to a script program, i.e. with menu. You might try looking at the .desktop entry for a program like firefox. Sometimes you are running a wrapper script. If you want to run mplayer in kde, you could simply call gmplayer instead.

Also, which terminal emulator are you running. I ran my test using konsole on two different computers. And on vt/1 using the framebuffer device. Also if you want to start playing something in particular by double clicking on an icon, you can make a copy of an xmms icon and add an argument list after the command in the properties.

Using dcop as the poster above mentioned is the most powerful and flexible approach.

You're right kdcop is indeed an awesome program. I learned many things by reading that link, but I cant seem to figure out how TERMINAL=OFF is acheived by it. Also, isn't there a simpler way to invoke the script without having to view the terminal. I'm fine with using the screen command, but I want to know if there is any other way.

I use konsole too.

While dcop is powerful and flexible, it is not portable.

The "TERMINAL=OFF" thing is a small flag in a special file. If you want to do something like that, you need to poke around in dcop/kde internals/docs to find out what happens from that.

Screen is very useful, but not really the right tool for what I think you want. The right tool is something similar to expect. I know you tried it before and had trouble, but I think it should work if you put a bit more effort into it. If you would like to work on the expect setup, you should start by seeing if you can run a simple expect script. After that, you can get it to run mplayer with almost no output.

Ok, I'll read the man pages of expect. nmh, from where did you learn all this stuff?

In general, from using it to complete tasks (and researching/asking for help when needed). For this specifically, I looked at expect because I had heard of its uses for ssh/passwd/telnet/etc... when normal IO redirection does not work. I looked online for a few examples, read the man page and tried to get a sample to work for me.

I have found that there are many problems that are very easy to figure out simply by poking at them, reading the man/info pages, or reading examples online. I have also found that there are problems that are *very* difficult to solve without asking for help. The real trick is knowing which you are trying to solve.

Good luck with the expect stuff - and feel free to ask more questions if some of it does not make sense.

Getting too complicated??
 

If i am understanding correctly, the following command gives the effect you want:

mplayer <video_file> < /dev/null > /dev/null 2>&1 &

So just stick that in your script??


Earlier in the thread, you had the output redirected but the video just didn't play. Someone mentioned that mplayer wants to be connected to a terminal - and this was your problem, it wasn't connected to any input, so it was hanging. " < /dev/null" connects /dev/null as standard input too.

Late to the party
 

Right, just noticed the dates on the previous postings.