Announcement

Collapse
No announcement yet.

binary plist AKA bplist viewing

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • binary plist AKA bplist viewing

    It would be nice if Beyond Compare had a way to view binary plists as XML. Is there any way to add such a viewer?

  • #2
    Hello,

    As a binary file, we would need to run an external conversion to open it as plain text. We have other, similar formats for binary files for download here, but not plist:
    http://www.scootersoftware.com/downl...kb_moreformats

    If you are familiar with any command line utility that can take a plist input and output the xml you wish to compare, we can incorporate its use. We have an example of that here:
    http://www.scootersoftware.com/suppo...rnalconversion
    Aaron P Scooter Software

    Comment


    • #3
      Originally posted by Aaron View Post
      If you are familiar with any command line utility that can take a plist input and output the xml you wish to compare, we can incorporate its use.
      /usr/local/bin/PlistBuddy

      Comment


      • #4
        Hello,

        I believe we can use plutil. How does this work for you?:

        Go to the Beyond Compare menu, File Formats, and create a New (+) Text format. Assign the file mask of *.plist.

        In the Conversion tab, enable an External Conversion, and use this command line:
        plutil -convert xml1 -o %t %s

        Also enable "Disable Editing"
        Aaron P Scooter Software

        Comment


        • #5
          Originally posted by Aaron View Post
          Hello,

          I believe we can use plutil. How does this work for you?:

          Go to the Beyond Compare menu, File Formats, and create a New (+) Text format. Assign the file mask of *.plist.

          In the Conversion tab, enable an External Conversion, and use this command line:
          plutil -convert xml1 -o %t %s

          Also enable "Disable Editing"
          Trying this out as we speak.

          Should I be using ANSI or UNICODE here? The above command line you mentioned hold good?
          Loading:
          Code:
          Helpers\Json\plutil -convert xml1 -o %t %s
          Copied plutil.exe to \helpers\plist\ and a whole bunch of dependency .dlls from Apple\Common Files from iTunes install.
          http://forensicswiki.org/wiki/Converting_Binary_Plists

          I am wondering if it would be better to point to the existing file in original folders, if so how?

          Standard Default Output:
          Code:
          C:\Program Files (x86)\Beyond Compare 3\Helpers\plist>plutil
          No files specified.
          plutil.exe: [command_option] [other_options] file...
          The file '-' means stdin
          Command options are (-lint is the default):
           -help          show this message and exit
           -lint          check the property list files for syntax errors
           -convert fmt   rewrite property list files in format
                          fmt is one of: xml1 binary1 json
           -p             print property list in a human-readable fashion without attempting to convert the actual data
                          (not for machine parsing! this 'format' is not stable)
          There are some additional optional arguments:
           -s             be silent on success
           -o path        specify alternate file path name for result;
                          the -o option is used with -convert, and is only
                          useful with one file argument (last file overwrites);
                          the path '-' means stdout
           -e extension   specify alternate extension for converted files
           -r             if writing JSON, output in human-readable form
           --             specifies that all further arguments are file names
          2015-10-23 21:14:57.705 plutil.exe[6960:1364] Windows edition
          Last edited by crashnburn; 23-Oct-2015, 12:05 PM.

          Comment


          • #6
            It looks like you setup the files in Helpers\since your Standard Out example looks like it is working.

            Before implementing into Beyond Compare, use the Windows Command line to define an input file and output.txt file, then check if the output is generated as expected. If so, then we should be able to to use the same command line, replacing the literal input and output.txt with %s and %t (source=input and target=output).

            Would this command line work?:
            C:\Program Files (x86)\Beyond Compare 3\Helpers\plutil -convert xml1 -o "c:\test\out.txt" "c:\original file to convert"
            Last edited by Aaron; 23-Oct-2015, 04:21 PM. Reason: update command line
            Aaron P Scooter Software

            Comment


            • #7
              Got this working:

              Helpers\plist\plutil.exe -convert xml1 %s -o %t

              Using Unicode option as XML's are typically UTF8. I am wondering if ANSI vs UNICODE in BC is related to something else as it says File"Name". Thoughts?

              I've copied one to local helpers but I have added Apple folder to PATH so I am guessing/ wondering if I can make it run from there as well.. maybe without the helpers path?

              Comment


              • #8
                That option controls how the file path is passed to the conversion utility. If you expect Unicode characters or are using newer conversion utilities, you can use Unicode. If the conversion utility you are calling does not support Unicode text as parameters, then you would need to use ANSI.

                There are methods of calling items on the Path; if it is properly configured we can reference it outside of Helpers\. I would usually recommend placing the conversion into Helpers\, as our Export process can then gather up those files as well if they are in a subdirectory.
                Aaron P Scooter Software

                Comment


                • #9
                  Any chance of getting this added to BeyondCompare? PLIST files are very common on Mac OS. I guess not many BeyonCompare developers are using a Mac.

                  Comment


                  • #10
                    For which conversion utility? For us to host a tool, it would either need to be packed in the OS by default or have a license that allows us to redistribute it. Otherwise, we provide the instructions above as a customized File Format, which the user can configure with any software they have installed that can function from the command line.
                    Aaron P Scooter Software

                    Comment


                    • #11
                      Binary PLIST - convert to XML and compare

                      Originally posted by Aaron View Post
                      Hello,

                      As a binary file, we would need to run an external conversion to open it as plain text. We have other, similar formats for binary files for download here, but not plist:
                      http://www.scootersoftware.com/downl...kb_moreformats

                      If you are familiar with any command line utility that can take a plist input and output the xml you wish to compare, we can incorporate its use. We have an example of that here:
                      http://www.scootersoftware.com/suppo...rnalconversion
                      Hey guys, to finish this thread here's a helpful conversion to XML using the built-in plutil tool on Mac.

                      BC4
                      General - Mask:
                      "*.plist"

                      Description:
                      "Compare PLIST files"

                      Conversion - Loading:
                      Code:
                      plutil -convert xml1 %s -o %t
                      Disable Editing: leave unchecked
                      Saving: leave this blank - We can leave PLIST in XML format, it's the best common denominator.
                      Encoding: UTF-8
                      Misc - Tab stop: 4

                      The rest are default.

                      I tried JSON format, however many tools do not recognize JSON encoded PLIST files so conversion to JSON is a 1-way street. However all tools recognize and load XML format inside a .PLIST document, so it's best to convert, compare, and save any changes as XML.

                      Hope this is helpful for many other Xcode developers out there!

                      Cheers!
                      - Aaron
                      Steampunk Digital

                      Comment


                      • #12
                        Originally posted by otri View Post
                        Hey guys, to finish this thread here's a helpful conversion to XML using the built-in plutil tool on Mac.

                        BC4
                        General - Mask:
                        "*.plist"

                        Description:
                        "Compare PLIST files"

                        Conversion - Loading:
                        Code:
                        plutil -convert xml1 %s -o %t
                        Disable Editing: leave unchecked
                        Saving: leave this blank - We can leave PLIST in XML format, it's the best common denominator.
                        Encoding: UTF-8
                        Misc - Tab stop: 4

                        The rest are default.

                        I tried JSON format, however many tools do not recognize JSON encoded PLIST files so conversion to JSON is a 1-way street. However all tools recognize and load XML format inside a .PLIST document, so it's best to convert, compare, and save any changes as XML.

                        Hope this is helpful for many other Xcode developers out there!

                        Cheers!
                        - Aaron
                        Steampunk Digital
                        Thanks for sharing that and your link is very interesting Steampunk Digital .. Nice.

                        Comment


                        • #13
                          Sorry for the thread necromancy, gang, but I've had a fun journey with this one, so far, so I wanted to chime in. Everything you guys have discussed (crashnburn, otri, and Scooter Aaron) is right on the money, and this one really isn't *super* tough... but, maybe some of this will interest you.

                          I actually wrote a helper for this back in 2013, and I still use it today (it's on its ~6th version). Works across all three platforms, too.

                          The main reason I didn't submit it (way back then) is that I wanted to make sure that the edited plist would save in the format of the original plist (yes, I'm a perfectionist), and the trickery that I used to do that didn't quite feel mature enough. I did manage to get around the "trickery" by asking the Scooter team if they could add a flag to the helper callout ("%o") to point to the original file (Aaron helped me with that one). Then, in the save call to the helper, it can check the original, and adds the corresponding -xml1 or -binary1.

                          Of course, then it turned into a pet project. I won't go into all the gory details, unless someone wants me to... but, part of me felt a twinge of motivation, reading this post, to take a swing at a final version.

                          An interesting wrinkle in the story was BC Profiles. I use profiles A LOT. There is nothing like opening BC on your Windows machine, and connecting to two Macs over SFTP, and seamlessly comparing and modifying plists. But, even though BC handles all of the file transfer mechanics for you, it resulted in my "poor-man's two-phase commit" being just a little tougher. The "%o" parameter returns the *pre*-transfer BC "URL", like "profile:user@host?Library/Preferences/com.apple.finder.plist". So, a little more trickery there. I really wish I had just asked the Scooter guys to parameterize the post-transfer file, and most importantly, some representation of the token they use to identify the temporary file that comes up for edit.

                          And, as otri mentioned, Apple adding JSON as a supported plist format was another fun exercise. I almost never run into plist files in JSON format, so I only barely implemented it (using xml-tidy). And, as you pointed out, deserializing JSON to an editable form, and then re-serializing it (properly!) isn't always the simplest task. Depending on the complexity of the document, and how strict the validation needs to be... it can tend close to impossible. There's another thread on here that gets deeper into that (on the BC side), and why it is such a sizable job to implement (in BC, and in general). But, most of the JSON plists I tested with converted back just fine (and, if not, the helper just errors out on save), so I ended up feeling okay, there.

                          As much as we'd probably love the native support, I'm guessing Team Scooter is pretty busy with the 64-bit conversion, security, and framework changes that Apple is hurrying through the pipeline.

                          Anyway, that was way too much detail, I'm sure. But, I'll probably circle back on this one, if anyone is interested.

                          BTW, Aaron, if you see this thread... those two parameters I mentioned above would really be great to have. There are probably also some other variables in BC that, if passable to helpers, could add a lot of power (like encoding details, or file type detection info). And, the only other thing I wish we had is a way to return a verbose status in the UI on a helper error (starting to feel greedy now, lol).

                          --Ed

                          Comment


                          • #14
                            Hi Ed,

                            Since you're always using XML as the in-BC representation, your tool could add an XML comment to the file that indicates what the original format was, and then strip it out before the save and (if necessary) return conversion. Since JSON doesn't have comments, that wouldn't work, but you could add an "originalFormat" element or something. Since it would be stripped out during the save process, as long as you're careful with how you edit the files, it shouldn't cause compatibility issues. Alternatively, add something outside the tags that the Xcode tools would explicitly flag as invalid so if you do manage to save a file with it you'll find out right away.

                            And yes, if we weren't rushing to match Apple's schedule, there's a whole host of macOS-specific enhancements I'd love to get in.
                            ZoŽ P Scooter Software

                            Comment


                            • #15
                              Hi, Zoe --

                              Thanks for the suggestion; great idea. I had actually considered ideas similar to that, and ultimately rejected them, because I wanted the helper "pipe" to be stateless/atomic (loosely applied, obviously). At the end of the day, I was just being OCD.

                              Nowadays, I'm realizing all sorts of things (about files, filesystems, and datastores; and, physics, lol) that didn't concern me before. I was testing a BTRFS system the other day, that had a SMB-based Time Machine backup system on it, and... well, I won't even go there, but... between forks, CNID databases, vfs:fruit, xattrs, and xacls, I was stunned. There's so much new entropy; it's unreal.

                              When I grew up, there were only a few kids in school who were nerds, and they were generally regarded negatively. Now, it's the complete opposite, and it's really nuts/amazing. Makes me wish I could go back and just lightly tweak one or two specific words or phrases in an early RFC or two, you know?

                              Oh, and I almost forgot. Definitely excited for your "BC on OSX" (or BC, period) ideas, too. I'll be here and ready, if and/or when Apple is done pouring on more sauce. Hopefully, we're not in old-age homes on Mars, by then...

                              --Ed
                              Last edited by foxnetradio; 30-Oct-2018, 08:21 PM.

                              Comment

                              Working...
                              X