Что еще за "синхронизированная цепочка команд" ? Синхронизированная с чем?

Изначально просили синхронизировать

Пусть будет с пользователем. Вот пусть как в обычной консоли: пользователь вводит команду и ждет результата, чтоб ввести новую. Только чтоб это было в рамках создаваемого подпроцесса с шелл.

Обычно пользователь ждёт пока увидит знакомые символы и начинает вводить следующую команду.

Ну так же как и с пользователем. Пользователь отслеживает завершение процесса по наличию приглашения PS1 на экране.

Как правило в определенной позиции экрана и приглашение зависит от многих факторов о которых пользователь знает

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

При чем тут высокоуровневые питоновские библиотеки?

Консоль? Консоль ничего не отслеживает. Отслеживает шелл

Консоль предоставляет шеллу только pty устройство, в которое он срет

Давай придираться к отдельным словам и дальше. Так очень конструктивно.

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

Питон напрямую общается с ядром и шеллом? Или всетаки через сишные нативные вызовы? Но опять же к чему это? Я пришел с конкретной подзадачей. А чувство как будто малолетние детишки или не особо малолетние хотят поиграть в экзаменаторов а не помочь.

> Питон напрямую общается с ядром и шеллом? С каким еще нахрен шеллом?

Да не было достаточно формально поставленной задачи. На любые попытки выяснить подробности ты начинаешь юлить и сливаться. Нет желания помочь нам решить твою проблему - выход рядом. Мы пытались разобраться, но тебе это похоже не нужно

А чем важно "в рамках созданного подпроцесса с шелл"? Опять что-то про мифическое "окружение"?

Что такое родительский процесс в линуксе и важность передачи его окружения в дочерние видна даже по аргументам создания Popen в subprocess. Но уровень дальнейшего общения уже понятен.

Если я начну рассказывать, то по вопросику и вопросику я от решения своей небольшой подзадачи, с которой просто на всякий случай решил обратиться и сюда, я перейду в разряд докладчика. И ради чего? Чтоб по итогу получить еще и хамство от больно умных думающих что если они тут имеют какой статус, то это их реальный уровень вне. В принципе, нормальные ответы тоже были. Спасибо и тебе и @Zart. В общем. Если у кого есть опыт в сложной коммуникации даже с обычным шеллом на питоне было бы интересно его обсудить лично. Потому что тут все-таки чат для новичков с соответствующим уровнем общения.

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

Обычно зарт наоборот угнетает 🧐🧐🧐

Хз что такое обычный Шелл и в чем заключается коммуникация.

Пока ты выдал какой-то бессвязный и часто некорректный набор утверждений и связки между ними гордо спускаешь на тормозах и обидах.

А зачем вам знать что передается? Речь пока о самом примитивном. Как на уровне обычного линуксового шелл отследить выполнение каждой из цепочки команд. Не создавая на каждый чих отдельный процесс через subprocess.run, а в рамках одного подпроцесса с запускаемым шеллом. Это понятно вопрос не уровня новичков. Есть те кто все понял. А тем кто не понял оно и не надо.

Никак.

Уже давно и решили. Тебе и @Zart спасибо за ответы 🤝

Затем, что это существенным образом влияет на решение. И вполне вероятно, что в итоге задача в таком виде решения не требует, а исходная задача решается куда проще. Типичная xy-problem.

Задача выглядит как xy problem.

В рамках линуксового шелла никак не влияет. А на его примере и шел разговор. Но некоторые хотят лекций за чужой счет 😂

И да, в чём проблема с "на каждый чих отдельный процесс" - вообще не ясно. Будто абстрактный шел будет делать иначе. Почему не считать свою замену заменой шелу и не передавать нужный контекст между приложениями - непонятно.

Хорошо. Вот еще конкретный пример-задача для понимания возможных проблем с другими шеллами. Тем более кастомными, со сложным окружением и контекстом, где бывает важен каждый байт памяти. Есть известный adb для работы с андроидами. У него есть режим shell. Допустим такая вроде бы простая конкретная задача. 1. Запустить режим adb shell. 2. Создать рутовую сессию через su. 3. Выполнить в рамках этой сессии пару вызовов. Скажем, ls /data, du /data, touch /data/tmp.txt, rm /data/tmp.txt. Навалять кучку subprocess.run большого ума не потребуется, а вот сделать всë в рамках одного подпроцесса другое дело. И это простой всем доступный пример. Без необходимости объяснять тонну реальных кастомных нутряков.

Ну и в чем проблем сделать это в рамках одного подпроцесса? /bin/bash -c "cmd1 && cmd2 && cmd3" ?

Мы же вроде в теме по питону где ты модератор. Вот и попробуй написать работающий код без кучек subprocess.run

subprocess.run(['/bin/bash', '-c', 'cmd1 && cmd2 && cmd3'])

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

adb shell < file.sh

пользователь не может знать в общем случае

1. Эта задача начинает иметь смысл, если шел нужен интерактивный, то есть ты заранее не знаешь, что именно будешь запускать и тебе нужно именно реагировать на происходящее и как-то по-разному действовать. Из твоих сообщений никак не следовало, что тебе нужно такое поведение. 2. Для общения с adb есть средства, заточенные конкретно на работу с adb. Не универсальное решение.

Ну да ладно никак не следовало. Обсуждалось и интерактивность с пользователем, и синхронизация.

я нынче слишком быстро устаю играть в гестапо не хотят люди объяснять свои проблемы - им же хуже

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

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

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

Да, вот как раз и уткнулись в невозможность отслеживания результата в питоне.

При чем здесь питон?

Да не в питоне дело

Питон тут радикально ничем не отличается, реализуй ты это на С или любом другом языке с вызовом системного API

Давай возьмём какой-нибудь шелл и выкинем из него все операции, связанные с выводом в stdout. Как отслеживать будешь? Пофиг, из питона или не из питона.

Ну, надо сказать, что subprocess.run эту проблему решает. Вот только каждый раз запускается новый подпроцесс на каждый чих. А это уже в случае кастомных вариантов огромная проблема.

RO 1d. флуд. флейм. научись формулировать свои мысли нормально.

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

как расшифровывается RO?

read-only

CD-ROM видел? Чем отличается от CD-RW?

понял, спасибки

аахаххв

Ты еще дискеты вспомни

o_O динозавр

это рофл или ты серьезно?

серьезно

О, тут недавно заказывали на кикстартере по good omens всякое. Так в каких-то наборах они предлагают дискеты

не решает

книга \ сериал или графическая новелла?

Комикс делают

3.5 или 5?