Re: Продвинутая работа с клипбордом
Evgeny M. Zubok - debian-russian@lists.debian.org @ Sun, 08 Jun 2014 01:50:11 +0400: Prior to Emacs 24, the kill and yank commands used the primary selection (see Primary Selection), not the clipboard. If you prefer this behavior, change x-select-enable-clipboard to nil, x-select-enable-primary to t, and mouse-drag-copy-region to t. EMZ То есть, если я правильно понимаю, в 24-м надо назад включить PRIMARY, EMZ но и не выключать CLIPBOARD, т. е.: EMZ (setq x-select-enable-clipboard t) EMZ (setq x-select-enable-primary t) EMZ И должно тогда одновременно попадать в оба буфера. Вероятно, да. Но надо проверить. -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87r42zc3sl@wizzle.ran.pp.ru
Re: Продвинутая работа с клипбордом
Hi. Вот, кстати, и аргумент в пользу старого доброго xterm vs. urxvt. А то я было хотел уже на urxvt переползать. Нет, ребята, лучше xterm пока ничего не придумали. В нем ВСЁ предусмотрено... [грустно] А может, в нем таки предусмотрена возможность восстанавливать содержимое после уменьшения окна, а потом возвращения прежнего размера? Я не нашел, но может, плохо искал?
Re: Продвинутая работа с клипбордом
Alex Kicelew - debian-russian@lists.debian.org @ Sun, 8 Jun 2014 12:34:53 +0400 (MSK): Вот, кстати, и аргумент в пользу старого доброго xterm vs. urxvt. А то я было хотел уже на urxvt переползать. Нет, ребята, лучше xterm пока ничего не придумали. В нем ВСЁ предусмотрено... AK [грустно] А может, в нем таки предусмотрена возможность AK восстанавливать содержимое после уменьшения окна, а потом AK возвращения прежнего размера? Я не нашел, но может, плохо искал? В нем - да. Если буфер экрана достаточного размера предусмотрен (у меня в .Xresources XTerm*saveLines: 1024), то оно так и работает. Но вот если в нем запущена терминальная программа, которая сама работает с экраном, то это вопрос уже к этой программе. -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87mwdnbu8d@wizzle.ran.pp.ru
Re: Продвинутая работа с клипбордом
Hi. AK [грустно] А может, в нем таки предусмотрена возможность AK восстанавливать содержимое после уменьшения окна, а потом AK возвращения прежнего размера? Я не нашел, но может, плохо искал? В нем - да. Если буфер экрана достаточного размера предусмотрен (у меня в .Xresources XTerm*saveLines: 1024), то оно так и работает. Но вот если в нем запущена терминальная программа, которая сама работает с экраном, то это вопрос уже к этой программе. Я имел в виду другое. Не количество строк, а их длину. Запускаем хтерм, в нем запускаем ls (или любую другую программу, которая выводит достаточно длинные строки). Уменьшаем ширину окна (в тайловом менеджере, например, запускаем еще один хтерм). В получившемся маленьком окне видим только часть оригинальной длинной строки. Увеличиваем окно до первоначального размера (или больше). И видим в нем ту же самую часть первоначальной строки. Остальное пропало безвозвратно при изменении ширины. В рокстерме обе ситуации отрабатывают более корректно. При уменьшении ширины окна строки разбиваются по текущей ширине (разумеется, при этом по-прежнему теряется часть информации, т.к. новое окно меньше оригинального, но теряется не правая, а _верхняя_ часть, и ее можно достичь через shift-pgup), а при восстановлении ширины восстанавливаются и оригинальные строки. Эта возможность для меня достаточно критична, из-за чего и приходится пользоваться рокстермом, который меня не устраивает по многим параметрам -- но менее критичным. Но допускаю, что я чего-то не разглядел в хтерме, в котором меня устраивает все кроме этого.
Re: Продвинутая работа с клипбордом
On Sun, 8 Jun 2014, Alex Kicelew wrote: Hi. AK [грустно] А может, в нем таки предусмотрена возможность AK восстанавливать содержимое после уменьшения окна, а потом AK возвращения прежнего размера? Я не нашел, но может, плохо искал? В нем - да. Если буфер экрана достаточного размера предусмотрен (у меня в .Xresources XTerm*saveLines: 1024), то оно так и работает. Но вот если в нем запущена терминальная программа, которая сама работает с экраном, то это вопрос уже к этой программе. Я имел в виду другое. Не количество строк, а их длину. Запускаем хтерм, в нем запускаем ls (или любую другую программу, которая выводит достаточно длинные строки). Уменьшаем ширину окна (в тайловом менеджере, например, запускаем еще один хтерм). В получившемся маленьком окне видим только часть оригинальной длинной строки. Увеличиваем окно до первоначального размера (или больше). И видим в нем ту же самую часть первоначальной строки. Остальное пропало безвозвратно при изменении ширины. В рокстерме обе ситуации отрабатывают более корректно. При уменьшении ширины окна строки разбиваются по текущей ширине (разумеется, при этом по-прежнему теряется часть информации, т.к. новое окно меньше оригинального, но теряется не правая, а _верхняя_ часть, и ее можно достичь через shift-pgup), а при восстановлении ширины восстанавливаются и оригинальные строки. Эта возможность для меня достаточно критична, из-за чего и приходится пользоваться рокстермом, который меня не устраивает по многим параметрам -- но менее критичным. Но допускаю, что я чего-то не разглядел в хтерме, в котором меня устраивает все кроме этого. Немного не то, но все же: xterm+screen обрабатывает ситуацию корректно. Плюс множество других удобств, скажем возможность работы с буфером вывода практически как с текстовым файлом. Ю.
Re: Продвинутая работа с клипбордом
Hi. Немного не то, но все же: xterm+screen обрабатывает ситуацию корректно. Плюс множество других удобств, скажем возможность работы с буфером вывода практически как с текстовым файлом. Да, спасибо, скрин я использую, но все же он применим не всегда. В частности, для корректной работы именно этого момента он должен быть уже запущен.
Re: Продвинутая работа с клипбордом
Alex Kicelew - debian-russian@lists.debian.org @ Sun, 8 Jun 2014 14:19:18 +0400 (MSK): AK [грустно] А может, в нем таки предусмотрена возможность AK восстанавливать содержимое после уменьшения окна, а потом AK возвращения прежнего размера? Я не нашел, но может, плохо искал? В нем - да. Если буфер экрана достаточного размера предусмотрен (у меня в .Xresources XTerm*saveLines: 1024), то оно так и работает. Но вот если в нем запущена терминальная программа, которая сама работает с экраном, то это вопрос уже к этой программе. AK Я имел в виду другое. Не количество строк, а их длину. Запускаем AK хтерм, в нем запускаем ls (или любую другую программу, которая AK выводит достаточно длинные строки). Уменьшаем ширину окна (в AK тайловом менеджере, например, запускаем еще один хтерм). В AK получившемся маленьком окне видим только часть оригинальной длинной AK строки. Увеличиваем окно до первоначального размера (или больше). И AK видим в нем ту же самую часть первоначальной строки. Остальное AK пропало безвозвратно при изменении ширины. AK В рокстерме обе ситуации отрабатывают более корректно. При AK уменьшении ширины окна строки разбиваются по текущей ширине AK (разумеется, при этом по-прежнему теряется часть информации, AK т.к. новое окно меньше оригинального, но теряется не правая, а AK _верхняя_ часть, и ее можно достичь через shift-pgup), а при AK восстановлении ширины восстанавливаются и оригинальные строки. AK Эта возможность для меня достаточно критична, из-за чего и AK приходится пользоваться рокстермом, который меня не устраивает по AK многим параметрам -- но менее критичным. Но допускаю, что я чего-то AK не разглядел в хтерме, в котором меня устраивает все кроме этого. А, понял. Да, есть такая проблема. Пишут, что у urxvt ее нет. Просто у меня такая конфигурация окон xmonad, что меня эта проблема практически не касается. На новой машинке, может, и коснется... -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87ioobbg3w@wizzle.ran.pp.ru
Re: Продвинутая работа с клипбордом
On 06/07/2014 10:50 AM, Artem Chuprina wrote: предыдущее состояние удалять путем зажимания BackSpace и/или Del s Вместо зажимания можно нажать Ctrl-A, а потом BackSpace или Del. Произойдет ровно описанный далее эффект. У меня всё работает. -- sergio. -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53949521.3040...@sergio.spb.ru
Re: Продвинутая работа с клипбордом
On 2014.06.06 at 15:38:54 +0400, Artem Chuprina wrote: - чтобы к выделению не надо было добавлять явную операцию помещения в clipboard (опционально; может быть, я зря этого хочу, и стоило бы переучиться, но тогда надо обучать этому urxvt/xterm) Я переполз на lxterminal, он умеет работать с клипборд по стандартной виндовой модели. В смысле с явной операцией copy. Переполз, конечно, не из-за этого. Но у меня сильное подозрение что мейнтейнеры emacs-а руководствовались именно мыслью о том, что нехорошо когда все программы идут не в ногу, один emacs в ногу. Поэтому когда терминальные программы, интегрированные во всякие de (lxterminal, gnome-terminal, konsole) cущественно потеснили старый-добрый xterm, на новую модель работы с выделениями пришлось переползать и emacs. Вдвоем универсальный обработчик текстов и эмулятор терминала - это сила. Но в одиночку каждый из них не тянет. -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140609041133.ga18...@wagner.pp.ru
[DONE] wml://security/2014/dsa-295{2,3}.wml
Cheers! Lev Lamberov --- english/security/2014/dsa-2953.wml 2014-06-08 17:32:26.0 +0200 +++ russian/security/2014/dsa-2953.wml 2014-06-08 21:11:43.349361624 +0200 @@ -1,29 +1,31 @@ -define-tag descriptionsecurity update/define-tag +#use wml::debian::translation-check translation=1.2 maintainer=Lev Lamberov +define-tag descriptionобновление безопасности/define-tag define-tag moreinfo -pMultiple vulnerabilities were discovered in dpkg that allow file -modification through path traversal when unpacking source packages with -specially crafted patch files./p +pВ dpkg были обнаружены многочисленные уязвимости, которые позволяют изменять +файлы с помощью изменения пути при распаковке пакетов с исходным кодом, содержащих +специально сформированные файлы заплат./p -pThis update had been scheduled before the end of security support for -the oldstable distribution (squeeze), hence an exception has been made -and was released through the security archive. However, no further updates -should be expected./p +pДанное обновление было запланировано до окончания поддержки безопасности +предыдущего стабильного выпуске (squeeze), поэтому было сделано исключение +и осуществлён выпуск обновления через архив безопасности. Тем не менее, дальнейшие обновления +для предыдущего стабильного выпуска ожидать не следует./p -pFor the oldstable distribution (squeeze), these problems have been fixed in -version 1.15.11./p +pВ предыдущем стабильном выпуске (squeeze) эти проблемы были исправлены в +версии 1.15.11./p -pFor the stable distribution (wheezy), these problems have been fixed in -version 1.16.15./p +pВ стабильном выпуске (wheezy) эти проблемы были исправлены в +версии 1.16.15./p -pFor the testing distribution (jessie), these problems will be fixed -soon./p +pВ тестируемом выпуске (jessie) эти проблемы будут исправлены +позже./p -pFor the unstable distribution (sid), these problems have been fixed in -version 1.17.10./p +pВ нестабильном выпуске (sid) эти проблемы были исправлены в +версии 1.17.10./p -pWe recommend that you upgrade your dpkg packages./p +pРекомендуется обновить пакеты dpkg./p /define-tag # do not modify the following line #include $(ENGLISHDIR)/security/2014/dsa-2953.data # $Id: dsa-2953.wml,v 1.2 2014/06/08 15:32:26 gusnan-guest Exp $ + --- english/security/2014/dsa-2952.wml 2014-06-08 11:38:49.0 +0200 +++ russian/security/2014/dsa-2952.wml 2014-06-08 21:06:38.165375419 +0200 @@ -1,46 +1,48 @@ -define-tag descriptionsecurity update/define-tag +#use wml::debian::translation-check translation=1.1 maintainer=Lev Lamberov +define-tag descriptionобновление безопасности/define-tag define-tag moreinfo -pSeveral vulnerabilities have been discovered in the FreeBSD kernel that may -lead to a denial of service or possibly disclosure of kernel memory. The Common -Vulnerabilities and Exposures project identifies the following problems:/p +pВ ядре FreeBSD были обнаружены несколько уязвимостей, которые могут +приводить к отказу в обслуживании или возможному раскрытию памяти ядра. Проект Common +Vulnerabilities and Exposures определяет следующие проблемы:/p ul lia href=https://security-tracker.debian.org/tracker/CVE-2014-1453;CVE-2014-1453/a -pA remote, authenticated attacker could cause the NFS server become -deadlocked, resulting in a denial of service./p/li +pУдалённый и авторизованный злоумышленник может вызвать зависание сервера NFS, +что приводит к отказу в обслуживании./p/li lia href=https://security-tracker.debian.org/tracker/CVE-2014-3000;CVE-2014-3000/a: -pAn attacker who can send a series of specifically crafted packets with a -connection could cause a denial of service situation by causing the kernel -to crash./p - -pAdditionally, because the undefined on stack memory may be overwritten by -other kernel threads, while difficult, it may be possible for an attacker -to construct a carefully crafted attack to obtain portion of kernel memory -via a connected socket. This may result in the disclosure of sensitive -information such as login credentials, etc. before or even without -crashing the system./p/li +pЗлоумышленник, имеющий возможность отправить серию специально сформированных пакетов, +может вызвать отказ в обслуживании, который возникает из-за аварийного завершения работы +ядра./p + +pКроме того, поскольку неопределённая переменная стека может быть перезаписана +другими нитями ядра, хотя это и сложно, это может позволить злоумышленнику +организовать специальную атаку для получения части памяти ядра +через подсоединённый сокет. Это может приводить к раскрытию чувствительной +информации, такой как данные учётной записи и проч. до или даже без +аварийного завершения работы системы./p/li lia href=https://security-tracker.debian.org/tracker/CVE-2014-3880;CVE-2014-3880/a -pA local attacker can trigger a kernel crash (triple fault) with potential -data loss, related to the
