Apostrophe in argv

[Guido Flohr <gufl0000@stud.uni-sb.de>]

On Sun, May 17, 1998 at 12:49:26PM +1200, Mario Becroft wrote:
> On Sat, 16 May 1998, Petr Stehlik wrote:
> 
> > The code in crtinit.c for extracting the argv from the environment
> > doesn't handle quoted filenames correctly. Modern desktops (Thing,
> > Gemini) use ' for filenames that containing special characters, e.g. a
> > blank. If you doubleclick the file <i:\with blank> it would be send as
> > 'i:\with blank' to the program.
> > The code in crtinit.c (PL46, PL47) split this name into two args:
> >     argv[1] = 'i:\with
> >     argv[2] = blank'

Looks correct!

> > 
> > I've implemented a simple parser that looks for ' in the cmdline. It
> > create a correct argv:
> >     argv[1] = i:\with blank

This looks bogus.

> I don't know whether I'm missing somthing obvious here, but surely this
> could get very confusing. Wouldn't mean that all the software, including
> the command-line tools, would respond to quoted filenames? And since this
> has never been the case before, wouldn't it cause some existing things
> that use the ' character in the command line to function incorrectly?

I think Mario is absolutely right.  The above patch would corrupt the
argument vector and would render the MiNTLib unportable because
you could not build programs any longer that rely on a correct 
argument vector.  Remember that the argument vector may not always
completely consist of pathnames but of any kind of data.  Furthermore
even for a pathname it is perfectly alright to contain apostrophes.

Not the MiNTLib has to be patched but the above mentioned modern
desktops.  This `filename quoting' stuff is simply a bad idea
which should be abandoned.  As far as I can see it the story
behind it is that the AES functions shel_* don't build a 
standard argument vector (a null-terminated array of null-
terminated strings).  But if the AES doesn't support spaces
in arguments you can't pass spaces in arguments (and you
you cannot use that `space in filename' feature).

My proposal:

Forget about filename quoting.  Use a mechanism similar to 
special characters in mail headers:

1. Any argument that begins with "-\177" marks the beginning
   of an encoded filename (replace `\177' with ASCII 127).
2. An arbitrary number of spaces (including zero space)
   may be inserted between the reserved option and the
   encoded filename.
3. The filename is encoded either in base64 or quoted-printable
   according to RFC 2047 (non-US-ASCII characters in mail
   headers) with the exception that `atarist' is an allowed
   codeset (download both RFC 2045 and RFC 2047 for further
   information).

Disadvantage:  Instead of abusing the apostrophe we abuse
ASCII 127.  But ASCII 127 (in the Atari charset that's the
little triangle) is a much better choice than the apostrophe.

Advantages:  
- Not the libc but the client programmer gives
  the special character a special meaning.  Since no space 
  can occur in the encoded filename a filename argument will
  always fit in one single member of the argument vector.

- Furthermore we are really fit for the future.  Future filesystems
  may allow multi-byte characters in filenames.  This mechanism
  could handle it.

- What's the story behind `blanks in filenames'?  It is actually
  intended to give the user the possibility to choose a descriptive
  text as a name.  If the client programmer decides that the
  exact filename is not important you may transport such filenames
  across architectures (with different codeset conventions) without
  losing the significance of such descriptive filenames.

- As far as I understood the `filename quoting' it is still error
  prone for subsequent occurencies of space in a filename.  Such
  errors would not happen with base64 or quoted-printable.

Petr, if you're still not convinced, try to build grep or sed
with your patch and then search for the apostrophes in this
mail. ;-)

Ciao

Guido
-- 
http://stud.uni-sb.de/~gufl0000
mailto:gufl0000@stud.uni-sb.de