The filePro path variables... STOP the presses!

[john at timescape.com]

OH my God!!!   After all that, about 10 minutes after I sent out that "I'm baffled" note, the person I was helping called to tell me that he had made the little 5 line batch file we were testing finally WORK!!!

It turns out there was a lot of cockpit error.  There some times when I would have him make a small change and he would run the file, but probably NOT saving the change first.  He had two windows open, and this turned out to be highly likely.  

However, more importantly, when he read some of the values I was "echo-ing" in the batch file to see if they were set properly, he read them sometimes without saying a SPACE when there was one where it shouldn't be.

For example when I had him read the following:

Echo %PFDATA%%PFDIR%
Pause

He would read the PFDATA value and then the PFDIR value without commenting that there *was* a SPACE between them.

This, of course would be incorrect, so how could a SPACE have gotten in there????  It turns out that in Windows  (apparently) when you set the value of a variable, and you leave a SPACE trailing the entered value before you press RETURN - that variable actually contains* that SPACE or however many you let trail before ending the assignment with a RETURN!

This does not happen on *nix. What's more you can enter a vlue that does have intervening white space, or trailing white space by surrounding everything with quotes.  On windows the quotes *become* part of the value you are entering!!!  This was all really baffling to me.  So, we made absolutely certain that each of the path variable in the tiny batch script had no trailing white space by immediately pressing RETURN as in:

Set pfdata=H:<RETURN>

Instead of a possible:

Set pfdata=H: <RETURN>


This way, when the pfdata var and the pfdir var are catted together to get the full path to the filepPro data folders, there would be NO thoroughly unwanted SPACES in that path.  

Aargh!  I'm sorry I burdened you all before I learned these small gotcha's.  like I say in linix, you can do:

Set pfdata=/u/appl     <RETURN>

And the value contained in $pfdata will start with / and end with l, no matter how many SPACES hang out after the assignment and the RETURN is encountered, or you can do:

Set pfdata="/u/appl"     <RETURN>

And this absolutely guarantees there will be no such troubles.

I can't imagine that there would ever be a need to assign a value like "value    " and have it stick that way as the actual contents of any variable, but of course one never knows, do one? ... Besides, batch language and its shell environment have been around for 40 plus years, and you would think they might have addressed this if the current behavior was not actually "desired".  Who knows...

Now, I do, at least.

Live and learn...

So, much apologies for the desperate, long winded message, but when you *know* something *should* work, and it continues not to....  it's difficult to not seek help.

/john

P.S.  But thanks to any of you who even gave this puzzler any thought, and there is a sort of primer on the 4 filePro path vars, which might help someone.  ��

If others  enjoyed the World Lament video, there is another much older video available through the youtube Search field by entering the following:

Hanging By A thread by John Esak

Lots more coming this summer, 7 more previously unreleased song/videos... assuming the crick don't rise...


(I hope this message is formatted correctly, it switched out of TEXT mode to HTML at the last moment that I pressed SEND.  I will fix it for any further messages.