Portion of pathway interpreted as a spcial charcter

[Partenheimer]

I have a routine that runs at startup (via an MNL file) which defines a source folder housing our in-house lisp routines. For previous releases the configuration worked as expected. For 2019, I modified the pathway and added a "2019" folder into the pathway.

Old :

(setq g:lispdir "K:\\WORKSPACES\\BU\\LDBU\\PSR\\+Lisps\\")

New:

(setq g:lispdir "K:\\WORSPACES\\BU\\LDBU\\PSR\\2019\\+Lisps\\")

Now the routines located in the +Lisps folder do not run.

In the command line the error displayed as < LOAD failed: "K\\WORKSPACES\\BU\\LDBU\\PSR9\\+Lisps\\name of routine" >

But I noticed...

Here is the same error message after cutting it from my command line and pasting it in Outlook. Note the special character in the middle of the path that only became visible after the paste into Outlook.

It almost appears to me that \\PSR\\2019 is being interpreted as \\PSRspecial character 9, where \\201 defines the special character.

I then changed all of the double backslashes to single forward slashes to test that theory but got the exact same error result.

Again, this configuration worked for previous releases and only stopped working when I added the 2019 folder into the pathway.

Does anyone have any insight as to what's happening?

Any thoughts would be appreciated.

Regards,

Michael Partenheimer

[SeeMSixty7]

First recommendation is don't uses special chars in path names. (+) is  special char. Not related to your problem, but just a suggestion.

Second, if you are having a problem like that I would recommend making sure you are using an actual text editor to update your lisp file, and not something that can allow you to place special chars(hidden) into a string.

I would try copying form below. ( I retyped it) see if that helps.

(setq g:lispdir "K:\\WORKSPACES\\BU\\LDBU\\PSR\\2019\\+Lisps\\")

Good luck,

[Partenheimer]

Thanks @SeeMSixty7 

I used Notepad to create the setq line.

Regards,

Michael Partenheimer

[SeeMSixty7]

It seems a bit odd.

Try dragging and dropping a lisp routine from that folder into an empty drawing. Watch the command line and see what path it returns there. Maybe you can copy and paste that path in and see what happens.

Is the path on the trusted path in your options as well?

Good luck,

[Partenheimer]

I actually found a work-around.

My MNL file called a file named Tri3D.lsp to run. Tri3D.lsp contained the setq line.

I cut and pasted the setq line from Tri3D.lsp into my MNL immediately following the Tri3D.lsp call and it works successfully, just like my pre-2019 folder versions.

It's odd. Something is substituting a piece of the pathway when run from the Tri3D.lsp, I just can't figure what or where. ...or why moving the line to the MNL matters or how it changes anything.

 Regards,

Michael Partenheimer

[SeeMSixty7]

attach the tri3d.lsp file and lets take a look at it.

[Partenheimer]

Adding the setq line to my MNL solved my problem so I'm good to go.

But I am really curious as to why the addition of a 2019 folder to the path triggered this as a problem that had to be solved.

I've attached the Tri3D.lsp.

The setq line is near the end of the file.

Thanks.