[win,nix,flame] Устройство правильной консоли [re: консоль в dll-е]

slonishka

Как именно она выводит в консоль? Если через WriteConsole, то оно в файл не перенаправится ни в каком виде.

ЖЕСТЬ
автор, послушай мантру стива балмера.

kokoc88

ЖЕСТЬ

Никакой ЖЕСТИ, просто это низкоуровневый метод для работы с окном консоли. Например, Far Manager рисует через этот метод свой GUI.

slonishka

Никакой ЖЕСТИ, просто это низкоуровневый метод для работы с окном консоли.
Например, Far Manager рисует через этот метод свой GUI.

а управляющие символы там есть? просто я привык к тому, как это в UNIX сделано,
там не нужно никаких методов все и так работает (и работает быстро).
впрочем, я не читал curses, мб там все тоже как-то причудливо.

kokoc88

а управляющие символы там есть?

Само консольное окно не имеет никакого отношения к управляющим символам, что в общем-то логично.

там не нужно никаких методов

Как это не нужно? Они там почти наверняка есть, учитывая, что консоль может быть каким-нибудь стандартным TTY. Просто ты уже говоришь про высокоуровневые функции.

slonishka

Само консольное окно не имеет никакого отношения к управляющим символам, что в общем-то логично.

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

Как это не нужно? Они там почти наверняка есть, учитывая, что консоль может быть каким-нибудь TTY.
Просто ты уже говоришь про высокоуровневые функции.

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

Serpent555

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

bleyman

а управляющие символы там есть? просто я привык к тому, как это в UNIX сделано,там не нужно никаких методов все и так работает (и работает быстро).

ХА ХА ХА ХА, "в UNIX всё работает"!
Как ты думаешь, какой "символ" посылает кнопка Esc? Нет, чувак, вовсе не эскейп последовательность соответствующую нажатию эскейпа, какой-нибудь ^[[E, а обычный голый сырой ^[. И типа если ты после этого быстро введёшь какую-нибудь валидную эскейп последовательность, там, не знаю, [OA, то она воспримется как нажатие кнопки вверх!
Теперь угадай, какая самая часто нажимаемая кнопка в основополагающем UNIX текстовом редакторе vi и его потомках! Обоссаться можно, не правда ли?
Причём в большинстве случаев эта стройная система костылей и подпорок как бы работает, но если вдруг сделать шаг в сторону, типа "inoremap <Esc> <Esc>`^", то гвим внезапно становится в полтора раза менее ебанутым, или вим запущенный из локальной консоли, зато в виме запущенном сквозь ssh перестают работать все непростые кнопки.
Причём жопа же — это не то, что кнопка ескейп и традиция её использования как кнопки, а не для ввода эскейп секвенсов, появилась недавно и вдруг оказалась в конфликте со старыми стандартами которые ещё не успели исправить, нет, UNIX официально превратился в окаменелое кривое говно в 1976 блядь году!

slonishka

не ХА ХА ХА, а бу-бу-бу

Причём в большинстве случаев эта стройная система костылей и подпорок как бы работает, но если вдруг сделать шаг в сторону, типа "inoremap <Esc> <Esc>`^", то гвим внезапно становится в полтора раза менее ебанутым, или вим запущенный из локальной консоли, зато в виме запущенном сквозь ssh перестают работать все непростые кнопки.

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

slonishka

хотя не, бу-бу-бу щас будет от топикстартера, у него же ПРОБЛЕМА!

apl13

и потом, они детям каким-то африканским помогают же, кстати, лол!

Из Уганды.

slonishka

Причём в большинстве случаев эта стройная система костылей и подпорок как бы работает, но если вдруг сделать шаг в сторону, типа "inoremap <Esc> <Esc>`^", то гвим внезапно становится в полтора раза менее ебанутым, или вим запущенный из локальной консоли, зато в виме запущенном сквозь ssh перестают работать все непростые кнопки.

т.е. ну да, вим - это один сплошной хак. например, можно не запускать вим сквозь ссш,
а редактировать локальные копии, а при :w заливать их по scp (там есть такой режим).
наверное есть еще 50 других хаков на этот случай.
ну просто он же вообще все почти умеет...
и потом африканские дети. ну т.е. из Уганды, да, как Денис подсказывает.
мне кажется, Ему можно простить неследование идеалам саклесс.орг.
у которых, кстати, даже свой проект статически слинкованного ЮНИКСА есть.

doublemother

Поддерживаю. Виму можно простить любой код.

okis

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

slonishka

только не bash, а sh. bash - это bourne again shell.
я сам их путаю вечно, эти названия. =)

C Is Not Algol
Writing the UNIX Version 7 shell (command interpreter) at Bell Labs in the late
1970's, Steve Bourne decided to use the C preprocessor to make C a little more
like Algol-68. Earlier at Cambridge University in England, Steve had written an
Algol-68 compiler, and found it easier to debug code that had explicit "end
statement" cues, such as `if ... fi` or `case ... esac`. Steve thought it wasn't
easy enough to tell by looking at a "}" what it matches. Accordingly, he set up
many preprocessor definitions:
  #define STRING char *
  #define IF if(
  #define THEN ){
  #define ELSE } else {
  #define FI ;}
  #define WHILE while (
  #define DO ){
  #define OD ;}
  #define INT int
  #define BEGIN {
  #define END }
This enabled him to code the shell using code like this:
  INT compare(s1, s2)
     STRING s1;
     STRING s2;
  BEGIN
     WHILE *s1++ == *s2
     DO IF *s2++ == 0
     THEN return(0);
     FI
     OD
     return(*--s1 - *s2);
  END
Now let's look at that again, in C this time:
  int compare(s1, s2)
     char * s1, *s2;
  {
     while (*s1++ == *s2) {
     if (*s2++ == 0) return (0);
     }
     return (*--s1 - *s2);
  }
This Algol-68 dialect achieved legendary status as the Bourne shell permeated
far beyond Bell Labs, and it vexed some C programmers. They complained that the
dialect made it much harder for other people to maintain the code. The BSD 4.3
Bourne shell (kept in `/bin/sh`) is written in the Algol subset to this day!
I've got a special reason to grouse about the Bourne shell - it's my desk that
the bugs reported against it land on! Then I assign them to Sam! And we do see
our share of bugs: the shell doesn't use malloc, but rather does its own heap
storage management using sbrk(2). Maintenance on software like this too often
introduces a new bug for every two it solves. Steve explained that the custom
memory allocator was done for efficiency in string-handling, and that he never
expected anyone except himself to see the code.
The Bournegol C dialect actually inspired The International Obfuscated C Code
Competition, a whimsical contest in which programmers try to outdo each other in
inventing mysterious and confusing programs.

Werdna

#define STRING char *
#define IF if(
#define THEN ){
#define ELSE } else {
#define FI ;}
#define WHILE while (
#define DO ){
#define OD ;}
#define INT int
#define BEGIN {
#define END }

Что-то во мне проснулся зверь, и желание КРОВИ. Не, ну я всё понимаю, как упражнение на дефайны пойдёт, но продакшен код-то зачем так писать?
По теме топикстартера. Типичные виндузятские вопли про "проблему". Один болван пишет прогу, которая вперемешку фигачит в stdout и stderr, другой болван видит вывод у себя в консоли, и называет это так как видит — «dll пишет в консоль». Для виндузятника писать в stdout и писать в консоль — одно и то же.
По теме, так сказать решение проблемы, открыть файл на дескрипторах stdout и stderr, причём помнить о том, что если это _НЕ_ сделать, то высеры это dll могут оказаться в непредсказуемом месте (например, в открытом сокете или другом файле).
Вот такое вот программирование...

Serpent555

По теме топикстартера. Типичные виндузятские вопли про "проблему". Один болван пишет прогу, которая вперемешку фигачит в stdout и stderr, другой болван видит вывод у себя в консоли, и называет это так как видит — «dll пишет в консоль». Для виндузятника писать в stdout и писать в консоль — одно и то же.

...третий болван не может прочитать описание проблемы
Именно для того, чтобы не уточнять, какими конкретно средстваим пользуется библиотека, я и использовал более общее "пишет в консоль". И откуда столько ненависти к "виндузятникам"?..
К слову, я уже запостил, в чем на самом деле была проблема. Очень забавно получать советы уже после этого, что лишний раз свидетельствует о внимании автора
Но спасибо за желание сделать пост не-оффтопик.

Werdna

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

Мне кажется ты недостаточно "скрыл несущественные мелочи", сказал бы проще — пишет на ЭКРАН. Для виндузятника это было бы просто и понятно, особенно если сказать что есть компонента для Дельфи визуалстудии за 15 баксов, которая решит проблему.
Видишь ли, прога может писать как stdout/stderr (это первый случай так и WriteConsole делать (совершенно другой случай). Но ты в упор не видишь, что у тебя спрашивают и над чем стебутся.
Бачан — эксперт, ФЖ_ — тоже не дурак, но... мне кажется бесполезно тут что-то объяснять.

Dasar

>Мне кажется ты недостаточно "скрыл несущественные мелочи", сказал бы проще — пишет на ЭКРАН.
не лезь со своим самоваром(со своей терминологией) в тулу.
если прога выводит на ЭКРАН - то это gui. а вывод в поток - это вывод на КОНСОЛЬ.
чел все правильно пишет.
зы
но ты прав, что стоит отличать между собой C-шные потоки, C++-потоки и windows-потоки. еще в виде экзотики бывает прямой вывод на консоль (через api, а не через потоки)