bash wrapper

вопрос не понял, вероятно:

$ locale
LANG=ru_RU.UTF-8
LANGUAGE=ru_RU.UTF-8
LC_CTYPE="ru_RU.UTF-8"
LC_NUMERIC="ru_RU.UTF-8"
LC_TIME="ru_RU.UTF-8"
LC_COLLATE="ru_RU.UTF-8"
LC_MONETARY="ru_RU.UTF-8"
LC_MESSAGES="ru_RU.UTF-8"
LC_PAPER="ru_RU.UTF-8"
LC_NAME="ru_RU.UTF-8"
LC_ADDRESS="ru_RU.UTF-8"
LC_TELEPHONE="ru_RU.UTF-8"
LC_MEASUREMENT="ru_RU.UTF-8"
LC_IDENTIFICATION="ru_RU.UTF-8"
LC_ALL=ru_RU.UTF-8

Сообщение не теряется (просто читается в два захода).

Локаль у меня на тестовой машине правильная, я тут привёл английский вариант, так как под рукой оказался лишь Debian без русской локали.

quester, запустил я на «родной» машине:

> ls /root/
ls: > 
> ls /
невозможно открыть каталог /root/: Отказано в доступе
> 

Linux()
> ls /root/
ls: невозможно открыть каталог /root/: Отказано в доступе
> exit

А что означают твои алиасы? см — сменить место?

А что означают твои алиасы? см — сменить место?

Да, типа того.

Посоветовались тут с другом, решили забить алиасы в python-код (конфиг). Чтобы работало и под Windows (там ведь команды alias нет).

Вчера решил не делать screen scraping, а просто валить stdout весь подряд на экран.

Сообщение не теряется (просто читается в два захода).

Это нормально. Такое происходит когда внутри программы реализовано в два вывода, вначале выводится сообщение в конкретном месте, что не смогла, а потом вызывается печать системной ошибки из кода уже при аварийном завершении. При чтении из pipe проиходит получение двух буферов. stderr не буферизуется и потому выводится всё одним куском с fflush при каждом выводе.

У меня файл в неблокирующем режиме, и после отправки команды в bash, ответ ещё не сформирован, а я пытаюсь его прочитать.

Это хорошая догадка, но не правильная. Как вы узнаете, что ответ уже полностью сформирован? А если там много-много чего будет написано, типа хелпа по вызову программы? Этот хелп при приличных размерах может даже при всё желании не поместиться в один PIPE_BUF.

Я вставил искуственно задержку

И вашим враппером будут пользоваться только вы. :)

советуют использовать asyncio

Можно подумать, оно поможет.

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

И вашим враппером будут пользоваться только вы. :)

Лол :-) Как будто есть шанс на нечто другое :-) Лол :-)

см — сменить место

забить алиасы в python-код (конфиг).

Чтобы работало и под Windows

У меня от такого ненужно чуть не лопнул экран.

Как вы узнаете, что ответ уже полностью сформирован?

По наличию Command prompt в stdout (PS1 env).

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

У меня сейчас дамп stdout-а реализован в отдельном потоке с ждущим select(). Попробуй, запусти yes - будет выдаваться в рилтайме.

Я вставил искуственно задержку

И вашим враппером будут пользоваться только вы. :)

Увы, вчера надо было ложиться спать, и успеть отправить коммит - чтобы друг прочитал.

Парсить на наличие Command prompt я пока не хочу.

Сорцы выкладываю ведь не с подписью «в продакшн», а для тех - кто умеет читать. Вон, Гоголь тоже не дописал свои романы.

При чтении из pipe проиходит получение двух буферов.

Да, собственно, никто не гарантирует, что не прилетит третий буфер. Окончание вывода баша можно определить лишь по наличию Command prompt, который задаётся в качестве переменных среды при запуске процесса (Popen()).

stderr не буферизуется и потому выводится всё одним куском с fflush при каждом выводе.

Что ты тут написал, я не понял. Ты внутрь bash заглядывал, и увидел там fflush()?

Понятие буфера - это внутреннее дело операционной системы, и не имеет никакого отношения к прикладному уровню обмена данными. У меня вопрос лишь был, когда выдавать следующий command prompt в своём враппере, какой read() считать «последним».

Мой sleep(0.2) - чисто косметический, для быстрых команд. И не сработает при seq 99999, например.

Ради шутки как-то пилили такое, хз поможет ли и ваще ли в тему.

https://github.com/tazhate/Russian-Console/blob/master/.bashrc

Ты внутрь bash заглядывал, и увидел там fflush()?

Куда я только не заглядывал... Но вас подпускать к программированию совсем нельзя. У вас в корне неправильные представления как работает система. Какой нафиг bash? У вас выводит сообщение в stderr команда ls, башу, если ему не сказано как-то читать stderr, на эти сообщения вообще плевать.

Я тебе говорю, мне без разницы - какие там буфера в операционной системе. Я работаю с данными. Собственно, ключевое слово было - screen scraping, и разговор с человеком, который такой парсинг выхлопа баша уже писал. Я ж про прикладной уровень.

То, то ты подтвердил мои догадки про два write(), за это спасибо. Я лишь хотел сказать, ты там сам видел fflush(), или просто теоретизируешь?

У вас в корне неправильные представления как работает система. Какой нафиг bash? У вас выводит сообщение в stderr команда ls.

Ну, поспешил я. ls может быть интегрирован и в оболочку, я не хочу вдаваться в эти мелочи.

мне без разницы

плохо.

какие там буфера в операционной системе

Это важно только для понимания, ибо этим управлять весьма-весьма проблематично.

Я работаю с данными. Собственно, ключевое слово было - screen scraping,

ну то есть вы работаете не с bash, а с терминалом. Это тоже полезная вещь, но тогда никакой надежды на PROMPT bash-а быть не может, работать надо именно с поступающей информацией как есть, а не парсить что-то там в надежде на какие-то их порции и промпт.

Это тоже полезная вещь, но тогда никакой надежды на PROMPT bash-а быть не может

Что-то я запутался. Приглашение ко вводу выдаёт всё-таки xterm, на основе переменных среды?

Или bash в интерактивном режиме сам печатает $PS1?

Bash сам отображает приглашение, xterm ни при чём

Да, я уже посмотрел исходники.

Запускаю такой py-скрипт:

#!/usr/bin/python
# -*- coding: utf-8 -*-
# MIT/Expat License

import sys
import os
from subprocess import Popen, PIPE, STDOUT
import errno
import select
from multiprocessing import Process
import time

def Dump(fd):
        reads = [fd]
        while True:
                ret = select.select(reads, [], [])
                s = os.read(ret[0][0],4096)
                sys.stdout.write(s)
                sys.stdout.flush()

p = Popen(["/bin/bash","-i"], shell = False,
stdin = PIPE, stdout = PIPE, stderr = STDOUT, bufsize = 1, env={"PS1":"\\h"})
proc = Process(target=Dump, args=(p.stdout.fileno(),))
proc.start()

while True:
        ss = raw_input("> ")
        if ss == "exit":
                proc.terminate()
                break
        if len(ss) == 0: continue # ничего кроме пробельных символов нет
        try:
                p.stdin.write(ss+"\n")
                p.stdin.flush()
        except IOError as e:
                print repr(e)
                if e.errno == errno.EPIPE:
                        break

        time.sleep(0.2) # чтобы выхлоп stdout не затирал промт

У друга на машине всё работает нормально. Выдаёт промт \h

У меня вылетает на шаге raw_input(), и через некоторое время упавший процесс становится зомби (Z). Debian 8.6 x86_64. Я пока в непонятках. Завтра буду смотреть на ROSA Fresh 10.

Здесь не подскажу, уж извиняй - в python нуб

Приглашение ко вводу выдаёт всё-таки xterm, на основе переменных среды?

xterm эмулирует графическую виртуальную консоль. Ему всё равно, bash там или текставая игра там запускается в качестве shell-а. Может там и 100 башей в параллель дерутся за ввод пользователя. xterm-у на это фиолетово, он выводит буковки, рисуя их в графике. Всё.

А вы занимаетесь какой-то фигнёй. Заставляете bash работать в интерактивном режиме, подсовывая ему pipe и пытаетесь что-то там предсказать на основе полученных символов. Совершенно пустая затея.

Что-то ты мне паришь мозги, vodz. Про терминал зачем-то начал объяснять. Как связан терминал и PROMPT, выдаваемый башем?

В общем, скрипт дописал (линуксовая версия). Ответ нашёл здесь: https://stackoverflow.com/a/41593121 (как грузить интерактивный bash)

#!/usr/bin/python
# -*- coding: utf-8 -*-
# MIT/Expat License

import sys
import os
from subprocess import Popen, PIPE, STDOUT
import errno
import select
from multiprocessing import Process
import time

def Dump(fd):
        reads = [fd]
        while True:
                ret = select.select(reads, [], [])
                s = os.read(ret[0][0],4096)
                sys.stdout.write(s)
                sys.stdout.flush()

# https://stackoverflow.com/questions/41542960/run-interactive-bash-with-popen-and-a-dedicated-tty-python

import ctypes

libc = ctypes.CDLL('libc.so.6')

p = Popen(["/bin/bash","-i"], shell = False,
        stdin = PIPE, stdout = PIPE, stderr = STDOUT, bufsize = 1,
        env={"PS1":"\\h"},
        preexec_fn=libc.setsid)

proc = Process(target=Dump, args=(p.stdout.fileno(),))
proc.start()

while True:
        ss = raw_input("> ")
        if ss == "exit":
                proc.terminate()
                break
        if len(ss) == 0: continue # ничего кроме пробельных символов нет
        try:
                p.stdin.write(ss+"\n")
                p.stdin.flush()
        except IOError as e:
                print repr(e)
                if e.errno == errno.EPIPE:
                        break

        time.sleep(0.2) # чтобы выхлоп stdout не затирал промт

Теперь уже можно будет парсить выхлоп баша (PROMPT), если нужно будет.