В рамках проекта TermKit (https://github.com/unconed/TermKit) развивается (http://acko.net/blog/on-termkit) платформа для создания терминалов нового поколения, отличающихся учетом контекста выполняемых команд и использованием элементов современных пользовательских интерфейсов. TermKit построен с использованием серверной JavaScript-платформы node.js и web-движка WebKit, тем не менее, терминал является полноценным десктоп-приложением, выполняемым обособленно от браузера. В настоящее время поддерживается только работа в ОС Mac OS X.
<center><a href="https://github.com/unconed/TermKit/raw/master/Mockups/Shot-0... src="http://www.opennet.me/opennews/pics_base/30597_1305738021.jp... style="border-style: solid; border-color: #e9ead6; border-width: 15px;" title="" border=0></a></center>
В процессе интерактивной работы пользователя в командной строке TermKit анализирует mime-типы файлов и обрабатывает выводимый на экран контент. Например, если выполнить "cat изображение.jpg", то...URL: http://acko.net/blog/on-termkit
Новость: http://www.opennet.me/opennews/art.shtml?num=30597
> если выполнить "cat изображение.jpg", то на экране будет показано изображениеЗакапывайте.
Я вот тоже думаю, что что-то здесь не то! Такое чувство, что идеологию Unix ломают
Для макоси же. Вы же понимаете что среднестатистическому пользователю макоси вообще похер что там у системы с юниквейностью. Думаю со временем в убунте внедрят и будут правы. Это дистрибутивы нецеленые не на юниксвей, потому что юниксвей не сильно-то привлекает среднестатистического пользователя коспьютера. Эти дистрибутивы/ОСи нацелены на простоту и удобство самого простого пользователя которые сайчас сидит на венде и тыкает в пуск.
Или вы всё ещё не понимаете всего этого?
Причем тут Mac OS X? Ах разработчик Взял WebKit, node.js, jQuery и что-то собрал и запустил на OS X и теперь вы преплятаете среднестатистических пользователей системы к TermKit и строите аргументацию.
ОК.
Причем тут Mac OS X - там так принято
Притом что эта штука ориентирована не на троллей которые плачут о не юниквейности на форумах подоных этому, а на тех пользователей которые просто пользуются чем-то потому что это удобно, и вроде как мак славиться именно своим удобством.
А что по поводу webkit, node.js и jquery, то причёт тут это вообще, вы по технологиям определяете ЦА? поделитесь секретом как вы это делаете?
> Притом что эта штука ориентирована не на троллей которые плачут о не юниквейности на форумах подоных этому,Понимаешь ли, мужики интересуются: если при cat facepalm.jpg будет выведена на экран терминала картинка, то что же будет выводиться при cat facepalm.jpg | grep "Пальмы" или при cat facepalm.jpg > newfacepalm.jpg ? Мы что-то тут не видим стройной концепции, в которую впишется эта программа-терминал. Получается, что это вовсе не терминал, а обычный файловый менеджер типа наутилуса, но только с извращенной формой UI - консолью вместо GUI. Т.е. получается, что это будет очередная поделка для людей, которые хотят поиграть в "крутых админов, работающих в терминале".
Согласен. Непонятно именно ЦА данного продукта. Пользователи в консоль все равно не полезут, хоть убей. Профи на такие "фичи" тока плеваться будут. Остается только прослойка "продвинутых пользователей" которые трюки в консоле умеют и перделкам радуются.Ну а про "cat facepalm.jpg". Если система считает себя умнее пользователя то это не сюда ... это идеология винды. Нам с ними не по пути.
> Согласен. Непонятно именно ЦА...
> Пользователи в консоль все равно...Одно время мечталось просмотреть в ТЕКСТОВОЙ :), не иксовой консоли какой-либо из 100тыщ жипегов, лежащих на колокейшене. Так и помнилась 286-ая тачка, на которой можно было жипег в досе посмореть :)
С VNC (парит, конечно, нешифрованный протокол) проблема сильно-сильно решилась.
И лично мне, при всей моей страсти "смотреть" жипеги именами файлов в выводе от ls и изредка простейшую гляделку из консоли запускать - такая возможность, как cat foo.jpg ну, совсем не нужна.
Дорогой, если ты плюешь бинарь на консоль - она вправе показать тебе его так, как она сможет. Эта - может и обработчики применить на основе mime-заголовка. остальные - просто покажут бинарные символы в текущей локали.Если ты будешь его в файл писать или грепом парсить - консоли до этого какое дело? не путай шелл и терминал - это теплое и мягкое.
>что же будет выводиться при cat facepalm.jpg | grep "Пальмы" или при cat facepalm.jpg > newfacepalm.jpg ?Объектной ориентированностью это называется. "cat" и "|" в данном подходе можно считать операторами, facepalm.jpg - объектом некоторого типа/класса.
И вот одной из возможностей ОО подхода является перегрузка операторов. Т.е. для типа JPEG будет вызван свой оператор cat, для текстового файла - свой, и т.д.
Операторы с одинаковым именем могут выбираться по типу принимаемого и типу возвращаемого аргумента. Поэтому "cat facepalm.jpg | grep "Пальмы" будет делать именно то, что вы от неё ждёте, т.е. unix way поведения.
Как-то так.
вы смешиваете терминальные функции и функции shell.не unix way.
>>что же будет выводиться при cat facepalm.jpg | grep "Пальмы" или при cat facepalm.jpg > newfacepalm.jpg ?
> Объектной ориентированностью это называется.Хоть жопой с ручкой. Технически, возможно 2 разных действия:
1) Разобрать это как кусок текста, хоть и содержащий непечатные символы местами. Тем не менее, так можно запросто грепнуть теги/коменты/что там еще. В нормальном шелле это даже катит.
2) Показать как картинку/обработать как картинку ака массив пиксеоей годных для отображения.При том, указанные действия принципиально различны, где проходит четкая грань когда надо 1) а когда 2) - вы и сами запутаетесь в сотнях mime type'ов, а в результате получится просто бардак. Консоль для блондинок? No way: блондинкам не нужна консоль!
> и вроде как мак славиться именно своим удобством.ключевые слова тут — «вроде как».
> Эти дистрибутивы/ОСи нацелены на простоту и удобство самого простого пользователя которые сайчас сидит на венде и тыкает в пуск.А зачем этим людям терминал?
> Для макоси же. Вы же понимаете что среднестатистическому пользователю макоси вообще похер
> что там у системы с юниквейностью.Уже представил как пользователь, поигравшись с "этим" попробует сделать в линухе "cat image.jpg" и увидев тонны кракозябр в консоле скажет "линукс - калл".
> Уже представил как пользователь, поигравшись с "этим" попробует сделать в линухе "cat
> image.jpg" и увидев тонны кракозябр в консоле скажет "линукс - калл".будет ещё хуже. с большой долей вероятности в бинаре встретится какой-нибудь искейп, и вообще переключит терминал в хитрый режим. после чего юзер будет бегать и кричать, что линух отстой, он, юзер, весь линух поломал одной командой.
Понимаем :)
"среднестатистическому пользователю" cat не нужен. "Среднестатистический" администратор windows, например, не знает что такое dir.
> "среднестатистическому пользователю" cat не нужен. "Среднестатистический" администратор
> windows, например, не знает что такое dir.вы не поверите, как задалбывает искать конкретную консольную команду для просмотра этой же картинки или любого другого бинаря в каждом нововстреченном линуксе/юниксе!!!
это шиздец. Хочешь открыть чем-то, но не vim и не cat - добро пожаловать в главное меню, изучай список установленных программ. хочешь быстрее - открывай через файловый менеджер, ползи снова до папки, щелкай - открывай.
я у себя в zsh настроил автоматический поиск и ассоциацию установленных программ к типам файлов по mime и по расширениям - но не будешь же свой профиль пихать на каждый комп, особенно чужой.
вот лежит на серваке бинарь, видео, например. какая у вас процедура? подрубиться по sshfs, начать смотреть плейером. это надо отдельную консоль запустить, команду выполнить, заново добраться до директории и потом уже запустить. а тут банальный cat - и смотришь файло.
А теперь усложним - некоторые интересные провайдеры хранят видео в базе оракля. делаешь select content_body from video where id=15 и смотришь. :) в вашем классическом случае надо будет, наверное, fuse2oracle писать?
Открой для себя xdg-open>вот лежит на серваке бинарь, видео, например. какая у вас процедура? подрубиться по sshfs, начать смотреть плейером. это надо отдельную консоль запустить, команду выполнить, заново добраться до директории и потом уже запустить. а тут банальный cat - и смотришь файло.
Далеко не факт что это будет работать удалённо
аха. беру первый попавшийся случайный линукс (с иксами, замечу)
zsh: command not found: xdg-openчяднт? вот об этом я и говорю - везде все по-разному, кроме базовых gnu-утилит, да и они от юникса к юниксу разнятся!
> Далеко не факт что это будет работать удалённо
в таком случае, навороченный cat нам тоже не поможет. надеюсь, речь идет об узости канала?
или отключенном sftp в конфиге ssh? (что нетипично)
> аха. беру первый попавшийся случайный линукс (с иксами, замечу)
> zsh: command not found: xdg-openУстанови xdg-utils
> чяднт? вот об этом я и говорю - везде все по-разному, кроме
> базовых gnu-утилит, да и они от юникса к юниксу разнятся!Думаешь эта поделка магическим образом появится во всех линуксах искаропки?
А xdg-utils есть во многих десктопных дистрах.>> Далеко не факт что это будет работать удалённо
> в таком случае, навороченный cat нам тоже не поможет. надеюсь, речь идет
> об узости канала?Нет, я просто не совсем пойму нужны ли модифицированные утилиты для этого. Если нужны - то на сервер их тоже придётся ставить.
> или отключенном sftp в конфиге ssh? (что нетипично)
sftp тут явно ни при чём... данные в любом случае будут передаваться через стандартные потоки ввода/вывода.
> Нет, я просто не совсем пойму нужны ли модифицированные утилиты для этого.
> Если нужны - то на сервер их тоже придётся ставить.Не совсем пойму, зачем модифицировать тот же cat, чтобы вытащить mime-тип передаваемых данных.
>> Нет, я просто не совсем пойму нужны ли модифицированные утилиты для этого.
>> Если нужны - то на сервер их тоже придётся ставить.
> Не совсем пойму, зачем модифицировать тот же cat, чтобы вытащить mime-тип передаваемых
> данных.mime-тип вставляет в поток отправляющая сторона. К тому же делает она это (на текущий момент) исходя из расширения файла (sic!)
Не согласен. Я думаю что, mime входящего потока тоже учитывается и команда
cat img.jpg | gzip -f
спросит куда сжатый файл выводить или выведет в консоль (скорее второе). Не вижу особого нарушения unix-way.
> cat img.jpg | gzip -f
> спросит куда сжатый файл выводить или выведет в консоль (скорее второе). Не
> вижу особого нарушения unix-way.а потом чувак перепишет весь bash и половину юзерленда, чтобы этот монстр хоть иногда мог делать что-то сложнее cat.
> cat img.jpg | gzip -fДефективность подхода уже в этом действе.
Если cat imag.jpg - вывод на экран как картинки, то почему тогда перенаправление в другую программу вдруг внезапно оказывается созданием архива? Две похожие команды делают нечто совершенно разное. Замечательно. А cat img.jpg | gzip -f | gzip -x я что примерно должен получить? По логике вещей?
что ты хочешь от дизайнеров-стилистов
> что ты хочешь от дизайнеров-стилистовНаличия мозга, желательно чуть побольше чем у обезьяны.
Есть мнение что это не специфика там реализованной команды cat, а анализ выводимого на консоль файла. Собственно, при таком подходе логика не нарушена - иначе также можно бить ногами авторов gzip которые сделали ограничение вывода на терминал по умолчанию -)
Допустим
cat img.jpg на выходе может иметь как бинарный вид, так и вид изображение.
gzip может иметь на входе только бинарные данные
Т.е. если cat используется как источник для gzip, то на вход gzip будет подан именно бинарный поток.
Юниксу капец? Ничего, что его "идеологию" сломали уже много-много раз? Ничего, что идеологией занимаются идейные, а простые люди просто работают? С тем что удобно им.
> Юниксу капец? Ничего, что его "идеологию" сломали уже много-много раз? Ничего, что
> идеологией занимаются идейные, а простые люди просто работают? С тем что
> удобно им.ломают периодически. это печально. но не смертельно: обычно засыхает и отваливается.
Идеология линукс заключается в том, что ты можешь делать со своим компьютером все что захочешь. Хочешь сиди в серой консоли без иксор, а хочешь работай в одном из демятка ДЕ и не ДЕ или в этом чуде.
По мне дак очень удобно. Давно надо было прокачать терминал =) Даешь компиз для терминала. Колышущиеся буковки ;)
Главное чтобы улучшили автодополнение (контекстное меню), сделали, наконец, удобную работу мышью с текстом.
> сделали, наконец, удобную работу мышью с текстом.для удобной работы мышью с чем угодно надо:
* купить мышь нормальной формы;
* научиться правильно держать на ней руку;
* повозить мышью по столу;
* выкинуть мышь и использовать нормальные методы и нормальные программы.
> Закапывайте.У вас кто-то xterm что-ли отнимает ? Пусть будет.
А мышкой там можно команды набирать?
Хотелось бы посмотреть на этого самого простого пользователя, который полезет в командную строку.
Небось оверхед огого. А так наглядно, можно опционально реализовать или на чем-то быстрее javascript-a.
Например смотреть pdf в консоли через "less". ls на директорию и там файлы с иконками или миникартинки
А если я напишу cat изображение.jpg > изображение.ai? Он мне еще и экспорт в Adobe Illustrator выполнит??? o_O
То есть теперь можно писать cat music.ogg вместо mplayer music.ogg ?
Ндааа..)
Зато, можно и так:
cat my-song.mp3 > my-song.ogg
Или даже так:
cat my-video.avi > my-video-sound.ogg
cat my-song.mp3 > /dev/my-head-phonesPS. Штука и идея в первом приближении -- обалденная. Хотелось бы потрогать. Если вся эта магия действительно настраваема (т.е., в случае "cat my-song.mp3 > my-song.ogg", можно прописать, что декодируется mencoder'ом, а кодируется чем-то другим с такими-то параметрами)... уфф. Это будет круто!
# echo "rm -rf /*" > ~/cool.sh
# cat ~/cool.sh
xDD
Скорее всего, ничего там настраиваемо не будет. Поскольку отсутствует центральная идея, это выродится в набор некастомизируемых костылей и заглохнет из-за недостатка в потребительской аудитории
> Скорее всего, ничего там настраиваемо не будет. Поскольку отсутствует центральная идея,
> это выродится в набор некастомизируемых костылей и заглохнет из-за недостатка в
> потребительской аудиторииА как же *контекст*? По-моему, он и составляет основную идею контекста.
cat my-music.ogg : по-умолчанию выводит в стандартное устройство вывода, которое, в данном случае -- не просто терминал, а десктоп (дектопный терминал), который умеет интерпретирвать *пользовательские* типы данных, вроде ogg, а не просто, по-тупому копировать байты в стандартный поток вывода.
А если контекста нет, то тогда утилиты работают по-стандартному: cat my-pic.jpg| bzip > mypic.jpg.bz
Разве что Ваше предположение, здесь оно самое разумное. Если инфо выводится в терминал, то можно попробовать угадать mime-тип и запустить соответствующую программу-вьюер. Но сильно полагаться на эту вещь я бы не стал - если она не угадает тип файла, который я хочу вывести, то я получу кучу кракозябр и перекошенные настройки. Возможна и другая проблема, когда я захочу получить обычный текстовый вывод, а эта прога, считающая себя умнее меня, распознает в нем какой-нибудь SVG и преобразует его в хер пойми что
> а эта прога, считающая
> себя умнее меня, распознает в нем какой-нибудь SVG и преобразует его
> в хер пойми чтопотому применимость у неё весьма ограниченая. собственно, вряд ли усилия по пилению адекватны применимости.
> Разве что Ваше предположение, здесь оно самое разумное. Если инфо выводится в
> терминал, то можно попробовать угадать mime-тип и запустить соответствующую программу-вьюер.
> Но сильно полагаться на эту вещь я бы не стал -
> если она не угадает тип файла, который я хочу вывести, то
> я получу кучу кракозябр и перекошенные настройки. Возможна и другая проблема,
> когда я захочу получить обычный текстовый вывод, а эта прога, считающая
> себя умнее меня, распознает в нем какой-нибудь SVG и преобразует его
> в хер пойми чтоДа, то же решаемо всё.
1. Во-первых, анализируем строку ввода, смотрим что на входе .avi, а на выходе (в STDOUT) .ogg, значит, предположительно нужно играть mplayer'ом это. Во-вторых, когда все это прогоняется через фильтры, каждый раз (или только на выходе) проверить на соответствие типа mime, что наша выходная програмка действительно поддерживает его... и вуаля.
2. Ну в случае с "cat hello.html" (cat hi.svg), имхо, просто решается: мы либо выполняем его стандартно, либо в режиме "магической" интерпретации. Как мы в этот режим переключаемся, и какой по-умолчанию, не важно: хоть по ctrl-enter, если данной комбинацией закончился ввод, то всё идёт стандартным путем.
> Да, то же решаемо всё.ага. причём давно уже решено. mplayer movie.avi. links hello.html. и так далее. кому лень — можно добавить в профиль функцию шелла — open, например. которая будет распознавать расширения и вызывать нужный софт (уверен, что это уже давно написано и есть), и писать тупо open anyfile.anyext.
зачем городить сложный и монструозный велосипед для простой задачи, которая вообще от терминала не зависит — я не понимаю.
"распознавать расширения и magic"quick sfx
> зачем городить сложный и монструозный велосипед для простой задачи, которая вообще от
> терминала не зависит — я не понимаю.Затем, чтобы по
*ls dir*, мне показался список файлов, и если там есть картинки, то чтобы они показались мне в уменьшенном виде, если есть видео, то с кадром из фильма, и чтобы, при желании я мог кликнуть на него, чтобы удобным образом просмотреть его, или набрать cat film.avi
*scp ...*, программка асинхронно копировала бы файлик и сразу показывала бы прогресс.Это не просто терминал, а _десктопный_ терминал.
> Затем, чтобы по
> *ls dir*, мне показался список файлов, и если там есть картинки, то
> чтобы они показались мне в уменьшенном виде, если есть видео, то
> с кадром из фильма, и чтобы, при желании я мог кликнуть
> на него, чтобы удобным образом просмотреть его, или набрать cat film.aviэ… открой для себя гуёвые файломенеджеры. добавь хоткей «открыть терминал в текущем каталоге» — и получишь телемаркет.
> Это не просто терминал, а _десктопный_ терминал.лолщито? терминал — это терминал. gui fm — это gui fm. зачем надевать ужа на ежа?
> PS. Штука и идея в первом приближении — обалденная. Хотелось бы потрогать.
> Если вся эта магия действительно настраваема (т.е., в случае "cat my-song.mp3
> > my-song.ogg", можно прописать, что декодируется mencoder'ом, а кодируется чем-то другим
> с такими-то параметрами)… уфф. Это будет круто!хотелось бы намекнуть, что если уж хочется таких извращений — то это всяко будет задача шелла, но никак не эмулятора терминала.
добавить несколько искейпов для вывода картинок, так и быть (или просто для встраивания другого окна в терминал, так лучше) и сделать свой шелл, пользоваться которым невозможно, но который умеет играть в преферанс вне зависимости от того, под каким терминалом запущен.
блин, неужели сложно немного головой-то подумать?
Если Вы делаете "cat my-song.mp3 > my-song.ogg", вывода в терминал НЕ ПРОИСХОДИТ! Это целиком и полностью остаётся в шелле!
Изменяться будет тот контент, который идёт в терминал!
> Например, если выполнить "cat изображение.jpg", то на экране будет показано изображение, а не бинарное содержимое файла.А если выполнить "curl http://malware.org/tr0jan.c", то исходник будет автоматичесчки скачан и скомпилирован, и на экран сразу будет выведен результат выполнения программы, а не непонятный текст с фигурными скобочками.
прогнозирую эпический fail :-Dпотомучто:
1. для продвинутых пользователей -- наверняка в такой shell -- будет мега ущербным (как уже ранее отметили -- хотябы взять: less и grep)
2. для непродвинутых пользователей -- надо мышкой тыкать и командная строка чтото слишком сложное
************************************************************
а если им докалывает что команда cat выводит текст с подстветкой синтаксиса --
тык что же им мешает взять да и доработать этот cat:
включить в него опцию:
--color=auto
и сделать alias в bash:
alias cat='cat --color=auto'для этого всякие "node.js" -- поднимать не придётся :-)
>для продвинутых пользователей -- наверняка в такой shell -- будет мега ущербным (как уже ранее отметили -- хотябы взять: less и grep)Иксовое выделение не ущербно. Можно представить себе переговор между less/grep и чем-то ещё о mime-типе пайпа.
> Можно представить себе переговор между less/grep и чем-то ещё о mime-типе пайпа.А если вместо относительно стандартных less, grep и т. п. мне понадобится использовать свою утилитку из 10 строк, я должен буду ее переписать так, чтоб она умела разбираться с mime-типами, кодировками, парсила xml и т. д. и т. п. ?
> А если вместо относительно стандартных less, grep и т. п. мне понадобится
> использовать свою утилитку из 10 строк, я должен буду ее переписать
> так, чтоб она умела разбираться с mime-типами, кодировками, парсила xml и
> т. д. и т. п. ?конечно. это Будущее. а то мы всё в прошлом живём, с нашими пайпами глупыми.
Это не проблема - просто ваша утилитка, как не умеющая договариваться, будет получать/отдавать сырой бинарный поток, как и раньше. Плюс пара простейших конструкций для указания принимаемых утилиткой типов и для получения типов, принимаемых выходным потоком (это скорее надо где-то в FS держать - инфа статическая вроде), ну и определение, что же действительно вам сунули - это вообще можно получать в переменной окружения.В общем, сделать-то это аккуратно можно (тут уже считай вчерне спроектировали), осталось понять - зачем сие.
> 1. для продвинутых пользователей -- наверняка в такой shell -- будет мега ущербнымНу так он и есть. Какой-то гибрид кофемолки со сканером. Нет, чисто физически совместить кофемолку и сканер можно, даже можно придумать юзкейс: а вдруг захочется кофе попить при сканировании пачки документоы?! Вопрос только в том какому количеству людей это потом понадобится...
На самом деле, я бы не отказался от такой операционки, которая работала бы не с текстом, а с более продвинутыми структурами данных. Например, чтобы команда ls возвращала не текст, а список объектов типа "файл". По умолчанию терминал будет просто выводить список в виде текста, по элементу на строку, а для каждого элемента будет выводить дефолтное текстовое представление, то есть имя файла. Но если хочется, можно выводить рядом с именем файлов и превьюшки картинок, и на что у юзера фантазии хватит. Или, например, наводишь мышку на имя файла в терминале, и сразу получаешь всплывающую подсказку с полезной инфой. Wait... мышка это некошерно. Тогда просто взгляд наводишь, и компьютер сразу догадывается, чего ты от него хочешь. <убежал такое делать>
Для "список объектов" есть ЯПВУ, а для скриптинга есть то что нехрен ломать и не путайте мягкое с тёплым. А то что пытаются втюхать тут, это сродни - использовать метлу для подметания и для чистки ушей, мотивируя: А чо, я бы не отказался от действия "чыстить усё" одним инструментом. А ещё гланды удалять можно той же метлой попытаться. Иногда даже получится
> а список объектов типа "файл".Список *объектов* типа *файл* - это ФЭЙЛ на уровне самой концепции. Файл всегда был задуман как простая структура. Зачем вам файловая система? Юзайте объектно-ориентированную БД. А то что тормозить будет в 20 раз сильнее - ну так зато продвинутые сущности. Обработка которых ессно медленнее чем обработка простых, типа файлов.
>На самом деле, я бы не отказался от такой операционки, которая работала бы не с текстом, а с более продвинутыми структурами данных. Например, чтобы команда ls возвращала не текст, а список объектов типа "файл".Если чо, виндовый PowerShell так и работает с объектами, а не только с текстом
> В настоящее время поддерживается только работа в ОС Mac OS XСпасибо, конечно, но такой опенсорс - не нужен. Да и практически целый браузер в роли всего лишь консольки - истинно мако#$ское извращение. Зачем терминалу быть браузером? Или браузеру терминалом?
>> В настоящее время поддерживается только работа в ОС Mac OS X
> Спасибо, конечно, но такой опенсорс - не нужен.Портировать слабо? Ну так и молчи.
Я то думал, что терминал необходим для работы в системе что называется "из коробки" и без лишних зависимостей, а теперь это стало свистоперделкой с графическим выводом. Чтож, похвально. Правильным путем развиваетесь товарищи!
Осталось только каждому серверу по плазме (или ЖК на крайняк) и смотреть на них прон. Надеюсь что за рамки маков это уеб... ущербное творение никуда не спаразитирует.
>Например, если выполнить "cat изображение.jpg", то на экране будет показано изображение, а не бинарное содержимое файла.Эхем. cat обозначает "catenate" - соединять. Вывод содержимого на экран - побочная функция этой программы.
Как предполагается соединять два изображения? Склеить по вертикали, по горизонтали, наложить? Или просто соединить два файла, как обычно?
И почему такой вывода нужно делать по команде cat? Почему не назвать команду, например, "uniview" или в "do-zaebis"?
> И почему такой вывода нужно делать по команде cat?Потому что кто-то обкурился и решил что забивать микроскопом гвоздь - это прикольно.
давай, расскажи мне о твоих буднях. о том, как ты делаешь
cat image1.jpeg image2.png
и что ты с этим потом делаешь дальше... :)))
> давай, расскажи мне о твоих буднях. о том, как ты делаешь
> cat image1.jpeg image2.png
> и что ты с этим потом делаешь дальше... :)))А вот это надо спросить у утупка который придумал что cat должен выдавать картинку на экран как картинку. Потому что получается здорово: cat image.jpg - выводит картинку на экран. А cat image.jpg | gzip что делает? Ну уж точно не выводит картинку на экран?! Итого 2 тотально разных действия ... по 1 команде! Допереть до такого кретинизма может только макинтошник.
Народ, убейтесь об стену, или начните в конце концов читать новости дальше первого абазаца. Речь идет о терминале а не о модификации программы cat. Никаких объектов она вам создавать не будет. Какой --color-auto!? cat просто был взят для примера. С там-же успехом можно и dd использовать: всё анализирует терминал.
А домыслы про пайпы — ваще ФГМ: в каком больном мозгу это могло родиться?
Ну если "cat изображение.jpg" выводит на экран картинку, то "display изображение.jpg" очевидно будет создавать файловую систему в файле изображение.jpg?
макосно, очень макосно. макосность мне противна.
на самом деле в этом нет смысла, так как как правило ты в курсе какие данные планируешь получить, и поэтому можешь сразу загнать их в программу подсвечивающую синтаксис, показывающую картинку итд.
автор, задумайся, многим ли людям оно нужно? так смеху ради можно поставить, но работать в этом никто не станет. потому что юниксвэй - полный контроль над происходящим. чтобы картинка не выводилась если ТЫ не изъявишь на то свое БОЖЕСТВЕННОЕ ЖЕЛАНИЕ. а изъявляется оно при помощи пайпа и программы просмотра изображений.
опять же
cat img1.jpg img2.jpgмы то знаем что там 2 картинки и понимаем в принципе как их поделить и посмотреть, а вот это ПО скорее всего отреагирует неадекватно. может конечно этот случай оно обработает, но тогда я придумаю что-то еще на чем оно сработает некорректно. не нужно делать ПО которое будет пытаться быть умнее меня, так как мне тогда придется его сломать, или разработчику запретить мне нажимать на некоторые кнопки.
> опять же
> cat img1.jpg img2.jpgГлавное в юниксоидном подходе это действо имеет смысл и даже может применяться на практике. Например можно сперва наэхать текстовую шапку-заголовок с размерами файлов а потом картинки именно вот так вот донавесить. Потом это при помощи нехитрых манипуляция можно будет из 1 файла опять на картинки распетрушить. А вот у мако$#ов в этом месте вырисовывается неоднозначность операции.
Ну, никого же давно не удивляет, что "ls" и "ls | cat" дают разный вывод.Если утилита может различать терминал и другой файл в качестве дескрипторов вывода, почему бы терминалу не различать при выводе на него --- текстовые и двоичные данные. Никакого такого тотального нарушения Unix way не просматривается.
Другое дело, что опора на расширения имен файла и подвязанные к ним типы xmime, а не на магические циферки, бесперспективны, поскольку не позволят адекватно отображать стандартный нетекстовый вывод утилит.
И остается вопрос, что будет происходить при этом с другими дескрипторами, натравленными на терминал (допустим, если STADERR туда же смотрит и гонит текстовый вывод одновременно).
> Другое дело, что опора на расширения имен файла и подвязанные к ним
> типы xmime, а не на магические циферки, бесперспективны, поскольку не позволят
> адекватно отображать стандартный нетекстовый вывод утилит.а где это написано, что именно на расширения идет упор? я в новости этого не вижу. разве что иконки отображаются - так никто не мешает по mime-типам брать иконки, как это делают нормальные файл-манагеры.
> И остается вопрос, что будет происходить при этом с другими дескрипторами, натравленными
> на терминал (допустим, если STADERR туда же смотрит и гонит текстовый
> вывод одновременно).хз, но мне кажется, что и терминал понимает, что в каком потоке. просто обычный терминал по умолчанию все потоки слепливает воедино.
да, так и есть - см диаграммы
вообще что то подобное уже давно было xul terminal или как то так, и давно сдохло, с этим будет тоже самое
Идиотизм. Ни файл мэнэджер ни консоль. Написали бы уже хороший файлмэнэджер с нормально-интегрированной консолью а-ля FAR, ну и со всё том же распознаванием майм типов. Разбирали бы коммандную строку так, что бы комманда типа: cat picture.jpg | termkit, таки открывал картинку этим вот термкитом. Подсветку синтаксиса можно и автоматически делать, думаю тут против никто не будет.
Нельзя быть такими красноглазыми-фанатиками, хорошая задумка имеет право на жизнь. Альтернатива всегда должна быть, а то сидели бы сейчас с vi и sh всю жизнь, че лучше было бы? Оторвитесь немного уже от мониторов, жизнь она разнообразна.
Хм, насколько я понял у него всё же модифицированные утилиты cat, grep, которые ещё вставляют заголовок content-type в свой std-out...
щас я объясню как надо.
пишешь утилиту magick которая все это реалирует.
и тогда любой админ легко и просто делает
cat img.jpg | magick
и получает вожделенные сиськи в окне терминала.
а если ему надо посмотреть все сиськи в дире то find ./ -name '*.jpg' -exec cat {} | magick \;второй способ - реализуешь терминал которые знает четвертый стандартный дескриптор stdmagick и если админу хочется увидеть сиськи, то он посылает их потоком бинарным в этот дескриптор.
Совершенно закономерное развитие идеи терминала. Идея настолько проста и красива, что странно, что это ещё не стало стандартом.Если утилита имеет графический вывод - зачем открывать для этого новое окно, когда можно нарисовать прямо в терминале (canvas же!)?
А если нужен табличный вывод - почему бы не сделать его средствами html, например.
Да и вообще, разве область применения терминала ограничивается работой с файлами?Собственно это и не bash уже, возможности круче и шире. Типа интерактивный COM (от DOM:)
И это однозначно круче, чем тот катастрофический PоwеrShеll, который и не шелл и не язык программирования полноценный. Странно и хорошо, что _те_ до этого не додумались.
Или может таки додумались где-то?Вопрос возникает: как там с патентами?
В графической оболочке Математики (которая Wolfram) есть такой rich terminal, который умеет показывать и интерактивую графику, и звуки. По идеологии слегка похоже на повер щель, там тоже все функции возвращают некие объекты, а терминал сам решает, в каком виде их представить. Но при этом у всех объектов есть и каноническое текстовое представление.
Спасибо, классное применение.
Да, конечно же, функциям лучше возвращать объекты, а как их представить - всегда можно выбрать - от текста до интерактивного html, как в Firebug, например.
вдохновившись TermKit'ом, сделал то же самое, но как эмулятор терминала. соответственно, остаётся родной bash/zsh и все родные юниксовые утилиты, и ссх и всё-всё-всё. плюс добавляются картинки
https://github.com/shepik/wkterm
буду рад замечаниям и багрепортам
а нельзя ли это на Qt как-нибудь того? а то лень вебкит-гтк собирать, да и выглядит гтк страшновато.
думаю, что можно. я с qt не работал вообще. embedded webkit можно найти уже готовый пример, но там из самого гтк кроме обёрточного кода используется ещё и gio, чтобы из сокета в фоне читать. буду рад, если расскажете, как это в кьюти делается.
> буду рад, если расскажете, как это в кьюти делается.собственно, встроеным классом для сокетов, он дёргает события. да и gio можно привинтить, если что. я попробую глянуть на код в ближайшие дни, авось скажу что-то конкретней. может, даже на гитхабе зарегистрируюсь по этому поводу. потому как идея сама по себе вполне забавная.