How do you handle punctuation in path names

KimOllivier

The convention that you do not use spaces or other special characters in pathnames is long standing but flouted by Microsoft users.
Special characters are "legal" in many operating systems, but by convention are not used in unix, and could not be used in MS DOS.
Because Apple has a "fork" for file names (an alias) there was pressure on MS to allow file names to be full sentences in Windows 3.1.
Hence the "Program <space> Files" that broke all previous DOS code, and allowed ridiculous file names for Word documents.
I suppose it was to provide some rudimentary metadata functionality in the absence of full text searching and even the concept of metadata.

So we all know this and observe the convention, because if we don't, strange unrelated crashes regularly occur.
We kept ARC/INFO Workstation executables out of 'Program Files" and even Python avoids this path on Windows.

Databases have further restrictions for table names and field names, particularly not starting with a digit.
Starting with a digit will still cause crashes if you are using any GRID functions.
Using a source shapefile with paths containing spaces will fail in geoprocessing tools.

My problem now is to 'bullet-proof' models or tools that are intended to be distributed where the path names are no longer under control of the developer.

I have discovered one workaround to the input problem, use a list even if there is only one input. This seems to insulate the path.

lstFC = [r"E:\05 CCAMLR GIS\Circumpolar_shapefiles\Benthic_regionalisation_DelCano_Crozet_level2.shp"]

My second problem is the installation of the tool. The suggested template
A_structure_for_sharing_tools only works for me if the "toolshare" path is without punctuation or starting with a digit.

Do you have strange path names in your system?
How do you get the tools to work in this environment?

KimOllivier

The case I have found does not use an input featureclass. I am creating a featureclass from an interactive featureset. It seems that the 'relative' option on the tool properties does not handle unexpected root paths. Maybe the template needed for this datatype is not being parsed properly.

I try to make all my own 'home' calculations by parsing the location of the script using python functions.

home2 = os.path.dirname(os.path.dirname(sys.argv[0])).replace("\\","/")
domain = os.path.basename(home)
arcpy.AddWarning(domain)

basews = home+"/base.gdb"
scratchws = home+"/scratch.gdb"

Using a layer source only applies if you are running tools interactively and in process in ArcMap. I want to also run tools for debugging, and in ArcCatalog.

try:
    lay = arcpy.mapping.ListLayers(mxd,"Domain")[0]
    if lay.supports("DATASOURCE"):
        source = lay.dataSource
        home = os.path.dirname(os.path.dirname(source)).replace("\\","/")
except :
    if source:
        home = os.path.dirname(os.path.dirname(source)).replace("\\","/")
    else:
        arcpy.AddError("Domain layer missing in MXD, cannot find Domain location")
        sys.exit()

This lack of robustness for paths is a serious impediment to distribution of reliable tools and models.
I know that it is very hard for Esri to support relative paths when Microsoft only provides grudging support to be POSIX compliant.
It is a problem with COM or .NET or Python? It would be helpful to know to avoid and build reliable workarounds.