Develop Reference

How to determine the depth of file path?

I have a path as a string like this:
path = "directory/folder1/folder2/folder3/file1.txt"
I want to know how many levels this path has - in this case 4 (directory, folder1, folder2, folder3).
What's the best way to do it in Python? I thought about counting the "/":
path.count("/")
but I am wondering if there is a better way.

You could do it quite easily using pathlib:
from pathlib import Path
path = Path("directory/folder1/fodler2/folder3/file1.txt")
print(len(path.parents), list(path.parents))
Which gives:
5 [Path('directory/folder1/fodler2/folder3'), Path('directory/folder1/fodler2'), Path('directory/folder1'), Path('directory'), Path('.')]
As can be seen, the results is 5 because "." is also in the list as "directory/folder1/fodler2/folder3/file1.txt" is implicitly equal to "./directory/folder1/fodler2/folder3/file1.txt" so you can always just subtract 1 from the result.
Compared to path.count('/'), this is platform-independent...

It all depends on how precise you want to be. Problems I can think of:
Are you sure the last part of the string is the filename? If it is a directory, does it matter?
Are you sure the path separator is '/'? os.sep is your separator.
What if the string starts with os.sep?
What if some os.sep is repeated? For example os.path.exists("/var//log") returns True.
This might be slightly better, but the solution with pathlib.Path is definitely better.
os.path.normpath(path).count(os.sep)

Maybe one optimal solution could be path.count(os.sep). However, Tomerikoo answer is better than this. However, Make sure that pathlib module is installed, as this module does not come by default in the standard distribution of python2. But if you are using python3. Then it comes by default.

Avoid syntax error using hyphens in Python

I am writing a python script to automate some simulations with Aspen Plus via its COM functions. But when I want to get access to molecular weights values, I have to write something like this:
import os
import win32com.client as win32
aspen = win32.Dispatch('Apwn.Document')
aspen.InitFromArchive2(os.path.abspath('Aspen\\Flash.bkp'))
MW = aspen.Tree.Data.Properties.Parameters.Pure Components.REVIEW-1.Input.VALUE.MW ACID.Value
But it launchs a syntax error in REVIEW-1, due to hyphens can not be used as identifiers. How can I use them like that?
EDIT:
I replaced dot synax for FindNode function of Aspen COM like that:
MW = aspen.Tree.FindNode("\\Data\\Properties\\Parameters\\Pure Components\\REVIEW-1")
But I still get a None object, however this:
MW = aspen.Tree.FindNode("\\Data\\Properties\\Parameters\\Pure Components")
works, getting the "COMObject FindNode" so I think that the problem is in the hyphen as well.
Thanks in advance!

Thanks for the tip
For cases of having hyphens, the following should work instead of escaping the "\" character:
MW = aspen.Tree.FindNode(r'\Data\Properties\Parameters\Pure Components\REVIEW-1\Input\VALUE')

Ok, I was breaking my head trying to solve it in Python, but was easier solving it in Aspen renaming the node. I've noticed, also, that spaces sometimes give problems too, so should be renamed as well. In some cases it can't be done or I don't know how, for example:
MW = aspen.Tree.FindNode("\\Data\\Properties\\Parameters\\Pure Components\\REVIEW1\\Input\\VALUE\\MW ACID")
It returns a None object and I don't know hot to rename "MW ACID", but there is a tricky way to get the value:
MW = aspen.Tree.FindNode("\\Data\\Properties\\Parameters\\Pure Components\\REVIEW1\\Input\\VALUE")
for o in MW.Elements:
if o.Name == "MW ACID":
MW_acid = o.Value
For now it works for me, however it will be slower due to iteration. So if someone knows how to solve the problem in Python without renaming names, it will be still helpful. I tried to use unicode and bytes notation for non-breaking hyphen but it didn't works too.
Regards!

How can I create a file with `/` in its file name? [duplicate]

I know that this is not something that should ever be done, but is there a way to use the slash character that normally separates directories within a filename in Linux?

The answer is that you can't, unless your filesystem has a bug. Here's why:
There is a system call for renaming your file defined in fs/namei.c called renameat:
SYSCALL_DEFINE4(renameat, int, olddfd, const char __user *, oldname,
int, newdfd, const char __user *, newname)
When the system call gets invoked, it does a path lookup (do_path_lookup) on the name. Keep tracing this, and we get to link_path_walk which has this:
static int link_path_walk(const char *name, struct nameidata *nd)
{
struct path next;
int err;
unsigned int lookup_flags = nd->flags;
while (*name=='/')
name++;
if (!*name)
return 0;
...
This code applies to any file system. What's this mean? It means that if you try to pass a parameter with an actual '/' character as the name of the file using traditional means, it will not do what you want. There is no way to escape the character. If a filesystem "supports" this, it's because they either:
Use a unicode character or something that looks like a slash but isn't.
They have a bug.
Furthermore, if you did go in and edit the bytes to add a slash character into a file name, bad things would happen. That's because you could never refer to this file by name :( since anytime you did, Linux would assume you were referring to a nonexistent directory. Using the 'rm *' technique would not work either, since bash simply expands that to the filename. Even rm -rf wouldn't work, since a simple strace reveals how things go on under the hood (shortened):
$ ls testdir
myfile2 out
$ strace -vf rm -rf testdir
...
unlinkat(3, "myfile2", 0) = 0
unlinkat(3, "out", 0) = 0
fcntl(3, F_GETFD) = 0x1 (flags FD_CLOEXEC)
close(3) = 0
unlinkat(AT_FDCWD, "testdir", AT_REMOVEDIR) = 0
...
Notice that these calls to unlinkat would fail because they need to refer to the files by name.

You could use a Unicode character that displays as / (for example the fraction slash), assuming your filesystem supports it.

It depends on what filesystem you are using. Of some of the more popular ones:
ext3: No
ext4: No
jfs: Yes
reiserfs: No
xfs: No

Only with an agreed-upon encoding. For example, you could agree that % will be encoded as %% and that %2F will mean a /. All the software that accessed this file would have to understand the encoding.

The short answer is: No, you can't. It's a necessary prohibition because of how the directory structure is defined.
And, as mentioned, you can display a unicode character that "looks like" a slash, but that's as far as you get.

In general it's a bad idea to try to use "bad" characters in a file name at all; even if you somehow manage it, it tends to make it hard to use the file later. The filesystem separator is flat-out not going to work at all, so you're going to need to pick an alternative method.
Have you considered URL-encoding the URL then using that as the filename? The result should be fine as a filename, and it's easy to reconstruct the name from the encoded version.
Another option is to create an index - create the output filename using whatever method you like - sequentially-numbered names, SHA1 hashes, whatever - then write a file with the generated filename/URL pair. You can save that into a hash and use it to do a URL-to-filename lookup or vice-versa with the reversed version of the hash, and you can write it out and reload it later if needed.

The short answer is: you must not. The long answer is, you probably can or it depends on where you are viewing it from and in which layer you are working with.
Since the question has Unix tag in it, I am going to answer for Unix.
As mentioned in other answers that, you must not use forward slashes in a filename.
However, in MacOS you can create a file with forward slashes / by:
# avoid doing it at all cost
touch 'foo:bar'
Now, when you see this filename from terminal you will see it as foo:bar
But, if you see it from finder: you will see finder converted it as foo/bar
Same thing can be done the other way round, if you create a file from finder with forward slashes in it like /foobar, there will be a conversion done in the background. As a result, you will see :foobar in terminal but the other way round when viewed from finder.
So, : is valid in the unix layer, but it is translated to or from / in the Mac layers like Finder window, GUI. : the colon is used as the separator in HFS paths and the slash / is used as the separator in POSIX paths
So there is a two-way translation happening, depending on which “layer” you are working with.
See more details here: https://apple.stackexchange.com/a/283095/323181

You can have a filename with a / in Linux and Unix. This is a very old question, but surprisingly nobody has said it in almost 10 years since the question was asked.
Every Unix and Linux system has the root directory named /. A directory is just a special kind of file. Symbolic links, character devices, etc are also special kinds of files. See here for an in depth discussion.
You can't create any other files with a /, but you certainly have one -- and a very important one at that.

How to make Python use a path that contains colons in it?

I have a program that includes an embedded Python 2.6 interpreter. When I invoke the interpreter, I call PySys_SetPath() to set the interpreter's import-path to the subdirectories installed next to my executable that contain my Python script files... like this:
PySys_SetPath("/path/to/my/program/scripts/type1:/path/to/my/program/scripts/type2");
(except that the path strings are dynamically generated based on the current location of my program's executable, not hard-coded as in the example above)
This works fine... except when the clever user decides to install my program underneath a folder that has a colon in its name. In that case, my PySys_SetPath() command ends up looking like this (note the presence of a folder named "path:to"):
PySys_SetPath("/path:to/my/program/scripts/type1:/path:to/my/program/scripts/type2");
... and this breaks all my Python scripts, because now Python looks for script files in "/path", and "to/my/program/scripts/type1" instead of in "/path:to/myprogram/scripts/type1", and so none of the import statements work.
My question is, is there any fix for this issue, other than telling the user to avoid colons in his folder names?
I looked at the makepathobject() function in Python/sysmodule.c, and it doesn't appear to support any kind of quoting or escaping to handle literal colons.... but maybe I am missing some nuance.

The problem you're running into is the PySys_SetPath function parses the string you pass using a colon as the delimiter. That parser sees each : character as delimiting a path, and there isn't a way around this (can't be escaped).
However, you can bypass this by creating a list of the individual paths (each of which may contain colons) and use PySys_SetObject to set the sys.path:
PyListObject *path;
path = (PyListObject *)PyList_New(0);
PyList_Append((PyObject *) path, PyString_FromString("foo:bar"));
PySys_SetObject("path", (PyObject *)path);
Now the interpreter will see "foo:bar" as a distinct component of the sys.path.

Supporting colons in a file path opens up a huge can of worms on multiple operating systems; it is not a valid path character on Windows or Mac OS X, for example, and it doesn't seem like a particularly reasonable thing to support in the context of a scripting environment either for exactly this reason. I'm actually a bit surprised that Linux allows colon filenames too, especially since : is a very common path separator character.
You might try escaping the colon out, i.e. converting /path:to/ to /path\:to/ and see if that works. Other than that, just tell the user to avoid using colons in their file names. They will run into all sorts of problems in quite a few different environments and it's a just plain bad idea.

Unpredictable results from os.path.join in windows

So what I'm trying to do is to join something in the form of
os.path.join('C:\path\to\folder', 'filename').
**edit :
Actual code is :
filename = 'creepy_%s.pcl' % identifier
file = open(os.path.join(self.cache_dir, filename), 'w')
where self.cache_dir is read from a file using configobj (returns string) and in the particular case is '\Documents and Settings\Administrator\creepy\cache'
The first part is returned from a configuration file, using configobj. The second is a concatenation of 2 strings like: 'file%s' % name
When I run the application through the console in windows using the python interpreter installed, I get the expected result which is
C:\\path\\to\\folder\\filename
When I bundle the same application and the python interpreter (same version, 2.6) in an executable in windows and run the app the result is instead
C:\\path\\to\\folderfilename
Any clues as to what might be the problem, or what would cause such inconsistencies in the output ?

Your code is malformed. You need to double those backslashes or use a raw string.
os.path.join('C:\\path\\to\\folder', 'filename').
I don't know why it works in one interpreter and not the other but your code will not be interpreted properly as is. The weird thing is i'd have expected a different output, ie: C:pathtofolder\filename.

It is surprising behavior. There is no reason it should behave in such a way.
Just be be cautious, you can change the line to the following.
os.path.join(r'C:\path\to\folder\', 'filename').
Note the r'' raw string and the final \

Three things you can do:
Use double-slashes in your original string, 'C:\\path\\to\\folder'
Use a raw string, r'C:\path\to\folder'
Use forward-slashes, 'C:/path/to/folder'

I figure it out yesterday. As usual when things seem really strange, the explanation is very simple and most of the times involve you being stupid.
To cut a long story short there were leftovers from some previous installations in dist-packages. The bundled interpreter loaded the module from there , but when i ran the python script from the terminal , the module (newer version) in the current dir was loaded. Hence the "unpredictable" results.