xonsh

У меня самописный Шелл buttsh. Плагины примерно как у тебя:

buttplug "benis/oh-my-butt", as:plugin, use:"lib/*.buttsh"

t184256

Я пользуюсь, много лет основным шеллом. Долгий старт на утюгах, нельзя бездумно копипастить шелл-код. В остальном — божественная благодать.

Названия половины плагинов звучат как встроенная безxontribная функциональность.

Какие недостатки?

https://github.com/xonsh/xonsh/issues/2561

zsh форкнул?)

this is almost certainly an issue with how stderr and stdout are being synchronized.

А нечего на это полагаться =P

мдааа

Всё не так. Никто stdout/stderr не синхронизирует вообще и не должен, и никто на несуществующую синхронизацию нигде и не полагается.

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

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

Касательно stdout/stderr и их мнимой «синхронизации» отдельный коммент.

Действительно, если бездумно чередовать fprintf в stdout и stderr, то надписи могут (не во всех случаях) появиться на экране не в том порядке, как вызывались соответствующие fprintf. Ситуация может усугубиться либо выводом неполных строк, либо конвеером (типа | grep xxx да даже просто | cat) на выходе программы. Создаётся впечатление, будто что-то там синхронизировалось обычно, а тут вот синхронизация нарушилась. Обманчивое.

На самом деле, тут всё дело в буферизации вывода, и делает её вовсе не терминал и не ядро, а сама программа, кодом внутри функций printf и других из stdio.h. А именно (по умолчанию, но это поведение можно перенастроить в коде программы), всё что пишется в stderr - сразу попадает в fd 2 через syscall write(), а вот то, что пишется в stdout - попадает в fd 1 далеко не сразу. Если fd 1 - терминал, то оно попадает обычно при выводе очередного перевода строки. Если fd 1 - не терминал (а например конвеер в grep), то оно попадает ещё позже - при заполнении внутреннего юзерспейсного буфера в структуре FILE). А вот дальше, обычно, fd 1 и fd 2 - синонимы, и write(1,...) с write(2,...) делают одно и то же, никакой рассинхронизации между ними быть не может. Если там есть конвеер, то уже не синонимы, да, fd1 идёт в конвеери и что с ним будет дальше - зависит исключительно от конвеерной проги (grep?), fd2 (если его специально не редиректить) остаётся терминалом.

Но шелл тут, во всех случаях, ни при чём, и влиять не ситуацию не должен!

Ещё отмечу, что всё вышеописанное полностью детерминировано, и даже если stderr c stdout и выводятся не в том порядке, то это не какая-то рандомная «рассихронизацияя», а полностью заранее известное поведение (с точностью до каждого символа), опять повторюсь, независимо от шеллов.

Речь о чем-то типа этого?

~ 
➜ echo -e "foo\nbar\nbaz\nquix" > /tmp/file         

~ 
➜ sort /tmp/file
bar
baz
foo
quix

~ 
➜ sort /tmp/file > /tmp/file


# Где мои отсортированные строки? - Нетути строк!
~ 
➜ cat /tmp/file                    

Ты затёр файл перед чтением, причём тут это вообще?

me никогда не думать над тем, что если есть оператор redirect >, то добавляется скрытая операция с высшим приоритетом «очистить файл», те:

$ cat file > file

1. TRUNCATE file
2. CAT file
3. REDIRECT cat output TO file

Неявное - лучший друг плохого

изучив вопрос, взвесив все доводы за (питон мой основный язык) и против (питон - говно, которое не позволяет писать эпичные однострочники для этого лучше подходят perl, haskel), я пришел к выводу, что xon.sh не нужен. bash - убогое говно, powershell лучше, а поэтому я остаюсь при zsh

Каким ещё приоритетом?

> означает очистить файл, если он существовал

>> редирект без очистки

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

ты, видимо, далекий от программирования человек. по логике человека, который писал на 10-ке языков, операции должны выполняться так:

1. output a file
2.1. truncate a file
2.2. write input (output previous command) to a file

Не позорься и изучи организацию файловых операций в POSIX. И английский заодно.

Редирект (>) делает open(O_TRUNC|O_CREAT) и затем dup2(fd,1). Первый вызов создаёт, либо открывает+чистит файл, второй вызов ставит его дескриптор на место стандартного вывода.

После редиректа шелл делает execve() - запускает (в твоём примере) /bin/cat, причём дескриптор стандартного вывода уже редиректнут на файл, вызовами выше.

Программа, когда делает стандартный вывод, делает write(1, ...), а уж что там в fd1 открыто (терминал или файл) тут уже почти не важно.

1. создать подпроцесс
2. заменить (в созданном подпроцессе, пока что ещё принадлежащем шеллу) файловые дескрипторы в соответствии с редиректами
3. вызвать в созданном подпроцессе указанную в команде программу

Иными словами (для тупых) нет никакой операции «запись в файл», есть только операция «запись в fd1». Открывание файла и настройка fd1 происходит до запуска cat, делается шеллом. Если редиректа нет то дефолтный fd1 это консоль.

для тупых же объясняют, что выражения во всех языках выполняются слева-направо, так же как их читает мозг. первая операция тут вывод в stdout, как там в системе оно реализовано я думать не должен. молодец, что освоил как syscalls посмотреть. это, несомненно, тебя делает сверхчеловеком среди эникеев

Который раз повторяю.

Сначала шелл делает редиректы, затем шелл запускает команду. В другом пордке это сделать невозможно: в ужезапущеной командешелл ничего поменять не может.

Редиректы делаются слева направо, да.

cat x1.txt > q1.txt > q2.txt x2.txt

Тут есть два редиректа: сначала шелл создаст файл q1.txt и перенастроит на него fd1, затем создаст файл q2.txt и перенастроит на него fd1 (а старый редирект в q1.txt при этом потеряется, файл останется пустым). После выполнения редиректов останется команда:

cat x1.txt x2.txt

Из неё слово cat с помощью поиска по $PATH расшифруется в /bin/cat, который и будет запущен, а три строки «cat», «x1.txt», «x2.txt» будут переданы ему в качестве аргументов.

Для шелла тут нет операции «чтение x1.txt», x1.txt это просто строка, которую надо передаь дочернему процессу, что он там будет с ней делать - его дело.