Рыба ржавеет

Ну и правильно делают, в баше и то много лишнего. Нескучные шеллы это такое же задротство, как тайловые wm.

Без обид, да, просто наблюдение. У коллег с линуксом в качестве основной ОС поголовно стоят почти дефолтные дебиан-штабле или убунта с гномом. Самое большее украшательство, которое я видел - кайро-док внизу. Ни тайлов, ни фигурной сборки арчика, ни пердолинга zsh - скукота.

Где мне у тебя его найти? В комментах на ЛОРе?

Надеюсь хотя бы основной шелл не сломается пока переезжают. Боюсь спрашивать про плагины

Ни тайлов, ни фигурной сборки арчика, ни пердолинга zsh - скукота.

И правильно. Людям ведь работать нужно, а не фигурно задрачивать какерские тайлы.

Пока искал примеры ядер с -Werror, -Wall, наткнулся на сайт ИСП РАН, их проекты.

Кстати, один из проектов - как раз про Си: https://forge.ispras.ru/projects/klever

Пока искал примеры ядер с -Werror, -Wall, наткнулся на сайт ИСП РАН, их проекты.

Я имел ввиду Linux.

с головы?

Ты опечатался в xonsh.

Судя по моему недавнему треду в Development

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

Да. вот тут например (я на него давал ссылку из комментов). Предупреждаю - оно когда-то переведено на си с пхп (моего же), без желания вкладывать какие-то силы, поэтому код местами очень некрасивый и архитектурно плохой. Более того, там что-то (побочное) не собирается новыми компиляторами на 64 битах, но не из-за си, а из-за ассемблера (можно обойти выбором не-асм варианта или вообще убиранием того файла из сборки). Но мы говорим про use-after-free, и его там нет (malloc-и есть). Или тут (эта прога без пхп-прошлого, хотя там нету почти malloc-ов но можешь ещё какие-нить «си-проблемы» поискать).

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

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

А надо с #!/usr/bin/env

Не надо. #!/bin/sh гарантируется в POSIX, в отличие от других шеллов. Например, в NixOS – системе, кладующий большой и толстый на FHS – /bin/sh является единственным файлов в /bin.

считаю пхп хорошим языком для «набросать что-то по-быстрому».

Как он в этом плане в сравнении с питоном?

Система, кладущая большой и толстый, может его положить и на posix. Вот кто ей запретит?

Никто, конечно. Но тогда и env работать не будет.

#!/bin/sh гарантируется в POSIX

Я так-то позикс за говно держу, не волнует что оно там гарантирует.

в NixOS – системе, кладующий большой и толстый на FHS – /bin/sh является единственным файлов в /bin

А еще это ссылка на bash, а в убунте - на dash. Это называется «удачного дебага».

Не писал ничего не питоне (только исправлял немного). Могу предположить такие аспекты:

1) у питона слишком самобытный синтаксис, у пхп же он сишный который везде; лично мне это огромный плюс (т.к. си я уже знал), и думаю много кому

2) питон прощает мусор вместо кода на входе? это весьма снижает порог входа

Но если кто-то уже изучил питон и привык к нему - наверно тоже годится для этих целей.

А почему это собственно плохо?

Уверен что я не использую и 10% возможностей fish (может кто подскажет самые имбовые, которым следует научиться?), но мне нравятся его маленькие fishечки, поэмуто первым делом ставлю fish и htop.

А еще это ссылка на bash, а в убунте - на dash. Это называется «удачного дебага».

Что не так? Bash покрывает все фишки bourne shell, так что тут проблем нет. Алсо, можно указать любой шелл по вкусу envoronment.binsh, хотя документация не рекомендует так делать.

Штука хорошая, но бесполезная. Т.к. bash/sh это дефолт, а fish это только на компе у гиков бывает.

Ну к слову сказать повершел убог

избавиться от ошибок, таких как обращение к памяти после её освобождения

Ничего не понял. Зачем они оставляют ошибки там, где им известно, что они там есть?

при обработке строк, для которых в Fish используется тип wchar_t

Почему они не используют std::wstring?

Скрипты пишу только с !#/bin/sh.

И получаешь мучение с тем что у него разные интерпретаторы на разных дистрах… dash или не dash, dash или не dash?

Я скрипты пишу только с !#/bin/bash

Интерактивно пользуюсь разным, но не bash.

И получаешь мучение с тем что у него разные интерпретаторы на разных дистрах… dash или не dash, dash или не dash?

Какие скрипты без башизмов по-разному работают в ash, dash и bash?

некоторые вещи по сравнению с башем испортили

Что именно?

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

Однако следить за тем что написано на минимальном подмножестве - это отдельная малоавтоматизируемая задача. Приходится заглядывать в мануал чтоб понять является ли какой-то нюанс в коде универсальным или просто «случайно работает на конкретнмо шелле». Но это мелочи. Крупные проблемы совместимости начинаются там, когда из-за отсуствия втроенных продвинутых конструкций на каждый чих начинается вызов внешних утилит типа [, grep, awk и что там вызывают в качестве калькулятора.

И теперь даже если сам код на sh оказывается соответствующим минмальным стандартам - встаёт вопрос о том, а полностью ли совместимо использование [ в коде или случайно заюзали какое-то расширение?

Если же писать bash по максимум используя внутренние функции, и по минимуму внешние вызовы - то в вопросе своместимости остаётся только версионирование bash. Что тоже конечно вопрос, но это уже одномерная шкала совместимости, а не вопрос из версий кучи разных утилит.

Также доки на возможности bash собраны в одном линейном месте, в man bash. А вот на весь этот зоопарк утилит - есть одна линейная дока?

Когда в целевой системе есть питон то пишу только под него. Но быват ситуации когда скрипт должен мочь выполниться во всяких примитивных окружениях где питона реально нет, поэтому ниша для bash/sh остаётся

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

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

Штука хорошая, но бесполезная. Т.к. bash/sh это дефолт, а fish это только на компе у гиков бывает.

1. Как, по-твоему, должно измениться твое использование шелла с fish, чтобы ты не смог использовать bash при необходимости? Это точно такой же шелл, только нормально настроенный по дефолту;

2. Что мешает установить fish где тебе надо? Это несколько мегабайт, которые устанавливаются вместе с другими полезными вещами типа htop и нормального вима.

И получаешь мучение с тем что у него разные интерпретаторы на разных дистрах… dash или не dash, dash или не dash?

Я предлагаю сначала получить мучение, а потом уже думать что с ним делать.

Линуксовые шеллы рассчитаны на интерактивное использование, именно поэтому они такие как есть. Из Повершелла пытались сделать язык программирования, а получилось говно.

А километровые портянки на баше – это типа не программирование?

Для интерактивного использования линуксовый шелл тоже кстати просасывает. Например, банально нет возможности использовать вывод предыдущей команды. Он тупо нигде не сохраняется, и надо копипастить.

С + Lua + pthreads/omp == быстро, безопасно, многопоточно. И скомпиляется на любом калькуляторе.

повысить безопасность работы с памятью и избавиться от ошибок, таких как обращение к памяти после её освобождения

Просто не обращайся к ней после освобождения?

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

Так это же здорово. Перестали о нем сраться и начали на нем писать.

Поддерживаю. /bin/sh единственный способ писать по-настоящему переносимые скрипты, потому что bash/zsh и прочие есть не везде, а sh везде

На самом деле дело привычки. Я например работаю из под мака. И для навигации консоль с чистым zsh использую чаще чем родной графический проводник. Я не говорю, что у меня есть какие-то претензии к родному проводнику. Он нормальный. Но мне прост командный интерфейс привычнее. В нем я быстрее работаю.

встаёт вопрос о том, а полностью ли совместимо использование [ в коде

Давай пример несовместимости test между дистрибутивами Линукса.

Спасибо, что хоть сделали тег LastC++11. Может и форк появится.

`команда` например. Зачем ЭТО было менять несовместимым образом, я хз.

Клещи устарели и лучше их не использовать:

http://mywiki.wooledge.org/BashFAQ/082

Очень неубедительные причины не использовать ``. Типа стоя на лыжах в гамаке вам будет неудобно. А может мне и не надо в гамаке. Про плохую читаемость это уж точно не башистам рассказывать. Просто лол.

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

Ну вот тебе еще одна причина: сейчас везде маркдаун и клещи его легко могут сломать cat /etc/os-release.

# что было в маркдауне:
``cat /etc/os-release``

# что подразумевалось:
`cat /etc/os-release`

У меня исторически сложилось, что в баше горка функций и алиасов. С перделками и свистелками в виде уровня заряда батереи и текущей git-ветки.

однажды может стать deprecated

Нет, потому что древние скрипты никто не станет переписывать. Хотя от линупсоидов любых пакостей можно ожидать конечно.

и текущей git-ветки

А вот в fish это из коробки без всяких перделок :)

Новость строго негативная. Вместо развития шелла теперь ближайшие 5 лет он будет переписываться на раст с задействованием пары сотен лефтпадов, пока его не постигнет участь wlroots-rs.

А познания автора в С++ отлично видны еще по использованию wchar.

А вот в fish это из коробки без всяких перделок :)

Да. Оно просто работает, тем и хорошо.

Зачем fish многопоточность?