I am having this script to find a file and select it
set filePath to ("filePath.ext" as POSIX file)
tell application "Finder"
if (exists filePath) then
select filePath
activate
else
display alert "File " & filePath & " does not exist"
end if
end tell
it is working perfect well on Mac os x 10.6.x (LION) but when I try to run this script on Mac os x 10.5.x (snow-leopard) it is selecting file but taking too much time. Any suggestion how can I make this code work fine on both versions of Mac.
Thanks in advance :)
EDIT:
I am selecting file from a network drive and hostel system is having a Windows Os. All systems are located in the same network.
The reveal command may be of assistance to you. It simply locates a file in the finder, opens a new window if necessary, and then selects the file—all that using just one line of code:
tell application "Finder" to reveal path:to:some:file
The file must actually exist for this to work, of course. You know a particular file/directory exists when it is presented in alias form (I.e. Macintosh HD:Users:billybob:Desktop:howToHack.pdf). Attempting to coerce a nonexistent file into an alias will result in an error. If you are 100% certain that the file exists and know exactly where it is, congratulations! You have one less thing to worry about. If your certainty level is anything less than 100%, use a try-catch block. They have saved my life on multiple occasions. That way, if you distribute your applications via the Internet like I do, your clients are not presented with undecipherable error messages.
An example of this is demonstrated below:
set theFile to "/Users/billybob/Desktop/folder/subfolder/subfolder2/subfolder3/fineByMe.mp3"
try
set theFile to (theFile) as alias
tell application "Finder" to reveal theFile
on error
display alert "The file " & quoted form of theFile & "does not exist."
-- The variable 'theFile' couldn't be coerced into an alias.
-- Therefore, 'theFile' still has a string value and it can be used in dialogs/alerts among other things.
end try
Is this more efficient or less time consuming than what you've written? I'm not particularly sure, to be honest. However, I have written many scripts that have included the reveal command on Mac OS X 10.5.8 (Leopard), Mac OS X 10.6.8 (Snow-Leopard), and Mac OS X 10.7.3 (Lion), and the results have been satisfying.
You have errors in your code.
You forgot a period after "exists" in the display alert line.
You cannot display a posix file. It must be converted to string. Apple doesn't have this optimization.
The exists command will always return false the way you've used it because you didn't provide a full file path. Although java and c++ allow abbreviated file paths, apple does not.
I cannot comment, so I was forced to put this as an answer instead.
Related
I have several Windows sourced p-files internally coded with the '\' file separator that I want to run on Matlab under macOS.
I get errors caused by the '\' because macOS uses '/'.
eg The pfile tries to call a file named "model\xyz' which causes a warning:
"Name is nonexistent or not a directory: model\ "
1) Is there code that I might insert somewhere to recognise the 'model\' call from the pcode file and change it to 'model/' before it is used by MATLAB addpath?
2) Is there a generic fix I could apply to the addpath code?
3) Or better still is there a way to modify the Windows p-file without access to its source code so that it will run under macOS?
There are several things you can do (none of which are particularly easy; listed here in increasing order of how nasty I think they are):
Contact the author of the code and ask them to fix it.
Install an older MATLAB version (R2007b <= ver < R2015b, I think) which allowed debugging (stepping into) p-files within MATLAB, then, assuming that there is some line in the original source code that does
filepath = ['model' '\' 'xyz.m'];
step until you see filepath appear in the workspace (having the wrong path in it), then simply edit the value to the correct path, and hope for the best.
(Essentially the same idea as before, but on newer MATLAB versions, VERY DIFFICULT to pull off) Obtain an external debugger, attach to the MATLAB process, run the p-file and scan the memory for the contents of filepath. When you discover it, change the value to the correct path and detach/disable the debugger.
If this code relies on some external (and open source) function to get (or use) the path, you can modify its behavior to output the string you want. This requires some knowledge about the source code.
Find/make a tool for decoding p-files and fix the resulting source code yourself.
For completeness I describe how my problem was solved:
As suggested by Dev-iL I was eventually able to locate the author and he modified his code. This is the best solution but it took some time and is not always possible.
Based on: https://au.mathworks.com/matlabcentral/answers/117110-dealing-with-and-windows-vs-unix-for-path-definition I located a module (I've forgotten its name) within the Matlab package which handles file calls and intercepted all incoming file path names containing the '\' Windows separator, and replaced them with the always acceptable '/'. This quick and dirty fix worked until solution 1. was obtained.
Thanks to all who responded so quickly to this question.
I'm not used to c or c++ or AHK. My problem is the following:
There exists a tool called "TI Helper", which is composed of 1 EXE and several text files. This EXE enables you to press "CTR+SPACE" in TM1 application, which will popup a (right-click kind of menu) based on the text files...
I opened the EXE with notepad and we can see the code...
Can i simply re-use or modify this code? WHat should i keep in mind?
This has nothing to do with C, C++ or assembly and you have neither decompiled, nor can you recompile the executable.
TIHelper is an open source AHK (autohotkey scripting language) file. As a script file, it is not compiled into unreadable machine gibberish, but instead interpreted in it's human readable form.
You are free to make changes to that AHK file and run with those changes.
Link to the source code archive of TIHelper
First of all - will any exe file modifications violate or comply software licensing terms?
If it is allowed, you should know the format of exe file, better if assembler language too.
Generally, modifying data segment in exe file (e.g. 13 characters "File created" to "Result is OK" - watching that total number of exe file bytes will not change) could eventually result only in changes in displayed text.
Modifying binary code (code segment of exe file) requires understading what "mov ax,60" is, what could it cause and could give expected result ONLY if machine (assembler) code is fully understood.
I'm trying to convert a program from S5 to S7. I've taken a look into the tutorials and documents that are available. But I cant seem to find any information about this problem:
The program is pretty complicated and I should need the XR.INI file to convert it with the S5 Converter program that came with Simatic S7. When I open the folder with the project I see all the files I need and that are described in the tutorial made by Siemens.
.ST.S5D
.XR.INI
.Z0.SEQ
I start the converter and open .ST.S5D. When I did this I get the error there is no .XR.INI file. But I can see it in the folder. Its called CERMST.INI. So I guess the name isnt correct?
In PG2000 I remade the XRF with CTRL Q but nothing changed. I also tried to rename the file to CERM.XR.INI because I saw somewhere these files can only be 6 characters long (not sure if this is true).
I tried first without the XRF. There were some errors because of the ASM command. In the tutorial I saw the converter cant handle these so I removed these functions from the program to rewrite manually later on. After this I had an error because I had no XRF. Error was:
Error No PLC type description found for called or addressed block
So I really need the .XR.INI file but the program can't find it, but its clearly in the folder. How can I fix this? How can I make a new .INI file?
Link to tutorial: http://www.sankotek.com/TR/Dokumanlar/STEP%207%20-%20From%20S5%20to%20S7.pdf
Thanks in advance!
Siemens S5 file extensions used also last two letters before file extension to mark file type, like xxxxxxXX.XXX where x is file name and X is file type for S5, without second dot in the middle like you have. File name length limit exists, I think it comes from DOS or some older operating system file length limit.
If you don't have XRF file then if i remember correctly compiler does not have compile order. Some blocks have not been compiled but are referenced in caller block that the compiler tries to compile. Compiler does not find called block in compiled blocks folder and wham... fatal error. When i had such troubles i compiled called blocks independenly before calling blocks. So you can do without XRF file. But try to include Z0.SEQ, that file has assignment list so you get nice variable names instead of just variable address numbers.
Also, stackoverflow is not the correct place to ask questions about Siemens S5-S7 conversion. You should post your questions in http://www.plctalk.net, they have guys there who used to program S5 plc-s.
In solaris when open call to char special device file is made in user space, the driver's open call is called with only two parameters. 1. major and minor number and 2. flag that contains read/write etc.. Is there any way to the get the name of the opened device file in driver's open call. or Is there any way to get the name of the device file from major and minor number in driver code?
I doubt the OS has any way to retrieve the name of the device file. Actually, this file name is not enforced by the OS and can be any name created with the mknod command. The only things that matter are the major and minor device numbers.
You can go through the lists of entries in /dev or /devices and compare the numbers. But of course in general, the special file could have been created anywhere in the filesystem.
But you shouldn't try doing this. Which problem are you trying to solve by this?
I have a program on a Windows XP computer on another continent. If I start it by double-clicking on an associated file, so that it runs the program according to the file-type association, it crashes at a certain point. If I start it by dragging an associated file to the program icon, it works fine. If I double-click on the icon and drag the associated file to the window, it works fine.
The guy on site assures me that he's triple-checked the file-type association, and it should be correct.
Assuming that the icon points to the same executable as the registry, what differences would there be in starting the program in these two different ways?
EDIT: In response to a comment, the machine I'm having problems on is running in Japanese, while my normal machine is US English.
One possible difference is the initial working directory: if you drag a file onto the executable, the initial working directory is set to the directory containing the executable, whereas if you double click the file, the initial working directory is set to some default value independent of where the file or executable is located.
If you want to get consistent behavior in all cases, you can use SetCurrentDirectory() to set the current working directory to whatever you want; I recommend the directory containing the executable, which can be found by calling GetModuleFileName(NULL, ...) and stripping off the executable name, or by examining argv[0] inside main().
When you double click the file, the program is run, and (usually) the name of the file that you double click, is passed in to the program as a command line argument.
When you are dragging onto the window, the program is already running.
The difference is obviously in the startup process that the program has. Is this software written in-house? Perhaps check how it handles starting up, and make sure that all appropriate code paths are still executed when there is a file in the command line arguments.
If you can't check the program code, or how it behaves at startup, about the only thing to check in the registry, and possibly change, is how the filename is passed in. Usually they are passed in inside talking marks, so that the path to the file can have spaces and not confuse the program. Something to try would be to make sure the association uses talking marks on the argument, or if it already does, try it without. Perhaps the program isn't handling the talking marks correctly.