exec fails but re-directed stdout and stdlog is empty
in [TCL]
|
Prev: Ffidl and ShellExecuteEx
Next: Frequent Wiki problems
From: jemptymethod on 7 Aug 2010 12:31 On Aug 7, 9:52 am, Robert Heller <hel...(a)deepsoft.com> wrote: > At Sat, 7 Aug 2010 04:31:49 -0700 (PDT) jemptymethod <jemptymet...(a)gmail.com> wrote: > > > > > I'm trying to execute a shell command with exec and redirect stderr > > and stdout to a file as follows: > > > exec $cmd >& [file join $root_home log exec.log] > > What is cmd set to? If it is a full command line, the above won't work > at all. Eg this will fail to work: > > set cmd "gcc -c foo.c" > exec $cmd >& [file join $root_home log exec.log] > > But this will work: > > set cmd [list gcc -c foo.c] > eval exec $cmd >& [file join $root_home log exec.log] The above did the trick, in conjunction with Pat's suggestion from the starkit group that I first copy my tclkit cli and gui executables out of the vfs and onto the OS' file system proper. Without wrapping the segments of the command with a list and then using eval/exec I noticed the following behavior during debugging: I could log the $cmd string to a file but when I tried to exec it, the slashes within the file names were getting reversed, and actually the first one, after "C:" was being deleted altogether. Are these the sorts of thing that eval/exec/list obviates? Just trying to deepen my understanding. Many thanks!
From: Robert Heller on 7 Aug 2010 13:36 At Sat, 7 Aug 2010 09:31:10 -0700 (PDT) jemptymethod <jemptymethod(a)gmail.com> wrote: > > On Aug 7, 9:52=A0am, Robert Heller <hel...(a)deepsoft.com> wrote: > > At Sat, 7 Aug 2010 04:31:49 -0700 (PDT) jemptymethod <jemptymet...(a)gmail.= > com> wrote: > > > > > > > > > I'm trying to execute a shell command with exec and redirect stderr > > > and stdout to a file as follows: > > > > > exec $cmd >& [file join $root_home log exec.log] > > > > What is cmd set to? =A0If it is a full command line, the above won't work > > at all. =A0Eg this will fail to work: > > > > set cmd "gcc -c foo.c" > > exec $cmd >& [file join $root_home log exec.log] > > > > But this will work: > > > > set cmd [list gcc -c foo.c] > > eval exec $cmd >& [file join $root_home log exec.log] > > The above did the trick, in conjunction with Pat's suggestion from the > starkit group that I first copy my tclkit cli and gui executables out > of the vfs and onto the OS' file system proper. > > Without wrapping the segments of the command with a list and then > using eval/exec I noticed the following behavior during debugging: I > could log the $cmd string to a file but when I tried to exec it, the > slashes within the file names were getting reversed, and actually the > first one, after "C:" was being deleted altogether. Are these the > sorts of thing that eval/exec/list obviates? YES! You have to understand that exec takes a bunch of 'words' as arguments: [From 'man n exec':] SYNOPSIS exec ?switches? arg ?arg ...? _________________________________________________________________ DESCRIPTION This command treats its arguments as the specification of one or more subprocesses to execute. The arguments take the form of a standard shell pipeline where each arg becomes one word of a command, and each distinct command becomes a subprocess. It does NOT take a 'command line string' as an argument. This is (appearently) a common newbie mistake/misunderstanding. Esp. MS-Windows users. UNIX people seem to understand this, since this is pretty much how sh/bash/csh/tcsh/ksh/exec() all work. Actually, command.com and cmd.exe work this way too, but few MS-Windows are really as familar with command.com/cmd.exe as UNIX people are with sh/bash/csh/tcsh/ksh. When you do something like: exec "C:\foo.exe /switch1 file1" exec (under MS-Windows) tries to execute a program named: "C:foo.exe \switch1 file1" That is the program named 'switch1 file1' in the directory 'foo.exe ' on drive C:. This is (obviously!) not what you want. What you really want to do is: exec {C:\foo.exe} /switch1 file1 (OR exec C:/foo.exe /switch1 file1 ) which passes to exec three 'words': the path to the executable (C:\foo.exe), and two 'parameter' words: /switch1 and file1. If you need to assemble the "command line" programmatically, you want to use list and/or lappend: set cmd [list {C:\foo.exe}] if {$needswitch} {lappend cmd {/switch1} lappend cmd [file nativename $somefiletoprocess] Then use eval (or the Tcl 8.5+ '*' syntax): eval exec $cmd >& [file join $logfiledir mylogfile.log] > > Just trying to deepen my understanding. Many thanks! > -- Robert Heller -- 978-544-6933 Deepwoods Software -- Download the Model Railroad System http://www.deepsoft.com/ -- Binaries for Linux and MS-Windows heller(a)deepsoft.com -- http://www.deepsoft.com/ModelRailroadSystem/
From: jemptymethod on 7 Aug 2010 14:59
On Aug 7, 1:36 pm, Robert Heller <hel...(a)deepsoft.com> wrote: > At Sat, 7 Aug 2010 09:31:10 -0700 (PDT) jemptymethod <jemptymet...(a)gmail.com> wrote: > > > On Aug 7, 9:52=A0am, Robert Heller <hel...(a)deepsoft.com> wrote: > > > At Sat, 7 Aug 2010 04:31:49 -0700 (PDT) jemptymethod <jemptymet...(a)gmail.= > > com> wrote: > > > > > I'm trying to execute a shell command with exec and redirect stderr > > > > and stdout to a file as follows: > > > > > exec $cmd >& [file join $root_home log exec.log] > > > > What is cmd set to? =A0If it is a full command line, the above won't work > > > at all. =A0Eg this will fail to work: > > > > set cmd "gcc -c foo.c" > > > exec $cmd >& [file join $root_home log exec.log] > > > > But this will work: > > > > set cmd [list gcc -c foo.c] > > > eval exec $cmd >& [file join $root_home log exec.log] > > > The above did the trick, in conjunction with Pat's suggestion from the > > starkit group that I first copy my tclkit cli and gui executables out > > of the vfs and onto the OS' file system proper. > > > Without wrapping the segments of the command with a list and then > > using eval/exec I noticed the following behavior during debugging: I > > could log the $cmd string to a file but when I tried to exec it, the > > slashes within the file names were getting reversed, and actually the > > first one, after "C:" was being deleted altogether. Are these the > > sorts of thing that eval/exec/list obviates? > > YES! > > You have to understand that exec takes a bunch of 'words' as arguments: > > [From 'man n exec':] > > SNIP Thanks again! Between RTFM and standing on the shoulders of giants, I hope to create some awesome software! |