Opening multiple tabs from command line?

[barries]

Is there a recommended way to open multiple file compare tabs in the same window from the command line (in rapid succession) without (a) causing multiple windows to open when a file comparison takes a while or (b) using folder-based scripting?

Context: we have a Perl program that (1) identifies all files that have been edited locally compare to an SCM, (2) retrieves a copy of each "old" file from the SCM and places it in a temporary file, and (3) launches BC to compare each pair of files. When it works as desired, a single window is launched and the user can switch back and forth very handily between tabs as they review the changes.

The Perl script runs the commands as though it were a bash script like so:

scm print file1.c > tmp0001.c
bcompare.exe /leftreadonly /lefttitle=file1.c#head /righttitle=file1.c#have tmp0001.c file1.c &
scm print file2.c > tmp0002.c
bcompare.exe  /leftreadonly /lefttitle=file2.c#head /righttitle=file2.c#have tmp0002.c file2.c
scm print file3.c > tmp0003.c
bcompare.exe  /leftreadonly /lefttitle=file3.c#head /righttitle=file3.c#have tmp0003.c file3.c
rm tmp0001.c tmp0002.c tmp0003.c

If, for instance, the BC for file2.c is slow to display its tab in the first window, the file3.c comparison opens in a new window. On a slower machine (or VM), this happens more often than not. I have tried using BComp.exe too; same effect.

I'd try to script a folder view, but it's not a folder oriented operation so that would require extra complexity and hoop-jumping. What would be ideal is to open tabs from a script that's not folder-based or to be able to tell BC wait and open it in a previous instance even if that instance is busy. If instances were named in some way (for instance, we could name them by the SCM's assigned change number), that would be ideal because we could have multiple windows, one per change, each with all of the files that have been changed in that change.

[Aaron]

Thanks for all the info.

Are these files located on a network or another location that may take awhile to begin loading?

[barries]

They are not located on slow or remote storage. The tmp*.c and file*.c files are all local and load quickly. But some of the files are big and have complex diffs and these can take a while, especially on slower workstations (slow due to hardware or things like virus scans, IDEs building in the background, etc).

BC's startup time isn't the real issue--even if it were lightening quick by itself, things like the network response times, heavily loaded machines and BC popup dialogs would still need to be accounted for.

To handle this use case in a robust manner, the Perl program (in this case) needs to either (a) synchronize with BC so the program doesn't try to open a new comparison/tab until BC is completely ready to do so or (b) pass the entire list of comparisons to BC in such a way that BC will open them in multiple tabs regardless of timing vagaries and BC popup dialogs.

[Aaron]

Hello,

This should only be occurring if BC3's foreground thread is locked for more than a minute, and there are not many circumstances where that should be the case with local files.

Would you happen to be using the Alternate Alignment method for the Text Compare's default session settings in the Alignment tab? If so, does switching to the Standard alignment help resolve the loading issue? (To switch the default, please go to the Home screen, expand the Edit session defaults folder, select the Text Compare, and in the Alignment tab switch from Alternate to Standard.)