Develop Reference

Directory and path said to exist, but not appearing when using terminal to access directory (python)? [duplicate]

My book states:
Every program that runs on your computer has a current working directory, or cwd. Any filenames or paths that do not begin with the root folder are assumed to be under the current working directory
As I am on OSX, my root folder is /. When I type in os.getcwd() in my Python shell, I get /Users/apple/Documents. Why am I getting the Documents folder in my cwd? Is it saying that Python is using Documents folder? Isn't there any path heading to Python that begins with / (the root folder)? Also, does every program have a different cwd?

Every process has a current directory. When a process starts, it simply inherits the current directory from its parent process; and it's not, for example, set to the directory which contains the program you are running.
For a more detailed explanation, read on.
When disks became large enough that you did not want all your files in the same place, operating system vendors came up with a way to structure files in directories. So instead of saving everything in the same directory (or "folder" as beginners are now taught to call it) you could create new collections and other new collections inside of those (except in some early implementations directories could not contain other directories!)
Fundamentally, a directory is just a peculiar type of file, whose contents is a collection of other files, which can also include other directories.
On a primitive operating system, that was where the story ended. If you wanted to print a file called term_paper.txt which was in the directory spring_semester which in turn was in the directory 2021 which was in the directory studies in the directory mine, you would have to say
print mine/studies/2021/spring_semester/term_paper.txt
(except the command was probably something more arcane than print, and the directory separator might have been something crazy like square brackets and colons, or something;
lpr [mine:studies:2021:spring_semester]term_paper.txt
but this is unimportant for this exposition) and if you wanted to copy the file, you would have to spell out the whole enchilada twice:
copy mine/studies/2021/spring_semester/term_paper.txt mine/studies/2021/spring_semester/term_paper.backup
Then came the concept of a current working directory. What if you could say "from now on, until I say otherwise, all the files I am talking about will be in this particular directory". Thus was the cd command born (except on old systems like VMS it was called something clunkier, like SET DEFAULT).
cd mine/studies/2021/spring_semester
print term_paper.txt
copy term_paper.txt term_paper.backup
That's really all there is to it. When you cd (or, in Python, os.chdir()), you change your current working directory. It stays until you log out (or otherwise exit this process), or until you cd to a different working directory, or switch to a different process or window where you are running a separate command which has its own current working directory. Just like you can have your file browser (Explorer or Finder or Nautilus or whatever it's called) open with multiple windows in different directories, you can have multiple terminals open, and each one runs a shell which has its own independent current working directory.
So when you type pwd into a terminal (or cwd or whatever the command is called in your command language) the result will pretty much depend on what you happened to do in that window or process before, and probably depends on how you created that window or process. On many Unix-like systems, when you create a new terminal window with an associated shell process, it is originally opened in your home directory (/home/you on many Unix systems, /Users/you on a Mac, something more or less like C:\Users\you on recent Windows) though probably your terminal can be configured to open somewhere else (commonly Desktop or Documents inside your home directory on some ostensibly "modern" and "friendly" systems).
Many beginners have a vague and incomplete mental model of what happens when you run a program. Many will incessantly cd into whichever directory contains their script or program, and be genuinely scared and confused when you tell them that you don't have to. If frobozz is in /home/you/bin then you don't have to
cd /home/you/bin
./frobozz
because you can simply run it directly with
/home/you/bin/frobozz
and similarly if ls is in /bin you most definitely don't
cd /bin
./ls
just to get a directory listing.
Furthermore, like the ls (or on Windows, dir) example should readily convince you, any program you run will look in your current directory for files. Not the directory the program or script was saved in. Because if that were the case, ls could only produce a listing of the directory it's in (/bin) -- there is nothing special about the directory listing program, or the copy program, or the word processor program; they all, by design, look in the current working directory (though again, some GUI programs will start with e.g. your Documents directory as their current working directory, by design, at least if you don't tell them otherwise).
Many beginners write scripts which demand that the input and output files are in a particular directory inside a particular user's home directory, but this is just poor design; a well-written program will simply look in the current working directory for its input files unless instructed otherwise, and write output to the current directory (or perhaps create a new directory in the current directory for its output if it consists of multiple files).
Python, then, is no different from any other programs. If your current working directory is /Users/you/Documents when you run python then that directory is what os.getcwd() inside your Python script or interpreter will produce (unless you separately os.chdir() to a different directory during runtime; but again, this is probably unnecessary, and often a sign that a script was written by a beginner). And if your Python script accepts a file name parameter, it probably should simply get the operating system to open whatever the user passed in, which means relative file names are relative to the invoking user's current working directory.
python /home/you/bin/script.py file.txt
should simply open(sys.argv[1]) and fail with an error if file.txt does not exist in the current directory. Let's say that again; it doesn't look in /home/you/bin for file.txt -- unless of course that is also the current working directory of you, the invoking user, in which case of course you could simply write
python script.py file.txt
On a related note, many beginners needlessly try something like
with open(os.path.join(os.getcwd(), "input.txt")) as data:
...
which needlessly calls os.getcwd(). Why is it needless? If you have been following along, you know the answer already: the operating system will look for relative file names (like here, input.txt) in the current working directory anyway. So all you need is
with open("input.txt") as data:
...
One final remark. On Unix-like systems, all files are ultimately inside the root directory / which contains a number of other directories (and usually regular users are not allowed to write anything there, and system administrators with the privilege to do it typically don't want to). Every relative file name can be turned into an absolute file name by tracing the path from the root directory to the current directory. So if the file we want to access is in /home/you/Documents/file.txt it means that home is in the root directory, and contains you, which contains Documents, which contains file.txt. If your current working directory were /home you could refer to the same file by the relative path you/Documents/file.txt; and if your current directory was /home/you, the relative path to it would be Documents/file.txt (and if your current directory was /home/you/Music you could say ../Documents/file.txt but let's not take this example any further now).
Windows has a slightly different arrangement, with a number of drives with single-letter identifiers, each with its own root directory; so the root of the C: drive is C:\ and the root of the D: drive is D:\ etc. (and the directory separator is a backslash instead of a slash, although you can use a slash instead pretty much everywhere, which is often a good idea for preserving your sanity).

Your python interpreter location is based off of how you launched it, as well as subsequent actions taken after launching it like use of the os module to navigate your file system. Merely starting the interpreter will place you in the directory of your python installation (not the same on different operating systems). On the other hand, if you start by editing or running a file within a specific directory, your location will be the folder of the file you were editing. If you need to run the interpreter in a certain directory and you are using idle for example, it is easiest to start by creating a python file there one way or another and when you edit it you can start a shell with Run > Python Shell which will already be in that directory. If you are using the command line interpreter, navigate to the folder where you want to run your interpreter before running the python/python3/py command. If you need to navigate manually, you can of course use the following which has already been mentioned:
import os
os.chdir('full_path_to_your_directory')

This has nothing to do with osx in particular, it's more of a concept shared by all unix-based systems, and I believe Windows as well. os.getcwd() is the equivalent of the bash pwd command - it simply returns the full path of the current location in which you are in. In other words:
alex#suse:~> cd /
alex#suse:/> python
Python 2.7.12 (default, Jul 01 2016, 15:34:22) [GCC] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import os
>>> os.getcwd()
'/'
It depends from where you started the python shell/script.

Python is usually (except if you are working with virtual environments) accessible from any of your directory. You can check the variables in your path and Python should be available. So the directory you get when you ask Python is the one in which you started Python. Change directory in your shell before starting Python and you will see you will it.

os.getcwd() has nothing to do with OSX in particular. It simply returns the directory/location of the source-file. If my source-file is on my desktop it would return C:\Users\Dave\Desktop\ or let say the source-file is saved on an external storage device it could return something like G:\Programs\. It is the same for both unix-based and Windows systems.

Why I need to specify working directories and path?

Whenever I do a project for computer science, I have to make sure all of my files are located in the same folder, or I'll have errors. If I want to use a file from somewhere else, I have to insert it into the path. I do these things but don't fully understand what is happening or why. Why is the path changed in the runtime environment?

When you run a python script you are executing it in the current working directory /home/user/python.py for example. That means this script since it lives in /home/user has access to everything in that path. However you should be able to access any other directory from here as long as the permissions are setup right. You would do that by using relative paths. so for example /home/user/python.py could access a file that is /home/example/file.txt by giving it the path ../example/file.txt from the python project.

Have you tried adding the path using sys.path.append? If you don't want to do that every time then you can set (Windows) %PYTHONPATH% to include your custom path. That's what I do for my include folder.

Changing Directory With Python, Directory Not Found Error

I am trying to os.chdir() into system32 from python on windows, but when i attempt to change into this directory I am getting this error:
FileNotFoundError: [WinError 2] The system cannot find the file specified:
'/System32/
So obviously Python can't see this directory but I don't know why because os.listdir() shows this directory in the list. Does this have to do with the permissions that python has? Ultimately my goal is to change into the winevt directory to pull and dump the log files and to check for any errors, so any way to grab these is completely fine. My intuition was simply to change into the directory, open and read the log files and then check for errors, then print and report those errors.

Your current working directory may be different from the one where folder is.
Use this to check your current working directory before changing the directory.
print('Present DIR is : ',os.getcwd())
Then go to the correct directory and change the directory.

When you try to get into System32, use absolute path rather than the relative path, with the following:
os.chdir(r'C:/Windows/System32')
or in your case:
os.chdir(r'C:\Windows\System32\winevt\Logs')
As Archit said, you might not be in the correct directory.

The solution to this problem was a little bit hard to come by. I first tried uninstalling python 32 bit but that just broke everything.
I eventually installed python36 and added the python36.dll and the location of this dll to the user and system path (on Windows). Then I made sure to remove anything in the path involving python 34 or python36-32 which is the 32 bit version of python. This then allowed my to easily os.chdir into system32

Popen with conflicting executable/path

I'd like to call the "convert" utility from ImageMagick from my Python script using Popen, like so:
Popen(["convert", input_path, "-flop", output_file_path])
(The above example simply reverses the image horizontally)
The problem is that when I run the script in Windows, it mistakenly calls the convert.exe utility that ships with Windows to convert FAT partitions to NTFS! (located in \Windows\system32)
Now, if I randomly open a command prompt at any directory other than system32, and type "convert", it correctly runs the ImageMagick executable. So, this implies that Popen is automatically looking in system32. How can I make it not look in system32, and run the correct executable?

Search for a program is not trivial. I'd specify the full path to the convert.exe executable explicitly instead.
subprocess uses CreateProcess on Windows that looks in system32 directory even before any other directory in %PATH%:
... If the file name does not contain an extension, .exe is appended.
Therefore, if the file name extension is .com, this parameter must
include the .com extension. If the file name ends in a period (.) with
no extension, or if the file name contains a path, .exe is not
appended. If the file name does not contain a directory path, the
system searches for the executable file in the following sequence:
The directory from which the application loaded.
The current directory for the parent process.
The 32-bit Windows system directory. Use the GetSystemDirectory function to get the path of this directory.
The 16-bit Windows system directory. There is no function that obtains the path of this directory, but it is searched. The name of this directory is System.
The Windows directory. Use the GetWindowsDirectory function to get the path of this directory.
The directories that are listed in the PATH environment variable. Note that this function does not search the per-application path specified by the App Paths registry key. To include this per-application path in the search sequence, use the ShellExecute function.
Therefore convert is equivalent to convert.exe in this case. It first looks in a directory that contains sys.executable e.g., C:\Python27. Then in the current directory: where you started the Python script from. Then in system32 where it finds convert.exe (filesystem utility, not imagemagick).
You could try to remove system32 directory from os.environ['PATH'] it may(?) suppress checking it: Popen(cmd, env=no_system32_environ) but it is fragile (worse than the explicit path).
There is a related issue on Python bug tracker: "Subprocess picks the wrong executable on Windows."
cmd.exe (the shell) uses different algorithm. See How does Windows locate files input in the shell?
If you set shell=True then the search sequence for convert program:
convert is not an internal shell command
there is no explicit path, so the search continues
search the current directory
search each directory specified by the PATH environment variable, in the order listed
%PATHEXT% defines which file extensions are checked and in what order e.g., convert.com, convert.exe, convert.bat, convert.cmd if %PATHEXT% is .com;.exe;.bat;.cmd.

As a completely different approach, you may want to try out PythonMagick, a Python wrapper for ImageMagick. This way you can access convert's functions from within Python, and you won't have to spawn outside processes.

Just ran into this myself. Running a php script in a shell has access to the shell $PATH, while running within Apache does not (at least not a $PATH with the Cygwin dll/exe).
Secondly, use the native Windows notation C:/dir/subdir/pgm within php when on a windows platform and you will get what you expect.
So multi-platform code needs to switch/case the pathing and then reference the decision.

finding absolute path from a relative path in python

my question is pretty much what the title suggests. my research has led me to try something like this:
import os
pathname = os.path.abspath("some/relative/directory")
print pathname
this problem is that whenever i do something like this, it simply returns whatever relative directory i gave it preceded by my python directory. for example:
C:\Python27\some\relative\directory
which is not even an existing directory on my computer. i understand that the python interpreter searches the working directory by default, but what i'd like to do is have it search my entire computer for an absolute path that contains the partial directory i specify.
the purpose of this is for me to create an exe (using py2exe) that can search for an arbitrary directory on any computer. is there a method for doing this in the standard library or through some available module - or would i have to implement the algorithm myself?

abspath is based on getcwd. Most likely, your current working directory simply isn't what you expect.
You can change the code that launches your script, change directories manually, or just use chdir in Python.

Did you try os.path.realpath("my/relative/dir")? Actually it seems the directory may not exist, but if it does, it will resolve symbolic links and whatnot.