Re: Why won't exec work?

On Sat, 23 Feb 2008 00:02:17 +0000, Simon Bachmann wrote:

Cameron Laird wrote:
In article <628j6lF21qmtvU2@xxxxxxxxxxxxxxxxx>, Tim Köhlmann
<crono@xxxxxxxxxxx> wrote:
On Fri, 22 Feb 2008 17:44:26 +0000, Glenn Jackman wrote:

At 2008-02-22 11:42AM, "Tim Köhlmann" wrote:
Hi!
I'm fairly new to tcl/tk so please don't be too hard on me.
Welcome!
For example:
ffmpeg2theora --optimize -o /home/tim/videos/dsfargeg.ogg -v 10 -S
0 -a 10 -A 196 /home/tim/videos/sauce.avi
or
mencoder -oac mp3lame -ovc lavc
-lavcopts vcodec=mpeg4:vqmin=1:vqmax=3:v4mv
/home/tim/videos/sauce.avi -o /home/tim/videos/dsfargeg.avi

It's probably not necessary to know those programs to help me with
my problem though. The problem is, that I try to open them with the
exec-command which looks like this:
eval exec $cmd 2>/dev/null 1>/dev/null
Tcl's exec command has no "1>filename" argument. You might try

tcl8.5: set output [exec {*}$cmd 2>@1]

tcl8.4: set output [eval exec $cmd 2>@ stdout]

See
http://www.tcl.tk/man/tcl8.5/TclCmd/exec.htm
http://www.tcl.tk/man/tcl8.4/TclCmd/exec.htm


I use 8.4 and that worked! Even ffmpeg works now. The only question
left is: Why?
.
.
.
I don't understand the one question outstanding. Are you asking why
8.4 and 8.5 have been presented as different? Are you asking how it
happens that

exec $cmd 2>@ stdout

evaluates to a different result than

eval exec $cmd 2>@ stdout

? Do you mean ...?

While I have trouble parsing, "I'm fairly new to tcl/tk so please don't
be too hard on me", perhaps it bears on your question: in telling you
I don't understand, I'm trying to make your life *easier*, rather than
more difficult. My assumption is that answers are more likely to
satisfy you when they're supplied by people who understand the
questions.

I think he's wondering why

eval exec $cmd 2>/dev/null 1>/dev/null

does not work, while

eval exec $cmd 2>@ stdout

does.

@Tim:

As it was already pointed out, exec does not recognizes '1>filename' as
stdout redirection, so it passed it as argument to the command. The
command actually executed might then look like this:

mencoder -oac mp3lame -ovc lavc 1>/dev/null

Note that this line does *not* go through a shell, so mencoder gets
'1>/dev/null' as an argument!


I don't understand why it works the way it does.

On my first tries every time exec finished that error window popped up
which had the stdout of mencoder in it, as seen here:
http://img182.imageshack.us/img182/5041/screenshotapplikationsfqv2.png

Now you're redirecting stderr directly to stdout and no window pops up, no
nothing. I *guess* that's because I didn't know that 1>/dev/null was used
as a parameter but shouldn't mencoder just have died because of
wrong/unknown parameters instead of completing its work, causing the
interpreter to pop up error windows with stdout in it?

Well, I obviously managed to confuse myself with it :-/


To redirect sdout with exec, you must use '>filename', so the correct
syntax would be:

eval exec $cmd 2>/dev/null >/dev/null

Just an example to clarify the point:

% exec echo foobar 1>/dev/null
foobar 1>/dev/null
% exec echo foobar >/dev/null
%

Remains to clarify if you *really* want the output of your commands to
be redirected to /dev/null, but that has already been pointed out by
others...



That was actually a try to get rid of stdout and stderr so that error
window would go away. I CAN redirect them to files now, but I think that
that would be a bit overkill for such a small program. I can use catch to
see if the command succeeded and let the user choose if he wants too see
stderr or stdout but I don't necessarily want to save it in temporary
files. Is there any way I can redirect stdout and stderr it so that it can
be stored in a variable?

The manual says that exec returns stdout if it finished without errors (or
the errors are redirected somewhere else) and that works. Except that
mencoder's output is that much that it's just gibberish in a normal
tk_messagebox. Guess I'll have to make my own window for it.

But what about stderr?
If exec fails it returns stdout followed by stderr and shows it in this
error window. Is there ANY way to prevent this window from opening? It's
nasty because if mencoder is used then it doesn't help at all, since
mencoder's stdout is so ridiculously long. If I could somehow redirect it
into a variable then I could also put it into my own window, just showing
the relevant parts (read: the actual error) which would probably prevent
everyone from being confused about the window's content. The screenshot
above is a good example, and you may have noticed that it is WAY higher
than my desktop. About 4 times as high. And it was a 32 seconds-video.

Thank you for your patience with me...
.

Relevant Pages

  • Re: redirect output to both stdout and file
    ... | output to both stdout and a file, ... This is the documented behaviour of 'exec': ... puts [exec ls | tee tmp.log] ... or redirect the output to stdout: ...
    (comp.lang.tcl)
  • IO redirection
    ... I need to redirect the results of exec. ... $stdout.reopen(file), and I can redefine $stdout to anything with a ...
    (comp.lang.ruby)
  • Re: How do i Run programs
    ... *.exe program and also how to put inputs in it ... try.exe and save all the stdout into a file ... exec*() functions ...
    (comp.lang.c)
  • Re: Backgrounding a stream, and sendmail?
    ... >> just redirect the output to a file instead of sendmail.) ... > shell command like ... when prog_b has it's stdout redirected nothing ... > is done instead of printing to stdout you could start sendmail from within ...
    (comp.os.linux.development.apps)
  • Re: yet another fork issue (I think)
    ... If you're calling forkprior to an exec function, the simplest thing is to avoid using stdout in the child (this only applies to the original child process image, since the buffer disappears with the exec). ...
    (comp.unix.programmer)