home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / sys / atari / st / tech / 4214 < prev    next >
Encoding:
Text File  |  1992-07-31  |  2.5 KB  |  51 lines

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