0

On all systems I know about, passing a name with no preceding path opens the path relative to the current working directory. However, how reliable is this practice, compared to, for example, always using an absolute path and prepending the result of getenv("HOME") or getpwuid(getuid()) (see Get home directory in Linux).

Which practice is more standard or reliable or recommended? It is certainly simpler to use the relative path with no preceding /, as there is no allocating memory to concatenate strings, but what are the downsides to this practice over manually concatenating the absolute path of the home directory?

user16217248
  • 3,119
  • 19
  • 19
  • 37
  • Depends entirely on the use case. – dbush Jan 25 '22 at 19:45
  • @dbush For example which use cases should I use one over the other – user16217248 Jan 25 '22 at 19:45
  • Not opinion based as I am looking for objective pros and cons of each practice based on which I can form an opinion – user16217248 Jan 25 '22 at 19:46
  • The working directory and the home directory are not the same thing. Why do you want to replace one with the other? – user17732522 Jan 25 '22 at 19:46
  • @user17732522 Are you sure because when I type `pwd` in the terminal (print working directory) the result is the same as when I print the result of `getenv("HOME")` – user16217248 Jan 25 '22 at 19:48
  • 1
    I don't understand the question. You should use relative paths when you want to refer a file that is known to be in a certain *relative* position to the working directory (if your project and associated files have a well defined structure). You would use absolute path in case the file you need is usually in a fixed absolute position, but your working directory might vary. – Eugene Sh. Jan 25 '22 at 19:48
  • 1
    @user16217248 Not if you change your working directory before calling the program, e.g. with `cd some_directory`. The working directory is the path from which the executable was called. The home directory is a specific directory belonging to the user running the program. – user17732522 Jan 25 '22 at 19:48
  • Note: There is no point asking about what 'Standard C' says, because C does not have any notion of 'relative' or 'absolute' paths. The means by which filenames are composed or handled is completely implementation defined. – user16217248 Oct 18 '22 at 04:04

1 Answers1

0

Given that relative paths use the current working directory of program, the behavior depends on how well defined or reliable the 'default' working directory is, which in not necessarily the same as the home directory.

Obtaining the home directory manually (via getenv("HOME") or getpwuid(getuid())), and then passing it to the chdir() function to manually define the working directory to be the home directory causes reliable behavior if I use relative paths for fopen()/open()/etc.

user16217248
  • 3,119
  • 19
  • 19
  • 37
  • 1
    Mostly true, provided that the behavior the program wants to rely upon is interpreting paths relative to the home directory of the user running it. And occasionally that *is* what programs want to do, but it is far more common to want to access files relative to the program's installation directory or relative to its original working directory. Few programs should ever call `chdir()`. The main exceptions I can think of are shells. – John Bollinger Oct 18 '22 at 03:58
  • @JohnBollinger How about an application that needs to save configuration data such as user settings? – user16217248 Oct 18 '22 at 04:04
  • How about it? As I said, occasionally a program does want to access files relative to the user's home directory. But such operations are comparatively rare for most programs, and *never* a good reason to programmatically `chdir()`. – John Bollinger Oct 18 '22 at 04:09
  • @JohnBollinger So `chdir()` is *not* a good way to even open files relative to the user's home directory? Why not? – user16217248 Oct 18 '22 at 04:11
  • No, it is not. More precisely, it is not a good way to open files whose paths are defined relative to the user's home directory specifically. Since one cannot rely on the working directory to be the user's home directory, it follows that you should form an absolute path in such cases. – John Bollinger Oct 18 '22 at 04:16
  • @JohnBollinger Is it possible for an external process to change a program's working directory arbitrarily? – user16217248 Oct 18 '22 at 04:17
  • 1
    No operating system I know has a defined mechanism for such an action. A program's initial working directory can be controlled by the circumstances of its launch, but after that, the wd is entirely under the program's own control. – John Bollinger Oct 18 '22 at 04:23
  • @JohnBollinger But then, with `chdir()` one *could* rely on the working directory to be the user's home directory. So why is this discouraged? Is it because later if I want to use the actual working directory I won't be able to because I `chdir()`ed it to the home directory? – user16217248 Oct 18 '22 at 06:40
  • 1
    There is a variety of reasons why `chdir()` can be problemmatic. Among them are: (i) it changes the interpretation of file names given on the command line; (ii) it is prone to causing conflicts between threads; (iii) it is prone to causing conflict between different functions even without threads; (iv) it interferes with the ability to access paths relative to the initial working directory, which is a common need; (v) it's confusing. Yes, you can work around most of those, but for most purposes it is a better idea to just avoid `chdir()`. – John Bollinger Oct 18 '22 at 12:26