Programming for Separator Character in File Paths between platforms

[dhakkan 3]

Hello,

 

I'm experimenting with porting my existing LabVIEW application from Windows to Mac OS X. The code uses several instances of 'Build Path' function in 'File I/O' functions sub-palette. The 'Name or Relative Path' input is being connected with a 'string' data type rather than a 'file path' data type. With some quick code change and checks, I've realized that it's better to use the latter data type, so that the separator character '\' in Windows is automatically interpreted as ':' in Mac OS.

 

Some parts of the code, however, build up the string. E.g. a 'Format Into String' is used to output based on a format string, e.g. 'Images\%s.jpg'. Doing a 'String to Path' after this function does not automatically interpret the '\' in Mac OS to ':'. (I can imagine that it would be difficult for the compiler to recognize that a specific character is meant to be a separator and not part of a file/folder name.)

 

I can write more complicated code where the format string is itself concatenated based on the execution platform. Are there any easier or recommended approaches? Also, does LabVIEW have any 'File Constant' that provides the equivalent string character depending on the platform?

 

Thank you.

 

[ShaunR 855]

Hello,

 

I'm experimenting with porting my existing LabVIEW application from Windows to Mac OS X. The code uses several instances of 'Build Path' function in 'File I/O' functions sub-palette. The 'Name or Relative Path' input is being connected with a 'string' data type rather than a 'file path' data type. With some quick code change and checks, I've realized that it's better to use the latter data type, so that the separator character '\' in Windows is automatically interpreted as ':' in Mac OS.

 

Some parts of the code, however, build up the string. E.g. a 'Format Into String' is used to output based on a format string, e.g. 'Images\%s.jpg'. Doing a 'String to Path' after this function does not automatically interpret the '\' in Mac OS to ':'. (I can imagine that it would be difficult for the compiler to recognize that a specific character is meant to be a separator and not part of a file/folder name.)

 

I can write more complicated code where the format string is itself concatenated based on the execution platform. Are there any easier or recommended approaches? Also, does LabVIEW have any 'File Constant' that provides the equivalent string character depending on the platform?

 

Thank you.

 

There are two VIs in "vi.lib\Advanced String\"

• Path To Command Line String.vi
• Command Line String To Path.vi

These take in to account the platform separator when converting to and from strings and paths. Use those instead of the palette primitives.

Edited December 28, 2015 by ShaunR

[candidus 30]

Also, does LabVIEW have any 'File Constant' that provides the equivalent string character depending on the platform?

 

Not exactly a constant but a VI that returns the path separator:

 

vi.lib/Utility/sysinfo.llb/Get File System Separator.vi

 

Edited December 28, 2015 by candidus

[dhakkan 3]

At the outset, my apologies for the delay in acknowledging your responses - a holiday trip and getting under the weather did not help...

 

 

 

Not exactly a constant but a VI that returns the path separator:

 

vi.lib/Utility/sysinfo.llb/Get File System Separator.vi

 

 

 

Thanks! that helps. A clever way to get the separator, though!

 

There are two VIs in "vi.lib\Advanced String\"

• Path To Command Line String.vi
• Command Line String To Path.vi

These take in to account the platform separator when converting to and from strings and paths. Use those instead of the palette primitives.

 

Am confused by 'Command Line String To Path.vi'. Under the wrapper it seems to call the native 'String to Path' function except for a Mac OS 32-bit application. In this exception case, not-a-path constant is returned. That doesn't seem to help solve my problem.

 

Now, I'm using the solution candidus provided to build the necessary relative path.

 

Thanks! folks, for your help; and a very Happy New Year to one and all.

[ShaunR 855]

At the outset, my apologies for the delay in acknowledging your responses - a holiday trip and getting under the weather did not help...

 

 

Thanks! that helps. A clever way to get the separator, though!

 

 

Am confused by 'Command Line String To Path.vi'. Under the wrapper it seems to call the native 'String to Path' function except for a Mac OS 32-bit application. In this exception case, not-a-path constant is returned. That doesn't seem to help solve my problem.

 

Now, I'm using the solution candidus provided to build the necessary relative path.

 

Thanks! folks, for your help; and a very Happy New Year to one and all.

 

The VI "UNIXPathStringToPath" is an unused placeholder on windows. It is replaced with a platform specific implementation when loaded on Mac.

[Phillip Brooks 193]

http://themacview.blogspot.com/2014_08_01_archive.html

 

 

LabVIEW 2014, First 64-bit Version for Mac POSIX Paths

This was long overdue. Paths in 32-bit are formatted in HFS Classic format. 64-bit uses the more common POSIX paths. It's mostly showing slash (/) instead of colon ( between path elements (although there is more to it than that). 

 

There is also a little bit of magic that happens in 64-bit when a path in a string is converted to a path type that allows either format, and then converts it into POSIX style. You can try this by copying the path from the 32-bit path indicator and paste it into the 64-bit indicator. Once focus leaves the indicator, the path will be converted to POSIX format (it's pretty fun to watch).

 

This magic also happens when using the String to Path primitive. You can have a string of either format and it will convert it to a POSIX path. This makes it easier to transition between 32-bit and 64-bit as you are testing your VIs in 64-bit.

Some other VIs that assist in dealing with paths between 32-bit and 64-bit are Path to Command Line String.vi and Command Line String To Path.vi inProgramming -> String -> Path/Array/String Conversion palette. These VIs are helpful in building a path that can be used in System Exec.vi or system shared libraries in a cross-platform manner. They have actually existed in LabVIEW since before 2009, but are added to the palettes now to assist in transitioning between 32-bit and 64-bit on Mac.

 

Another path related VI that is helpful for Mac users is Executable Path To Command Line String.vi. This VI helps in getting the path to the executable in an app.

This is particularly helpful writing cross platform code that will launch LabVIEW built apps, LabVIEW itself, or other GUI applications. Windows and Linux just take the path to the EXE. On Mac, the .app is really just a folder. This VI will give you a path to the executable you can call from System Exec.vi, in a cross-platform way. This VI did not make the cut for the palettes, but you can find it in vi.lib/AdvancedString.