From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,8a0999bfe89e1b4f X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2002-11-27 10:10:50 PST Message-ID: <3DE50998.9050809@cogeco.ca> From: "Warren W. Gay VE3WWG" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: Call to execvp in Rational Ada References: <1b585154.0211270841.3ae227e0@posting.google.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Date: Wed, 27 Nov 2002 13:06:16 -0500 NNTP-Posting-Host: 198.96.47.195 X-Complaints-To: abuse@sympatico.ca X-Trace: news20.bellglobal.com 1038420376 198.96.47.195 (Wed, 27 Nov 2002 13:06:16 EST) NNTP-Posting-Date: Wed, 27 Nov 2002 13:06:16 EST Organization: Bell Sympatico Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!logbridge.uoregon.edu!snoopy.risq.qc.ca!torn!webster!nf1.bellglobal.com!nf2.bellglobal.com!news20.bellglobal.com.POSTED!not-for-mail Xref: archiver1.google.com comp.lang.ada:31266 Date: 2002-11-27T13:06:16-05:00 List-Id: See comments, peppered about below.. Peter Richtmyer wrote: > I want to use Rational's "execvp". The following > is my test code. test results are listed at the end. > Anybody know what I am doing wrong? Or have an example > of doing it right that I can look at? > > Thanks, > Peter > ------------------------------------------- > with system; > with Ada.Exceptions; > use Ada.Exceptions; > with Unix_Operations; -- in rational.rss > use Unix_Operations; > with Unix_Types; -- also > use Unix_Types; > with text_io; > use text_io; > > procedure artest is > status : int := 0; > > nul : constant Character := Character'Val (0); > > command : String := "ls" & nul; > > argvnul : string := "" & nul; > argv0 : string := "-la" & nul; > > type argv_array_t is array (0 .. 19) of system.address; > pragma pack (argv_array_t); > for argv_array_t'size use 20 * 32; > > argv_array : argv_array_t := ( > 0 => argv0'address, > others => system.null_address); > begin > text_io.put_line ("calling execvp"); > > status := execvp (File => To_Char_Ptr(command'address), > Argv => To_Char_Ptr_Ptr(argv_array'address)); > > text_io.put_line ("back fm execvp, status = " & int'image(status)); > > exception > when E: others => > put_line ("artest exception: " & Exception_Name (E)); > > end artest; > ------------------------------------------- > -- TEST RESULTS > -- > -- using: "ls" and argv0 of "-la", > -- get: list of files, but not with the "-la" option info > -- and then it just stops (does not return to Ada) This makes perfect sense, because argv[0] is supposed to be the command's name ("ls"), and argv[1] is the first command line argument to ls ("-la"). But here, you have lied about the command name (this is permitted), but you have not supplied a argument 1. This causes the command to run as simply "ls". > -- using: "ls" and first arg is a null string (argvnul), > -- get: list of files, > -- and then it just stops (does not return to Ada) From the UNIX command line (shell) prompt, this should be equivalent to entering: "ls ''". Try it -- you should be able to duplicate the same results. > > -- using: "ls" and all null_address for argv's, > -- get: it just stops after calling execvp, no list of files This is bad, because C programs normally expect something to be in argv[0] (usually the command name). The behavior of this may vary with commands and/or platforms. > -- using: "ls" and Argv => To_Char_Ptr_Ptr(system.null_address)); > -- get: status = -1 I don't think this is valid for the system call. You should check errno and see what it reported to you. As to why each of these are hanging on you, I cannot answer. The binding to invoke the system call may be playing a role, but I would have thought that after the exec call had been successfully performed, it would have no further influence (but note that there may be influeces like whether or not the "Close on Exec" flag is set on open file descriptors etc.) To trouble shoot the hang, I would also look at any environmental issues (variable settings, file descriptors that were open when the call is made etc.) If you have access to the binding source code, see what the execvp() call is doing. My approach would be to bind to the execvp() call myself directly (bypassing your binding) and see if you don't run into the same problems. That might narrow down how much you have to debug (i.e. is it binding related or OS related?) -- Warren W. Gay VE3WWG http://home.cogeco.ca/~ve3wwg