Two points

    screenshot of the console that rips the template

    In the picture above, you can see how ls thinks linkylink / .. is not the same as the current directory. At the same time, cd does not seem to agree with him.

    I'll start the story with all the familiar web addresses that look like system paths.

    Two points in URI paths (on the web)


    The interpretation of points is described in section 5.2.4 of RFC 3986 .
    It works like this: each segment of two points destroys the previous segment:

    /a/b/c/../../g <=> / a / g

    at the same time, if there is nothing to destroy, two points are ignored:

    example.com/../../../etc/passwd <=> example.com/etc/passwd

    The rules were invented so that relative paths (../img/pic.png) could be converted to absolute prefixes from the uri context:

    1. /a/css/index.css refers to ../img/pic.png
    2. in /a/css/index.css everything is destroyed after the last slash => / a / css /
    3. ../img/pic.png is added to / a / css / => /a/css/../img/pic.png
    4. points are interpreted => /a/img/pic.png

    These operations are usually done by the browser when it converts relative uri to absolute. Also, according to the standard , the operation of destroying points must be performed when the uri is converted to the canonical form - normalization - including absolute uri.

    Web servers in the wild do not encounter requests containing dots and each processes them in its own way.

    In general, based on the normalization rule, it follows that in the uri of the form 'http://example.com/a/b/../c' 'b' is not required to exist.

    Two points in the shell


    The shell command cd behaves in a similar way: two points always behave one segment of the path above, as if undoing the previous transition to a subdirectory. But, unlike uri, the shell checks for the existence of intermediate directories.

    If you think the first is natural, then this publication is for you. In fact, the shell emulates this behavior of cd: in all other places * nix ".." works differently.


    Even the built-in source command (or its synonym ".") Has a different behavior from cd.

    The difference is manifested in symbolic links to directories: for cd, clicking on such a link is reversible through "..", while the rest of the system will perceive ".." as physical parent of the directory referenced.

    In another way, the first behavior is called logical (-L in pwd and cd), as opposed to physical (-P).

    Two points in the file system


    In * nix, ".." is the real subdirectory, the only physical parent independent of symbolic links. If you look inside the ext2 file system, then the description of the subdirectories ".." and "." will not be different from others, except that they are listed at the beginning.

    In some cases (for example, in FreeBSD ) this fact is even used to calculate the path to the working directory (which is not stored there separately), through successive jumps to "..".

    Going along a path is the same as going to subdirectories in sequence.

    It is easy to see that if we got into some directory using a symbolic link, then we don’t have any information left to return: ".." will indicate the physical parent. But how then does cd work with logical paths that include symlinks? For this, the shell remembers the path by which it came to the catalog. The logical path constructed by the shell is accessible via the $ PWD environment variable or via pwd [-L].


    Two points require attention, especially in scripts.

    PS: There are a lot of symbolic links to directories in sysfs:

    bug @ earth / sys / class / net / lo% ls
    addr_assign_type flags phys_port_id
    address gro_flush_timeout phys_switch_id
    addr_len ifalias power
    ...
    bug @ earth / sys / class / net / lo% ls ..
    lo
    bug @ earth / sys / class / net / lo% pwd -P; pwd -L
    / sys / devices / virtual / net / lo
    / sys / class / net / lo
    bug @ earth / sys / class / net / lo% cd ..; ls
    eth0 lo
    

    Also popular now: