Viewing a shell ascii file and creating a shell path 

I am using the view() function to open an ascii file from the shell, but it opens the file in the form/window in Virtuoso looking at the tail end of the file.  EG if the ascii file is larger than the viewing window, the contents scroll down to the end of the file.  Is there a way to use view() to open an ascii file but have the first view in the Virtuoso window remain at the head end of the file so the user can then scroll down instead of up?

Also, how can we create a path to write to a file location and pull from a specified path location by getting a path string from dbFullPath() and modifying it?

I am creating a new file using the cell name retrieved from geGetEditCellView()->cellName, but want to write to the same path location returned by dbFullPath() - with the exception of the last directory location.

For example, dbFullPath() returns ".../MyLibrary/MyLayout/layout/layout.cdb"

I create a file called "MyLayout_newfile" and want to write to ".../MyLibrary/MyLayout/MyLayout_newfile"

How do I truncate the end of the path returned by dbFullPath() - losing the "/layout/layout.cdb" portion?

What version are you using? The view() function doesn't do that for me - it shows the beginning of the file - the case it wouldn't by default is if you are passing t as the fourth argument to view(), and then updating the file after initially viewing it (the fourth argument is the auto-update flag, to "tail" the file live).

For your second question, I guess you're after geGetEditCellView()~>cell~>writePath

Regards,

Andrew.

Given any path like /a/b/c/d/e, you can use the following:

path="/a/b/c/d/e"
rindex(path "/") 
    "/e"
substring(path 1 strlen(path) - strlen(rindex(path "/")))
    "/a/b/c/d"

Derek

My apologies and thanks again Andrew.

I am using v 5.1.41, and I think you are correct about the autoUpdate being responsible for this.  When I use view(MyLayout_newfile), the form/window opens with the correct title, but is blank.  So I was following the view() call with hiEnableUpdateWindowCB(), and this updated the window with the file contents, but scrolled to the tail (almost every time but for some reason not every time...and did not matter if the file already existed or not).

So this begs the question, how do I get my file contents to load in the window without forcing it with the hiEnableUpdateWindowCB() func?

And - geGetEditCellView()->cell->writePath is just what I wanted - thanks!

I don't really see why you should have to use hiEnableUpdateWindowCB(). Presumably you haven't finished writing to the file before you view it? Could you make sure the file is written, the output port closed, and then view it?

Otherwise there's also  hiScrollWindowToIndex(hiGetCurrentWindow() 0) which could be used to scroll back to the top - but that sounds clunky...

Andrew

Yes, it is possible the view() func is trying to load a file before it is written.

Here is more sample code:

ipcBeginProcess(strcat("shellscript" MyLayout_newfile)) ; creates output ascii file MyLayout_newfile_out in shell env

view(MyLayout_newfile_out)

What code can I use to make sure the file is written, and the output port closed before viewing it?

Derek,

thank you!

FYI after experimentation, I am currently using :

ipcKillProcess(ipcBeginProcess(strcat("myshellscript " MyLayout_newfile)))

view(MyLayout_newfile_out)

This seems to work, but takes several seconds (5-10) to return the final viewing window, whereas the hiEnableUpdateWindowCB() func had immediate results despite loading in the file in tail view.

ipcCloseProcess(ipcBeginProcess(same as above) and ipcWait(ipcBeginProcess(same as above) did not work....

The delay of the ipcKillProcess(ipcBeginProcess()) is frustrating enough to consider (while() or until()) creating a comment popup form telling the user that background processes are running...tic tic tic... until they complete, then delete the comment form before displaying the file view window.

I don't think ipcKillProcess is what you want. Surely ipcWait(ipcBeginProcess(...)) is what you want.

Or you could use the optional exit callback on ipcBeginProcess() - 6th argument I think - to do this.

Andrew.

ipcWait(ipcBeginProcess(...)) never returns....and keeps my Virtuoso session suspended in the meantime until I kill the icfb process at the shell.

But it does usefully (!) display the following in the CIW:

"Waiting for ipc: [id#] to terminate"

over and over again....

I do not see an exit callback argument on ipcBeginProcess()....there is an optional [tsu_postFunc] argument - is that it?  If so, can you suggest what to use for this?

Andrew,

I think the problem I have is in the shell script, not in the SKILL code.  The shell script was written to write to a file output but also to the shell, and the output to the shell is unable to complete its operation...this is what I can surmise.  So until I can rewrite the shell script to avoid shell output, I will rely on the ipcKillProcess() func and then test ipcWait() once more.

Thanks again for your help.

 The postFunc arg is the one I meant, but it's definitely not going to help if the child process is not actually exiting. That's the problem you have to solve.

The challenge with using your ipcKillProcess() approach is that you are extremely susceptible to the time it takes to run. If the child process takes slightly too long, you may have killed it before it did anything yet...

The horribly sloppy way of solving this is to:

1. Start the job with ipcBeginProcess and record the job id somewhere
2. Use hiRegTimer() to set up a command to invoke some time in the future to call ipcKillProcess() on the saved job id (making it long enough that the file will reasonably have been written)
3. view() the file
4. Use hiEnableTailViewfile to update it as the content changes
5. Use hiScrollWindowTop or hiScrollWindowToIndex to scroll to the top (might have to hiDisableTailViewFile first)

Or fix the script and spend the rest of the time that you would have spent implementing and debugging the above in the pub.

Andrew.

Thanks again for the info.

I will opt for fixing the script and a Bass!