GDisk Hex Codes

Question

I want to replace words in a vector based on original and replacement words in another dataframe. As an example:

A vector of strings to be altered:

my_words <- c("example r", "example River", "example R", "anthoer river",
        "now a creek", "and another Ck", "example river tributary")

A dataframe of words to be replaced and the corresponding replacement words:

my_replace <- data.frame(
  original = c("r", "River", "R", "river", "Ck", "creek", "Creek"),
  replacement = c("R", "R", "R", 'R', "C", "C", "C"))

I want to replace any occurrence of one of the words in my_replace$original with the corresponding value in my_replace$replacement in the vector my_words. I tried using stringr::str_replace_all(), but it replaced all instances of the letter/word, rather than just whole words (e.g. "another" became "anotheR") which is undesirable.

psuedo code of what I want to do:

str_replace_all(my_words, my_replace$original, my_replace$replacement)

Desired output:

"example R", "example R", "example R", "another R", "now a C", "and another C", "example R tributary"  

I did find a solution using a for loop, but given my dataset is large, the for loop option is too slow. Any advice much appreciated.

Solution 1

kyodake's answer is correct, but it's also rather MBR-centric. Under GPT, the same principles apply -- that is, a partition type code identifies the intended purpose of a partition. The difference is that GPT type codes are 128-bit GUIDs, vs. the 8-bit codes used under MBR. The nature of GUIDs means that it's not necessary to register codes with a central authority to avoid collisions; two GUIDs are statistically very unlikely to be identical by accident.

AFAIK, there is no official repository of GPT type codes, but they are documented on the Wikipedia page about GPT. One disadvantage of GPT type codes is that, as GUIDs, they're long and awkward -- for instance, 0FC63DAF-8483-4772-8E79-3D69D8477DE4 for Linux filesystem data, vs. 0x83 for the MBR equivalent. Thus, most tools for partitioning GPT disks use some form of "shorthand" or "natural-language translation" in their user interfaces. I'm the author of GPT fdisk, and as my goal in writing it was to create something that was as similar to (MBR) fdisk as possible, I took the approach of using MBR codes as a base; however, because the correspondence between GPT and MBR type codes isn't 1:1, I multiplied the MBR type codes by 0x100 to get the GPT equivalents. Thus, MBR's 0x83 became 8300. This also enables related follow-on codes that don't exist in MBR, such as 8301, 8302, etc. These codes are easy to use for people who are already familiar with the MBR equivalents, but they're admittedly arbitrary for people who don't know the MBR codes. Internally, GPT fdisk translates these codes to GUIDs. You can see the actual GUIDs by viewing detailed partition information (via the i option in gdisk, for instance). You can also enter an arbitrary GUID rather than use the GPT fdisk four-character codes, if you like or if you need to use a code that GPT fdisk doesn't support.

Other tools use other approaches. The libparted library (and thus parted, GParted, and other tools based upon libparted) translates some type codes to "flags" and completely hides other codes. This helps simplify things for some users, but it renders some tasks impossible -- for instance, you can't set an arbitrary type code with anything based on libparted. OS X's Disk Utility translates known GUIDs to plain-text descriptions. (IIRC, when you create a partition it sets an appropriate type code based on the filesystem created in a partition, similar to what GParted does.)

For the most part, Linux doesn't use type codes, for either MBR or GPT. That is, you can put your standard Linux filesystem on a (GPT fdisk) 8300 partition, or use 0700 (as was common in the past), or assign your own random GUID. Similar comments apply to RAID, LVM, swap, and other partition types. There are a few exceptions to this rule, though. For one, distribution installers often look at and set type codes, so you may need the right type code on a partition before it will be used properly. Another exception is that systemd is starting to make use of type codes as a fallback if /etc/fstab isn't properly configured. (That's where most of GPT fdisk's 830x codes originate -- they're part of the Discoverable Partitions Specification, which is a Freedesktop/systemd initiative.) Currently, Ubuntu is just using the main Linux filesystem type code (8300 in GPT fdisk) for filesystems, plus the appropriate codes for LVM, RAID, swap, etc. One big exception to the "Linux doesn't use type codes" rules is the BIOS Boot Partition code (21686148-6449-6E6F-744E-656564454649; ef02 in GPT fdisk or the bios_grub flag in libparted). This type code identifies a partition used by GRUB, and when you run grub-install, GRUB will install part of itself to that partition. If you install GRUB on a BIOS-booting system with a GPT disk, a BIOS Boot Partition must normally be present. (There are ways around this rule, though.) More importantly, if you mistakenly set this type code on the wrong partition, that partition will be damaged when you install GRUB! I've seen quite a few people make that mistake in various online forums.

Where type codes become more important is when dealing with other OSes. Windows and OS X, for instance, tend not to touch partitions with type codes they don't recognize. Their list of type codes excludes common Linux-specific type codes, so using a Linux-specific type code helps reduce the risk that Windows or OS X will trash your Ubuntu installation. These OSes don't care if you use the GPT fdisk 8300 or fd00 code, though. Problems can arise if you use codes that are recognized by these other OSes. For instance, at one time the Linux filesystem type GUID (0FC63DAF-8483-4772-8E79-3D69D8477DE4) did not exist. I created it and pushed it into both my own GPT fdisk and libparted because the common practice of using the "Microsoft Basic Data" type code (EBD0A0A2-B9E5-4433-87C0-68B6B72699C7) was causing problems in dual-boot setups. Specifically, certain Windows tools would think the Linux partition was a damaged or un-initialized Windows partition and offer to prepare it. User error at this prompt would be disastrous. See this page of mine for more on this subject.

Solution 2

Lists of assigned partition types to be used in the partition table were originally maintained by IBM and Microsoft internally.

When the market of PC operating systems and disk tools grew and liberated, other vendors had a need to assign special partition types to their products as well.

Several industry experts in the 1990s started to research partition types and published partition type lists in order to help document the industry de facto standard and thereby reduce the risk of further conflicts.

It is up to an operating system's boot loader and/or kernel how to interpret the value. So the table specifies which operating systems or disk-related products originally introduced an ID and what file system or special partition type they mapped it to.

Partition ID: 83h. Type: file system. Origin: GNU/Linux. Description: any native Linux file system.

Partition ID: FDh. Origin: GNU/Linux. Supported: Linux. Description: Linux RAID superblock with auto-detect.

Comments

[Samuel Harmer]

Great explanation. For anyone else looking for the mapping of GPT fdisk codes to GUIDs, it's here.

[flee]

I should have given a more detailed example, with my full dataset there are 20-30 other alterative replacement codes and not all are single letters (e.g. "pond" and "Pond" become "Pnd" and "Sound" and "sounds" become "Snd"). So I need a solution that uses the values in my_replace$replacement., rather than relying on deleting part of the word.

[Tim Biegeleisen]

@flee Well for 20-30 other target matches, you could just expand the alternation in my answer to include them.