After making changes below relative paths are supported in both Windows and Linux:
./foo.png # saved in the current working directory
../foo.png # saved in parent directory
foo.png # saved in the current working directory

However, Because the home character is not supported by windows,

~/foo.png # user's home directory - This works only in Linux.

Should I explicitly handle '~' char for windows system and replace it with users home directory programmatically?

Please review the code in the following branch,

https://bitbucket.org/kkorey/kkorey-igb/branch/IGBF-1286-Rel-path-snapshot

Works in mac as well.

My test process:
Using the latest installer of master branch, I added the Command Socket plugin.
I copied the example script into a text file, saved it, and made it executable.
The example file uses the file name /tmp/igbImage-'$i'.png (where i is a variable) to save each image.
I replaced /tmp/ with other paths to see where the image is saved.

Results:
The relative path that this exports to is not relative to the current working directory (ie, the user's current working directory). The relative paths are relative to the install location of the IGB program.
On mac, the ~ seems to operate correctly. When I save to ~/Downloads/igbImage-'$i'.png, the images are saved to my downloads folder.

Summary:
This is not ideal.
If we say that this supports relative file paths, I think users will expect that to be relative to their working directory.
I think it will be clearer to users if we say that this command only supports absolute file paths.

I talked with Kiran. He said IGB does not receive information about what directory the command is sent from. So paths can only be relative to the program (IGB) or absolute paths.

I am assigning this to Ann.
She can decide if she would like to create a new issue to support file paths relative to the users current working directory (which I think was the original intention in this issue), or leave this as it is given the limitations of information passed to the program.

Made changes to support tilde in windows.

Please review the code in the following branch,
https://bitbucket.org/kkorey/kkorey-igb/branch/IGBF-1286-tilde

In our meeting with Ann, we decided we cannot truly support relative paths, but we can help the user out by supporting '~' paths.

Kiran expanded the '~' support to Windows, I am reviewing that change.

git review:
single commit, suitable message.

code review:
Question: is f.getName() different from f.getPath() ? Why do they both need to be in the print statement?

Code is:
+ if(filePath.startsWith("~"))

return filePath.replaceAll(":","-");

I suggest changing it to:
+ if(filePath.startsWith("~"))

return filePath.replaceAll(":", "-");

The replace() call exists exactly once. The if-code-block only contains the operations that are dependent on the if-condition.
Spaces around "+" signs make code easier to read.

I wonder, was the replace included within the if-statement so as NOT to change the ':' that appears in the Windows System.getProperty("user.home") string. If so,... What happens if a Windows user supplies a full file path? Doesn't the ":" in the path get changed to a "" ? does that mess things up? If so--that is a bug introduced by a recent change to this function. If not, it should be safe to make the change I suggested above.

Functional review:
This change and my concerns around it are specific to Windows. So I am passing this to Sneha to test on a windows systems.

This issue needs to be tested on a Windows machine.

Question: is f.getName() different from f.getPath() ? Why do they both need to be in the print statement?

Ans: f.getName() returns only the name of the file and f.getPath() returns the complete path.

Also, I have made some changes to handle the absolute file path and moved the replaceAll() to a single place as mentioned in the review.

Kiran Korey: Please list the testing process for this issue asap so that I start with this?
There is no information on how to test this issue.

The testing procedure is in the following link:
https://wiki.transvar.org/display/ITD/Command+Socket+Plugin

You need to make sure to try different paths to save the images.
Some example paths :
1. using ~: ~/igb-images/
2. Absolute path : C:\igb-images
3. current installation directory: ./igb-images
4. parent installation directory: ../igb-images

Note 3rd and 4th points are wrt where igb is installed and not from the place where script file is saved.
The directory that you specify has to exist, igb will not create it.

Tested and found issues:
Saving of images is not working in recent installer on Windows.
When I use current or parent directory, Its not saving even if the given folder exists in the script.
I am checking in C:/ProgramFiles/IGB/ folder for the images. Is it correct?

Image saving works for absolute path and home directory path.

Also please handle exception caused when FileNotFound Exception is thrown.

Image saving works for current and parent directory if the installer is opened in Administrator mode but not in normal mode because of access permissions.

Also I have an input on this. If the folder doesn't exist in the system to store images, then how about changing the script to create folder.?
Because currently, User is misled with the information that his images are saving but console error says that the folder is not found!

Ivory Blakley : Did you face the "Access Denied" issue in mac while saving images in current and parent directory?

Done with testing on Windows. Few features aren't working due to Permission issues.
Assigning it to Kiran Korey to cross verify in his machine. Moving it to "To-do" column.

After talking to [~aloraine]
Showing Acces denied if using dot or dot-dot is expected behavior in windows systems and is absolutely fine.
I have created issue IGBF-1384 to handle file not found exception to create a folder if it does not exist.

So moving to Ready for pull Request column.

Using main master, and the script down in the Command socket app readme,
and I modified the script to save to '~/Downloads/'$

'.png'.
Both worked, I think all looks good here.

I tested this on mac.
I never encountered a permission issue. I assume it has to do with the fact that my user has permission to make changes in the folder where I installed IGB.

I am reassigning this to Kiran so records show that he tackled the issue, and I am marking it as done.