Sigh, It Must Be Me

Panorama X
1

Suspicion confirmed. PanX does not want to get along with me. It must be me.

As I understand it, the two macros below should be identical.

FARCALL "Various Macros", «myOpenFile»,
    "~/Data/Financial/Checkbooks/Compass Bank", "NOT"

and

FARCALL "Various Macros", «myOpenFile»,
  "Macintosh HD/Users/vicdifranco/Data/Financial/Checkbooks/Compass Bank", "NOT"

The first macro works as intended.

The second one fails with the message "The file could not be opened because there is no such file.

Needless to say, both macros work with Pan6.

Vic

2

It is not always Panorama X. Sometimes it is macOS and its file system. Read the chapter about Files and Folders in the Pan X Help.

Here is a paragraph that might explain what you are seeing:

Expert Tip: In previous versions of Panorama, since Folder IDs were opaque binary values they could not be created manually, only with special functions. In the current version of Panorama, Folder IDs are no longer opaque binary values. Instead, they are simply standard, fully qualified paths. Fully qualified means that the path must be absolute (starting with /) and contain the complete path of the folder. Note: A Folder ID must not end with the / character.)

Here are some examples of valid Folder IDs:

/Users/steve/Documents
/Volumes/BigFatDisk/Programming/Perl
3

Hello KJM,

I’m not sure I follow your point. Is there something wrong with my second example? The path and file name are exactly as my OS requires. That exact path works perfectly in Pan6.

By the way, the first command in the FARCALL subroutine is

openfile parameter(1)

In PanX, it makes no difference if I start the path as “/Macintosh HD/ (etc.)” or as “Macintosh HD/ (etc.)”. PanX does not like the full path name, starting with the root name. You must start the path with “~”, and pick up the remaining folders as necessary or it will fail. What could be happening?

4

Unix file paths do not begin with the volume name. A full path will begin with a slash, and then the name of the first folder. In this case it would be

/Users/vicdifranco/Data/Financial/Checkbooks/Compass Bank

I find this really surprising. I wouldn’t expect Panorama 6 to work with either one of those paths.

5

If you want to use the entire path to the file in Panorama X you have to then include Volumes:

"/Volumes/Macintosh HD/Users/vicdifranco/Data/Financial/Checkbooks/Compass Bank"

So in your example path these three variations would indicate the same path using Pan X:

"~/Data/Financial/Checkbooks/Compass Bank"
"/Users/vicdifranco/Data/Financial/Checkbooks/Compass Bank"
"/Volumes/Macintosh HD/Users/vicdifranco/Data/Financial/Checkbooks/Compass Bank"

Another change from Pan 6 to conform to modern Apple code.

6

I can assure you, Dave. The second of my macro examples works flawlessly in Pan6. In Pan6, though, I used a colon as a folder separator, while apparently, PanX prefers a “/” separator. I wonder if PanX would object to a colon separator? I will try this out.

Thank you, Dave and Gary, for your usual informative responses.

Regards,
Vic

7

That explains it then. I found it surprising that Panorama 6 would accept a slash as the separator.

There are places where Panorama X will accept the old style colon separated paths, but without knowing what your procedure is actually doing, I won’t try to guess whether this is one of them.

8

Pretty much anywhere you want to type a file path in Panorama X, you can do it by dragging the file from the Finder onto the procedure window, or formula pane where you want to type that path, and Panorama will write the path for you. Here, I did it in the formula pane of an image display object.

12%20PM
Screen Shot 2018-10-13 at 2.13.12 PM.png1311×697 457 KB

9

Wow, that is cool, Dave. And it properly omits the lead “Macintosh HD” from the path.

10

The difference in these two macros is in the third parameter, which is a parameter passed to the subroutine. As far as FARCALL is concerned

"~/Data/Financial/Checkbooks/Compass Bank"

and

"Macintosh HD/Users/vicdifranco/Data/Financial/Checkbooks/Compass Bank"

are just two different text values, the FARCALL statement doesn’t care what is in the text.

So the question is, what does your subroutine actually DO with this text. Unfortunately, you haven’t given us any clue.

These text values look sort of like file paths, but normally, as Dave correctly pointed out, neither of these would work as file paths in Panorama 6. Panorama 6 does not understand the leading ~ syntax for file paths at all. Also, Panorama 6 doesn’t understand the use of slashes for file paths. Since you say these do work, you must be passing this text outside of Panorama, perhaps to an AppleScript, a shell script or perhaps shellopendocument. But I can say for sure you aren’t using this with openfile, fileload( or other Panorama 6 statements and functions that access files.

If you have access to the Panorama Intensive Training course, there is a video that covers file access.

Quick recap - this path is NOT valid in Panorama 6, but is ok in Panorama X (also valid in shell scripts, etc) –

"~/Data/Financial/Checkbooks/Compass Bank"

This path IS VALID in both Panorama 6 and X (but won’t work in shell scripts, which don’t understand colons) –

"Macintosh HD:Users:vicdifranco/Data:Financial:Checkbooks:Compass Bank"

This path is NOT VALID in Panorama 6 or X (or shell scripts). In a UNIX path, the volume name is only specified for external drives, not the boot drive (I am assuming Macintosh HD is your boot drive).

"Macintosh HD/Users/vicdifranco/Data/Financial/Checkbooks/Compass Bank"

This path IS VALID in Panorama X (but not Panorama 6), and will also work in shell scripts.

"/Users/vicdifranco/Data/Financial/Checkbooks/Compass Bank"

If you want to use the old format, DON’T CHANGE THE COLONS TO SLASHES! If you leave everything alone, Panorama X will understand it. But if you change the colons to slashes, you must use the modern UNIX format, not the old HFS (OS 9) format.

11

True, but you could still use the “/Volumes/Macintosh HD/…” with the boot drive and it will be recognized. I just tried this with fileinfo( for a file on my boot drive and it worked the same as the preferred method (even though there would never be a need to use this longer alternative). Totally useless info to be sure.:zipper_mouth_face:

12

Hello Jim,

An early command in the FARCALL subroutine is

openfile parameter(1)

which is why the first parameter of the FARCALL command must be a legal path and name. It is why my macro gave me the “file does not exist” message.

When I ported the Pan6 main macro over to PanX, I noticed that your PanX examples in Help always used “/” instead of colons. So, using my superior powers of prescient reasoning, I edited the FARCALL command to change all colons to slashes. After all, what could possibly go wrong? I thought the change was cosmetic rather than substantive.

But the programming Gods are subtle and devious. They demand impeccable logic, which is not a universal human trait.

At any rate, Gary and Dave have explained the nuances of Unix path protocols, and now everything is working well. It might be a good idea, Jim, to include a short explanation of this in the Help files, to avoid another non-programmer running into the same problem when he ports Pan6 macros into PanX. You could even use Gary’s clear explanation above, after removing references to me of course, in full. Or, just repeat your quote above in the Help file.

Regards,
Vic

13

See the page in the help system entitled Files and Folders.

14

Hello CooperT,

I did read that entry, and just re-read it.

The entry is of course correct in what it says. But although the section titled “HFS Paths” says that with HFS format, the drive name is ALWAYS required, it does not indicate that the drive name should absolutely NOT be used for Unix paths, unless you begin the path with /Volumes.

That is the missing subtlety. No big deal, but a few words right there would have saved a lot of trouble.

Towards the middle of the Help page, Jim gives some examples of paths that are NOT valid. That would be an excellent place to add a fourth non-valid entry.

Regards,
Vic

15

Hi Vic, you may suggest revisions or corrections to help pages if you wish. I think users have made hundreds of improvements to them. tom

16

I think the Files and Folders documentation is correct and complete as is.

That section is examples of invalid folder id’s, not paths. There is a lot of crossover, but those are not the same thing. Those examples are paths that are valid paths, but not valid as folder id’s. So I don’t agree that this is a good place to add this.

At the top of the page, the File Paths and Secondary Disk Drives explains how drives are handled in paths. It’s all spelled out.

Please keep in mind that UNIX file paths are not a Panorama feature – they are the way file paths are handled by ALL UNIX systems. The rules for file paths are the same for ANY program on the system, not just Panorama. So anyone that has used file paths in any other program will instantly be familiar with how file paths work in Panorama.

HFS file paths are used by NO other program on the system, other than ancient “Carbon” programs like Panorama 6. They are a relic of the Mac’s pre-NEXT history.

When creating Panorama X, the easiest thing to do would have been to just say “sorry, HFS is an ancient relic, so you’ll just have to rewrite any program that uses it to switch to the modern UNIX system.” But I didn’t do that – instead, I went to a lot of extra trouble to write the code so that either HFS or UNIX can be used, you can even mix them in a single procedure.

The choice of : or / is not cosmetic, this is two completely different systems for identifying file location. You can’t just swap one for the other.

In this case, you’d probably have been best off just to leave your code alone – leave it in HFS format with colons. I went to extra trouble so that you wouldn’t have to touch your code. Panorama does not prefer slashes to colons, you can use either HFS or UNIX format, it’s your choice. A new users that has never used Panorama 6 is going to prefer UNIX format, because that is what they are used to in all other programs. I certainly was not about to force new users to use an obsolete format. But if you wish to use HFS format, that is completely fine, and there are no plans for this to be removed in a future version of Panorama.

Technical note: Internally, OS X/macOS only understands UNIX format, so in a way that is the “native” format on modern systems. If you use HFS format, Panorama internally changes it to UNIX format before handing it over to the operating system. But this translation is straightforward, and all this is completely invisible to you as a Panorama programmer.