{"id":170,"date":"2020-08-18T19:23:47","date_gmt":"2020-08-18T20:23:47","guid":{"rendered":"http:\/\/www.linux-tutorial.info\/?page_id=77"},"modified":"2020-08-22T19:26:01","modified_gmt":"2020-08-22T20:26:01","slug":"this-is-the-page-title-toplevel-4","status":"publish","type":"page","link":"http:\/\/www.linux-tutorial.info\/?page_id=170","title":{"rendered":"Files and Directories"},"content":{"rendered":"\nFiles and Directories<\/title>\n<p>\nAnother key aspect of any <glossary>operating system<\/glossary> is the concept of a file. A file is nothing\nmore than a related set of bytes on disk or other media. These bytes are labeled with a\nname, which is then used as a means of referring to that set of bytes. In most cases, it\nis through the name that the <glossary>operating system<\/glossary>\nis able to track down the file’s exact location on the disk.\n<\/p>\n<p>\n<question id=\"9\" text=\"Linux accesses files using\" \/>\nThere are three kinds of files with which most people are familiar: programs, text\nfiles, and data files. However, on a <glossary>UNIX<\/glossary>\nsystem, there are other kinds of files. One of\nthe most common is a device file. These are often referred to as <em>device files<\/em> or\n<em>device nodes<\/em>. Under <glossary>UNIX<\/glossary>,\n every device is treated as a file. Access is gained to\nthe hardware by the <glossary>operating system<\/glossary>\nthrough the device files. These tell the system what\nspecific <glossary>device driver<\/glossary>\nneeds to be used to access the hardware.\n<\/p>\n<question id=\"11\" text=\"Pipes take up physical space on the hard disk.\" \/>\n<p>\nAnother kind of file is a <glossary>pipe<\/glossary>. Like a real pipe, stuff goes in one end and\nout the other. Some are named pipes. That is, they have a name and are located permanently\non the hard disk. Others are temporary and are unnamed pipes. Although these do not exist\nonce the process using them has ended, they do take up physical space on the hard disk.\nWe’ll talk more about pipes <site id=\"21\">later<\/site>.\n<\/p>\n<p>\nUnlike operating systems like <glossary>DOS<\/glossary>, there is no pattern for file names\nthat is expected or followed. <glossary>DOS<\/glossary>\nwill not even attempt to execute programs that do not end with .EXE,\n.COM, or .BAT. <glossary>UNIX<\/glossary>,\non the other hand, is just as happy to execute a program called\nprogram as it is a program called program.txt. In fact, you can use any character in a\nfile name except for “\/” and NULL.\n<\/p>\n<concept id=\"13\" description=\"Linux uses a file's 'magic number' to determine what kind of file it is.\" \/>\n<p>\nHowever, completely random things can happen if the <glossary>operating system<\/glossary>\ntries to execute a text file as if it were a <glossary>binary<\/glossary> program. To prevent\nthis, <glossary>UNIX<\/glossary> has two mechanisms to ensure that text\ndoes not get randomly executed. The first is the file’s permission bits.\nThe permission bits determine who can read, write, and execute a particular file. You can\nsee the <glossary>permissions<\/glossary>\nof a file by doing a long listing of that file. What the permissions\nare all about, we get into a little later. The second is that the system must recognize a\n<em>magic number<\/em> within the program indicating that it is a <glossary>binary<\/glossary>\nexecutable. To see\nwhat kinds of files the system recognizes, take a look in <file type=\"\">\/etc\/magic<\/file>. This file contains a\nlist of file types and information that the system uses to determine a file’s type.\n<\/p>\n<p>\nEven if a file was set to allow you to execute it, the beginning portion of the file must contain\nthe right information to tell the <glossary>operating system<\/glossary> how to start this program.\nIf that information is missing, it will attempt to start it as a <glossary>shell<\/glossary> script\n(similar to a <glossary>DOS<\/glossary> batch file). If the lines in the file do not belong to a\n<glossary>shell script<\/glossary> and you try to execute the program, you end up with a screen full\nof errors.\n<\/p>\n<question id=\"12\" text=\"In contrast to Windows, a Linux program does not need a special extension.\" \/>\n<question id=\"432\" text=\"Unlike DOS, a Linux file name can contain multiple dots.\" \/>\n<concept id=\"210\" description=\"Unlike DOS, a Linux file name can contain multiple dots.\" \/>\n<concept id=\"12\" description=\"File and directory names do not have the same limitations under Linux as they do under Windows.\" \/>\n<p>\nWhat you name your file is up to you. You are not limited by the eight-letter name and\nthree-letter extension as you are in <glossary>DOS<\/glossary>. You can still use periods as\nseparators, but that’s all they are. They do not have the same “special” meaning that they do under\nDOS. For example, you could have files called\n<\/p>\n<p>\nletter.txt <br \/>\nletter.text <br \/>\nletter_txt <br \/>\nletter_to_jim<br \/>\nletter.to.jim<br \/>\n<p>\nOnly the first file example is valid under <glossary>DOS<\/glossary>,\n but all are valid under Linux. Note that even in older versions of <glossary>UNIX<\/glossary>\nwhere you were limited to 14 characters in a file name, all of these are still valid. With Linux, I\nhave been able to create file names that are 255 characters long. However, such long file names\nare not easy to work with. Note that if you are running either Windows NT or\n<glossary>Windows 95<\/glossary>, you can create file names that are basically the same as\nwith Linux.\n<\/p>\n<p>\nAlso keep in mind that although you can create file names with spaces in them, it can\ncause problems. Spaces are used to seperate the different components on the command line. You can\ntell your shell to treat a name with spaces as a single unit by including it in quotes. However, you\nneed to be careful. Typically, I simply use an underline (_) when the file name ought to have a\nspace. It almost looks the same and I don’t run into problems.\n<\/p>\n<p>\nOne naming convention does have special meaning in Linux: “dot” files. In these files,\nthe first character is a “.” (dot). If you have such a file, it will by default be\ninvisible to you. That is, when you do a listing of a <glossary>directory<\/glossary>\ncontaining a “dot” file, you won’t see it.\n<\/p>\n<concept id=\"14\" description=\"Files and directories that start with a dot ('.') are not normally displayed in a directory listing.\" \/>\n<question id=\"10\" text=\"Linux does not have 'hidden' files like Windows.\" \/>\n<question id=\"431\" text=\"What would you do to create a 'hidden' file in Linux?\" \/>\n<concept id=\"81\" description=\"A dot (.) as the first character in a file makes it 'hidden'.\" \/>\n<p>\nHowever, unlike the <glossary>DOS<\/glossary>\/Windows concept of “hidden” files, “dot” files\ncan be seen by simply using the -a (all) option to <command>ls<\/command>, as in ls -a. (ls is a command\nused to list the contents of directories.) With DOS\/Windows the “dir” command can show\nyou hidden files and directories, but has no option to show these along with the\nothers.\n<\/p>\n<question id=\"16\" text=\"Files and directories are grouped into units called\" \/>\n<p>\nThe ability to group your files together into some kind of organizational structure is very\nhelpful. Instead of having to wade through thousands of files on your hard disk to find the one you\nwant, Linux, along with other operating systems, enables you to group the files into a\n<em><glossary>directory<\/glossary><\/em>. Under Linux, a directory is actually nothing more than a file itself with a\nspecial format. It contains the names of the files associated with it and some pointers or other\ninformation to tell the system where the data for the file actually reside on the hard disk.\n<\/p>\n<p>\nDirectories do not actually “contain” the files that are associated with them. Physically (that\nis, how they exist on the disk), directories are just files in a certain format. The <glossary>directory<\/glossary>\nstructure is imposed on them by the program you use, such as ls.\n<\/p>\n<question id=\"13\" text=\"Directories reference files using\" \/>\n<p>\nThe directories have information that points to where the real files are. In comparison, you\nmight consider a phone book. A phone book does not contain the people listed in it, just their\nnames and telephone numbers. A <glossary>directory<\/glossary> has the same information: the names of files and their\nnumbers. In this case, instead of a telephone number, there is an information node number, or <em>inode<\/em> number.\n<\/p>\n<p>\nThe logical structure in a telephone book is that names are grouped alphabetically. It is very\ncommon for two entries (names) that appear next to each other in the phone book to be in different\nparts of the city. Just like names in the phone book, names that are next to each other in a\n<glossary>directory<\/glossary> may be in distant parts of the hard disk.\n<\/p>\n<p>\nAs I mentioned, directories are logical groupings of files. In fact, directories are nothing more\nthan files that have a particular structure imposed on them. It is common to say that the <glossary>directory<\/glossary>\n“contains” those files or the file is “in” a particular directory. In a sense, this is true. The\nfile that is the directory “contains” the name of the file. However, this is the only connection\nbetween the directory and file, but we will continue to use this terminology. You can find more details about this in the <site id=\"95\">section on files and file systems<\/site>.\n<\/p>\n<p>\nOne kind of file is a <glossary>directory<\/glossary>. What this kind of file can\ncontain are files and more directories. These, in turn, can contain still\nmore files and directories. The result is a hierarchical tree structure of directories, files, more\ndirectories, and more files. Directories that contain other directories are referred to as the\n<em>parent<\/em> directory of the <em>child<\/em> or <glossary>subdirectory<\/glossary> that they\ncontain. (Most references I have seen refer only to parent and subdirectories. Rarely have I seen references to child directories.)<\/p>\n<p>\nWhen referring to directories under <glossary>UNIX<\/glossary>,\nthere is often either a leading or trailing slash (“\/”), and sometimes both. The top of the\ndirectory tree is referred to with a single “\/” and is called the “root” directory. Subdirectories\nare referred to by this slash followed by their name, such as \/bin or \/dev. As you proceed down the\ndirectory tree, each subsequent directory is separated by a slash. The concatenation of slashes and\ndirectory names is referred to as a path. Several levels down, you might end up with a path such as\n<file type=\"\">\/home\/jimmo\/letters\/personal\/chris.txt<\/file>, where chris.txt is the actual\nfile and <file type=\"\">\/home\/jimmo\/letters\/personal<\/file> is all of the directories leading to\nthat file. The directory <directory>\/home<\/directory> contains the <glossary>subdirectory<\/glossary> jimmo, which contains the subdirectory letters, which\ncontains the subdirectory personal. This directory contains the file chris.txt.\n<\/p>\n<concept id=\"16\" description=\"Although you change directories with the 'cd' command, or move up and down the directory tree, you do not actually move anywhere.\" \/>\n<p>\nMovement up and down the tree is accomplished by the means of the cd (change directory) command,\nwhich is part of your <glossary>shell<\/glossary>. Although this is often difficult to grasp at\nfirst, you are not actually moving anywhere. One of the things that the\n<glossary>operating system<\/glossary> keeps track of within the context of each process is the process’s\n<em> current directory<\/em>, also referred to as the <em>current working directory<\/em>. This is merely the name\nof a directory on the system. Your process has no physical contact with this directory; it is\njust keeping the directory name in memory.\n<\/p>\n<p>\nWhen you change directories, this portion of the process memory is changed to reflect your new\n“location.” You can “move” up and down the tree or make jumps to completely unrelated parts of the\ndirectory tree. However, all that really happens is that the\n<glossary>current working directory<\/glossary> portion of your process gets changed.\n<\/p>\n<p>\nAlthough there can be many files with the same name, each <em>combination<\/em> of directories\nand file name must be unique. This is because the <glossary>operating system<\/glossary> refers to\nevery file on the system by this unique combination of directories and file name. In the example\nabove, I have a personal letter called chris.txt. I might also have a business letter by the same\nname. Its path (or the combination of directory and file name) would be\n<file type=\"\">\/home\/jimmo\/letters\/business\/chris.txt<\/file>. Someone else named John might\nalso have a business letter to\nChris. John’s path (or combination of path and file name) might be\n<file type=\"\">\/home\/john\/letters\/business\/chris.txt<\/file>. This might look something like this:\n<p>\n<img decoding=\"async\" src=\"home_dir.png\" width=367 height=236 border=0 usemap=#home_dir_map>\n<map name=\"home_dir_map\">\n<area shape=\"RECT\" coords=\"95,117,360,156\" HREF=\"popup#files and directories#Both users have a directory named <i>letters<\/i>.”>\n<area shape=\"RECT\" coords=\"93,79,202,113\" HREF=\"popup#files and directories#This is the home directory for the user <i>jimmo<\/i>.”>\n<area shape=\"RECT\" coords=\"278,80,357,113\" HREF=\"popup#files and directories#This is the home directory for the user <i>john<\/i>.”>\n<area shape=\"RECT\" coords=\"148,175,363,204\" HREF=\"popup#files and directories#Each user as a (probably) unique directory named <i>letters\/business<\/i>.”>\n<area shape=\"RECT\" coords=\"151,206,363,234\" HREF=\"popup#files and directories#Each user has a file named <i>chris.txt<\/i> which could possibly be the same physical file.”>\n<area shape=\"RECT\" coords=\"275,63,276,64\" href=\"popup#files and directories#A selection of directories directly under the root directory.\">\n<\/map>\n<p>\n<icaption>Image – Example of home directories. (<b>interactive<\/b>)<\/icaption>\n<p>\nOne thing to note is that John’s business letter to Chris may be the exact same file as Jim’s. I\nam not talking about one being a copy of the other. Rather, I am talking about a situation where\nboth names point to the same physical locations on the hard disk. Because both files are referencing\nthe same bits on the disk, they must therefore be the same file.\n<\/p>\n<question id=\"14\" text=\"Two directory entries that point to the same file are called a\" \/>\n<question id=\"430\" text=\"What is the name of the table containing the physical location of files on the hard disk?\" \/>\n<concept id=\"18\" description=\"A single inode could be referenced by hundreds of individual file names.\" \/>\n<p>\nThis is accomplished through the concept of a <em>link<\/em>. Like a chain link, a file link\nconnects two pieces together. I mentioned above the “telephone number” for a file was its\n<glossary>inode<\/glossary>. This number actually points to a special place on the disk called the\n<em>inode table<\/em>, with the inode number being the offset into this table. Each entry in this\ntable not only contains the file’s physical location on this disk, but the owner of the file, the\naccess <glossary>permissions<\/glossary>, and the number of links, as well as many other things. In\nthe case where the two files are referencing the same entry in the inode table, these are referred\nto as <em>hard links<\/em>. A <em>soft link<\/em> or <em>symbolic link<\/em> is where a file is created\nthat contains the <i>path<\/i> of the other file. We will get into the details of this later.\n<\/p>\n<question id=\"15\" text=\"The inode does not contain the file's\" \/>\n<concept id=\"17\" description=\"An inode does <b>not<\/b> contain the name of a file.” \/>\n<p>\nAn <glossary>inode<\/glossary>\ndoes <em>not<\/em> contain the name of a file. The name is <em>only<\/em> contained within the\ndirectory. Therefore, it is possible to have multiple directory entries that have the same inode.\nJust as there can be multiple entries in the phone book, all with the same phone number. We’ll get\ninto a lot more detail about inodes in the section on filesystems. A directory and where the inodes\npoint to on the hard disk might look like this:\n<\/p>\n<a onclick=\"opennew('{3f0b0cf5c640d99e599990c4a720721a04ec3a009b1323dd81fc335ceb655a63}{3f0b0cf5c640d99e599990c4a720721a04ec3a009b1323dd81fc335ceb655a63}CURRENT_DIRECTORY{3f0b0cf5c640d99e599990c4a720721a04ec3a009b1323dd81fc335ceb655a63}{3f0b0cf5c640d99e599990c4a720721a04ec3a009b1323dd81fc335ceb655a63}\/direntrya.gif',395,576)\" >\n<img loading=\"lazy\" decoding=\"async\" src=\"direntryc.gif\" width=\"576\" height=\"354\" border=\"0\" usemap=#direnty_map>\n<\/a>\n<map name=\"direnty_map\">\n<area shape=\"RECT\" coords=\"69,66,219,91\" href=\"popup#files and directories#Although this is a diffent name, it points to the same physical location as the other two files.\">\n<area shape=\"RECT\" coords=\"68,212,222,240\" href=\"popup#files and directories#Although this is a diffent name, it points to the same physical location as the other file.\">\n<area shape=\"RECT\" coords=\"70,95,219,121\" href=\"popup#files and directories#Although this is a diffent name, it points to the same physical location as the other file.\">\n<area shape=\"RECT\" coords=\"68,153,225,181\" href=\"popup#files and directories#Although this is a diffent name, it points to the same physical location as the other two files.\">\n<area shape=\"RECT\" coords=\"68,244,222,268\" href=\"popup#files and directories#Although this is a diffent name, it points to the same physical location as the other two files.\">\n<area shape=\"RECT\" coords=\"366,146,410,188\" href=\"popup#files and directories#In this example, there are three different files that point to this location on the hard disk.\">\n<area shape=\"RECT\" coords=\"505,135,543,176\" href=\"popup#files and directories#In this example, there are two different files that point to this location on the hard disk.\">\n<area shape=\"RECT\" coords=\"475,263,520,306\" href=\"popup#files and directories#Only one file name points to this physical location on the disk.\">\n<area shape=\"RECT\" coords=\"467,183,507,221\" href=\"popup#files and directories#Only one file name points to this physical location on the disk.\">\n<area shape=\"RECT\" coords=\"355,232,402,276\" href=\"popup#files and directories#Only one file name points to this physical location on the disk.\">\n<area shape=\"RECT\" coords=\"357,63,410,103\" href=\"popup#files and directories#Only one file name points to this physical location on the disk.\">\n<area shape=\"RECT\" coords=\"67,6,225,305\" href=\"popup#files and directories#Although file names have to be unique within a given directory, multiple files anywhere on the system can point to the same physical location on the hard disk.\">\n<area shape=\"RECT\" coords=\"2,63,66,92\" href=\"popup#files and directories#This file has the same inode as the other two files and therefore points to the exact same physical location on the hard disk.\">\n<area shape=\"RECT\" coords=\"3,153,65,180\" href=\"popup#files and directories#This file has the same inode as the other two files and therefore points to the exact same physical location on the hard disk.\">\n<area shape=\"RECT\" coords=\"0,242,64,269\" href=\"popup#files and directories#This file has the same inode as the other two files and therefore points to the exact same physical location on the hard disk.\">\n<area shape=\"RECT\" coords=\"4,95,66,119\" href=\"popup#files and directories#This file has the same inode as the other file and therefore points to the exact same physical location on the hard disk.\">\n<area shape=\"RECT\" coords=\"4,215,63,239\" href=\"popup#files and directories#This file has the same inode as the other file and therefore points to the exact same physical location on the hard disk.\">\n<area shape=\"RECT\" coords=\"1,3,68,302\" href=\"popup#files and directories#The inode is a unique number that points to the physical location on the hard disk.\">\n<\/map>\n<p>\n<icaption>Image – The relationship between file names, inodes and physical data on your hard disk. (<b>interactive<\/b>)<\/icaption>\n<p>\nLets think about the telephone book analogy once again. Although it is not common for an\nindividual to have multiple listings, there might be two people with the same number. For example,\nif you were sharing a house with three of your friends, there might be only one telephone. However,\neach of you would have an entry in the phone book. I could get the same phone to ring by dialing the\ntelephone number of four different people. I could also get to the same <glossary>inode<\/glossary>\nwith four different file names.\n<\/p>\n<p>\nUnder Linux, files and directories are grouped into units called <em>filesystems<\/em>. A\n<glossary>filesystem<\/glossary> is a portion of your hard disk that is administered as a single\nunit. Filesystems exist within a section of the hard disk called a <em>partition<\/em>. Each hard\ndisk can be broken down into multiple partitions and the filesystem is created within the\n<glossary>partition<\/glossary>. Each has specific starting and ending points that are managed by\nthe system. (Note: Some dialects of <glossary>UNIX<\/glossary> allow multiple filesystems within a\npartition.)<\/p>\n<p>\nWhen you create a <glossary>filesystem<\/glossary>\nunder Linux, this is comparable to formatting the <glossary>partition<\/glossary>\nunder <glossary>DOS<\/glossary>.\nThe filesystem structure is laid out and a table is created to tell you where the actual data are\nlocated. This table, called the <glossary>inode<\/glossary> table in\n<glossary>UNIX<\/glossary>,\nis where almost all the information related to the file is kept.\n<\/p>\n<p>\nIn an <glossary>operating system<\/glossary>\nsuch as Linux, a file is more than just the basic unit of data. Instead, almost everything is either\ntreated as a file or is only accessed through files. For example, to read the contents of a data\nfile, the operating system must access the hard disk. Linux treats the hard disk as if it were a\nfile. It opens it like a file, reads it like a file, and closes it like a file. The same applies to\nother hardware such as tape drives and printers. Even memory is treated as a file. The files used to\naccess the physical hardware are the device files that I mentioned earlier.\n<\/p>\n<p>\nWhen the <glossary>operating system<\/glossary>\nwants to access any hardware device, it first opens a file that “points” toward that device (the\ndevice node). Based on information it finds in the <glossary>inode<\/glossary>, the operating\nsystem determines what kind of device it is and can therefore access it in the proper manner. This\nincludes opening, reading, and closing, just like any other file.\n<\/p>\n<p>\nIf, for example, you are reading a file from the hard disk, not only do you have the file open\nthat you are reading, but the <glossary>operating system<\/glossary> has opened the file that\nrelates to the <glossary>filesystem<\/glossary> within the <glossary>partition<\/glossary>,\nthe partition on the hard disk, and the hard disk itself\n(more about these <site id=\"96\">later<\/site>).\nThree additional files are opened every time you log in or start a <glossary>shell<\/glossary>.\nThese are the files that relate to input, output, and error messages.\n<\/p>\n<question id=\"17\" text=\"The three files initially opened by your shell are\" \/>\n<p>\nNormally, when you <glossary>login<\/glossary>,\n you get to a <glossary>shell<\/glossary>\nprompt. When you type a command on the keyboard and press enter, a moment later something comes onto\nyour screen. If you made a mistake or the program otherwise encountered an error, there will\nprobably be some message on your screen to that effect. The keyboard where you are typing in your\ndata is the input, referred to as <glossary>standard input<\/glossary> (standard in or\n<em>stdin<\/em>) and that is where input comes from by default. The program displays a message on\nyour screen, which is the output, referred to as <glossary>standard output<\/glossary> (standard out\nor <em>stdout<\/em>). Although it appears on that same screen, the <glossary>error message<\/glossary>\nappears on <glossary>standard error<\/glossary> (<em>stderr<\/em>).\n<\/p>\n<p>\nAlthough <glossary>stdin<\/glossary>\nand <glossary>stdout<\/glossary>\nappear to be separate physical devices (keyboard and monitor), there is only one connection to the\nsystem. This is one of those device files I talked about a moment ago. When you log in, the file\n(device) is opened for both reading, so you can get data from the keyboard, and writing, so that\noutput can go to the screen and you can see the error messages.\n<\/p>\n<p>\nThese three concepts (standard in, standard out, and standard error) may be somewhat\ndifficult to understand at first. At this point, it suffices to understand that these\nrepresent input, output, and error messages. We’ll get into the details\n<tutorial id=21>a bit later.<\/tutorial>\n<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Files and Directories Another key aspect of any operating system is the concept of a file. A file is nothing more than a related set of bytes on disk or other media. These bytes are labeled with a name, which … <a href=\"http:\/\/www.linux-tutorial.info\/?page_id=170\">Continue reading <span class=\"meta-nav\">→<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"parent":0,"menu_order":0,"comment_status":"closed","ping_status":"closed","template":"","meta":{"footnotes":""},"class_list":["post-170","page","type-page","status-publish","hentry"],"_links":{"self":[{"href":"http:\/\/www.linux-tutorial.info\/index.php?rest_route=\/wp\/v2\/pages\/170","targetHints":{"allow":["GET"]}}],"collection":[{"href":"http:\/\/www.linux-tutorial.info\/index.php?rest_route=\/wp\/v2\/pages"}],"about":[{"href":"http:\/\/www.linux-tutorial.info\/index.php?rest_route=\/wp\/v2\/types\/page"}],"author":[{"embeddable":true,"href":"http:\/\/www.linux-tutorial.info\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"http:\/\/www.linux-tutorial.info\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=170"}],"version-history":[{"count":1,"href":"http:\/\/www.linux-tutorial.info\/index.php?rest_route=\/wp\/v2\/pages\/170\/revisions"}],"predecessor-version":[{"id":558,"href":"http:\/\/www.linux-tutorial.info\/index.php?rest_route=\/wp\/v2\/pages\/170\/revisions\/558"}],"wp:attachment":[{"href":"http:\/\/www.linux-tutorial.info\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=170"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}