Michael: Honestly, I don't get the appeal. Diamonds are literally carbon molecules lined up in the most boring way. They are worthless space garbage. What you're holding right now, that's basically meteorite poop. Tahani (happily): And I have the biggest piece!
В фильмах часто показывают, как драгоценный камень приносят какому-нибудь ювелиру, тот надевает окуляр, смотрит на камень — и говорит, что это фальшивка, обычное стекло или ещё что-то в этом духе. Давно интересно: как они это определяют, по каким характеристикам?
Вы смешиваете совершенно разные сценарии. Я знаю, что поиск глобальный, но при чём тут это, если я говорил про удобство чтения одной страницей вместо постоянных прыжков туда-сюда? Причём прыжков практически вслепую, с невозможностью даже посмотреть полное дерево страниц или своё текущее положение в этом дереве.
Но хорошо, возьмём ваш поиск. Что толку с того, что он глобальный, если он ведёт себя точно так же, как поиск в мане? Как мне перейти к описанию опции -f, если поиск мне в первую очередь подсовывает всевозможные "если опция -f включена" и "а вот это вы узнаете в описании -f, если когда-нибудь до него доберётесь"?
Если сравнить с HTML, то man — это одностраничный документ сплошного текста, которому не хватает лишь расстановки внутренних ссылок-якорей. info — это многостраничный веб-сайт с разветвлённой навигацией и кучей независимых страниц.
Для быстрого поиска и для общего обзора всей информации сразу одностраничный документ намного удобнее. Поэтому я предпочитаю man, так как он показывает всё и сразу. Но вот навигации в man мне не хватает. Не в виде разбиения документа на отдельные кусочки, как это сделано в info, а в виде быстрых переходов к нужной точке в пределах единого сплошного документа.
Любопытно. Раньше точно нельзя было. Я точно помню, как когда-то давно натыкался на это и запомнил, что f — это "файл", и имя файла должно идти строго после. Видимо, подшаманили.
info на мой взгляд слишком ударился в противоположную крайность: всё разбито на кучу разделов и подразделов. На то, чтобы добраться до нужного (и понять, куда этот нужный раздел вообще засандалили), зачастую уходит больше времени, чем на чтение. Плюс курсорная навигация сбивает привычные шаблоны.
Из сложившихся у меня паттернов работы с документацией я бы сказал, что хотелось бы типичный сплошной man, но с дополнительной метаинформацией, которая позволяла бы ускорить поиск некоторых ключевых элементов в массиве текста.
А для следующего -f есть не менее широко известная букавка n )
Я знаю. И про поиск как прямой через /, так и обратный через ?, и про g, и про G, и про включение-выключение регистрозависимости, и многое другое. Но это не отменяет того факта, что для нахождения требуемой опции часто приходится пробегать через множество нерелевантных вхождений идентичного текста. Нет простого способа сказать "найди мне не просто подстроку в массиве текста, а конкретно опцию с конкретно таким именем". Также как нет простого и быстрого способа заставить мануал перепрыгнуть к конкретному разделу.
Вот только этот поиск найдёт не только -f, но и всякие "--first", "--delete-file", "well-formed" и так далее. Надо изгаляться с пробелами, но лишний пробел — и вот мы уже не можем найти нужную опцию, потому что там не "-f", а "-f, --force".
Особенно доставляют инструкции вида "а вот это описано в разделе Pattern Matching", но чтобы найти этот раздел, надо сначала прокликать Next'ом ещё сто двадцать упоминаний этого раздела.
В общем, man — штука полезная, тут спорить сложно, но вот юзабилити у неё не ахти.
И как автокомплитить, если даже не помнишь, что константа начинается именно с S_? Да и констант таких как бы не так уж мало.
$ grep -E '\bS_' -r /usr/include/ | wc -l
222
Ну, ОК, 202, если исключить упоминания в комментариях. И 148 из них начинаются с S_I. То есть чтобы получить внятную подсказку автодополнения, нужно ввести бо́льшую часть самого имени, а для этого надо его помнить. Разве что система дополнения жутко умная и подставляет не все константы, а только соответствующие контексту в вызове функции. Но опять же, а если я в переменную засовываю значение, чтобы потом применить? Контекста уже не будет.
Это во всех системах так, если вместо знака = между ugoa и rwx поставить знак +. И это совершенно стандартное документированное поведение chmod.
Я про запуск без указания оператора. Кроме того, если не указывать, к кому применять права (типа chmod +rwx), то где-то это будет применено к юзеру, а где-то — ко всем. В общем, не супер-важная проблема, можно указывать и явно. Но лично мне проще вписать 0755 и не дёргаться. Буквенные использую, только когда права нужно именно частично модифицировать, а не установить полный набор.
IMHO, эти константы ещё сложнее запомнить. USR или USER? или просто U? G/GRP/GROUP, O/OTH/OTHER? read-user или user-read? И что за I в начале, и почему префикс S_?
И даже в команде chmod с простыми однобуквенными обозначениями есть свои сюрпризы. Помнится, в каких-то системах буквенные rwx по умолчанию означали "установить указанные права", а в других — "добавить права к имеющимся". А число — что указал, ровно то и будет.
Там, кстати, довольно элементарно. Всё идёт из операции сравнения, которая по сути вычитание. Самый элементарный сравниватель — это буквально "a-b" (в некоторых языках/библиотеках проверяется только знак возвращаемого значения и не требуется обеспечивать строго -1/0/1).
Ну, HTML там уже отображают раздутым и тормозящим хромодвижком. С девятой что ли версии. А интерфейс самой программы пока вроде как нативный, но направление движения в последних версиях мне давно уже не нравится. :-(
единственный минус - ящики gmail превратились в тыкву из-за гугловских политик безопасности.
Это можно обойти. Если проблема в oauth2, то можно либо настроить в гугле пароль приложения и использовать его для аутентификации Бата, либо задействовать локальный аутентификационный прокси типа Email OAuth 2.0 Proxy. Если же проблема в неподдерживаемых TLS-сертификатах, то с этим справляется, например, stunnel: он берёт зашифрованное подключение на себя, а Бат обменивается с ним данными уже по локальному незашифрованному каналу.
Еще неудобство с письмами не тестом, а html - ответ будет текстом (а может я настроил так, не помню уже - сколько лет прошло!)
Да, это настраивается. Можно поменять на HTML (или сделать так, чтобы на текстовые отвечал текстом, на HTML — HTML'ем).
Я не лингвист, но не думаю, что здесь этот аргумент применим. Ведь абсолютно то же самое можно сказать и про "он водит" — но там никакой замены не произошло. С другой стороны, у глагола "ходить" аналогичная картина (ты ходишь, он ходит, но я хожу), а ему смысловое отдаление не требуется.
Насколько я слышал, замена и миграция букв/звуков в языках происходит совершенно по другим принципам и более глобально, чем просто "эти два слова слишком похожи, давайте одно заменим" (не говоря уж о том, что проще заменить "воду" на условную "жидкость" с сохранением корректных словоформ, чем кардинально ломать грамматику в одном конкретном случае). Причём зачастую такие миграции как раз приводят к сближению изначально отличавшихся разнородных слов, как, скажем, "мир" (отсутствие войны) и "мир" (вселенная).
Когда учил турецкий язык, впечатлился тем, какая у него высокая информационная плотность. То, что в русском языке выражается длинным сложноподчинённым предложением, там укладывается в два-три слова, так как все смысловые уточнения кодируются цепочкой коротких суффиксов. Но это же делает язык более сложным в восприятии, так как становится слишком много похожих слов и фраз, обозначающих разные вещи.
Набор passkey'ев, которые давали доступ ко всем моим аккаунтам, ко всем банковским счетам, госуслугам и так далее? Позволю себе не согласиться, для меня это будет именно что самая главная проблема.
© The Good Place
Что глаз набит — это понятно. Интересно, на что именно он набит. Неужто коэффициент преломления на глаз оценивает?
В фильмах часто показывают, как драгоценный камень приносят какому-нибудь ювелиру, тот надевает окуляр, смотрит на камень — и говорит, что это фальшивка, обычное стекло или ещё что-то в этом духе. Давно интересно: как они это определяют, по каким характеристикам?
Вы смешиваете совершенно разные сценарии. Я знаю, что поиск глобальный, но при чём тут это, если я говорил про удобство чтения одной страницей вместо постоянных прыжков туда-сюда? Причём прыжков практически вслепую, с невозможностью даже посмотреть полное дерево страниц или своё текущее положение в этом дереве.
Но хорошо, возьмём ваш поиск. Что толку с того, что он глобальный, если он ведёт себя точно так же, как поиск в мане? Как мне перейти к описанию опции -f, если поиск мне в первую очередь подсовывает всевозможные "если опция -f включена" и "а вот это вы узнаете в описании -f, если когда-нибудь до него доберётесь"?
Если сравнить с HTML, то man — это одностраничный документ сплошного текста, которому не хватает лишь расстановки внутренних ссылок-якорей. info — это многостраничный веб-сайт с разветвлённой навигацией и кучей независимых страниц.
Для быстрого поиска и для общего обзора всей информации сразу одностраничный документ намного удобнее. Поэтому я предпочитаю man, так как он показывает всё и сразу. Но вот навигации в man мне не хватает. Не в виде разбиения документа на отдельные кусочки, как это сделано в info, а в виде быстрых переходов к нужной точке в пределах единого сплошного документа.
Может, и от платформы, да. Я попробовал только на Rocky 9.6, которая была под рукой, и там
tar cfz a.tgz testfileотработала без ошибок.Любопытно. Раньше точно нельзя было. Я точно помню, как когда-то давно натыкался на это и запомнил, что f — это "файл", и имя файла должно идти строго после. Видимо, подшаманили.
info на мой взгляд слишком ударился в противоположную крайность: всё разбито на кучу разделов и подразделов. На то, чтобы добраться до нужного (и понять, куда этот нужный раздел вообще засандалили), зачастую уходит больше времени, чем на чтение. Плюс курсорная навигация сбивает привычные шаблоны.
Из сложившихся у меня паттернов работы с документацией я бы сказал, что хотелось бы типичный сплошной man, но с дополнительной метаинформацией, которая позволяла бы ускорить поиск некоторых ключевых элементов в массиве текста.
Я знаю. И про поиск как прямой через /, так и обратный через ?, и про g, и про G, и про включение-выключение регистрозависимости, и многое другое. Но это не отменяет того факта, что для нахождения требуемой опции часто приходится пробегать через множество нерелевантных вхождений идентичного текста. Нет простого способа сказать "найди мне не просто подстроку в массиве текста, а конкретно опцию с конкретно таким именем". Также как нет простого и быстрого способа заставить мануал перепрыгнуть к конкретному разделу.
Вот только этот поиск найдёт не только -f, но и всякие "--first", "--delete-file", "well-formed" и так далее. Надо изгаляться с пробелами, но лишний пробел — и вот мы уже не можем найти нужную опцию, потому что там не "-f", а "-f, --force".
Особенно доставляют инструкции вида "а вот это описано в разделе Pattern Matching", но чтобы найти этот раздел, надо сначала прокликать Next'ом ещё сто двадцать упоминаний этого раздела.
В общем, man — штука полезная, тут спорить сложно, но вот юзабилити у неё не ахти.
И как автокомплитить, если даже не помнишь, что константа начинается именно с S_? Да и констант таких как бы не так уж мало.
Ну, ОК, 202, если исключить упоминания в комментариях. И 148 из них начинаются с S_I. То есть чтобы получить внятную подсказку автодополнения, нужно ввести бо́льшую часть самого имени, а для этого надо его помнить. Разве что система дополнения жутко умная и подставляет не все константы, а только соответствующие контексту в вызове функции. Но опять же, а если я в переменную засовываю значение, чтобы потом применить? Контекста уже не будет.
Я про запуск без указания оператора. Кроме того, если не указывать, к кому применять права (типа
chmod +rwx), то где-то это будет применено к юзеру, а где-то — ко всем. В общем, не супер-важная проблема, можно указывать и явно. Но лично мне проще вписать 0755 и не дёргаться. Буквенные использую, только когда права нужно именно частично модифицировать, а не установить полный набор.IMHO, эти константы ещё сложнее запомнить. USR или USER? или просто U? G/GRP/GROUP, O/OTH/OTHER? read-user или user-read? И что за I в начале, и почему префикс S_?
И даже в команде chmod с простыми однобуквенными обозначениями есть свои сюрпризы. Помнится, в каких-то системах буквенные rwx по умолчанию означали "установить указанные права", а в других — "добавить права к имеющимся". А число — что указал, ровно то и будет.
Там, кстати, довольно элементарно. Всё идёт из операции сравнения, которая по сути вычитание. Самый элементарный сравниватель — это буквально "a-b" (в некоторых языках/библиотеках проверяется только знак возвращаемого значения и не требуется обеспечивать строго -1/0/1).
А почему было не экспортировать батовские ящики в mbox или тупо в набор eml-файлов, а в громоптичке это всё подхватить?
Ну, HTML там уже отображают раздутым и тормозящим хромодвижком. С девятой что ли версии. А интерфейс самой программы пока вроде как нативный, но направление движения в последних версиях мне давно уже не нравится. :-(
Это можно обойти. Если проблема в oauth2, то можно либо настроить в гугле пароль приложения и использовать его для аутентификации Бата, либо задействовать локальный аутентификационный прокси типа Email OAuth 2.0 Proxy. Если же проблема в неподдерживаемых TLS-сертификатах, то с этим справляется, например, stunnel: он берёт зашифрованное подключение на себя, а Бат обменивается с ним данными уже по локальному незашифрованному каналу.
Да, это настраивается. Можно поменять на HTML (или сделать так, чтобы на текстовые отвечал текстом, на HTML — HTML'ем).
Да, ещё одна приятная сторона турецкого — его стройность и логичность, и крайне малое число исключений.
Я не лингвист, но не думаю, что здесь этот аргумент применим. Ведь абсолютно то же самое можно сказать и про "он водит" — но там никакой замены не произошло. С другой стороны, у глагола "ходить" аналогичная картина (ты ходишь, он ходит, но я хожу), а ему смысловое отдаление не требуется.
Насколько я слышал, замена и миграция букв/звуков в языках происходит совершенно по другим принципам и более глобально, чем просто "эти два слова слишком похожи, давайте одно заменим" (не говоря уж о том, что проще заменить "воду" на условную "жидкость" с сохранением корректных словоформ, чем кардинально ломать грамматику в одном конкретном случае). Причём зачастую такие миграции как раз приводят к сближению изначально отличавшихся разнородных слов, как, скажем, "мир" (отсутствие войны) и "мир" (вселенная).
Когда учил турецкий язык, впечатлился тем, какая у него высокая информационная плотность. То, что в русском языке выражается длинным сложноподчинённым предложением, там укладывается в два-три слова, так как все смысловые уточнения кодируются цепочкой коротких суффиксов. Но это же делает язык более сложным в восприятии, так как становится слишком много похожих слов и фраз, обозначающих разные вещи.
Набор passkey'ев, которые давали доступ ко всем моим аккаунтам, ко всем банковским счетам, госуслугам и так далее? Позволю себе не согласиться, для меня это будет именно что самая главная проблема.