home *** CD-ROM | disk | FTP | other *** search
- Newsgroups: comp.sys.atari.st.tech
- Path: sparky!uunet!mnemosyne.cs.du.edu!nyx!ilepore
- From: ilepore@nyx.cs.du.edu (Ian Lepore)
- Subject: Re: Problems with ARGV - summary of ideas posted so far
- Message-ID: <1992Jul31.183812.4425@mnemosyne.cs.du.edu>
- X-Disclaimer: Nyx is a public access Unix system run by the University
- of Denver for the Denver community. The University has neither
- control over nor responsibility for the opinions of users.
- Sender: usenet@mnemosyne.cs.du.edu (netnews admin account)
- Organization: Nyx, Public Access Unix at U. of Denver Math/CS dept.
- References: <1992Jul29.130755.27902@mks.com> <1992Jul29.221225.24054@mnemosyne.cs.du.edu> <1992Jul30.171118.2682@its.bt.co.uk>
- Date: Fri, 31 Jul 92 18:38:12 GMT
- Lines: 36
-
- On the problem of passing empty/null arguments via ARGV, we've had so far:
-
- - Creating a new env var that indicates the position of the empty args.
- This is workable, but the drawbacks are extra complexity, and the need
- for yet another flag of some sort to validate this new variable so that
- it doesn't get misinterpreted when passed to children of the application
- it was intended for.
-
- - Using an escape character or sequence such as \1 to indicate an empty arg.
- This is workable, and very easy to implement. The drawback is that it
- may confuse current applications that don't expect \1 chars in args.
-
- - Various schemes that involve \0\0 sequences in the ARGV part of the
- environment. These won't work because GEMDOS won't copy the data
- following the \0\0 when it creates the env data for the child process.
-
- - Use a single space to indicate and empty arg. This is especially easy
- to implement, but locks out the possibility of ever passing a single
- space as a valid arg. It could be extended to add an extra space to
- any arg that ends in a space now, but then on the receiving end these
- have to be filtered out again, so it gets a bit complicated.
-
- So which one do we use? I'd like a relatively quick answer, so that it
- can be added to HSC 1.40 before its impending release in a week or two.
- I'm still kind of partial to the escape character, I think. (Not surprising
- since I suggested it, huh?) Perhaps we could choose a different escape
- char, one that wouldn't be as likely to confuse an unaware program? We
- could use an existing whitespace char, \t \r or \n as the escape char that
- means an empty arg. (I'd vote for \n, I think, it has a certain "nothing
- here" implication to it.)
-
-
- --
- - Ian
- (void *) where prohibited by law
-
-