On 2023/12/16 20:12:16 +0100, Robert Palm wrote:
>
> Thanks again to all of you!
>
> xterm is now working!!!
>
> Still, xfce4-terminal doesn't seem to use this settings.
>
> Don't dare to ask where that setting is digged.
I tried for curiosity and xfce4-terminal doesn't show the lock icon for
Thanks again to all of you!
xterm is now working!!!
Still, xfce4-terminal doesn't seem to use this settings.
Don't dare to ask where that setting is digged.
Quoting Omar Polo :
On 2023/12/16 12:08:03 +0100, Nowarez Market wrote:
Using xterm,
then CTRL + Right click,
I add TrueType and
On 2023/12/16 12:08:03 +0100, Nowarez Market wrote:
>
> Using xterm,
> then CTRL + Right click,
> I add TrueType and I can display the lock:
>
> https://5md.es/l/2cc972f
>
> Seems you need a TrueType font do display the trick...
Yes, the default 'fixed' font has some 'fancy' character in it
Who did ircnow Billy G ?
This is the setup I use for Chinese and it works OK for me for
traditional Chinese and xterm:
https://wiki.ircnow.org/index.php?n=Openbsd.Uim
Fonts render properly and traditional Chinese input works.
--
jrmu
IRCNow (https://ircnow.org)
Using xterm,
then CTRL + Right click,
I add TrueType and I can display the lock:
https://5md.es/l/2cc972f
Seems you need a TrueType font do display the trick...
== Nowarez Market
Robert Palm wrote:
>
> Seems I have no success...
>
Quoting Omar Polo :
On 2023/12/15 15:33:44 -0600, "Jay F. Shachter" wrote:
Centuries ago, Nostradamus predicted that Robert Palm would write
on Fri Dec 15 15:10:58 2023:
>
> I am playing with UTF-8 characters and try to display, e.g. a lock
> symbol https://www.compa
cal/bin/scim -d &
>
>xconsole -iconic &
>
>/usr/local/bin/startxfce4
>
>Indeed I can now do the following from xfce4-terminal:
>
>wiz$ pwd
>/home/wiz
>wiz$ ls
>
>wiz$ touch 你好.txt
>wiz$ ls
>你好.txt
>
>Please not that xfce4-terminal encoding is co
xport XMODIFIERS="@im=SCIM"
/usr/local/bin/scim -d &
xconsole -iconic &
/usr/local/bin/startxfce4
Indeed I can now do the following from xfce4-terminal:
wiz$ pwd
/home/wiz
wiz$ ls
wiz$ touch 你好.txt
wiz$ ls
你好.txt
Please not that xfce4-terminal encoding is configured on UTF-8 but
On 2023/12/15 15:33:44 -0600, "Jay F. Shachter" wrote:
>
> Centuries ago, Nostradamus predicted that Robert Palm would write on Fri Dec
> 15 15:10:58 2023:
>
> >
> > I am playing with UTF-8 characters and try to display, e.g. a lock
> > symbol ht
Centuries ago, Nostradamus predicted that Robert Palm would write on Fri Dec 15
15:10:58 2023:
>
> I am playing with UTF-8 characters and try to display, e.g. a lock
> symbol https://www.compart.com/en/unicode/U+1F512
>
> I use xfce and set the terminal default character en
I am playing with UTF-8 characters and try to display, e.g. a lock
symbol https://www.compart.com/en/unicode/U+1F512
I use xfce and set the terminal default character encoding to UTF-8 in
advanced settings.
Still I cannot get it displayed in xterm or emacs, e.g. by simply
trying to
+0200 schreef Bambero :
Hi,
It seems that perl regular expressions lost one polish letter (ą):
https://www.compart.com/en/unicode/U+0105
I can see this problem only under OpenBSD 6.7 with php-7.4 (same >
version of php under linux is OK)
Ex.:
PHP 7.4.10 or 7.4.5
The same happens with any UT
/ UPS???
> > > >
> > > > PHP 7.3.21
> > > > > > > int(1) // OK
> > > >
> > > > PHP 7.3.21
> > > > > > > int(1) // OK
> > > >
> > > > Any ideas how to fix that?
> > > >
>
gt;
> PHP 7.3.21
> int(1) // OK
>
> Any ideas how to fix that?
>
> Regards,
> Bambero
The same happens with any UTF-8 sequence that ends in 0x85. I guess (a
part of) PHP's PCRE code is not in UTF-8 mode, causing triggers on
CHAR_NEL (=0x85).
I don't know a lo
> PHP 7.3.21
> > > int(1) // OK
> >
> > PHP 7.3.21
> > > int(1) // OK
> >
> > Any ideas how to fix that?
> >
> > Regards,
> > Bambero
>
> The same happens with any UTF-8 sequence that ends in 0x85. I guess (a part
> of) P
The same happens with any UTF-8 sequence that ends in 0x85. I guess (a
part of) PHP's PCRE code is not in UTF-8 mode, causing triggers on
CHAR_NEL (=0x85).
for ($i = 0x75; $i <= 0x825; $i++) {
$u = mb_chr($i);
$str = 'dasw' . $u . 'zdas';
Hi,
It seems that perl regular expressions lost one polish letter (ą):
https://www.compart.com/en/unicode/U+0105
I can see this problem only under OpenBSD 6.7 with php-7.4 (same version of
php under linux is OK)
Ex.:
PHP 7.4.10 or 7.4.5
Original message From: Larry Hynes
Date: 5/23/18 10:03 AM (GMT-09:00) To: justina colmena
Subject: Re: utf-8 support in OpenBSD's httpd
> I think the usual response to this is "use relayd to add headers".> There's a
> hack here, that works:
&
Hi, Justina.
You can not set HTTP headers in httpd.conf, there is no such feature.
You need to run relayd in front of it to set some headers by example
for text files like "contacto.txt", where it is not possible to set headers
on application level, like calling header() function in case of PHP.
My question is: How can I get OpenBSD's httpd to serve a particular
file, or all files of a particular extension, as the case may be, with
the following HTTP header?
Content-type: text/plain; charset=utf-8
I have written a simple "hello-world" PHP script which creates a table
a
my way has a weak point that the kernel of the small HDD may become
different from that of the big HDD by of using ' upgrade ' .
( it is good in case of virsion up 6.2->6.3 )
are there sophistcated methods not chainging kernel ?
i used 'upgrade' process to load the boot loader to small HDD .
On Fri, Dec 1, 2017 at 11:38 AM, Stefan Sperling wrote:
> On Fri, Dec 01, 2017 at 12:14:48PM +0100, Ingo Schwarze wrote:
> > Anthony J. Bentley wrote on Thu, Nov 30, 2017 at 11:28:54PM -0700:
> >
> > > You'll need extra fonts once I finish my patch to add situationally
> > > appropriate emoji to
On Fri, Dec 01, 2017 at 12:14:48PM +0100, Ingo Schwarze wrote:
> Hi Anthony,
>
> Anthony J. Bentley wrote on Thu, Nov 30, 2017 at 11:28:54PM -0700:
>
> > You'll need extra fonts once I finish my patch to add situationally
> > appropriate emoji to all our manpages.
>
> I'm looking forward to that
Anthony J. Bentley wrote:
>I was internally debating this earlier. The bug is already exposed by
>any combining characters that don't have precomposed forms. It also
>doesn't show up with the default (i.e. non TrueType) fonts. Given that
>and how unfriendly the precomposition behavior is, I think d
Anthony J. Bentley wrote:
>Philippe Meunier writes:
>> - When the precompose resource is set to false, copy-pasting the result of
>> printf "e\xcc\x81\n" never works correctly in xterm, regardless of
>> whether I use TrueType fonts or not. xterm copy-pastes the correct
>> sequence of bytes b
Allan Streib writes:
> $ printf "e\xcc\x81\n" | od -a
> 000e cc 81 nl
>
> $ printf "e\xcc\x81\n"
> é
>
> ^ copy/pasting: $ echo "é" | od -a
> 000 c3 a9 nl
Also in case it's interesting:
$ printf "e\xcc\x81" | xclip -i
$ xclip -o | od -a
000e cc 81
Ingo Schwarze writes:
> Hi,
>
> Anthony J. Bentley wrote on Fri, Dec 01, 2017 at 08:18:59AM -0700:
> > Philippe Meunier writes:
>
> >> - In addition, when the precompose resource is set to false and TrueType
> >> fonts are used, the result of printf "e\xcc\x81\n" itself is wrong (even
> >> befo
Hi,
Anthony J. Bentley wrote on Fri, Dec 01, 2017 at 08:18:59AM -0700:
> Philippe Meunier writes:
>> - In addition, when the precompose resource is set to false and TrueType
>> fonts are used, the result of printf "e\xcc\x81\n" itself is wrong (even
>> before trying to copy-paste it): od(1) s
Philippe Meunier writes:
> - When the precompose resource is set to false, copy-pasting the result of
> printf "e\xcc\x81\n" never works correctly in xterm, regardless of
> whether I use TrueType fonts or not. xterm copy-pastes the correct
> sequence of bytes but that sequence is not display
Philippe Meunier writes:
> - Allan probably did his tests with the precompose resource set to its
> default true value.
I assume this is correct because I have never deliberately changed it.
And you're right after all.
$ printf "e\xcc\x81\n" | od -a
000e cc 81 nl
$ printf "e\xcc\
Ingo Schwarze writes:
> >> +*precompose: false
>
> > Sure.
>
> On a more serious note, i'll commit that tomorrow then
> based on OK bentley@ unless somebody can point out a downside.
Please update the OPENBSD SPECIFICS section of the manual as well.
> Hum, i don't doubt your analysis. But now i
Ingo Schwarze wrote:
>Hum, i don't doubt your analysis. But now i don't understand why
>uxterm(1) works for Allan and plain xterm(1) doesn't...
Re-reading Allan's email, it's not clear to me whether he did his tests
with the precompose resource set to true or false. If using the default
value of
Hi Anthony,
Anthony J. Bentley wrote on Thu, Nov 30, 2017 at 11:28:54PM -0700:
> You'll need extra fonts once I finish my patch to add situationally
> appropriate emoji to all our manpages.
I'm looking forward to that. Don't forget to make them animated,
make the colours fully configurable, and
Hi Ingo,
Ingo Schwarze writes:
> Except in a professional typesetting system like groff or LaTeX, i
> consider anything that makes the end user worry about fonts
> fundamentally broken.
I think everybody's in agreement that xterm is broken and wrong here.
> Fonts that work should be installed by
Well that's one that I overlooked. I've been upgrading since 5.x
> and I never removed uxterm. I'm on 6.2 now and still using it.
It's a trivial but wordy wrapper script. The only things it does
that i could imagine to be relevant are setting two command line
options: -class U
Philippe Meunier writes:
> Allan Streib wrote:
>>Are you using xterm(1) or uxterm(1)?
>
> uxterm does not exist anymore on OpenBSD 6.1:
> https://www.openbsd.org/faq/upgrade61.html
Hm. Well that's one that I overlooked. I've been upgrading since 5.x and
I never removed uxterm. I'm on 6.2 now and
Allan Streib wrote:
>Are you using xterm(1) or uxterm(1)?
uxterm does not exist anymore on OpenBSD 6.1:
https://www.openbsd.org/faq/upgrade61.html
Philippe
Philippe Meunier writes:
> So there seems to be two problems:
>
> - Copy-pasting the result of printf "e\xcc\x81\n" never works correctly in
> xterm, regardless of whether I use TrueType fonts or not. xterm
> copy-pastes the correct sequence of bytes but that sequence is not
> displayed co
Anthony J. Bentley wrote:
>I get the same result, but only when using TrueType fonts (default or no).
If I use TrueType fonts:
$ printf "e\xcc\x81\n"
only shows the letter 'e', and when I try to copy-paste it I get a letter
'e' followed by a question mark inside a circle. If I then redraw the l
Philippe Meunier writes:
> The strange part is that, when I copy the first filename and paste
> it to become the second filename, the second filename is shown without
> any accent, even though the first and second filenames are now the exact
> same sequence of bytes (I checked using od(1)). So on
Anthony J. Bentley wrote:
> precompose (class Precompose)
Thanks! That makes xterm work (almost) as expected:
$ ls
Thérèse
$ ls | od -c
000T h e 314 201 r e 314 200 s e \n
014
$ cp Thérèse Thérèse
cp: Thérèse and Thérèse are identical (not
On Wed, Nov 29, 2017 at 07:05:05PM +0100, Ingo Schwarze wrote:
> Anthony J. Bentley wrote on Wed, Nov 29, 2017 at 10:29:28AM -0700:
> > The only unexpected thing here is xterm doing these transformations
> > without asking.
>
> I think i would support a diff to fix that
Seconded. The current defa
e accessing
> files,
That's a very strong condition, which will rarely hold. But sure,
when it does hold, and when the number of files is too large to
assign sensible file names, it partially mitigates the problems.
But only partially.
> you can use whatever naming scheme you like. UTF
Ingo Schwarze writes:
> That's a bad idea. Do not use non-ASCII bytes in file names.
> You are in for all kinds of trouble.
I don't agree. In a situation where a single user will be accessing
files, you can use whatever naming scheme you like. UTF-8 works exactly
how you w
Hi Philippe,
Philippe Meunier wrote on Wed, Nov 29, 2017 at 11:35:59AM -0500:
> Ingo Schwarze wrote:
>> Philippe Meunier wrote:
>>> $ ls
>>> Thérèse
>> That's a bad idea. Do not use non-ASCII bytes in file names.
> That's a nice thought but in practice I have some files on that machine
> wit
Japanese, and for
some of these files renaming is not an option for work reasons. I somehow
doubt that I'm the only one in such a situation.
>In this respect, OpenBSD is better than other operating systems.
>The problem is mostly hidden on OpenBSD because OpenBSD supports
>UTF-8 only.
Hi Philippe,
Philippe Meunier wrote on Wed, Nov 29, 2017 at 09:11:38AM -0500:
> I've noticed something unexpected when copy-pasting UTF-8 characters in
> xterm: xterm seems to change some of the characters into something
> different but visually similar. Here's an
Hello,
I've noticed something unexpected when copy-pasting UTF-8 characters in
xterm: xterm seems to change some of the characters into something
different but visually similar. Here's an example (using ksh):
$ uname -a
OpenBSD foo.my.domain 6.1 GENERIC#19 i386
$ ls
Thérèse
$
On Sun, Jan 22, 2017 at 03:55:25PM +0100, Ingo Schwarze wrote:
> Hi,
>
> Anton Lindqvist wrote on Sun, Jan 22, 2017 at 02:57:12PM +0100:
>
> > I recently encountered a bug related to UTF-8 in ksh(1).
> >
> > While inserting the following sequence, part of my prom
Hi,
Anton Lindqvist wrote on Sun, Jan 22, 2017 at 02:57:12PM +0100:
> I recently encountered a bug related to UTF-8 in ksh(1).
>
> While inserting the following sequence, part of my prompt gets mangled:
>
> aö
>
> With PS1='ksh$ ' I expect the f
I recently encountered a bug related to UTF-8 in ksh(1).
While inserting the following sequence, part of my prompt gets mangled:
aö
With PS1='ksh$ ' I expect the following output:
ksh$ öa
... actual output:
kshöaa
Examining the output buffer when the 'ö' charact
> Use -current. I fixed ls(1) recently to correctly handle UTF-8.
> On May 1, 2016, upgrade to OpenBSD 5.9 if you want to use -stable.
> Do not forget to upgrade to OpenBSD 6.0 on November 1, 2016.
> UTF-8 support is likely to improve further between 5.9 and 6.0.
>
> Yours,
&g
Hi Jon,
Jon S wrote on Wed, Jan 06, 2016 at 10:56:52AM +0100:
> In an attempt to get a better idea on how to make all non-ascii chars
> appear correctly in windows/samba, ssh and the local console I get the
> impression that UTF-8 is the charset that is mostly used in general and
&g
> Hello misc!
>
> In an attempt to get a better idea on how to make all non-ascii chars
> appear correctly in windows/samba, ssh and the local console I get the
> impression that UTF-8 is the charset that is mostly used in general
> and
> also most growing.
>
> Using
s there a solution to make ls print correct
> UTF-8?
>
> Use colorls from packages instead.
>
> http://marc.info/?l=openbsd-misc&m=142539814225472&w=2
>
--
<>
Jon Sjöstedt
On 01/06/16 11:05, Mike Burns wrote:
On 2016-01-06 10.56.52 +0100, Jon S wrote:
Is this a known problem? Is there a solution to make ls print correct UTF-8?
Use colorls from packages instead.
http://marc.info/?l=openbsd-misc&m=142539814225472&w=2
Or wait for 5.9 to come ou
On 2016-01-06 10.56.52 +0100, Jon S wrote:
> Is this a known problem? Is there a solution to make ls print correct UTF-8?
Use colorls from packages instead.
http://marc.info/?l=openbsd-misc&m=142539814225472&w=2
Hello misc!
In an attempt to get a better idea on how to make all non-ascii chars
appear correctly in windows/samba, ssh and the local console I get the
impression that UTF-8 is the charset that is mostly used in general and
also most growing.
Using UTF-8 in samba and ssh on a OpenBSD 4.9 i386
On September 12, 2015 11:02:13 AM GMT+02:00, Jiri Navratil
wrote:
>Hello,
>
>Is it possible to edit UTF-8 text files under vi or mg?
I'll add to the replies that you've already received that it is quite possible
to edit UTF-8 files with vi from base, just that you won&#
On 2015-09-12, Jiri Navratil wrote:
> Is it possible to edit UTF-8 text files under vi or mg?
The editors in base do not support UTF-8 yet.
--
Christian "naddy" Weisgerber na...@mips.inka.de
On Sat, Sep 12, 2015 at 11:02:13AM +0200, Jiri Navratil wrote:
> Hello,
>
> Is it possible to edit UTF-8 text files under vi or mg?
As far as I know most base utilities do not yet have UTF-8 support, but
it might be coming soon, as announced in stsp@'s c2k15 report:
http://un
On 2015-09-12, Jiri Navratil wrote:
> Hello,
>
> Is it possible to edit UTF-8 text files under vi or mg?
>
> I'm using some machines, where I need to touch UTF-8 encoded files only
> rarely. I would prefer to avoid installation of Vim there and instead
> use a "
Hello,
Is it possible to edit UTF-8 text files under vi or mg?
I'm using some machines, where I need to touch UTF-8 encoded files only
rarely. I would prefer to avoid installation of Vim there and instead
use a "in OS included" text editor. Is that possible and how to use and
On Tue, Mar 03, 2015 at 11:41:07PM +0100, Thomas Bohl wrote:
> Thank you very much! Colorls still showed me ?? for the majority of
> characters. This patch works as expected.
I'm not sure what kind of behaviour you expect.
colorls showing some ?? indicates that the character set used by
filenames
Am 03.03.2015 um 17:58 schrieb Ted Unangst:
As a shortcut, filtering out just esc will prevent most terminal damage? I'm
not sure what other characters can do, though... I vageuly recall that the
intersection of utf-8 and xterm controls is unknowable.
poc diff:
Index: u
pkg_add colorls
alias ls=colorls
This one did it, many thanks!!
On Tue, Mar 3, 2015 at 5:41 PM, Stefan Sperling wrote:
> On Tue, Mar 03, 2015 at 04:55:01PM +0100, Thisis theone wrote:
> > $ touch "árvÃztűrÅ tükörfúrógép"
> > $ ls -lah
> > -rw--- 1 user user 0B Feb 8 18:20 ?
3)). Run pkg_add colorls
> and alias ls=colorls if you need multi-byte ls output.
As a shortcut, filtering out just esc will prevent most terminal damage? I'm
not sure what other characters can do, though... I vageuly recall that the
intersection of utf-8 and xterm controls is unknowable.
p
On Tue, Mar 03, 2015 at 04:55:01PM +0100, Thisis theone wrote:
> $ touch "árvíztűrő tükörfúrógép"
> $ ls -lah
> -rw--- 1 user user 0B Feb 8 18:20 ??rv??zt??r?? t??k??rf??r??g??p
> $
>
> I am using uxterm on OpenBSD 5.6. How can my uxterm show these accents in
> this way? Why doesn't it
??r??g??p
> > $
> >
> > I am using uxterm on OpenBSD 5.6. How can my uxterm show these accents in
> > this way? Why doesn't it displays it as it is?
>
> ls doesn't know about utf-8. it only prints basic ascii characters, and
> replaces all other bytes with ?.
&g
splays it as it is?
ls doesn't know about utf-8. it only prints basic ascii characters, and
replaces all other bytes with ?.
The problem is not in xterm (or the filesystem). If you run echo * you should
see the name echoed back correctly.
Thisis theone, 03 Mar 2015 16:55:
> $ touch "árvíztűrő tükörfúrógép"
> $ ls -lah
> -rw--- 1 user user 0B Feb 8 18:20 ??rv??zt??r?? t??k??rf??r??g??p
> $
>
> I am using uxterm on OpenBSD 5.6. How can my uxterm show these accents in
> this way? Why doesn't it displays it as it is?
look
$ touch "árvíztűrő tükörfúrógép"
$ ls -lah
-rw--- 1 user user 0B Feb 8 18:20 ??rv??zt??r?? t??k??rf??r??g??p
$
I am using uxterm on OpenBSD 5.6. How can my uxterm show these accents in
this way? Why doesn't it displays it as it is?
Many thanks!
Соберeм gля Вас пo ceти интepнет бaзу дaнных
пoтeнциaльныx клиeнтoв для Bашего Бизнеca
Bce koнтakты
Пoдpобнeе
Email:proda...@mixmail.com
Тел:+79IЗ79З6ЗЧ2
Skype:s8
ICQ:6288862
чтобы oтписатьcя oт pаcсылkи пришлите delete
P QP5P4P;P0P3P0P5P< P?P>P4P1P>Q P=P5P4P2P8P6P8PQQP8 P!P5P2P5QP=P>P3P>
PP8P?QP0 P>Q P7P0QQQP>P9Q P8P:P0. PQP5P4P8Q P>Q 6
%.P P8P=P8PP:QPP2(QP>P;Q P:P>
P7P0P3QP0P=.P?P0QP?P>QQ)
P P>PQ Q P8 P>QP3P0P=P8P7P0QP8Q P?P5QP5P5P7P4P0 P8 P8 P?P>P:QP?P:P8
P=P5P4P2P8P6P8PQQP8.
P P>PQ
On Fri, Aug 12, 2011 at 21:48:48 +0400, Alexander Polakov wrote:
> 2011/8/12, LEVAI Daniel :
> > Hi!
> >
> > I'm using -current, and running X with LC_CTYPE=hu_HU.UTF-8.
> > I noticed that ls(1) won't display this one character (there are maybe
> > more, I only noticed this one): 'E ' (nor its capi
2011/8/12, LEVAI Daniel :
> Hi!
>
> I'm using -current, and running X with LC_CTYPE=hu_HU.UTF-8.
> I noticed that ls(1) won't display this one character (there are maybe
> more, I only noticed this one): 'E ' (nor its capitalized version: 'E ').
ls doesn't support multibyte characters yet, try thi
On p, aug 12, 2011 at 16:22:17 +0200, LEVAI Daniel wrote:
> Hi!
>
> I'm using -current, and running X with LC_CTYPE=hu_HU.UTF-8.
> I noticed that ls(1) won't display this one character (there are maybe
> more, I only noticed this one): 'E' (nor its capitalized version: 'E').
Wow, it got messed u
mp -C
c3 b6 c5 91 0a|.|
0005
$ echo $LC_CTYPE
hu_HU.UTF-8
I can delete that file with `rm C6*`, and for example mc(1) can display
that two character filename fine.
Another thing I noticed is this:
$ ls -1 |iconv -f utf-8 -t latin2
C6C5
I don't know if t
P QQP0Q P P5P6P4QP=P0QP>P4P=P0Q P=P0QQP=P>-P?QP0P:QP8QP5QP:P0Q
P:P>P=QP5QP5P=QP8Q
"P$QP=P4P0PP1P;P5PP?P>P;P8QP8P:P8, P3P5P>Q
P:P>P=P>PP4P=Q Q
P>QP=P>QP5P=P8P9.
P QP>P4P2P8P6P5P=P8P5 P PP"P P8 PP2QP>QP>QP7P0 P=P0 PP>QQP>P: -
P?QP>P1P;P5PP?P0QP=P>QQP8 QQQP0P= P!P P, P
X P P5P6P4QP=P0QP>P4P=P0Q P=P0QQP=P>-P?QP0P:QP8QP5QP:P0Q
P:P>P=QP5QP5P=QP8Q
b PQQP;P5P4P>P2P0P=P8P5, QP0P7QP0P1P>QP:P0 P8 P?QP8PP:P8Q P"P5QP=P>P;P>P3P8P8 P2 P?QP>PQQP8b
9-11 P4P5P:P0P1QQ 2010, P3. P!P0P=P:Q-P P5QP5QP1QQP3, P P>QQP8Q
www.htfr.org, i...@htfr.org
P#P2P0P6P0P
f6e0h?e0i.d;6o< f/e f(e fd;,f d:e
(e3g3;o<e&f d= fd8
eg o< h/7g(Htmlf g$:h/7g9e;h?i >>
[IMAGE]
g=g; h*e
(h%i
h%ie$'e8
i.d;6h%i
g5h/ o<010-68462522
Email:market...@dotkun.com
[IMAGE]
i.d;6eef :ââi.d;6h%ig4f%fi+d= gie.d8g;)
â
Matthew Szudzik wrote (2010-08-05 19:50:16):
> http://en.wikipedia.org/wiki/IDN_homograph_attack
Try this in a default 4.7/i386 wscons console:
printf 'set -x\nnslookup www.AAA.com\nnslookup www.AA\300.com\n' > 1
less 1
sh 1
See: sys/dev/ic/pcdisplay_chars.c
Remedy:
#!/bin/sh
# Public do
Alexander Polakov wrote on Sat, Aug 07, 2010 at 06:52:24PM +0400:
> I made a patch for ls based on NetBSD (see below), works just fine for me.
Ugh.
I hate that.
Well, i partly see a point in providing such functions in libraries,
because libraries are used for compiling all sorts of software,
in
* Jordi Beltran Creix [100804 17:26]:
> > ls(1) does not seem to be 100% UTF-8 ready:
> >
> >
> > madro...@madthought:~% /bin/ls testb8-C4-D5-b/-\#
> > testo?=o?=-C4-D5-o?=o?=-#
> > madro...@madthought:~% /bin/ls testb8-C4-D5-b/-\# |cat
> > testb8-C4
On Friday 06 August 2010 07:31:45 Marc Espie wrote:
> On Thu, Aug 05, 2010 at 12:49:07PM +, Matthew Szudzik wrote:
> > On Wed, Aug 04, 2010 at 01:36:17PM -0700, Matthew Dempsky wrote:
> > > Is there any useful documentation that explains how you're supposed to
> > > write C code and what's chan
> Rest assured that OpenBSD developers are interested in better i18n support.
> It goes slow, because it's a tough problem, and yeah, we don't want to
> create security issues, and yeah, we have to be really, really careful about
> a lot of things.
>
I'd hope everyone is interested in better i18n
On Thu, Aug 05, 2010 at 12:49:07PM +, Matthew Szudzik wrote:
> On Wed, Aug 04, 2010 at 01:36:17PM -0700, Matthew Dempsky wrote:
> > Is there any useful documentation that explains how you're supposed to
> > write C code and what's changed under the i18n New World Order? From
> > your message,
On Thu, Aug 5, 2010 at 8:15 PM, Marco Peereboom wrote:
> Easy!
>
> vim
> BSD
> mutt
> 7 bit
>
> no controversy at all because everyone else is wrong and they know it.
>
> On Fri, Aug 06, 2010 at 12:11:41AM -0300, VICTOR TARABOLA CORTIANO wrote:
>> I know lots of flamewars, Emacs vs vi, GPL vs BSD,
Matthew Szudzik wrote:
> > So you want to see '41' instead of the letter 'A'? That's "how the
> > computer sees the data"...
>
> I simply want to be able to know "at one glance" what data the computer
> is using. For that purpose, it is unnecessary to decode an "A" as 0x41.
> The ASCII characte
On Thu, Aug 5, 2010 at 10:15 PM, Marco Peereboom wrote:
> Easy!
>
> vim
> BSD
> mutt
> 7 bit
>
> no controversy at all because everyone else is wrong and they know it.
>
>
That looks like a good combo, yep.
Easy!
vim
BSD
mutt
7 bit
no controversy at all because everyone else is wrong and they know it.
On Fri, Aug 06, 2010 at 12:11:41AM -0300, VICTOR TARABOLA CORTIANO wrote:
> I know lots of flamewars, Emacs vs vi, GPL vs BSD, Pine vs Mutt, etc.
> But ASCII vs Unicode is new to me.
I know lots of flamewars, Emacs vs vi, GPL vs BSD, Pine vs Mutt, etc.
But ASCII vs Unicode is new to me.
7 bits ought to be enough for everyone!
On Thu, Aug 05, 2010 at 07:50:16PM +, Matthew Szudzik wrote:
> On Thu, Aug 05, 2010 at 11:33:23AM -0700, Philip Guenther wrote:
> > Umm, punycode wasn't developed because of problems with
> > distinguishability. Indeed, it does nothing to solve those, s
On Thu, Aug 5, 2010 at 12:50 PM, Matthew Szudzik
wrote:
> On Thu, Aug 05, 2010 at 11:33:23AM -0700, Philip Guenther wrote:
...
>> experience by using LC_ALL=C. Oops, never mind, OpenBSD hasn't
>> actually implemented "plain ASCII only" for years.
>
> The fact that OpenBSD doesn't implement "plain
On Thu, Aug 05, 2010 at 11:33:23AM -0700, Philip Guenther wrote:
> Umm, punycode wasn't developed because of problems with
> distinguishability. Indeed, it does nothing to solve those, so I'm
> not sure why you would suggest that. punycode exists to encode
Although punycode may not have been dev
On Thu, Aug 5, 2010 at 5:49 AM, Matthew Szudzik
wrote:
...
> But it's even worse, because unicode also violates the principle
> (established by Alan Turing in 1936) that any two characters should be
> humanly distinguishable "at a glance".
[Citation needed]
> This has led to the invention of
>
On Wed, Aug 04, 2010 at 01:36:17PM -0700, Matthew Dempsky wrote:
> Is there any useful documentation that explains how you're supposed to
> write C code and what's changed under the i18n New World Order? From
> your message, it sounds like we're going to have to rewrite nearly all
> of our user-sp
ike regexes is out but
> not simple matching and replacement), are safe from i18n. If you
> ignore its features, UTF-8 is just like ASCII and nothing has to
> change, no need to use Unicode functions for everything.
Reminded me of the php escapeshellarg exploit that only worked on utf-8
e
String and input mangling occurs when the programs try to sanitize
control characters. In the case of UTF-8, terminal control sequences
over 0x80 can be a valid part of a printable character.
And then there is collation which means people get angry when IJ.txt
is listed after II.txt. However, many
1 - 100 of 152 matches
Mail list logo
