Can anyone explain to me, how applications usually communicate if one application has to send data to a second application. (an image for example). Or how can i find out how the communication is implemented?
In my example, i am trying to find out how "Capture One 11.x" is opening images with other applications (like photoshop or lightroom).
I was guessing, that "Capture One 11.x" will open images inside other applications by running the second application with additional start parameters (like the filepath of the opened image). But i can't find any evidence for this behaviour.
I am thankfull for any hint or help.
There are numerous ways applications can communicate with one another. Through temp files, pipes, sockets, etc.
Your specific question sounds like it boils down to "What is one way to have application A open file B in application C".
This is pretty easily achievable from the command line, for example, using the macOS command open with -a to choose the application.
open -a Adobe\ Photoshop file.jpg
or
open -a TextEdit file.txt
open -a MacVim file.txt
So, one very rudimentary way an application could open a file in another specific application would be to make a system call to macOS open.
Related
I have written a script that writes multiple file paths to stdout. (one path per line)
eg.
C:\Users\user\Documents\someFolder1\foo.txt
C:\Users\user\Documents\someFolder2\someSubFolder\bar.jpeg
C:\Users\user\Documents\someFolder3\baz.docx
Ideally I would like to pipe those file paths into Windows File Explorer so that non-technical users can interact with them in a familiar way. (previews, contexts menus, sorting, double-click to open, etc.) But really any file browser with a GUI and similar functionality would do.
I am also interested in ways to solve the same problem on Linux and macOS
I'm using OSXFuse
https://osxfuse.github.io/
And wanted to know if I can tell apart the following operations:
File is opened by the user
File is previewed in Finder
My problem is that for both cases readFileAtPath is called, and seemingly with the same parameters.
Apparently this cannot be done using the simple API, as read is read no matter who requests it.
But that's the point, if you could identify who requested to read, you could block it for some processes.
Using Fuse's C api, you could you fuse_get_context(), and get the pid, and from it get the process name. No need for more.
See my question at Fuse Google Group.
My university has quite a lot files (like past papers etc) which I need to be on the uni network to access them. I ssh, using port forwarding, into the network and set my browser (Firefox) to go through that port. I know it would be quite easy to write something in most languages that would enter the command into a terminal, but which language/method could I use to make this happen? I expect some sort of scripting language could but I really know nothing about them, but I'd be willing to learn one just to have a little fun with this.
I'm using a cygwin terminal on Windows 7, if that will make a difference.
To neaten up my question: Which language would be best to acheive the above effect? Not necessarily the best, just possible and relatively simple to learn. I used the word best so I suppose I'll put a subjective tag.
EDIT:
Just in case anyway wants to do this precise thing, I'll show my solution. I ended up using a batch file because a few things made the bash more difficult. Anyway, in order to SSH into the network and open a new firefox window with the proxy changed, I just have to open this batch file and enter my password.
cd C:/cygwin/bin
ssh -fND 9001 username#your.website.here
cd "C:/Program Files/Mozilla Firefox"
firefox -no-remote -P SSH_profile
Save as .bat
In order for this to work you need to set up a profile with name SSH_profile (or whatever) and set the connection settings to go through port 9001. The script will open use the ssh command in /cygwin/bin and enter in the information. You enter your password and then it goes to your firefox directory, uses those arguments which opens a separate profile with the connection settings changed (means you can view unaccessible files in one window and anything else you don't want to be on your uni network in another. Just close the windows when you are done.
Quite a specific case but I thought I'd share my answer in the hope of helping someone, some day.
Since you are using cygwin, write a bash shell script.. If you don't want to rely on bash, powershell would be what you want, although you could probably get it working using a batch file.
This is exactly the kind of thing shell scripting is for.
Edit
You can change the firefox settings on the command line by passing the -override flag. This will let you have special settings for the invoked process.
I am trying to copy C source files from a vms alpha to a windows machine to allow easier editing of the code. (VMS editor is just a text editor and it would be nice to have syntax highlighting etc)
I can copy this across using Exceed FTP and this handles the issue of duplicate filenames with version suffix that vms has:
File.c;1
File.c;2
Flle.c;3
But when I open a file I've transferred, all the line breaks have been lost and the entire file is just one line.
Can anyone recommend a solution to this or offer any hints?
Thanks in advance
ps. I need to be able to copy the files back to vms and still maintain format.
It may be off interest by now, but in case you still wonder about "one-line" text files after FTP transfer.
The short answer: force the FTP transfer mode to ASCII (or text) in your FTP client. This will make sure that the C-files you transferring (in fac all files) are treated as text, otherwise they're assumed to be binary, so you get a byte-stream.
Long answer: There're 2 FTP transfer modes: ASCII/text and binary/image. The default is sometimes clent or server-specific.
Many clients have Auto-mode that interprets the file extension to set the proper transfer mode (.TXT,.CSV etc..)
When you access the VMS server via FTP client, too often the [Win-based] client is not VMS friendy, so it does not parse the file-list properly. Thus it gets confused by version number appended to the "usual" file-name:
filename.ext;ver ==> file.c;1
So instead of seeing .C (and assuming text), it sees .C;1 and thinks it's binary.
I use Filezilla FTP client to/from VMS and so far it does it properly (though version-support is not as I'd sometimes like).
Copying a file to and from your windows desktop every time you want to edit gets old very quickly.
You may be able to implement a much nicer alternative. There is some software under VMS that permits a VMS directory tree to be treated as a "network disk" under windows. Once you've set it up, and set up your windows to recognize the network disk, you can just open the file with a windows text editor without moving it from VMS to windows. You can also browse the directory tree, which appears like a tree of folders.
When you issue a save from your text editor, the saved copy supercedes the previous version over in VMS land. And it mediates correctly between RMS format and embedded newline format. It's a whole lot more convenient than FTP, for this purpose.
After doing a quick Google search, I think the name of the VMS software is PATHWORKS. But I'm not sure.
A few points I have on this
PATHWORKS is fairly old and (as far as I recall - I dont use it) doesnt work well with recent windows versions, such as supporting Active Directory. Within the last few years HP have ported SAMBA to VMS and this is the way to go if you want to make areas of disk visible to windows machines. Should be easyt to find on HP web site.
If you want to try the FTP/SFTP route I would try SFTP and go for VMS version of at least 8.2. TheTCPIP suite was rewritten (or reported from a Unix version) at this point.
VMS supports a number of formats for text files. As well as the complex record structure described above, there is STREAM_LF which is the same as a unix file and STREAM_CRLF
I found some interesting information about OpenVMS text file structure. That corresponds with a vague memory I have of how VMS handles text files; they're not stored as streams of bytes like Windows and Unix systems, but as a sequence of records (each record is a text line). Records can be either fixed width or variable width. Whatever reads the file is responsible for the "paper control", what we normally call newlines these days.
You might check the options in Exceed FTP to make sure that you're transferring the file in an appropriate ASCII mode. There might be special options you need to set on the FTP server to read and write the files in the appropriate mode too.
I'm no expert - let's get that out and in the open ;)
I have been having similar problems in FTPing files from OVMS Alphaserver to Win7 desktop so I can migrate to SQL.
FTP [Attachmate & WIn CLI] workled fine under WinNT.
I suspect Win7 does not like the name.ext;version format of the OVMS file.
Filezilla - doesn't work.
PuTTY - doesn't work
Window CLI FTP - doesn't work [partial file transfer; times out & truncates file].
Using Attachmate's "Reflections for the Web 2011" to emulate Vax terminal - works fine.
Think I'll have to go back to Attachmate for assistance but partially hamstrung by our [Australian Fed Govt] IT services which has the final say
Some editors, such as BBEdit on the Mac, support directly opening/saving files via FTP/SFTP/etc. (BBEdit also supports various different line endings as used on different platforms, which would help with your other problem). I expect there must be a Windows editor with similar functionality - my Windows-using colleagues all rave about something called CodeWrite (or CodeWright ?) so I guess I would take a look at something like that.
UNIX file-locking is dead-easy: The operating system assumes that you know what you are doing and lets you do what you want:
For example, if you try to delete a file which another process has opened the operating system will usually let you do it. The original process still keeps it's file-handles until it terminates - at which point the the file-system will quietly re-cycle the disk-resources. No fuss, that's the way I like it.
How different things are on Windows: If I try to delete a file which another process is using I get an Operating-System error. The file is untouchable until the original process releases it's lock on the file. That was great back in the single-user days of MS-DOS when any locking process was likely to be on the same computer that contained the files, however on a network it's a nightmare:
Consider what happens when a process hangs while writing to a shared file on a Windows file-server. Before the file can be deleted we have to locate the computer and ID the process on that computer which originally opened the file. Only then can we kill the process and delete our unwanted file.
What a nuisance!
Is there a way to make this better? What I want is for file-locking on Windows to behave a like file-locking in UNIX. I want the operating system to just let me do what I want because I'm in charge and I know what I'm doing...
...so can it be done?
No. Windows is designed for the "average user", that is people who don't understand anything about a computer. Therefore, the OS tries to be smart to avoid PEBKACs. To quote Bill Gates: "There are no issues with Windows that any number of people want to be fixed." Of course, he knows that 99.9999% of all Windows users can't tell whether the program just did something odd because of them or the guy who wrote it.
Unix was designed when the world was more simple and anyone close enough to a computer to touch it, probably knew how to assemble it from dirty sand. Therefore, the OS usually lets you do what you want because it assumes that you know better (and if you didn't, you will next time).
Technical answer: Unix allocates an "i-nodes" if you create a file. I-nodes can be shared between processes. If two processes create the same file (that is, two processes call create() with the same path), then you end up with two i-nodes. This is by design. It allows for a fancy security feature: You can create files which no one can open but yourself:
Open a file
Delete it (but keep the file handle)
Use the file any way you like
Close the file
After step #2, the only process in the universe who can access the file is the one who created it (unless you want to read the hard disk block by block). The OS will keep the data alive until you either close the file or your process dies (at which time Unix will clean up after you).
This design is the foundation of all Unix filesystems. The Windows file system NTFS works much the same way but the high level API is different. Many applications open files in exclusive mode (which prevents anyone, even backup programs) to read the file. This is even true for applications which just display information like PDF viewers.
That means you'll have to fix all the Windows applications to achieve the desired effect. If you have access to the source, you can create a file in a shared mode. That would allow other processes to access it at the same time but then, you will have to check before every read/write if the file still exists, whether someone has made changes, etc.
According to MSDN you can specify to CreateFile() 3rd parameter (dwSharedMode) shared mode flag FILE_SHARE_DELETE which:
Enables subsequent open operations on a file or device to request delete access.
Otherwise, other processes cannot open the file or device if they request delete access.
If this flag is not specified, but the file or device has been opened for delete access, the function fails.
Note Delete access allows both delete and rename operations.
http://msdn.microsoft.com/en-us/library/aa363858(VS.85).aspx
So if you're can control your applications you can use this flag.
Note that Process Explorer allow for force closing of file handles (for processes local to the box on which you are running it) via Handle -> Close Handle.
Unlocker purports to do a lot more, and provides a helpful list of other tools.
Also deleting on reboot is an option (though this sounds like not what you want)
That doesn't really help if the hung process still has the handle open. It won't release the resources until that hung process releases the handle. But anyway, in Windows it is possible to force close a file out from under a process that's using it. Process Explorer from sysinternals.com will let you look at and close handles that a process has open.