[ViewVC] Diff of: cvs/pbcdedit/pbcdedit

Comparing pbcdedit/pbcdedit (file contents):
Revision 1.68 by root, Sun Sep 1 15:57:48 2019 UTC vs.
Revision 1.76 by root, Tue Aug 9 11:44:54 2022 UTC

 # along with this program. If not, see <https://www.gnu.org/licenses/>.
 #
 use 5.016; # numerous features need 5.14, __SUB__ needs 5.16
-our $VERSION = '1.4';
+our $VERSION = '1.5';
 our $JSON_VERSION = 3; # the version of the json objects generated by this program
 our $CHANGELOG = <<EOF;
+1.5  Mon Nov 25 15:54:34 CET 2019
+        - add "del" edit instruction.
-	- work around lsblk bug sometimes giving dos pttype for gpt partitions.
+	- work around lsblk bug sometimes giving "dos" pttype for gpt partitions.
-        - bootmenupolicy in synopsis must be set to 0 for text menu.
+        - bootmenupolicy in synopsis must be set to 0 to get the text menu.
+        - minor doc fxes.
+        - disable use of perldoc for help, doesn't work well.
 1.4  Thu Aug 22 10:48:22 CEST 2019
 	- new "create" subcommand.
         - "create" and "edit" try to save and restore ownership/permissions
           of bcd hives when writing the new file.
 =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
+be refused when it exists and the version stored inside doesn't match
 the JSON schema version of PBCDEDIT. This ensures that different and
 incompatible versions of PBCDEDIT will not read and misinterpret each
 others data.
 =head2 The object keys
 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}>.
-Each BCD, object has an associated type. For example,
+Each BCD object has an associated type. For example,
 C<application::osloader> for objects loading Windows via F<winload.exe>,
 C<application::bootsector> for real mode applications and so on.
 The type of a object is stored in the pseudo BCD element C<type> (see next
 section).
    [{GUID}]type[<flags>][=arg,arg...]
 Here are some examples:
    boot
-   {b097d29f-bc00-11e9-8a9a-525400123456}block=file,<boot>,\\EFI"
+   {b097d29f-bc00-11e9-8a9a-525400123456}block=file,<boot>,\EFI
    locate=<null>,element,systemroot
    partition=<null>,harddisk,mbr,47cbc08a,1048576
    partition=<null>,harddisk,gpt,9742e468-9206-48a0-b4e4-c4e9745a356a,76d39e5f-ad1b-407e-9c05-c81eb83b57dd
    block<1>=ramdisk,<partition=<null>,harddisk,mbr,47cbc08a,68720525312>,0,0,0,\Recovery\b097d29e-bc00-11e9-8a9a-525400123456\Winre.wim
    block=file,<partition=<null>,harddisk,gpt,9742e468-9206-48a0-b4e4-c4e9745a356a,ee3a393a-f0de-4057-9946-88584245ed48>,\
 Probably not yet implemented. Tell me of your needs...
 =back
+=back
 =head4 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 have
 many questions, but I can walk you through some actual examples using more
 complex aspects.
+=over
 =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:
 I don't know what the purpose of the C<< <1> >> flag value is, but it
 seems to be always there on this kind of entry.
 If you have some good examples to add here, feel free to mail me.
+=back
 =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 executing a series
 Example: change the bootmgr default too
 C<{b097d2ad-bc00-11e9-8a9a-525400123456}>:
    pbcdedit edit BCD set "{bootmgr}" default "{b097d2ad-bc00-11e9-8a9a-525400123456}"
+=item C<del> I<object> I<element>
+Similar to C<get>, but removed the BCD element from the specified BCD object.
 =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
 our @part_type = qw(gpt mbr raw);
 our $NULL_DEVICE = "\x00" x 16;
 # biggest bitch to decode, ever
-# this decoded a device portion after the GUID
+# this decodes a device portion after the GUID
 sub dec_device_($$);
 sub dec_device_($$) {
    my ($device, $type) = @_;
    my $res;
          $object = $object eq "{default}" ? $default : dec_wguid enc_wguid $object;
          $bcd->{$object}{$elem} = $value;
+      } elsif ($insn eq "del") {
+         my $object = shift @insns;
+         my $elem   = shift @insns;
+         $object = $object eq "{default}" ? $default : dec_wguid enc_wguid $object;
+         delete $bcd->{$object}{$elem};
       } elsif ($insn eq "eval") {
          my $perl = shift @insns;
          bcd_edit_eval "#line 1 'eval'\n$perl";
       } elsif ($insn eq "do") {
          my $path = shift @insns;
          my $file = file_load $path;
          bcd_edit_eval "#line 1 '$path'\n$file";
       } else {
-         die "$insn: not a recognized instruction for edit/parse\n";
+         die "$insn: not a recognized instruction for create/edit/parse\n";
       }
    }
 }
 # command line parser
 our %CMD = (
    help => sub {
       require Pod::Usage;
-      Pod::Usage::pod2usage (-verbose => 2);
+      Pod::Usage::pod2usage (-verbose => 2, -quotes => "none", -noperldoc => 1);
    },
    objects => sub {
       my %rbcd_types = reverse %bcd_types;
       $_ = sprintf "%08x", $_ for values %rbcd_types;

Diff Legend

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

Comparing pbcdedit/pbcdedit (file contents): Revision 1.68 by root, Sun Sep 1 15:57:48 2019 UTC vs. Revision 1.76 by root, Tue Aug 9 11:44:54 2022 UTC

Diff Legend

Comparing pbcdedit/pbcdedit (file contents):
Revision 1.68 by root, Sun Sep 1 15:57:48 2019 UTC vs.
Revision 1.76 by root, Tue Aug 9 11:44:54 2022 UTC