RE: [stellation-res] Database location specifier

["Jonathan Gossage" <jgossage@xxxxxxxx>]

> At 08:19 AM 4/20/2003, Jonathan Gossage wrote:
>
>
> > > -----Original Message-----
> > > From: stellation-res-admin@xxxxxxxxxxxxxxx
> > > [mailto:stellation-res-admin@xxxxxxxxxxxxxxx]On Behalf Of Jim Wright -
> > > IBM Research
> > > Sent: Saturday, April 19, 2003 1:52 PM
> > > To: stellation-res@xxxxxxxxxxxxxxx
> > > Cc: stellation
> > > Subject: Re: [stellation-res] Database location specifier
> > >
> > >
> > > Jonathan,
> > >
> > > Based on a quick Google search:
> > >
> > > Windows filename characters:
> > > Legal: A-Z 0-9 $#&@!()-{}'`_~ and the space
> > > Illegal: |<>\^+=?/[]";,* plus control characters
> > >
> > > Linux:
> > > Characters often recognized as metacharacters by Linux shells:
> > >
> > > * ? [ ] " ' ` \ $ ; & ( ) | ^ < > newline space tab
> > >
> > > So -- taking the intersection of both sets (more or less):
> > > | <> \ ^ ? [] " ; *
> > >
> > > Checking the man page for bash (Bourne-Again shell)
> > > yields the following:
> > > 1. "Enclosing characters between single quotes preserves
> > > the literal value of each character within the quotes."
> > > 2. "Enclosing characters between double quotes preserves
> > > the literal value of each character within the quotes, with
> > > the exception of $ (dollar sign) ` (backtick) and \
> > > (backslash)."
> > >
> > > Since single quote is a legal Windows filename character,
> > > I propose:
> > > a) Use ; (semicolon) as the delimiter within a database locator.
> > > b) Double-quote the entire locator to force command-line processors
> > > to process the locator as a single entity.
> > > Thus:
> > > "This;is a complete;locator;in five;parts."
> > >
> > > Thoughts?
> > >
> > > - Jim
> > >
> >This would work for FAT32 volumes but NTFS is more liberal. The only
> >reserved characters are < > : " / \ | and the control characters. The
> >semi-colon is a legal file name character for NTFS.
>
> How about '|' (vertical bar, pipe, binary OR, etc.) ?
> This appears to be illegal as a filename character on all systems we're
> likely to
> care about (famous last words....)
>
> >I am also reluctant to
> >require special quoting rules over and above those that are normal for a
> >shell. Quoting would also mean additional parsing code in Stellation.
>
> Quoting is required with filenames that include spaces, on both
> Windows and
> Linux.
> While it does require some extra parsing, handling double quotes isn't a
> lot of work
> (but of course, another place for bugs to creep in...).
>
> You had previously suggested:
> >2. Continue with the current support using the '+' as the location
> >separator. This would have the limitation  that any Windows
> based Firebird
> >database could not have a '+' character in it's path.
>
> That also seems like a reasonable solution (least-impact for our coding,
> certainly).
> The restriction re: database names seems unlikely to cause problems.
>
> Anyone else?  Barring other comment, I'd vote to keep using '+'
> with the caveat
> about database names stated clearly in the docs.
>
> Regards,
>
> Jim
>
>
If no else objects, I will vote for this solution also.

Regards

Jonathan