Single release for all platforms?

[pps83]

Wouldn't make more sense to simply merge all the release into a single zip? Seems like each OS has it's own scripts with different names.
There could be a single ibc.bat and ibc.sh that could take commands and based on the OS (relevant only for .sh) to route to the right script with required params. This way there wouldn't be any difference from running IBC on windows/linux/mac

[rlktradewright]

I'm afriad i don't understand what you mean.

Please clarify.

The current structure has worked well for a very long time. It's simple and straightforward. The start scripts for Linux and macOS have different names because they are radically different. I see no sense or benefit at all in trying to combine them into a single script.

[pps83]

First part, you have 3 zip releases now, if you simply copy zip contents from all of the 3 releases into a single dir the you'll end up with single release that is actually usable on mac, windows, and linux (because all scripts filenames are different). Files with the same name are bitexact between releases. It will obviously be confusing as f*ck for mac/linux users and they will run wrong scripts.

Second part, there could be scripts that make it all work the same way for all platforms. For example, there is StartGateway.bat for windows. If you add StartGateway.sh and this new script would simply check if it's mac or linux and would run relevant script to start it. With single release for all platforms each linux script could check for mac and forward to relevant mac script, and mac script could do the same if they detect linux.
Alternatively, there could be a "meta" script like ibc.bat / ibc.sh (or simply ibc) that accept commands like start, stop, reconnect etc.

I'm trying to automate it all directly from c++ and all the commands are very different for win/mac/linux.

Also, I just tested RECONNECTACCOUNT from tcp control port and it doesn't work. IBC log says taht it received the message, but nothing happens. After some debugging, here's what I found:

What IBC's source does for RECONNECTACCOUNT:
  - It creates Java KeyEvent objects (KEY_PRESSED, KEY_TYPED, KEY_RELEASED) for Ctrl-Alt-R and dispatches them programmatically to the Gateway main window via dispatchEvent().

  Why it doesn't work for you:
  - Swing menu accelerators (the Ctrl-Alt-R shortcut) often don't fire when triggered by programmatically-dispatched KeyEvents - they need the real OS key-event pipeline (which is what your manual
  Ctrl-Alt-R uses). To do this properly IBC would need java.awt.Robot.keyPress, which in turn needs the window to be the OS foreground - tricky when our process is hidden.
  - This is a known limitation of IBC's RECONNECTACCOUNT/RECONNECTDATA for non-foreground Gateway. STOP and RESTART go through different code paths (menu-click style) and DO work, as you saw with
  STOP at exit.

(that's AI debugging)