\: In filepath breaks shell commands my LiveCode app
Moderators: FourthWorld, heatherlaine, Klaus, kevinmiller, robinmiller
-
- Posts: 57
- Joined: Sat Feb 01, 2014 8:57 pm
\: In filepath breaks shell commands my LiveCode app
HI,
I’m not exactly sure what is going on here - I’m somewhat stymied by my lack of vocabulary/knowledge when it comes to command line stuff, but I’ll try. I’m doing this on a Mac.
I have a LiveCode project that accepts files via drag and drop. It process these files using some command line tools provided with an application called Hugin. When it gets to a certain point in the process, it stops under a certain condition. That condition is if a folder in the path has a "/" character in it.
So, a folder that is named "Folder 30/1/2016" is interpreted as being "Folder 30\:1\:2016" which mirrors how it’s displayed if I drag and drop it into Terminal.
The process runs like this:
User drags/drops a JPG image file onto a LiveCode window
ExifTool runs and grabs data from the file (this works)
A .pto file is made by pto_gen (this works)
A .mk file is made by pto2mk (this works)
The .mk file os processed by make - and this is where it falls over as I get a "No rule to make target '/path/to/Folder 30\:1\:2016'" error.
If there is NO / character in the folder, everything runs perfectly, and a processed TIFF is created by make.
Now, in the mk file there are various references to the folder where the JPG file is. Some look like this: /path/to/Folder 30\:1:\2016 and others look like this: /path/to/Folder 30\:1\:2016 - I have tried converting all instances of 30:1:2016 to 30\:1\:2016 in the .mk file. I have tried all the names as 30:1:2016, and still the same problem occurs.
So I’m stymied. I’ve exhausted all I can think of here. It is clearly something to do with the / character in the folder name, and its conversion to \: and : in various guises. However, it seems that even my own manual editing of the .mk file is not the solution. Is there a way to get this to work? This is probably a Mac only issue as I’ve not tested this in Windows.
As a note - I have to use make on the Mac. Hugin for the Mac has not been updated to include huginexecutor which would streamline the Mac side of the application, and will probably remove this problem.
I’m not exactly sure what is going on here - I’m somewhat stymied by my lack of vocabulary/knowledge when it comes to command line stuff, but I’ll try. I’m doing this on a Mac.
I have a LiveCode project that accepts files via drag and drop. It process these files using some command line tools provided with an application called Hugin. When it gets to a certain point in the process, it stops under a certain condition. That condition is if a folder in the path has a "/" character in it.
So, a folder that is named "Folder 30/1/2016" is interpreted as being "Folder 30\:1\:2016" which mirrors how it’s displayed if I drag and drop it into Terminal.
The process runs like this:
User drags/drops a JPG image file onto a LiveCode window
ExifTool runs and grabs data from the file (this works)
A .pto file is made by pto_gen (this works)
A .mk file is made by pto2mk (this works)
The .mk file os processed by make - and this is where it falls over as I get a "No rule to make target '/path/to/Folder 30\:1\:2016'" error.
If there is NO / character in the folder, everything runs perfectly, and a processed TIFF is created by make.
Now, in the mk file there are various references to the folder where the JPG file is. Some look like this: /path/to/Folder 30\:1:\2016 and others look like this: /path/to/Folder 30\:1\:2016 - I have tried converting all instances of 30:1:2016 to 30\:1\:2016 in the .mk file. I have tried all the names as 30:1:2016, and still the same problem occurs.
So I’m stymied. I’ve exhausted all I can think of here. It is clearly something to do with the / character in the folder name, and its conversion to \: and : in various guises. However, it seems that even my own manual editing of the .mk file is not the solution. Is there a way to get this to work? This is probably a Mac only issue as I’ve not tested this in Windows.
As a note - I have to use make on the Mac. Hugin for the Mac has not been updated to include huginexecutor which would streamline the Mac side of the application, and will probably remove this problem.
-
- Posts: 57
- Joined: Sat Feb 01, 2014 8:57 pm
Re: \: In filepath breaks shell commands my LiveCode app
Answering my own question here. It’s actually a problem documented in Hugin’s PaoTools Wiki.
So, basically, the user has to put their files in a folder that doesn’t contain a : or a / as Mac OSX converts the / to \:
OK, so now I know.
http://wiki.panotools.org/Hugin_FAQ#gnu ... ake_targetgnumake: *** No rule to make target
This is a message generated by w:Make_(software) (which Hugin uses to manage the stitching sequence). The error is caused by a : or # character in one of the file paths. The workaround is to rename to remove any 'special' shell characters and try again.
So, basically, the user has to put their files in a folder that doesn’t contain a : or a / as Mac OSX converts the / to \:
OK, so now I know.
Re: \: In filepath breaks shell commands my LiveCode app
Since Mac OS is based on UNIX, the SLASH is the system pathdelimiter (just like in Livecode,
which is also UNIX based!) and will always be "escaped" by the system.
Until Mac OS 9 the path delimiter had been colon -> :
As a rule of thumb you should stick to lowercase***, 0-9, a-Z and maybe a couple of "harmless"
characters like dot, underscore etc. for naming files and folders!
***Which also eliminates eventual troubles on case sensitive filesystems like iOS and Android!
which is also UNIX based!) and will always be "escaped" by the system.
Until Mac OS 9 the path delimiter had been colon -> :
As a rule of thumb you should stick to lowercase***, 0-9, a-Z and maybe a couple of "harmless"
characters like dot, underscore etc. for naming files and folders!
***Which also eliminates eventual troubles on case sensitive filesystems like iOS and Android!
-
- VIP Livecode Opensource Backer
- Posts: 10057
- Joined: Sat Apr 08, 2006 7:05 am
- Contact:
Re: \: In filepath breaks shell commands my LiveCode app
LiveCode should be able to handle any file path the OS can handle. If hand-written it needs to be in Unix format, but if a character is allows in a file or folder name it should be supported in LC as well. After all, we can't run around telling our users to conform to mystifying conventions just for our apps.
Which version of LC are you using? Or more specifically, are you still seeing the same issue in the latest Stable version? Some work was done for file path handling some versions ago, so with any luck this may have already been addressed. And if not, it should be a simple matter to fix it once a bug report is filed if needed.
Which version of LC are you using? Or more specifically, are you still seeing the same issue in the latest Stable version? Some work was done for file path handling some versions ago, so with any luck this may have already been addressed. And if not, it should be a simple matter to fix it once a bug report is filed if needed.
Richard Gaskin
LiveCode development, training, and consulting services: Fourth World Systems
LiveCode Group on Facebook
LiveCode Group on LinkedIn
LiveCode development, training, and consulting services: Fourth World Systems
LiveCode Group on Facebook
LiveCode Group on LinkedIn
-
- Posts: 57
- Joined: Sat Feb 01, 2014 8:57 pm
Re: \: In filepath breaks shell commands my LiveCode app
As I said, it seems the fault is not with LiveCode, but with the UNIX tool Make, which does not like the # or : character in file paths. Mac OS X tuns any / character in a file name into \: - you can see this if you drag a file with that name in to Terminal.
Using LiveCode 7.
Using LiveCode 7.
-
- VIP Livecode Opensource Backer
- Posts: 10057
- Joined: Sat Apr 08, 2006 7:05 am
- Contact:
Re: \: In filepath breaks shell commands my LiveCode app
Are you saying Make works correctly when a folder is named "Folder 30/1/2016"?
If so, how does it distinguish the folder in a path like /Users/rg/dev/Folder 30/1/2016/somefile ?
If not, what format does Make work with?
If so, how does it distinguish the folder in a path like /Users/rg/dev/Folder 30/1/2016/somefile ?
If not, what format does Make work with?
Richard Gaskin
LiveCode development, training, and consulting services: Fourth World Systems
LiveCode Group on Facebook
LiveCode Group on LinkedIn
LiveCode development, training, and consulting services: Fourth World Systems
LiveCode Group on Facebook
LiveCode Group on LinkedIn
-
- Posts: 57
- Joined: Sat Feb 01, 2014 8:57 pm
Re: \: In filepath breaks shell commands my LiveCode app
No. I doubt that it will. The foldr's name is CONVERTED by the OS to Folder\ 30\:1\:2016FourthWorld wrote:Are you saying Make works correctly when a folder is named "Folder 30/1/2016"?
If so, how does it distinguish the folder in a path like /Users/rg/dev/Folder 30/1/2016/somefile ?
If not, what format does Make work with?
That is all the / characters in the folder's name become \: - and for added bonus, the space is escaped. The : characters kill Make. See the link I posted above.
If you have a Mac, try dragging a file in a folder named that way into Terminal to see how the OS (and LiveCode) what you'll get.
-
- VIP Livecode Opensource Backer
- Posts: 10057
- Joined: Sat Apr 08, 2006 7:05 am
- Contact:
Re: \: In filepath breaks shell commands my LiveCode app
Thanks for the clarification. All the talk of drag-and-drop had me thinking this might be related to LC's path translation in drag-and-drop, an area they'd fixed a bug in a couple versions ago and I was thinking perhaps you may have found a regression.
As for whether this is a bug in Make or a design flaw in HFS+ is an issue I'll leave for others to determine, but probably not Linus Torvalds because we know where he stands on that <g>:
http://www.cio.com/article/2868393/linu ... -ever.html
FWIW, how Terminal translates paths, how OS X views them natively, and how LC translates them may not always be the same thing. When in doubt you can use "answer file..." to see how LC formats a path. Either way, glad you got it sorted. If you can discuss your project it would be interesting to learn more about it - panoramas?
As for whether this is a bug in Make or a design flaw in HFS+ is an issue I'll leave for others to determine, but probably not Linus Torvalds because we know where he stands on that <g>:
http://www.cio.com/article/2868393/linu ... -ever.html
FWIW, how Terminal translates paths, how OS X views them natively, and how LC translates them may not always be the same thing. When in doubt you can use "answer file..." to see how LC formats a path. Either way, glad you got it sorted. If you can discuss your project it would be interesting to learn more about it - panoramas?
Richard Gaskin
LiveCode development, training, and consulting services: Fourth World Systems
LiveCode Group on Facebook
LiveCode Group on LinkedIn
LiveCode development, training, and consulting services: Fourth World Systems
LiveCode Group on Facebook
LiveCode Group on LinkedIn
-
- Posts: 57
- Joined: Sat Feb 01, 2014 8:57 pm
Re: \: In filepath breaks shell commands my LiveCode app
Yes - panoramas. I have a Ricoh Theta which is a one button spherical camera. It's basically two fisheye lenses back to back. The camera does some clever stitching, so what you get is a rectilinear image. The camera knows which way up is, so it logs the pitch and roll in EXIF data. However, the camera does not level the image. Just simply rotating the image clockwise or anti-clockwise isn't appropriate here.FourthWorld wrote:Thanks for the clarification. All the talk of drag-and-drop had me thinking this might be related to LC's path translation in drag-and-drop, an area they'd fixed a bug in a couple versions ago and I was thinking perhaps you may have found a regression.
As for whether this is a bug in Make or a design flaw in HFS+ is an issue I'll leave for others to determine, but probably not Linus Torvalds because we know where he stands on that <g>:
http://www.cio.com/article/2868393/linu ... -ever.html
FWIW, how Terminal translates paths, how OS X views them natively, and how LC translates them may not always be the same thing. When in doubt you can use "answer file..." to see how LC formats a path. Either way, glad you got it sorted. If you can discuss your project it would be interesting to learn more about it - panoramas?
Ricoh's own software corrects for this, but it saves as a JPEG, so that's two levels of lossy compression before you get to start to work with it. Also, it will only work on one image at a time.
So I'm writing a small app in LiveCode which lets you drag and drop a file onto its window. It grabs the necessary EXIF data, rolls it into a a couple of files and tells Hugin to process it. The result is a TIFF file with a level horizon. Also, you can drag and drop more than one image onto the app and it will process them all as a batch. I'm trying to "user proof" it now so I can share with other Theta users. This problem stumped me for a bit today.
Anyway, I know what the problem is now, and that really I can't avoid it or correct for it. I'll need to drop in some warning messages so that the app doesn't just fail silently, and to inform the user of the problem.