mforget@nro.cs.athabascau.ca (Michel Forget) (05/08/91)
Does anyone know how to use the Pexec function so that it will take a command line longer than 80 charactes. I am writing a program that will require longer command lines, but I'm stumped on this one. The documentation that I have does not mention anything about command lines longer than 80 characters, yet they are possible... << ersys!mforget@nro.cs.athabascau.ca >> << or in the language that PEOPLE use >> << Michel Forget...:) >>
steve@thelake.mn.org (Steve Yelvington) (05/08/91)
[In article <LPmL22w164w@ersys.uucp>,
ersys!mforget@nro.cs.athabascau.ca (Michel Forget) writes ... ]
> Does anyone know how to use the Pexec function so that it will take a
> command line longer than 80 charactes. I am writing a program that will
> require longer command lines, but I'm stumped on this one. The
> documentation that I have does not mention anything about command lines
> longer than 80 characters, yet they are possible...
Command lines can be up to 125 characters long.
If you need to pass more information than that, there are three currently
used methods, of which one, XARG, is currently endorsed by Atari Corp. The
file EXARG.DOC in the Gemini distribution (see comp.binaries.atari.st)
will tell you all you need to know. There's some code in the samples
folder to show how it's done.
The Sozobon C compiler and dlibs support another method called ARGV.
See the dlibs sources.
Mark Williams Co. uses a third method with its C compiler, which, as has
been mentioned, is no longer being updated.
----
Steve Yelvington, Marine on St. Croix, Minnesota, USA / steve@thelake.mn.orgmforget@nro.cs.athabascau.ca (Michel Forget) (05/08/91)
steve@thelake.mn.org (Steve Yelvington) writes: > > Command lines can be up to 125 characters long. > > If you need to pass more information than that, there are three currently > used methods, of which one, XARG, is currently endorsed by Atari Corp. The > file EXARG.DOC in the Gemini distribution (see comp.binaries.atari.st) > will tell you all you need to know. There's some code in the samples > folder to show how it's done. Thanks for the information. I'll get the latest version of Gemini from atari.archives.umich.edu and see what happens. I am programming in Pascal, but C is close enough to convert back and forth. In the documentation I have, which doesn't seem to be too correct to begin with since the Pexec function they supply doesn't work at all, forces an 80 character limit on you. I'll see what the EXARG.DOC file says. Do I have to use Gemini to use the method of parameter passing? I use NeoDesk right now, and I'd like to keep using it. The last version of Gemini I saw was 1.1. Anyway, I'll take a look. Thanks. << ersys!mforget@nro.cs.athabascau.ca >> << or in the language that PEOPLE use >> << Michel Forget...:) >>
steve@thelake.mn.org (Steve Yelvington) (05/08/91)
[In article <mT3L24w164w@ersys.uucp>,
ersys!mforget@nro.cs.athabascau.ca (Michel Forget) writes ... ]
> character limit on you. I'll see what the EXARG.DOC file says. Do I
> have to use Gemini to use the method of parameter passing? I use NeoDesk
> right now, and I'd like to keep using it. The last version of Gemini I
> saw was 1.1. Anyway, I'll take a look. Thanks.
All that's necessary is that the parent process and the child process agree
on whatever extended argument-passing convention is in use.
If you're programming in Pascal, I suppose it should be easy enough to
code the parent's side of things, assuming the compiler allows you to have
access to the GEMdos calls. But the child's ability to parse the command
line may be another matter entirely. Can you modify the startup code? Or
is it hardwired into the compiler? This may be a good time to switch to a
less restrictive language. :-)
While we're on the subject:
Has anybody tried writing a replacement for Sozobon's dstart.o module that
supports XARG? And is it possible to support both XARG and ARGV?
----
Steve Yelvington, Marine on St. Croix, Minnesota, USA / steve@thelake.mn.orgmforget@nro.cs.athabascau.ca (Michel Forget) (05/09/91)
> All that's necessary is that the parent process and the child process agree > on whatever extended argument-passing convention is in use. Uh-oh. I am trying to pass long command lines to RZ.TTP (The Zmodem File Transfer Program) for batch Uploading and Downloading. The problem with the limit becomes obvious when you realize how few pathnames can be put on an 80 (or even 125) character command line. I wrote a program that will capture the command line when it is run and display it, and will try it on other programs that use SZ. I don't think that it supports the XARG convention you mentioned. Any other ideas? << ersys!mforget@nro.cs.athabascau.ca >> << or in the language that PEOPLE use >> << Michel Forget...:) >>
warwick@cs.uq.oz.au (Warwick Allison) (05/09/91)
>If you're programming in Pascal... >This may be a good time to switch to a less restrictive language. :-) On this subject, I have an xARG/ARGV/TOS Arguments module for Modula-2, maybe we should put these implementations together at the archive to help promote the use of these less restrictive argument passing techniques. Oh, and what would be the best order to try accessing arguments? I try xARG, then ARGV, the finally revert to TOS if all else fails. Ideas? >And is it possible to support both XARG and ARGV? Yes, depending on how restrictive your language is :-). Warwick. Frankly, I can't think of a language that COULDN'T do all this - but then, this isn't alt.religion.computers, so I doubt I'll be told! -- _-_|\ warwick@cs.uq.oz.au / * <-- Computer Science Department, \_.-._/ University of Queensland, v Brisbane, AUSTRALIA.
Roger.Sheppard@bbs.actrix.gen.nz (05/09/91)
> Uh-oh. I am trying to pass long command lines to RZ.TTP (The Zmodem File > Transfer Program) for batch Uploading and Downloading. The problem with > the limit becomes obvious when you realize how few pathnames can be put > on an 80 (or even 125) character command line. I wrote a program that > will capture the command line when it is run and display it, and will try > it on other programs that use SZ. I don't think that it supports the > XARG convention you mentioned. Any other ideas? > << ersys!mforget@nro.cs.athabascau.ca >> > << or in the language that PEOPLE use >> > << Michel Forget...:) >> I thought that the German GSZRZ18 supported XARG or ARCV. I am having the same problem with the Shells that support Zmodem, in the number of files that can be uploaded. The other problem that I have is SZ.TTP from ZMDM16, for some reason it drops down to Ymodem, is this caused by the delay in starting SZ.TTP ?. Is there a way around this ? -- Roger W. Sheppard 85 Donovan Rd, Kapiti New Zealand...
steve@thelake.mn.org (Steve Yelvington) (05/09/91)
[In article <eB2m23w164w@ersys.uucp>,
ersys!mforget@nro.cs.athabascau.ca (Michel Forget) writes ... ]
>> All that's necessary is that the parent process and the child process agree
>> on whatever extended argument-passing convention is in use.
>
> Uh-oh. I am trying to pass long command lines to RZ.TTP (The Zmodem File
> Transfer Program) for batch Uploading and Downloading. The problem with
> the limit becomes obvious when you realize how few pathnames can be put
> on an 80 (or even 125) character command line. I wrote a program that
> will capture the command line when it is run and display it, and will try
> it on other programs that use SZ. I don't think that it supports the
> XARG convention you mentioned. Any other ideas?
In that case you need to find out what compiler was used to make the RZ/SZ
programs. My guess would be Mark Williams, whose argument-passing scheme
is explained somewhat in the EXARG.DOC file. But that's just a guess.
If it's a correct guess:
Mark Williams passes arguments in the environment, so you need to know how
the environment is handled under GEMdos.
Remember that Pexec takes three arguments: An integer mode flag, a pointer
to a Pascal-style command string (first char of the string encodes its
length), and a pointer to the environment.
The environment is -- and somebody correct me please if I get this wrong
-- a sequence of C-style strings (simple arrays, terminated by a null
byte) with an extra null byte to terminate the environment itself. Each
entry in the environment is of the form
TAG=value
So, if 0 stands for a null byte, the environment might look like this:
PATH=A:\0USER=steve0ICECREAM=Chocolate00
If I read the MWC documentation correctly, it would pass arguments
by adding ARGV= to the environment followed by null-terminated
arguments. Example:
PATH=A:\0USER=steve0ICECREAM=Chocolate0ARGV=sz0file10file20file300
If there's no need for sz to know that the user is steve, the PATH is A:\
and the ice cream is Chocolate, I suppose you can leave that out. :-)
There are other things that can be encoded in the Mark Williams ARGV
string, but this is the basic idea.
----
Steve Yelvington, Marine on St. Croix, Minnesota, USA / steve@thelake.mn.orgrmacgreg@cs.strath.ac.uk (Sorcerer) (05/09/91)
In article <LPmL22w164w@ersys.uucp> ersys!mforget@nro.cs.athabascau.ca (Michel Forget) writes: >Does anyone know how to use the Pexec function so that it will take a >command line longer than 80 charactes. I am writing a program that will >require longer command lines, but I'm stumped on this one. The >documentation that I have does not mention anything about command lines >longer than 80 characters, yet they are possible... > > ><< ersys!mforget@nro.cs.athabascau.ca >> ><< or in the language that PEOPLE use >> ><< Michel Forget...:) >> There are 2 methods, Xarg and Exarg, which you use depends on how you feel, cos from what I can see they do the same job. I'll leave descriptions to the experts as I cannot remember how to do either of them. The Sorcerer is 'Only visiting this planet' but can be found at: JANET: cadx862 @uk.ac.strathclyde.computer-centre-sun rmacgreg@uk.ac.strathclyde.computer-science INTERNET: via nsfnet-relay.ac.uk BITNET: via ukacrl UUCP: via ukc.uucp or second star to the right and straight on 'till morning.
rcb@netcom.COM (Roy Bixler) (05/09/91)
In article <A3023378088@thelake.mn.org> steve@thelake.mn.org (Steve Yelvington) writes: >[In article <eB2m23w164w@ersys.uucp>, > ersys!mforget@nro.cs.athabascau.ca (Michel Forget) writes ... ] > > >> All that's necessary is that the parent process and the child process agree > >> on whatever extended argument-passing convention is in use. > > > > Uh-oh. I am trying to pass long command lines to RZ.TTP (The Zmodem File > > Transfer Program) for batch Uploading and Downloading. The problem with > > the limit becomes obvious when you realize how few pathnames can be put > > on an 80 (or even 125) character command line. I wrote a program that > > will capture the command line when it is run and display it, and will try > > it on other programs that use SZ. I don't think that it supports the > > XARG convention you mentioned. Any other ideas? > >In that case you need to find out what compiler was used to make the RZ/SZ >programs. My guess would be Mark Williams, whose argument-passing scheme >is explained somewhat in the EXARG.DOC file. But that's just a guess. Not correct. I compiled it with GNU C ver. 1.37. From what I've heard, it supports the extended argument passing scheme of Atari. > ---- > Steve Yelvington, Marine on St. Croix, Minnesota, USA / steve@thelake.mn.org -- Roy Bixler rcb@netcom.com -or- (UUCP) uunet!apple!netcom!rcb "Just when you think you know it all, it changes!"
mforget@nro.cs.athabascau.ca (Michel Forget) (05/10/91)
> I thought that the German GSZRZ18 supported XARG or ARCV. > > I am having the same problem with the Shells that support Zmodem, in > the number of files that can be uploaded. > > The other problem that I have is SZ.TTP from ZMDM16, for some reason it > drops down to Ymodem, is this caused by the delay in starting SZ.TTP ?. > Is there a way around this ? The shells that suppot Zmodem, namely Zflash, have problems with the command line as well. They try to send as many as thirty-two files along the command line, but the command line simply isn't big enough. Not very useful. I received a message from someone that contained a Shar archive, but I haven't been able to extract it since I don't know what a SHAR archive is...:) I'll keep looking and probably find the utility somewhere to extract it. At any rate, it explained the XARG parameter format. << ersys!mforget@nro.cs.athabascau.ca >> << or in the language that PEOPLE use >> << Michel Forget...:) >>
apratt@atari.UUCP (Allan Pratt) (05/10/91)
>[In article <LPmL22w164w@ersys.uucp>, > ersys!mforget@nro.cs.athabascau.ca (Michel Forget) writes ... ] >> Does anyone know how to use the Pexec function so that it will take a >> command line longer than 80 charactes. I am writing a program that will >> require longer command lines, but I'm stumped on this one. The >> documentation that I have does not mention anything about command lines >> longer than 80 characters, yet they are possible... steve@thelake.mn.org (Steve Yelvington) writes: >Command lines can be up to 125 characters long. >If you need to pass more information than that, there are three currently >used methods, of which one, XARG, is currently endorsed by Atari Corp. The >file EXARG.DOC in the Gemini distribution (see comp.binaries.atari.st) >will tell you all you need to know. There's some code in the samples >folder to show how it's done. >The Sozobon C compiler and dlibs support another method called ARGV. >See the dlibs sources. >Mark Williams Co. uses a third method with its C compiler [...] This is a badly confused accounting of the extended-argument stuff going around for TOS. ARGV and MWC's trick are nearly identical; ARGV is a superset which adds validation that the args in your environment are really intended for you. This is the method that's approved by Atari Corp. (at least by THIS part of Atari) and it's the method used by Bammi's GCC tools, Gulam (if you set env_style mw), and MiNT's shell, among others. XARG may or may not be endorsed by Atari Germany, but nobody here at Atari in Sunnyvale (to my knowledge) has endorsed it. The reason I hate it is that you have to poke through your parent's data space to find your arguments, and that is a no-no. It will be a much bigger no-no when memory protection and/or virtual memory come along. ARGV has no such problems. I don't know where the ARGV spec is -- I'll try to dig up a copy of it and post it again. ============================================ Opinions expressed above do not necessarily -- Allan Pratt, Atari Corp. reflect those of Atari Corp. or anyone else. ...ames!atari!apratt
ONM07@DMSWWU1A.BITNET (Julian F. Reschke) (05/10/91)
In article <LPmL22w164w@ersys.uucp>, ersys!mforget@nro.cs.athabascau.ca (Michel Forget) says: > >Does anyone know how to use the Pexec function so that it will take a >command line longer than 80 charactes. I am writing a program that will >require longer command lines, but I'm stumped on this one. The >documentation that I have does not mention anything about command lines >longer than 80 characters, yet they are possible... > > ><< ersys!mforget@nro.cs.athabascau.ca >> ><< or in the language that PEOPLE use >> ><< Michel Forget...:) >> The true limit for Pexec() is 124 characters. If you need more, should use the ARGV method, as documented by Atari and used in many *nix-like shells. ___________________________ cut here _____________________________________ Julian F. Reschke, Hensenstr. 142, D-4400 Muenster, Phone: ++49 251 861241 fast eMail: ONM07@DMSWWU1A.BITNET, slow: jr@ms.maus.de (++49 251 77216) ____________________ correct me if I'm wrong _____________________________
ONM07@DMSWWU1A.BITNET (Julian F. Reschke) (05/10/91)
In article <A1146492584@thelake.mn.org>, steve@thelake.mn.org (Steve Yelvington) says: >While we're on the subject: ...stuff deleted... > >Has anybody tried writing a replacement for Sozobon's dstart.o module that >supports XARG? And is it possible to support both XARG and ARGV? > > ---- > Steve Yelvington, Marine on St. Croix, Minnesota, USA / steve@thelake.mn.org This is no problem at all. Gemini and Mupfel are using both ARGV and xARGs when launching programs. ___________________________ cut here _____________________________________ Julian F. Reschke, Hensenstr. 142, D-4400 Muenster, Phone: ++49 251 861241 fast eMail: ONM07@DMSWWU1A.BITNET, slow: jr@ms.maus.de (++49 251 77216) ____________________ correct me if I'm wrong _____________________________
orc@vpnet.chi.il.us (david parsons) (05/11/91)
In article <A2876905127@thelake.mn.org> steve@thelake.mn.org (Steve Yelvington) writes: [about the Atari approved extended argument passing regime] |If you need to pass more information than that, there are three currently |used methods, of which one, XARG, is currently endorsed by Atari Corp. Umm, xArgs is the scheme that Dale Schumacher, John Stanley, and yours truely came up with a while back. The MWC/Official Atari scheme is called ARGV or somesuch, I think, unless it suffered from name drift. Anticipating a future article, here's a example of code from my C library runtime startup that will, if properly #defined, deal with either or both of the standards (I was forced to implement the MWC Xarg scheme because I've started using MiNT on my machine, and MiNT gleefully stomps all over the user-accessable genealogy of each process. o / >--------X--snip snip snip------- O \ /* * initargs(), for use with libc (xArgs and/or mwcArgs) */ #include <atari\osbind.h> #define MWCARGS 1 #define XARGS 0 extern int _argc; /* argc/argv as globals, for easy access */ extern char **_argv; extern char *strtok(); #if MWCARGS extern char *_getenv(); #endif #if XARGS #include <atari\xarg.h> extern BASEPAGE *_base; extern char *getenv(); char xArgname[] = "xArg"; /* xArg environment (ick!) flag */ #endif _initargs(tail, size) char *tail; { register char *p; register i; #if XARGS if (p=getenv(xArgname)) { register struct xArg *xarg; register totalsize; register long addr; register char **args; for (addr=i=0; p[i]; i++) if (p[i] >= '0' && p[i] <= '9') addr = (addr<<4L) + (p[i]-'0'); else if (p[i] >= 'A' && p[i] <= 'F') addr = (addr<<4L) + (p[i]-'A'+10); else goto hackline; #if 0 if (addr&01L) /* a little bit of address checking... */ goto hackline; #endif xarg = (struct xArg *)addr; if (xarg->_xmagic == XMAGIC && xarg->_xparent == _base->p_parent) { #ifdef CORRUPT /* Use our parents dataspace - real nasty, eh? */ _argc = xarg->_xargc; _argv = xarg->_xargv; #else /* * Malloc() a bit of memory for the arguments * to hide in... */ totalsize = (1+xarg->_xargc) * sizeof(char *); for (i=0; i<xarg->_xargc; i++) totalsize += 1+strlen(xarg->_xargv[i]); if ((_argv = (char **)Malloc((long)totalsize)) == 0L) _exit(-39); /* Out of memory - bye... */ _argc = xarg->_xargc; p = &_argv[1+xarg->_xargc]; for (args=xarg->_xargv, i=0; i<xarg->_xargc; i++) { strcpy(_argv[i] = p, *args); p += 1+strlen(*args++); } _argv[i] = 0L; return; #endif } } #endif #if MWCARGS /* reference Atari Corp's standard document for argument passing */ if ((size = 127) && (p = _getenv("ARGV"))) { /* mwc args here */ register char *mwargv; /* truncate the environment here by making the A in ARGV into * a null */ *p++ = 0; /* advance to the next argument */ while (*p++) ; /* everything from this point on is arglist */ mwargv = p; _argc = 0; /* always room for one null argument */ /* * scan the arglist in a particularly perverse way: using *p++ * to scan for nulls will always leave us on the character after * the null: if that character is also null, we've hit the * double-null that shows the end of the arglist. */ while (*p) { while (*p++) ; _argc++; } if (_argv = (char **)Malloc((long)((1+_argc)*sizeof(char*)))) { for (i=0, p=mwargv; *p; i++) { _argv[i] = p; while (*p++) ; } _argv[i] = (char*)0; return; } _exit(-39); /* out of memory - bye! */ } #endif hackline: { char *tmpargs[63]; /* 125 chars max in cmdline; 63 args... */ /*tail[size] = 0;*/ /* paranoia... */ for (i=1, p=strtok(tail, "\t "); p; p=strtok(0L, "\t ")) tmpargs[i++] = p; _argc = i; if ((_argv = (char **)Malloc((long)(1+i)*sizeof(char *))) == 0L) _exit(-39); /* Out of memory - bye... */ _argv[i] = (char*)0; while (--i > 0) _argv[i] = tmpargs[i]; _argv[0] = "(none)"; } } /* initargs */ o / >--------X--snip snip snip------- O \ Note that the routine _getenv() works just like getenv(), except it returns the start of the environment string (ie: given the environment string "EDITOR=vi", getenv("EDITOR") returns a pointer to "vi" and _getenv("EDITOR") returns a pointer to "EDITOR=vi". _getenv() is a internal routine to my libc, so you'll haveta poke around the guts of your libc to find the corresponding routine, if it exists. __ .david parsons \/
orc@vpnet.chi.il.us (david parsons) (05/11/91)
In article <1991May11.134908.29488@vpnet.chi.il.us> orc@vpnet.chi.il.us (me!) babbles about extended argument passing: . . . |#if MWCARGS | /* reference Atari Corp's standard document for argument passing | */ | if ((size = 127) && (p = _getenv("ARGV"))) { /* mwc args here */ ^ | This isn't what it should be. put a == in there and you'll defeat the evil initargs mangler. mumble.... __ .david parsons \/
ONM07@DMSWWU1A.BITNET (Julian F. Reschke) (05/13/91)
In article <2932@atari.UUCP>, apratt@atari.UUCP (Allan Pratt) says: >[stuff deleted] >XARG may or may not be endorsed by Atari Germany, but nobody here at Atari >in Sunnyvale (to my knowledge) has endorsed it. The reason I hate it is >that you have to poke through your parent's data space to find your >arguments, and that is a no-no. It will be a much bigger no-no when memory >protection and/or virtual memory come along. ARGV has no such problems. > >I don't know where the ARGV spec is -- I'll try to dig up a copy of it >and post it again. > >============================================ >Opinions expressed above do not necessarily -- Allan Pratt, Atari Corp. >reflect those of Atari Corp. or anyone else. ...ames!atari!apratt To clear up the confusion: (1) The only extended argument passing scheme ever supported by Atari Germany is the ARGV specification from Ken Badertscher. (2) Gemini 1.0 used Dale Schumachers xArgs methode, because at that time there was no other method. (3) Newer Gemini versions use ARGV (as documented by Atari Corp.). xArgs is maintained for backward compatibility with older tools. (4) The Gemini distribution contains the official ARGV documentation in sample\exarg.doc. This, I agree, should be 'ARGV.DOC'. Sigh! ___________________________ cut here _____________________________________ Julian F. Reschke, Hensenstr. 142, D-4400 Muenster, Phone: ++49 251 861241 fast eMail: ONM07@DMSWWU1A.BITNET, slow: jr@ms.maus.de (++49 251 77216) ____________________ correct me if I'm wrong _____________________________
steve@thelake.mn.org (Steve Yelvington) (05/14/91)
[In article <2932@atari.UUCP>,
apratt@atari.UUCP (Allan Pratt) writes ... ]
> steve@thelake.mn.org (Steve Yelvington) writes:
(omitted)
> This is a badly confused accounting of the extended-argument stuff going
> around for TOS. ARGV and MWC's trick are nearly identical; ARGV is a
Yup. I had XARG and ARGV reversed. Serves me right for playing with my
computer instead of getting enough sleep. :-)
Thanks for reposting the official description; it is the document
I was urging the original poster to obtain.
----
Steve Yelvington, Marine on St. Croix, Minnesota, USA / steve@thelake.mn.orgbammi@acae127.cadence.com (Jwahar R. Bammi) (05/16/91)
In article <TyVo23w164w@ersys.uucp> ersys!mforget@nro.cs.athabascau.ca (Michel Forget) writes: > The shells that suppot Zmodem, namely Zflash, have problems with the > command line as well. They try to send as many as thirty-two files along > the command line, but the command line simply isn't big enough. Not very this is a problem with the shell, not rz or sz in the zmdm distribution. they dont pass args using established conventions. recommended Xargs is not such a hot idea either in my opinion -- now that we have a (liviable) standard, lets use it and make things just that -- standard. -- -- bang: uunet!cadence!bammi jwahar r. bammi domain: bammi@cadence.com GEnie: J.Bammi CIS: 71515,155