Составление пути к файлу в Unix и Windows в Python.

При доступе к файлу в операционной системе требуется правильно указать путь к файлу. Путь к файлу — это строка, которая представляет местоположение файла.

Предупреждение. Сразу оговоримся, чтобы не получить геморрой при составлении путей к файлам с системе Windows используйте встроенный модуль pathlib .

Он разбит на три основные части:

1. Путь к файлу /path/to/file/ : расположение директории в файловой системе, где папки разделены прямой косой чертой ‘/’ в Unix подобных системах или обратной косой чертой ‘\’ в Windows.
2. Имя файла text : фактическое имя файла.
3. Расширение .txt : используется для указания типа файла.

Для чтения или записи в файл нам необходимо его открыть, а для этого нужно передать путь к нужному файлу в качестве строки функции open() . Для Unix подобных систем это делается просто:

В системе Windows путь включает в себя обратную косую черту ‘\’ . Этот символ в строках на Python используется для экранирования escape-последовательностей, таких как новая строка ‘\n’ .

Что бы избежать Windows системах такого безобразия, нам нужно вручную экранировать обратную косую черту ‘\\’ или передавать в функции open() сырую (необработанную) строку, указав перед первой кавычкой строковой литерал ‘r’ :

А вот как просто создавать и использовать пути при помощи встроенного модуля pathlib . Так как модуль встроенный, то устанавливать ничего не надо.

Строковое представление пути можно посмотреть функцией str() — это сам необработанный путь к файловой системе в собственном виде, например с обратным слешем в Windows, который можно передать любой функции, принимающей путь к файлу в виде строки:

Переводить путь в текстовое представление не обязательно, т.к. объект пути модуля pathlib принимают все функции.

Batch- string search on Windows PATH

I am writing an batch file in Windows to run post-installation scripts, and one of the things that needs to be done is to add a directory to the system path.

The script is working, and it does something like this:

setx Path «%PATH%;c:\path\to\add» -m

This is setting the path correctly, but this script could potentially be run multiple times if the user reinstalls the program.

I would like to search the string for c:\path\to\add so I don’t keep adding the same path over and over to the system path. This is pretty trivial in Linux with sed , but I don’t know what the command is in Windows. I’ve found findstr , but this seems to only work on files.

Is this possible in Windows without installing additional software?

I’m using Inno Setup to create the install executable.

5 Answers 5

At the risk of some downvotes till an expert provides a sound way of doing this,
the below removes the specific path from the environment variable if it exists, so that it can be added again:

This carries the risk of removing the string if it is in fact actually a part of a path, for instance c:\path\to\add\somefolder . Also if the path actually ends with a \ , or it is the first entry and it in fact does not start with ; , etc..

Various forms can be called consecutively to circumvent some of these,

But, AAMOF I’n not sure this is a sane way of doing this..

This is my code snippet to find the «cvsnt» path in the PATH variable.

The part to look at is

First I replace all occurrences of «cvsnt» with an empty string. The result is compared to PATH without replacement of «cvsnt». If they are not equal because of «cvsnt» was replaced then it exists in PATH and the code can proceed.

The starting x before %PATH% is only a placeholder to protect against certain «improper» starting characters. see Batch file: Find if substring is in string (not in a file)

The setx utility has a drawback, it can not handle variables longer than 1024 characters.

I have been wrote a script to handle cases longer than the limit and without a need to install anything. Answered the question here: Set environment variables with NSIS in Window 7

Instead of adding the path each time — you could check if the executable you are looking for can be found within the path using a command like this:

Make sure to check for /? to read more about the magic of %

This is a bit of a hackish workaround, but follows the logic you expect:

1. Search the PATH
2. Conditionally add to the PATH

It never removes anything from the PATH, so there’s no fear of screwing up Windows by removing something accidently. Also, it checks the PATH variable directly, so you don’t have to worry about another file with the same name that lives somewhere on the PATH.

I hate using temporary files, but it’s quick and dirty, and probably safer than removing something from the PATH.

The third line is the only tricky one. Basically, this line tests the outcome of the FIND command above. Rob van der Woude states:

FIND returns an errorlevel of 1 or higher if the search string wasn’t found.

Some executables return negative numbers for errorlevels! However, this can be fixed by using the following code to check for non-zero return codes:
IF %ERRORLEVEL% NEQ 0 .

Самая лучшая практика: работа с path в Python

Все та же проблема: список папок и дисков

В последней статье мы использовали рекурсивную функцию размером менее 10 строк для решения проблемы сканирования папок и ранжирования файлов по дате изменения и размеру.

Теперь я подниму планку и покажу, как можно было сделать лучше.

Объединяем пути с помощью Pathlib

Старые идеи в новом обличье?

Предыдущее решение с соединением путей выглядело следующим образом:

Преимущество такого подхода заключается в том, что решение не зависит от операционной системы, и вам не нужно складывать строки с помощью оператора «+» или форматирования.

Тем не менее, здесь можно допустить ошибку, например, непреднамеренно или ошибочно определить путь к каталогу с помощью закрывающего разделителя.

Несмотря на то, что в этом примере показан рабочий код, неправильный разделитель приведет к ошибке при вызове этого пути. И такие ошибки могут возникать всякий раз, когда далекие от кода пользователи оперируют путями в конфигурационных файлах, не обращая внимания на соглашения.

В Python 3.4 появилось лучшее решение — модуль pathlib . Он обрабатывает функции файлов и папок модуля os с помощью объектно-ориентированного подхода.

Напомню, старый вариант выглядел вот так:

А вот альтернативный:

Оба варианта дают один и тот же результат. Так чем же второй вариант лучше?

Объектно-ориентированный и более устойчивый к ошибкам

Вызовы в основном являются объектно-ориентированными, нравится вам это или нет, но лично мне такой подход по душе. Здесь у нас есть такой объект, как определение path , у которого есть атрибуты и методы.

Однако пример с операторами перегрузки в данном случае более интересен:

Сначала разделение на два пути кажется недопустимым. Однако объект path был перегружен так, чтобы работать как объединенный путь.

В дополнение к этому синтаксическому сахару объекты path будут перехватывать другие типичные ошибки:

Такой вариант не только приятнее, но и устойчивее к неправильным входным данным. В дополнение к другим преимуществам код также не привязан к определенной операционной системе. Он определяет только generic объект path , который объявляется в системе Windows как WindowsPath , а в Linux как PosixPath .

Большинство функций, которые ожидают строку в качестве пути, могу работать непосредственно с путем. В редких случаях вам может понадобиться изменить объект просто с помощью str(Path) .

Обработка пути с помощью os.walk

В своей последней статье я использовал os.listdir , os.path.isdir и рекурсивную функцию для итерации по дереву путей и разграничения файлов и папок.

Но os.walk предлагает решение получше. Этот метод создает не список, а итератор, который можно вызывать построчно. В результате мы получим соответствующий путь к папке и список всех файлов по этому пути. Весь процесс происходит рекурсивно, поэтому вы получите все файлы одним вызовом.

Лучшее решение с os.walk и Pathlib

Если вы объедините два вышеупомянутых метода, то получите решение, которое будет более простым, полностью независимым от операционной системы, устойчивым к неправильным форматам путей и без явных рекурсий:

Если вам удастся улучшить этот вариант, не постесняйтесь рассказать мне об этом. Я был бы рад вашим отзывам!

Первую часть статьи можно найти здесь.

Также приглашаем всех желающих принять участие в бесплатном демо-уроке курса на тему «Три кита: map(), filter() и zip()».

Можно ли писать код, требующий циклов, но без циклов? Может ли он быть быстрее, чем, если бы мы использовали циклы в Python? Для реализации задуманного понадобится знание слов «callback», «iterator» и «lambda». Если интересно — присоединяйтесь!

How can I convert a windows path to posix path using node path

I’m developing on windows, but need to know how to convert a windows path (with backslashes \ ) into a POSIX path with forward slashes ( / )?

My goal is to convert C:\repos\vue-t\tests\views\index\home.vue to C:/repos/vue-t/tests/views/index/home.vue

so I can use it in an import on a file I’m writing to the disk

I’d prefer not to .replace(/\\/g, ‘/’) the string, and would rather prefer to use a require(‘path’) function.

5 Answers 5

Slash converts windows backslash paths to Unix paths

Usage:

Given that all the other answers rely on installing (either way too large, or way too small) third party modules: this can also be done as a one-liner for relative paths (which you should be using 99.999% of the time) using Node’s standard library path module, and more specifically, taking advantage of its dedicated path.posix and path.win32 namespaced properties/functions:

This will convert your path to POSIX format irrespective of whether you’re already on POSIX platforms, or on win32, while requiring zero dependencies.

There is node package called upath will convert windows path into unix.

A one-liner mimicking slash and upath (see the multi-liner version for proof of validity)

to pin the version of the library you are sure it works. If you use import < toUnix >from ‘upath’; it only imports the needed function, so there is no runtime cost. – Amin Jul 5 ’20 at 5:04

is really useful, and should probably be used more frequently. The runtime cost is probably negligible either way, I was referring to the cost of 10 files you’re adding to your node_modules. Do note though: import < aFunc >is often not zero cost. It requires 1. using a bundler 2. that bundler having tree shaking and 3. the code be be written in a way that supports being tree-shook. The vast majority of the time libraries are better than copy-paste, but this is some tiny unchanging functionality here. – Jeff Hykin Jul 5 ’20 at 17:29