logo

oasis-root

Compiled tree of Oasis Linux based on own branch at <https://hacktivis.me/git/oasis/> git clone https://anongit.hacktivis.me/git/oasis-root.git

getcwd.3p (7987B)


  1. '\" et
  2. .TH GETCWD "3P" 2017 "IEEE/The Open Group" "POSIX Programmer's Manual"
  3. .\"
  4. .SH PROLOG
  5. This manual page is part of the POSIX Programmer's Manual.
  6. The Linux implementation of this interface may differ (consult
  7. the corresponding Linux manual page for details of Linux behavior),
  8. or the interface may not be implemented on Linux.
  9. .\"
  10. .SH NAME
  11. getcwd
  12. \(em get the pathname of the current working directory
  13. .SH SYNOPSIS
  14. .LP
  15. .nf
  16. #include <unistd.h>
  17. .P
  18. char *getcwd(char *\fIbuf\fP, size_t \fIsize\fP);
  19. .fi
  20. .SH DESCRIPTION
  21. The
  22. \fIgetcwd\fR()
  23. function shall place an absolute pathname of the current working directory
  24. in the array pointed to by
  25. .IR buf ,
  26. and return
  27. .IR buf .
  28. The pathname shall contain no components that are dot or dot-dot, or
  29. are symbolic links.
  30. .P
  31. If there are multiple pathnames that
  32. \fIgetcwd\fR()
  33. could place in the array pointed to by
  34. .IR buf ,
  35. one beginning with a single
  36. <slash>
  37. character and one or more beginning with two
  38. <slash>
  39. characters, then
  40. \fIgetcwd\fR()
  41. shall place the pathname beginning with a single
  42. <slash>
  43. character in the array. The pathname shall not contain any unnecessary
  44. <slash>
  45. characters after the leading one or two
  46. <slash>
  47. characters.
  48. .P
  49. The
  50. .IR size
  51. argument is the size in bytes of the character array pointed to by the
  52. .IR buf
  53. argument. If
  54. .IR buf
  55. is a null pointer, the behavior of
  56. \fIgetcwd\fR()
  57. is unspecified.
  58. .SH "RETURN VALUE"
  59. Upon successful completion,
  60. \fIgetcwd\fR()
  61. shall return the
  62. .IR buf
  63. argument. Otherwise,
  64. \fIgetcwd\fR()
  65. shall return a null pointer and set
  66. .IR errno
  67. to indicate the error. The contents of the array pointed to by
  68. .IR buf
  69. are then undefined.
  70. .SH ERRORS
  71. The
  72. \fIgetcwd\fR()
  73. function shall fail if:
  74. .TP
  75. .BR EINVAL
  76. The
  77. .IR size
  78. argument is 0.
  79. .TP
  80. .BR ERANGE
  81. The
  82. .IR size
  83. argument is greater than 0, but is smaller than the length of
  84. the string +1.
  85. .P
  86. The
  87. \fIgetcwd\fR()
  88. function may fail if:
  89. .TP
  90. .BR EACCES
  91. Search permission was denied for the current directory, or read or search
  92. permission was denied for a directory above the current directory in
  93. the file hierarchy.
  94. .TP
  95. .BR ENOMEM
  96. Insufficient storage space is available.
  97. .LP
  98. .IR "The following sections are informative."
  99. .SH EXAMPLES
  100. The following example uses
  101. {PATH_MAX}
  102. as the initial buffer size (unless it is indeterminate or very large),
  103. and calls
  104. \fIgetcwd\fR()
  105. with progressively larger buffers until it does not give an
  106. .BR [ERANGE]
  107. error.
  108. .sp
  109. .RS 4
  110. .nf
  111. #include <stdlib.h>
  112. #include <errno.h>
  113. #include <unistd.h>
  114. .P
  115. \&...
  116. .P
  117. long path_max;
  118. size_t size;
  119. char *buf;
  120. char *ptr;
  121. .P
  122. path_max = pathconf(".", _PC_PATH_MAX);
  123. if (path_max == -1)
  124. size = 1024;
  125. else if (path_max > 10240)
  126. size = 10240;
  127. else
  128. size = path_max;
  129. .P
  130. for (buf = ptr = NULL; ptr == NULL; size *= 2)
  131. {
  132. if ((buf = realloc(buf, size)) == NULL)
  133. {
  134. ... handle error ...
  135. }
  136. .P
  137. ptr = getcwd(buf, size);
  138. if (ptr == NULL && errno != ERANGE)
  139. {
  140. ... handle error ...
  141. }
  142. }
  143. \&...
  144. free (buf);
  145. .fi
  146. .P
  147. .RE
  148. .SH "APPLICATION USAGE"
  149. If the pathname obtained from
  150. \fIgetcwd\fR()
  151. is longer than
  152. {PATH_MAX}
  153. bytes, it could produce an
  154. .BR [ENAMETOOLONG]
  155. error if passed to
  156. \fIchdir\fR().
  157. Therefore, in order to return to that directory it may be necessary to
  158. break the pathname into sections shorter than
  159. {PATH_MAX}
  160. bytes and call
  161. \fIchdir\fR()
  162. on each section in turn (the first section being an absolute pathname and
  163. subsequent sections being relative pathnames). A simpler way to handle
  164. saving and restoring the working directory when it may be deeper than
  165. {PATH_MAX}
  166. bytes in the file hierarchy is to use a file descriptor and
  167. \fIfchdir\fR(),
  168. rather than
  169. \fIgetcwd\fR()
  170. and
  171. \fIchdir\fR().
  172. However, the two methods do have some differences. The
  173. \fIfchdir\fR()
  174. approach causes the program to restore a working directory even
  175. if it has been renamed in the meantime, whereas the
  176. \fIchdir\fR()
  177. approach restores to a directory with the same name as the original,
  178. even if the directories were renamed in the meantime. Since the
  179. \fIfchdir\fR()
  180. approach does not access parent directories, it can succeed when
  181. \fIgetcwd\fR()
  182. would fail due to permissions problems. In applications conforming to
  183. earlier versions of this standard, it was not possible to use the
  184. \fIfchdir\fR()
  185. approach when the working directory is searchable but not readable,
  186. as the only way to open a directory was with O_RDONLY, whereas the
  187. \fIgetcwd\fR()
  188. approach can succeed in this case.
  189. .SH RATIONALE
  190. Having
  191. \fIgetcwd\fR()
  192. take no arguments and instead use the
  193. \fImalloc\fR()
  194. function to produce space for the returned argument was considered.
  195. The advantage is that
  196. \fIgetcwd\fR()
  197. knows how big the working directory pathname is and can allocate an
  198. appropriate amount of space. But the programmer would have to use the
  199. \fIfree\fR()
  200. function to free the resulting object, or each use of
  201. \fIgetcwd\fR()
  202. would further reduce the available memory. Finally,
  203. \fIgetcwd\fR()
  204. is taken from the SVID where it has the two arguments used in this volume of POSIX.1\(hy2017.
  205. .P
  206. The older function
  207. .IR getwd (\|)
  208. was rejected for use in this context because it had only a buffer
  209. argument and no
  210. .IR size
  211. argument, and thus had no way to prevent overwriting the buffer, except
  212. to depend on the programmer to provide a large enough buffer.
  213. .P
  214. On some implementations, if
  215. .IR buf
  216. is a null pointer,
  217. \fIgetcwd\fR()
  218. may obtain
  219. .IR size
  220. bytes of memory using
  221. \fImalloc\fR().
  222. In this case, the pointer returned by
  223. \fIgetcwd\fR()
  224. may be used as the argument in a subsequent call to
  225. \fIfree\fR().
  226. Invoking
  227. \fIgetcwd\fR()
  228. with
  229. .IR buf
  230. as a null pointer is not recommended in conforming applications.
  231. .P
  232. Earlier implementations of
  233. \fIgetcwd\fR()
  234. sometimes generated pathnames like
  235. .BR \(dq../../../subdirname\(dq
  236. internally, using them to explore the path of ancestor directories back
  237. to the root. If one of these internal pathnames exceeded
  238. {PATH_MAX}
  239. in length, the implementation could fail with
  240. .IR errno
  241. set to
  242. .BR [ENAMETOOLONG] .
  243. This is no longer allowed.
  244. .P
  245. If a program is operating in a directory where some (grand)parent
  246. directory does not permit reading,
  247. \fIgetcwd\fR()
  248. may fail, as in most implementations it must read the directory to
  249. determine the name of the file. This can occur if search, but not read,
  250. permission is granted in an intermediate directory, or if the program
  251. is placed in that directory by some more privileged process (for
  252. example, login). Including the
  253. .BR [EACCES]
  254. error condition makes the reporting of the error consistent and warns
  255. the application developer that
  256. \fIgetcwd\fR()
  257. can fail for reasons beyond the control of the application developer or
  258. user. Some implementations can avoid this occurrence (for example, by
  259. implementing
  260. \fIgetcwd\fR()
  261. using
  262. .IR pwd ,
  263. where
  264. .IR pwd
  265. is a set-user-root process),
  266. thus the error was made optional. Since this volume of POSIX.1\(hy2017 permits the addition of
  267. other errors, this would be a common addition and yet one that
  268. applications could not be expected to deal with without this addition.
  269. .SH "FUTURE DIRECTIONS"
  270. None.
  271. .SH "SEE ALSO"
  272. .IR "\fImalloc\fR\^(\|)"
  273. .P
  274. The Base Definitions volume of POSIX.1\(hy2017,
  275. .IR "\fB<unistd.h>\fP"
  276. .\"
  277. .SH COPYRIGHT
  278. Portions of this text are reprinted and reproduced in electronic form
  279. from IEEE Std 1003.1-2017, Standard for Information Technology
  280. -- Portable Operating System Interface (POSIX), The Open Group Base
  281. Specifications Issue 7, 2018 Edition,
  282. Copyright (C) 2018 by the Institute of
  283. Electrical and Electronics Engineers, Inc and The Open Group.
  284. In the event of any discrepancy between this version and the original IEEE and
  285. The Open Group Standard, the original IEEE and The Open Group Standard
  286. is the referee document. The original Standard can be obtained online at
  287. http://www.opengroup.org/unix/online.html .
  288. .PP
  289. Any typographical or formatting errors that appear
  290. in this page are most likely
  291. to have been introduced during the conversion of the source files to
  292. man page format. To report such errors, see
  293. https://www.kernel.org/doc/man-pages/reporting_bugs.html .