[ViewVC] Diff of: cvs/pbcdedit/pbcdedit

Comparing pbcdedit/pbcdedit (file contents):
Revision 1.9 by root, Wed Aug 14 22:54:28 2019 UTC vs.
Revision 1.34 by root, Thu Aug 15 08:42:02 2019 UTC

 #
 # You should have received a copy of the GNU General Public License
 # along with this program. If not, see <https://www.gnu.org/licenses/>.
 #
-use 5.014; # numerous features needed
+use 5.016; # numerous features need 5.14, __SUB__ needs 5.16
 our $VERSION = '1.0';
 our $JSON_VERSION = 1; # the versiobn of the json objects generated by this program
 =head1 NAME
    pbcdedit - portable boot configuration data (BCD) store editor
 =head1 SYNOPSIS
    pbcdedit help                # output manual page
    pbcdedit export path/to/BCD  # output BCD hive as JSON
-   pbcdedit import path/to/bcd  # convert standard input to BCD hive
+   pbcdedit import path/to/BCD  # convert standard input to BCD hive
    pbcdedit edit path/to/BCD edit-instructions...
    pbcdedit objects             # list all supported object aliases and types
    pbcdedit elements            # list all supported bcd element aliases
 =item Does not rely on Windows
 As the "portable" in the name implies, this program does not rely on
 C<bcdedit> or other windows programs or libraries, it works on any system
-that supports at least perl version 5.14.
+that supports at least perl version 5.16.
 =item Decodes and encodes BCD device elements
 PBCDEDIT can concisely decode and encode BCD device element contents. This
 is pretty unique, and offers a lot of potential that can't be realised
 sensitive data.
 =back
 The target audience for this program is professionals and tinkerers who
-are rewady to invest time into learning how it works. It is not an easy
+are ready to invest time into learning how it works. It is not an easy
-program to use and requires patience and a good understanding of BCD data
+program to use and requires patience and a good understanding of BCD
 stores.
 =head1 SUBCOMMANDS
-PCBEDIT expects a subcommand as first argument that tells it what to
+PBCDEDIT expects a subcommand as first argument that tells it what to
 do. The following subcommands exist:
 =over
-=item help
+=item C<help>
-Displays the whole manuale page (this document).
+Displays the whole manual page (this document).
-=item export F<path>
+=item C<export> F<path>
 Reads a BCD data store and writes a JSON representation of it to standard
 output.
 The format of the data is explained later in this document.
-Example: read a BCD store, modify it wiht an extenral program, write it again.
+Example: read a BCD store, modify it with an external program, write it
+again.
    pbcdedit export BCD | modify-json-somehow | pbcdedit import BCD
-=item import F<path>
+=item C<import> F<path>
 The reverse of C<export>: Reads a JSON representation of a BCD data store
 from standard input, and creates or replaces the given BCD data store.
-=item edit F<path> instructions...
+=item C<edit> F<path> I<instructions...>
 Load a BCD data store, apply some instructions to it, and save it again.
-See the section L<EDITING BCD DATA STORES>, below, for more info.
+See the section L<EDITING BCD STORES>, below, for more info.
-=item parse F<path> instructions...
+=item C<parse> F<path> I<instructions...>
 Same as C<edit>, above, except it doesn't save the data store again. Can
 be useful to extract some data from it.
-=item lsblk
+=item C<lsblk>
 On a GNU/Linux system, you can get a list of partition device descriptors
 using this command - the external C<lsblk> command is required, as well as
 a mounted C</sys> file system.
 The output will be a list of all partitions in the system and C<partition>
 descriptors for GPT and both C<legacypartition> and C<partition>
-descritpors for MBR partitions.
+descriptors for MBR partitions.
-=item objects [--json]
+=item C<objects> [C<--json>]
-Outputs two tables: a table listing all type aliases with their hex bcd
+Outputs two tables: a table listing all type aliases with their hex BCD
 element ID, and all object name aliases with their GUID and default type
 (if any).
 With C<--json> it prints similar information as a JSON object, for easier parsing.
-=item elements [--json]
+=item C<elements> [C<--json>]
 Outputs a table of known element aliases with their hex ID and the format
 type.
 With C<--json> it prints similar information as a JSON object, for easier parsing.
-=item export-regf F<path>
+=item C<export-regf> F<path>
-This has nothing to do with BCD data stores - it takes a registry hive
+This has nothing to do with BCD stores, but simply exposes PCBEDIT's
+internal registry hive reader - it takes a registry hive file as argument
-file as argument and outputs a JSON representation of it to standard
+and outputs a JSON representation of it to standard output.
-output.
 Hive versions 1.2 till 1.6 are supported.
-=item import-regf F<path>
+=item C<import-regf> F<path>
 The reverse of C<export-regf>: reads a JSON representation of a registry
-hive from standard input and creates or replaces the registry hive file given as
+hive from standard input and creates or replaces the registry hive file
-argument.
+given as argument.
 The written hive will always be in a slightly modified version 1.3
 format. It's not the format windows would generate, but it should be
 understood by any conformant hive reader.
 Note that the representation chosen by PBCDEDIT currently throws away
-clasname data (often used for feeble attemtps at hiding stuff by
+classname data (often used for feeble attempts at hiding stuff by
 Microsoft) and security descriptors, so if you write anything other than
 a BCD hive you will most likely destroy it.
 =back
-=head1 BCD DATA STORE REPRESENTATION FORMAT
+=head1 BCD STORE REPRESENTATION FORMAT
 A BCD data store is represented as a JSON object with one special key,
 C<meta>, and one key per BCD object. That is, each BCD object becomes
 one key-value pair in the object, and an additional key called C<meta>
 contains meta information.
 =head2 The C<meta> key
 The C<meta> key is not stored in the BCD data store but is used only
 by PBCDEDIT. It is always generated when exporting, and importing will
 be refused when it exists and the version stored inside doesn't store
-the JSON schema version of PBCDEDIT. This ensures that differemt and
+the JSON schema version of PBCDEDIT. This ensures that different and
-incompatible versions of PBCDEDIT will not read and misinterüret each
+incompatible versions of PBCDEDIT will not read and misinterpret each
 others data.
 =head2 The object keys
 Every other key is a BCD object. There is usually a BCD object for the
 boot manager, one for every boot option and a few others that store common
 settings inherited by these.
 Each BCD object is represented by a GUID wrapped in curly braces. These
-are usually random GUIDs used only to distinguish bCD objects from each
+are usually random GUIDs used only to distinguish BCD objects from each
 other. When adding a new boot option, you can simply generate a new GUID.
 Some of these GUIDs are fixed well known GUIDs which PBCDEDIT will decode
 into human-readable strings such as C<{globalsettings}>, which is the same
 as C<{7ea2e1ac-2e61-4728-aaa3-896d9d0a9f0e}>.
 get a list of all BCD elements known to PBCDEDIT by running F<pbcdedit
 elements>.
 What was said about duplicate keys mapping to the same object is true for
 elements as well, so, again, you should always use the canonical name,
-whcih is the human radable alias, if known.
+which is the human readable alias, if known.
 =head3 BCD element types
 Each BCD element has a type such as I<string> or I<boolean>. This type
 determines how the value is interpreted, and most of them are pretty easy
    "description" : "Windows 10",
    "systemroot" : "\\Windows",
 =item boolean
-Almost as simnple are booleans, which represent I<true>/I<false>,
+Almost as simple are booleans, which represent I<true>/I<false>,
 I<on>/I<off> and similar values. In the JSON form, true is represented
 by the number C<1>, and false is represented by the number C<0>. Other
 values will be accepted, but PBCDEDIT doesn't guarantee how these are
 interpreted.
 =item integer
 Again, very simple, this is a 64 bit integer. IT can be either specified
 as a decimal number, as a hex number (by prefixing it with C<0x>) or as a
-binatry number (prefix C<0b>).
+binary number (prefix C<0b>).
 For example, the boot C<timeout> is an integer, specifying the automatic
 boot delay in seconds:
    "timeout" : 30,
 =item integer list
 This is a list of 64 bit integers separated by whitespace. It is not used
-much, so here is a somewhat artificial an untested exanmple of using
+much, so here is a somewhat artificial an untested example of using
 C<customactions> to specify a certain custom, eh, action to be executed
 when pressing C<F10> at boot:
    "customactions" : "0x1000044000001 0x54000001",
 =item guid
-This represents a single GUID value wrqapped in curly braces. It is used a
+This represents a single GUID value wrapped in curly braces. It is used a
 lot to refer from one BCD object to other one.
 For example, The C<{bootmgr}> object might refer to a resume boot option
 using C<resumeobject>:
 Human readable aliases are used and allowed.
 =item guid list
-Similar to te guid type, this represents a list of such GUIDs, separated
+Similar to the GUID type, this represents a list of such GUIDs, separated
 by whitespace from each other.
 For example, many BCD objects can I<inherit> elements from other BCD
-objects by specifying the GUIDs of those other objects ina GUID list
+objects by specifying the GUIDs of those other objects in a GUID list
 called surprisingly called C<inherit>:
    "inherit" : "{dbgsettings} {emssettings} {badmemory}",
 This example also shows how human readable aliases can be used.
 =back
 =head4 The BCD "device" element type
 Device elements specify, well, devices. They are used for such diverse
-purposes such as finding a TFTP network boot imagem serial ports or VMBUS
+purposes such as finding a TFTP network boot image, serial ports or VMBUS
 devices, but most commonly they are used to specify the disk (harddisk,
-cdrom ramdisk, vhd...) to boot from.
+cdrom, ramdisk, vhd...) to boot from.
 The device element is kind of a mini-language in its own which is much
 more versatile then the limited windows interface to it - BCDEDIT -
 reveals.
 element, so almost everything known about it had to be researched first
 in the process of writing this script, and consequently, support for BCD
 device elements is partial only.
 On the other hand, the expressive power of PBCDEDIT in specifying devices
-is much bigger than BCDEDIT and therefore more cna be don with it. The
+is much bigger than BCDEDIT and therefore more can be done with it. The
 downside is that BCD device elements are much more complicated than what
 you might think from reading the BCDEDIT documentation.
 In other words, simple things are complicated, and complicated things are
 possible.
 Anyway, the general syntax of device elements is an optional GUID,
-followed by a device type, optionally followed by hexdecimal flags in
+followed by a device type, optionally followed by hexadecimal flags in
 angle brackets, optionally followed by C<=> and a comma-separated list of
 arguments, some of which can be (and often are) in turn devices again.
    [{GUID}]type[<flags>][=arg,arg...]
 The types understood and used by PBCDEDIT are as follows (keep in mind
 that not of all the following is necessarily supported in PBCDEDIT):
 =over
-=item binary=hex...
+=item C<binary=>I<hex...>
 This type isn't actually a real BCD element type, but a fallback for those
 cases where PBCDEDIT can't perfectly decode a device element (except for
 the leading GUID, which it can always decode). In such cases, it will
 convert the device into this type with a hexdump of the element data.
-=item null
+=item C<null>
 This is another special type - sometimes, a device all zero-filled, which
 is not valid. This can mark the absence of a device or something PBCDEDIT
 does not understand, so it decodes it into this special "all zero" type
 called C<null>.
 It's most commonly found in devices that can use an optional parent
 device, when no parent device is used.
-=item boot
+=item C<boot>
 Another type without parameters, this refers to the device that was booted
 from (nowadays typically the EFI system partition).
-=item vmbus=interfacetype,interfaceinstance
+=item C<vmbus=>I<interfacetype>,I<interfaceinstance>
 This specifies a VMBUS device with the given interface type and interface
 instance, both of which are "naked" (no curly braces) GUIDs.
 Made-up example (couldn't find a single example on the web):
    vmbus=c376c1c3-d276-48d2-90a9-c04748072c60,12345678-a234-b234-c234-d2345678abcd
-=item partition=<parent>,devicetype,partitiontype,diskid,partitionid
+=item C<partition=><I<parent>>,I<devicetype>,I<partitiontype>,I<diskid>,I<partitionid>
-This designates a specific partition on a block device. C<< <parent>
+This designates a specific partition on a block device. I<parent> is an
->> is an optional parent device on which to search on, and is often
+optional parent device on which to search on, and is often C<null>. Note
-C<null>. Note that the anfgle brackets are part of the syntax.
+that the angle brackets around I<parent> are part of the syntax.
-C<devicetypes> is one of C<harddisk>, C<floppy>, C<cdrom>, C<ramdisk>,
+I<devicetypes> is one of C<harddisk>, C<floppy>, C<cdrom>, C<ramdisk>,
 C<file> or C<vhd>, where the first three should be self-explaining,
-C<file> is usually used to locate a device by finding a magic file, and
+C<file> is usually used to locate a file to be used as a disk image,
-C<vhd> is used for virtual harddisks - F<.vhd> and F<-vhdx> files.
+and C<vhd> is used to treat files as virtual harddisks, i.e. F<vhd> and
+F<vhdx> files.
-The C<partitiontype> is either C<mbr>, C<gpt> or C<raw>, the latter being
+The I<partitiontype> is either C<mbr>, C<gpt> or C<raw>, the latter being
 used for devices without partitions, such as cdroms, where the "partition"
 is usually the whole device.
-The C<diskid> identifies the disk or device using a unique signature, and
+The I<diskid> identifies the disk or device using a unique signature, and
-the same is true for the C<partitionid>. How these are interpreted depends
+the same is true for the I<partitionid>. How these are interpreted depends
-on the C<partitiontype>:
+on the I<partitiontype>:
 =over
-=item mbr
+=item C<mbr>
 The C<diskid> is the 32 bit disk signature stored at offset 0x1b8 in the
 MBR, interpreted as a 32 bit unsigned little endian integer and written as
 hex number. That is, the bytes C<01 02 03 04> would become C<04030201>.
-Diskpart (using the C<DETAIL> command) and the C<lsblk> comamnd typically
+Diskpart (using the C<DETAIL> command) and the C<lsblk> command typically
 found on GNU/Linux systems (using e.g. C<lsblk -o NAME,PARTUUID>) can
-display the disk id.
+display the I<diskid>.
-The C<partitionid> is the byte offset(!) of the partition counting from
+The I<partitionid> is the byte offset(!) of the partition counting from
 the beginning of the MBR.
-Example, use the partition on the harddisk with C<diskid> C<47cbc08a>
+Example, use the partition on the harddisk with I<diskid> C<47cbc08a>
 starting at sector C<2048> (= 1048576 / 512).
    partition=<null>,harddisk,mbr,47cbc08a,1048576
-=item gpt
+=item C<gpt>
-The C<diskid> is the disk UUID/disk identifier GUID from the partition
+The I<diskid> is the disk GUID/disk identifier GUID from the partition
-table (as displayed e.g. by C<gdisk>), and the C<partitionid> is the
+table (as displayed e.g. by F<gdisk>), and the I<partitionid> is the
-partition unique GUID (displayed using e.g. the C<gdisk> C<i> command).
+partition unique GUID (displayed using e.g. the F<gdisk> F<i> command).
 Example: use the partition C<76d39e5f-ad1b-407e-9c05-c81eb83b57dd> on GPT
 disk C<9742e468-9206-48a0-b4e4-c4e9745a356a>.
    partition=<null>,harddisk,gpt,9742e468-9206-48a0-b4e4-c4e9745a356a,76d39e5f-ad1b-407e-9c05-c81eb83b57dd
-=item raw
+=item C<raw>
-Instead of diskid and partitionid, this type only accepts a decimal disk
+Instead of I<diskid> and I<partitionid>, this type only accepts a decimal
-number and signifies the whole disk. BCDEDIT cannot display the resulting
+disk number and signifies the whole disk. BCDEDIT cannot display the
-device, and I am doubtful whether it has a useful effect.
+resulting device, and I am doubtful whether it has a useful effect.
 =back
-=item legacypartition=<parent>,devicetype,partitiontype,diskid,partitionid
+=item C<legacypartition=><I<parent>>,I<devicetype>,I<partitiontype>,I<diskid>,I<partitionid>
 This is exactly the same as the C<partition> type, except for a tiny
 detail: instead of using the partition start offset, this type uses the
 partition number for MBR disks. Behaviour other partition types should be
 the same.
 The partition number starts at C<1> and skips unused partition, so if
 there are two primary partitions and another partition inside the extended
 partition, the primary partitions are number C<1> and C<2> and the
-partition inside the extended partition is number C<3>, rwegardless of any
+partition inside the extended partition is number C<3>, regardless of any
 gaps.
-=item locate=<parent>,locatetype,locatearg
+=item C<locate=><I<parent>>,I<locatetype>,I<locatearg>
 This device description will make the bootloader search for a partition
 with a given path.
-The C<< <parent> >> device is the device to search on (angle brackets are
+The I<parent> device is the device to search on (angle brackets are
-still part of the syntax!) If it is C<< <null> >>, then C<locate> will
+still part of the syntax!) If it is C<null>, then C<locate> will
 search all disks it can find.
-C<locatetype> is either C<element> or C<path>, and merely distinguishes
+I<locatetype> is either C<element> or C<path>, and merely distinguishes
 between two different ways to specify the path to search for: C<element>
-uses an element ID (either as hex or as name) as C<locatearg> and C<path>
+uses an element ID (either as hex or as name) as I<locatearg> and C<path>
-uses a relative path as C<locatearg>.
+uses a relative path as I<locatearg>.
-Example: find any partition which has the C<magicfile.xxx> path in the
+Example: find any partition which has the F<magicfile.xxx> path in the
 root.
    locate=<null>,path,\magicfile.xxx
 Example: find any partition which has the path specified in the
-C<systemroot> element (typically C<\Windows>).
+C<systemroot> element (typically F<\Windows>).
    locate=<null>,element,systemroot
-=item block=devicetype,args...
+=item C<block=>I<devicetype>,I<args...>
 Last not least, the most complex type, C<block>, which... specifies block
 devices (which could be inside a F<vhdx> file for example).
-C<devicetypes> is one of C<harddisk>, C<floppy>, C<cdrom>, C<ramdisk>,
+I<devicetypes> is one of C<harddisk>, C<floppy>, C<cdrom>, C<ramdisk>,
 C<file> or C<vhd> - the same as for C<partiion=>.
-The remaining arguments change depending on the C<devicetype>:
+The remaining arguments change depending on the I<devicetype>:
 =over
-=item block=file,<parent>,path
+=item C<block=file>,<I<parent>>,I<path>
-Interprets the C<< <parent> >> device (typically a partition) as a
+Interprets the I<parent> device (typically a partition) as a
 filesystem and specifies a file path inside.
-=item block=vhd,<parent>
+=item C<block=vhd>,<I<parent>>
-Pretty much just changes the interpretation of C<< <parent> >>, which is
+Pretty much just changes the interpretation of I<parent>, which is
 usually a disk image (C<block=file,...)>) to be a F<vhd> or F<vhdx> file.
-=item block=ramdisk,<parent>,base,size,offset,path
+=item C<block=ramdisk>,<I<parent>>,I<base>,I<size>,I<offset>,I<path>
-Interprets the C<< <parent> >> device as RAM disk, using the (decimal)
+Interprets the I<parent> device as RAM disk, using the (decimal)
 base address, byte size and byte offset inside a file specified by
-C<path>. The numbers are usually all C<0> because they cna be extracted
+I<path>. The numbers are usually all C<0> because they can be extracted
 from the RAM disk image or other parameters.
 This is most commonly used to boot C<wim> images.
-=item block=floppy,drivenum
+=item C<block=floppy>,I<drivenum>
 Refers to a removable drive identified by a number. BCDEDIT cannot display
-the resultinfg device, and it is not clear what effect it will have.
+the resulting device, and it is not clear what effect it will have.
-=item block=cdrom,drivenum
+=item C<block=cdrom>,I<drivenum>
 Pretty much the same as C<floppy> but for CD-ROMs.
 =item anything else
 =back5 Examples
 This concludes the syntax overview for device elements, but probably
 leaves many questions open. I can't help with most of them, as I also ave
-many questions, but I can walk you through some actual examples using mroe
+many questions, but I can walk you through some actual examples using more
 complex aspects.
-=item locate=<block=vhd,<block=file,<locate=<null>,path,\disk.vhdx>,\disk.vhdx>>,element,path
+=item C<< locate=<block=vhd,<block=file,<locate=<null>,path,\disk.vhdx>,\disk.vhdx>>,element,path >>
 Just like with C declarations, you best treat device descriptors as
 instructions to find your device and work your way from the inside out:
    locate=<null>,path,\disk.vhdx
 Next, this takes the device locate has found and finds a file called
 F<\disk.vhdx> on it. This is the same file locate was using, but that is
 only because we find the device using the same path as finding the disk
 image, so this is purely incidental, although quite common.
-Bext, this file will be opened as a virtual disk:
+Next, this file will be opened as a virtual disk:
    block=vhd,<see above>
 And finally, inside this disk, another C<locate> will look for a partition
 with a path as specified in the C<path> element, which most likely will be
    locate=<see above>,element,path
 As a result, this will boot the first Windows it finds on the first
 F<disk.vhdx> disk image it can find anywhere.
-=item locate=<block=vhd,<block=file,<partition=<null>,harddisk,mbr,47cbc08a,242643632128>,\win10.vhdx>>,element,path
+=item C<< locate=<block=vhd,<block=file,<partition=<null>,harddisk,mbr,47cbc08a,242643632128>,\win10.vhdx>>,element,path >>
-Pretty much the same as the previous case, but witzh a bit of variance. First, look for a specific partition on
+Pretty much the same as the previous case, but with a bit of
-an MBR-partitioned disk:
+variance. First, look for a specific partition on an MBR-partitioned disk:
    partition=<null>,harddisk,mbr,47cbc08a,242643632128
 Then open the file F<\win10.vhdx> on that partition:
 And again the windows loader (or whatever is in C<path>) will be searched:
    locate=<see above>,element,path
-=item {b097d2b2-bc00-11e9-8a9a-525400123456}block<1>=ramdisk,<partition=<null>,harddisk,mbr,47cbc08a,242643632128>,0,0,0,\boot.wim
+=item C<< {b097d2b2-bc00-11e9-8a9a-525400123456}block<1>=ramdisk,<partition=<null>,harddisk,mbr,47cbc08a,242643632128>,0,0,0,\boot.wim >>
 This is quite different. First, it starts with a GUID. This GUID belongs
 to a BCD object of type C<device>, which has additional parameters:
    "{b097d2b2-bc00-11e9-8a9a-525400123456}" : {
       "ramdisksdidevice" : "partition=<null>,harddisk,mbr,47cbc08a,1048576",
       "ramdisksdipath"   : "\boot.sdi"
    },
 I will not go into many details, but this specifies a (presumably empty)
-template ramdisk image (F<\boot.sdi>) that is used to initiaolize the
+template ramdisk image (F<\boot.sdi>) that is used to initialize the
-ramdisk. The F<\boot.wim> file is then extracted into it. As you cna also
+ramdisk. The F<\boot.wim> file is then extracted into it. As you can also
 see, this F<.sdi> file resides on a different C<partition>.
-Continuitn, as always, form the inside out, first this device descriptor
+Continuing, as always, from the inside out, first this device descriptor
 finds a specific partition:
    partition=<null>,harddisk,mbr,47cbc08a,242643632128
 And then specifies a C<ramdisk> image on this partition:
 seems to be always there on this kind of entry.
 If you have some good examples to add here, feel free to mail me.
-=head1 EDITING BCD DATA STORES
+=head1 EDITING BCD STORES
 The C<edit> and C<parse> subcommands allow you to read a BCD data store
-and modify it or extract data from it. This is done by exyecuting a series
+and modify it or extract data from it. This is done by executing a series
 of "editing instructions" which are explained here.
 =over
-=item get I<object> I<element>
+=item C<get> I<object> I<element>
 Reads the BCD element I<element> from the BCD object I<object> and writes
 it to standard output, followed by a newline. The I<object> can be a GUID
 or a human-readable alias, or the special string C<{default}>, which will
 refer to the default BCD object.
 Example: find description of the default BCD object.
    pbcdedit parse BCD get "{default}" description
-=item set I<object> I<element> I<value>
+=item C<set> I<object> I<element> I<value>
 Similar to C<get>, but sets the element to the given I<value> instead.
-Example: change bootmgr default too
+Example: change the bootmgr default too
 C<{b097d2ad-bc00-11e9-8a9a-525400123456}>:
    pbcdedit edit BCD set "{bootmgr}" resumeobject "{b097d2ad-bc00-11e9-8a9a-525400123456}"
-=item eval I<perlcode>
+=item C<eval> I<perlcode>
 This takes the next argument, interprets it as Perl code and
 evaluates it. This allows you to do more complicated modifications or
 extractions.
 The example given for C<get>, above, could be expressed like this with
 C<eval>:
    pbcdedit edit BCD eval 'say $BCD->{$DEFAULT}{description}'
-The example given for C<set> could be expresed like this:
+The example given for C<set> could be expressed like this:
    pbcdedit edit BCD eval '$BCD->{$DEFAULT}{resumeobject} = "{b097d2ad-bc00-11e9-8a9a-525400123456}"'
-=item do I<path>
+=item C<do> I<path>
 Similar to C<eval>, above, but instead of using the argument as perl code,
 it loads the perl code from the given file and executes it. This makes it
 easier to write more complicated or larger programs.
 =back
 =head1 SEE ALSO
-For ideas on what you can do, and some introductory material, try
+For ideas on what you can do with BCD stores in
+general, and some introductory material, try
 L<http://www.mistyprojects.co.uk/documents/BCDEdit/index.html>.
-For good reference on BCD objects and elements, see Geoff Chappels pages
+For good reference on which BCD objects and
+elements exist, see Geoff Chappell's pages at
-at L<http://www.geoffchappell.com/notes/windows/boot/bcd/index.htm>.
+L<http://www.geoffchappell.com/notes/windows/boot/bcd/index.htm>.
 =head1 AUTHOR
-Written by Marc A. Lehmann <pbcdedit@schmorp.de>.
+Written by Marc A. Lehmann L<pbcdedit@schmorp.de>.
 =head1 REPORTING BUGS
-Bugs can be reported dorectly tt he author at L<pcbedit@schmorp.de>.
+Bugs can be reported directly the author at L<pcbedit@schmorp.de>.
 =head1 BUGS AND SHORTCOMINGS
 This should be a module. Of a series of modules, even.
 Registry code should preserve classname and security descriptor data, and
 whatever else is necessary to read and write any registry hive file.
 I am also not happy with device descriptors being strings rather than a
 data structure, but strings are probably better for command line usage. In
-any case,. device descriptors could be converted by simply "splitting" at
+any case, device descriptors could be converted by simply "splitting" at
 "=" and "," into an array reference, recursively.
 =head1 HOMEPAGE
 Original versions of this program can be found at
 free to change and redistribute it. There is NO WARRANTY, to the extent
 permitted by law.
 =cut
-BEGIN { require "common/sense.pm"; common::sense->import } # common sense is optional, but recommended
+# common sense is optional, but recommended
+BEGIN { eval { require "common/sense.pm"; } && common::sense->import }
-use Data::Dump;
 use Encode ();
 use List::Util ();
 use IO::Handle ();
 use Time::HiRes ();
       or die "$path: short read\n";
    $buf
 }
-# sources and resources used for this:
+# sources and resources used for writing pbcdedit
+#
 # registry:
 # https://github.com/msuhanov/regf/blob/master/Windows%20registry%20file%20format%20specification.md
 # http://amnesia.gtisc.gatech.edu/~moyix/suzibandit.ltd.uk/MSc/
 # bcd:
 # http://www.geoffchappell.com/notes/windows/boot/bcd/index.htm
       Objects => [undef, \%objects],
    }]]
 }
 #############################################################################
+# edit instructions
 sub bcd_edit_eval {
    package pbcdedit;
    our ($PATH, $BCD, $DEFAULT);
       if ($insn eq "get") {
          my $object = shift @insns;
          my $elem   = shift @insns;
-         $object = $default if $object eq "{default}";
+         $object = $object eq "{default}" ? $default : dec_wguid enc_wguid $object;
          print $bcd->{$object}{$elem}, "\n";
       } elsif ($insn eq "set") {
          my $object = shift @insns;
          my $elem   = shift @insns;
          my $value  = shift @insns;
-         $object = $default if $object eq "{default}";
+         $object = $object eq "{default}" ? $default : dec_wguid enc_wguid $object;
          $bcd->{$object}{$elem} = $value;
       } elsif ($insn eq "eval") {
          bcd_edit_eval shift @insns;
    }
 }
 #############################################################################
+# command line parser
 # json to stdout
 sub prjson($) {
    print $json_coder->encode ($_[0]);
 }

Diff Legend

-–
+Removed lines
-+
+Added lines
-<
+Changed lines
->
+Changed lines

Comparing pbcdedit/pbcdedit (file contents): Revision 1.9 by root, Wed Aug 14 22:54:28 2019 UTC vs. Revision 1.34 by root, Thu Aug 15 08:42:02 2019 UTC

Diff Legend

Comparing pbcdedit/pbcdedit (file contents):
Revision 1.9 by root, Wed Aug 14 22:54:28 2019 UTC vs.
Revision 1.34 by root, Thu Aug 15 08:42:02 2019 UTC