Pautomount — демон автоматического монтирования, запуска скриптов и всего такого прочего

Tab не работает в таких случаях.

Да ну? Переходите на zsh, всё работает. В fish тоже всё работает. Даже bash можно настроить, чтобы всё работало. Под «всё» я имею ввиду, что повторное нажатие Tab вызывает циклическое переключение между вариантами автодополнения. Zsh дополнительно позволяет управлять переключением стрелками, что очень помогает (как ни странно, у меня нет русской раскладки и все русские тексты я пишу либо со смартфона (транслитом, но используя ruKeyboard), либо транслитом в Vim). Так что я знаю, о чём говорю.

К тому же префикс никак не поможет Таб-ом перейти на нужную папку в консоли, если папок с одинаковым префиксом больше одной =)

Это целиком и полностью вопрос выбора способа создания префикса.

Про библиотеки из C, которые используются как основы для Питоновских библиотек, понятно. Но если уж Питон предоставляет обёртки над функциями из C — можно сделать эти обёртки удобными, как это, собственно, и сделано в большинстве Питоновских библиотек.

Они удобные. Во‐первых, только shell оперирует сплошной строкой: и exec*, и main(), и вещи вроде sys.argv — это всё списки.

Сплошная строка в main()/sys.argv никому на хрен не сдалась и совершенна неудобна: попытайтесь обработать список файлов, полученный в виде сплошной строки и поймёте, почему. Соответственно нелогично иметь сплошную строку на другом конце: это нарушает принцип «явное лучше неявного»: получается «сплошная строка» → «магия» → «список». Вряд ли вы найдёте здесь много человек, способных полностью описать, как работает «магия» в случае с shell: а ведь там это одна из основополагающих вещей.

Собственно, здесь вы нарушаете сразу два принципа: «явное лучше неявного» и «простое лучше сложного». Это не дело.

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

Сплошная строка неудобна для генерации списка аргументов из списка вещей (к примеру, файлов) — из‐за экранирования простым ' '.join(argument_list) не обойдётся.

Список удобен для генерации аргументов от и до, и, чёрт возьми, я ни разу, ни в одной своей программе не хотел использовать shell=True или использовать строку. И, по‐моему, нигде и не использую.

Сплошная строка неэкономична: чтобы её создать вам придётся пройти процесс «генерация аргументов» — «экранирование» — «парсинг строки» — «генерация char ** массива». В случае списка половина пунктов из середины выкидывается.

И ещё, если у вас есть функция со списком, то вы можете взять её и прикрутить наверх функцию со строкой, обратное тоже верно. Так зачем тащить в стандартную библиотеку всякую дрянь? Ruby уже имел проблемы с безопасностью от того, что никто не помнит всю документацию (вспомните, к примеру, $ против \Z).
Конечно, вы не можете сделать язык, на котором все программы будут безопасны. Но вы можете уменьшить нагрузку на программиста, уменьшив пространство выбора, оставив только более безопасные решения. В идеологии языка никогда не было TMTOWTDI.

В Python было бы логичнее сделать Popen с *args в качестве списка, чтобы не отличаться от прочих функций, а никак не принимать на вход строку. И отдельный модуль, который позволяет засунуть в *args запуск $SHELL с заданной строкой.

Насчёт однородности — нашёл os.system.

В модуле os много практически прямых привязок к C’шным функциям. И этот вариант использует оболочку. Кроме того, «The subprocess module provides more powerful facilities for spawning new processes and retrieving their results; using that module is preferable to using this function.» и «Note that POSIX does not specify the meaning of the return value of the C system() function, so the return value of the Python function is system-dependent.»

То есть вы нашли deprecated функцию. Не удивительно, что тут не соблюдается условие однородности: такие функции существуют только для обратной совместимости. По‐моему, её не собираются удалять только потому, что из‐за простоты os.system слишком часто используется.

Более того, однородность между теми же check_output и popen тоже неполная — так почему между моей функцией и вышеперечисленными она должна быть полной?

Мне не жалко повторить во второй раз, что однородность должна быть в библиотеках языка, и что она не идеальна. И, кстати, вы не нашли «что-то, что non-shell и принимает на вход строку». Ну и os.popen* тоже deprecated. Более того, в документации на os.system стоит просто рекомендация использовать subprocess. А в документации на os.popen стоит очень заметное розовое предупреждение о том, что popen «Deprecated since version 2.6». Жаловаться на неоднородность deprecated функций имеет не больше смысла, чем жаловаться на то, что человеческий эмбрион не выглядит как человек: такие неоднородности обусловлены историческими причинами.

Замечу, что в Python 3 ситуация иная: там нет ни deprecation warning при os.popen (но есть рекомендация использовать subprocess), ни информации о том, что с subprocess нужен для замены os.popen в первых абзацах документации этого модуля: здесь написано только то, что subprocess — это замена os.system и os.spawn*. os.popen с цифрами, впрочем, нет вообще.

То же разное поведение subprocess.check_output при shell=True и shell=False — это ли не вопиющий пример неоднородности? Вон, человек тоже недоволен — asvetlov.blogspot.com/2011/03/subprocess.html, плюс там пример вообще неадекватного поведения.

Я с ним согласен. Как я сказал выше, я бы вообще зарубил Popen возможность использовать shell, но добавил модуль или функцию в subprocess, которая сформирует список аргументов для Popen так, чтобы вызывался shell со строкой. Ну и Popen('cat', filename, filename2) выглядит лучше, чем Popen(['cat', filename, filename2]). Но всё это не меняет того факта, что функции в subprocess принимают практически одни и те же аргументы.

Кстати, в той issue, что вы привели здесь, есть ссылка на shell-command.readthedocs.org/en/latest/index.html. Если вам нужно использовать оболочку, то этот модуль выглядит весьма интересно (он занимается, в том числе, автоматическим экранированием аргументов).