tmp/tmp2tip0dn7/{from.md → to.md}
RENAMED
|
@@ -0,0 +1,62 @@
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| 1 |
+
##### `path` argument format conversions <a id="fs.path.fmt.cvt">[[fs.path.fmt.cvt]]</a>
|
| 2 |
+
|
| 3 |
+
[*Note 1*:
|
| 4 |
+
|
| 5 |
+
The format conversions described in this section are not applied on
|
| 6 |
+
POSIX-based operating systems because on these systems:
|
| 7 |
+
|
| 8 |
+
- The generic format is acceptable as a native path.
|
| 9 |
+
- There is no need to distinguish between native format and generic
|
| 10 |
+
format in function arguments.
|
| 11 |
+
- Paths for regular files and paths for directories share the same
|
| 12 |
+
syntax.
|
| 13 |
+
|
| 14 |
+
— *end note*]
|
| 15 |
+
|
| 16 |
+
Several functions are defined to accept *detected-format* arguments,
|
| 17 |
+
which are character sequences. A detected-format argument represents a
|
| 18 |
+
path using either a pathname in the generic format (
|
| 19 |
+
[[fs.path.generic]]) or a pathname in the native format (
|
| 20 |
+
[[fs.def.native]]). Such an argument is taken to be in the generic
|
| 21 |
+
format if and only if it matches the generic format and is not
|
| 22 |
+
acceptable to the operating system as a native path.
|
| 23 |
+
|
| 24 |
+
[*Note 2*: Some operating systems may have no unambiguous way to
|
| 25 |
+
distinguish between native format and generic format arguments. This is
|
| 26 |
+
by design as it simplifies use for operating systems that do not require
|
| 27 |
+
disambiguation. An implementation for an operating system where
|
| 28 |
+
disambiguation is required is permitted to distinguish between the
|
| 29 |
+
formats. — *end note*]
|
| 30 |
+
|
| 31 |
+
Pathnames are converted as needed between the generic and native formats
|
| 32 |
+
in an operating-system-dependent manner. Let *G(n)* and *N(g)* in a
|
| 33 |
+
mathematical sense be the implementation’s functions that convert
|
| 34 |
+
native-to-generic and generic-to-native formats respectively. If
|
| 35 |
+
*g=G(n)* for some *n*, then *G(N(g))=g*; if *n=N(g)* for some *g*, then
|
| 36 |
+
*N(G(n))=n*.
|
| 37 |
+
|
| 38 |
+
[*Note 3*: Neither *G* nor *N* need be invertible. — *end note*]
|
| 39 |
+
|
| 40 |
+
If the native format requires paths for regular files to be formatted
|
| 41 |
+
differently from paths for directories, the path shall be treated as a
|
| 42 |
+
directory path if its last element is a *directory-separator*, otherwise
|
| 43 |
+
it shall be treated as a path to a regular file.
|
| 44 |
+
|
| 45 |
+
[*Note 4*: A path stores a native format pathname (
|
| 46 |
+
[[fs.path.native.obs]]) and acts as if it also stores a generic format
|
| 47 |
+
pathname, related as given below. The implementation may generate the
|
| 48 |
+
generic format pathname based on the native format pathname (and
|
| 49 |
+
possibly other information) when requested. — *end note*]
|
| 50 |
+
|
| 51 |
+
When a path is constructed from or is assigned a single representation
|
| 52 |
+
separate from any path, the other representation is selected by the
|
| 53 |
+
appropriate conversion function (*G* or *N*).
|
| 54 |
+
|
| 55 |
+
When the (new) value *p* of one representation of a path is derived from
|
| 56 |
+
the representation of that or another path, a value *q* is chosen for
|
| 57 |
+
the other representation. The value *q* converts to *p* (by *G* or *N*
|
| 58 |
+
as appropriate) if any such value does so; *q* is otherwise unspecified.
|
| 59 |
+
|
| 60 |
+
[*Note 5*: If *q* is the result of converting any path at all, it is
|
| 61 |
+
the result of converting *p*. — *end note*]
|
| 62 |
+
|