Skip to main content
18-Opal
November 1, 2011
Question

Batch editing with Arbortext

  • November 1, 2011
  • 8 replies
  • 2346 views
Hi Steve--



You can execute Arbortext commands from the command line in Windows
using the -c switch, which means you could set up a batch file to do
what you want.



The batch file would look roughly like this: (untested, debugging left
as an exercise)



:: resave.bat



:: set the following based on your version/environment

set arbortext=C:\Program Files\PTC\Arbortext Editor\bin\x64\editor.exe

for %%i in (%1) do "%arbortext%" -c "save" "%%i"



HTH



--Clay




    8 replies

    1-Visitor
    November 3, 2011

    Steve,


    Gareth mentions this, but I use the concept of "normalizing" the XML/SGML. I use a $30 program called Search & Replace by Funduc Software (www.funduc.com). You can run it using an UI, or through scripts. I have some scripts that are 100's of lines manipulating the heck out of a document for some reason or another. The one I use to normalize simply puts everything on its own line, start tags always start the line... and so on.


    The problem with relying on Arbortext to save a document is that it uses the recordlength setting to determine where to break a line. When you modify the document it can shift a lot based on entering the letter "a". Point is, just because you save both documents with Arbortext won't guarantee that they will line up when doing a line-by-line comparason. I use this concept everyday trying to figure out why a new version of a document doesn't publish the same way it's previous version did (barring changes, of course).


    HTH,


    Bob

    1-Visitor
    November 3, 2011
    Not that this answers the original question for an external diff function,
    but the editor is able to compare files. I'm assuming it compares them in
    an XML aware manner.

    ..dan

    > Steve,
    > Gareth mentions this, but I use the concept of "normalizing" the XML/SGML.
    > I use a $30 program called Search & Replace by Funduc Software
    > (www.funduc.com). You can run it using an UI, or through scripts. I have
    > some scripts that are 100's of lines manipulating the heck out of a
    > document for some reason or another. The one I use to normalize simply
    > puts everything on its own line, start tags always start the line... and
    > so on.
    > The problem with relying on Arbortext to save a document is that it uses
    > the recordlength setting to determine where to break a line. When you
    > modify the document it can shift a lot based on entering the letter "a".
    > Point is, just because you save both documents with Arbortext won't
    > guarantee that they will line up when doing a line-by-line comparason. I
    > use this concept everyday trying to figure out why a new version of a
    > document doesn't publish the same way it's previous version did (barring
    > changes, of course).
    > HTH,
    > Bob
    >
    >
    1-Visitor
    November 3, 2011
    Thanks for all the tips.

    I really like the suggestion of using an external tool to “pretty print” the XML. Is there a way to do this as a save hook in Arbortext?

    Steve
    1-Visitor
    November 3, 2011
    Be sure to do some testing with the pretty-print. We ran into an issue
    where some of our developers were using XMLSpy that introduced undesirable
    whitespace between text and tags. In general, whitespace in XML is
    typically ignored, but for us, even a single space made our output look
    funny. Breaks that take place within the tags themselves should avoid
    this issue.

    On Thu, Nov 3, 2011 at 11:39 AM, Steven Anderson
    <sanderson@salesforce.com>wrote:

    > Thanks for all the tips. ****
    >
    > ** **
    >
    > I really like the suggestion of using an external tool to "pretty print"
    > the XML. Is there a way to do this as a save hook in Arbortext?****
    >
    > ** **
    >
    > Steve****
    >
    > ** **
    >
    > *From:* Bob Spangenburg [
    > I use a $30 program called Search & Replace by Funduc Software (
    > www.funduc.com). You can run it using an UI, or through scripts. I have
    > some scripts that are 100's of lines manipulating the heck out of a
    > document for some reason or another. The one I use to normalize simply puts
    > everything on its own line, start tags always start the line... and so on.
    > ****
    >
    > The problem with relying on Arbortext to save a document is that it uses
    > the recordlength setting to determine where to break a line. When you
    > modify the document it can shift a lot based on entering the letter "a".
    > Point is, just because you save both documents with Arbortext won't
    > guarantee that they will line up when doing a line-by-line comparason. I
    > use this concept everyday trying to figure out why a new version of a
    > document doesn't publish the same way it's previous version did (barring
    > changes, of course).****
    >
    > HTH,****
    >
    > Bob???****
    >
    > ** **
    1-Visitor
    December 9, 2011
    Clay, this is working really well for me *except* the checksum PI is included at the end. Any idea how to do the save without that PI?

    Steve
    18-Opal
    December 9, 2011
    Hi Steve--



    You can do this by adding the -nopi flag to the save command:



    :: set the following based on your version/environment

    set arbortext=C:\Program Files\PTC\Arbortext Editor\bin\x64\editor.exe

    for %%i in (%1) do "%arbortext%" -c "save -nopi" "%%i"



    Note that this will remove most Arbortext PI's from the save file,
    including _font and _link PI's. If you don't want that, you may have to
    use some kind of post-processor like a PERL script to strip out just the
    checksum PI.



    --Clay



    Clay Helberg

    Senior Consultant

    TerraXML


    1-Visitor
    December 9, 2011
    Do "help set writepi".



    Starting in 6.0 there are 5 choices to allow you to pick which category
    of PIs you want saved.



    Also starting in 6.0, we no longer write/use the checksum PI.



    paul




    1-Visitor
    December 9, 2011
    That's great news. Another reason to push our switch to 6.0.