Re: Spinner Function for Shell Scripts
Devin Teske dte...@vicor.com wrote: So, just as the subject-line says, ... here's an efficient and robust spinner function compatible with many shells. DONE=$( /bin/sh -c 'read -t 0 DONE; echo $DONE' ) Is this expected to be portable to other operating systems? The dash shell, used as /bin/bash in Ubuntu, does not acept the -t argument to the read builtin command. Using /bin/bash solves the problem. I was shooting for bourne-shell, FreeBSD's /bin/sh is *not* a Bourne shell. It's rather unfortunate that bourne-shell has what we need but is not available on all operating systems since many OSes have started swapping out bourne-shell for it's younger cousin. A traditional Bourne shell, such as Solaris's, does not implement read -t at all. -- Christian naddy Weisgerber na...@mips.inka.de ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Checksum mismatch -- will transfer entire file
Gary Jennejohn gljennj...@googlemail.com wrote: csup already has a CVS mode, at least in 9-current. I don't use older versions of FreeBSD so I don't know whether it supports CVS there. It does at least down to 7.x. -- Christian naddy Weisgerber na...@mips.inka.de ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Checksum mismatch -- will transfer entire file
Victor Sudakov sudakov+free...@sibptus.tomsk.ru wrote: I see nobody is ever going to fix this? Cvsup mails me a bunch of Checksum mismatch errors on every run, with a risk of overlooking real errors. It is particularly egregious when a tag is laid down, like today. csup(1) ends up refetching a big chunk of the tree from scratch because so many files have these spurious checksum mismatches. Personally, I don't care too much, but quite a bit of mirror bandwidth is wasted this way. How do others deal with this noise? Do you grep cvsup output or what? I optimistically assume that there are no real errors and I run csup without -s once a week or so, just in case. -- Christian naddy Weisgerber na...@mips.inka.de ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: patch for /usr/src/usr.bin/fmt/ (not 8 bit clean) for German French
Julian H. Stacey j...@berklix.com wrote: Problem: /usr/src/usr.bin/fmt/fmt.c is not 8 bit clean. (ie French or German etc text with accents in gets broken) Can you provide an example where it fails? It works fine for ISO 8859-1 and UTF-8 for me, *provided* the locale is set correctly. -- Christian naddy Weisgerber na...@mips.inka.de ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: nroff -man, .An Aq formatting
Dag-Erling Smørgrav d...@des.no wrote: It has come to my attention that whereas with LANG=C nroff -man formats .An name Aq email as name email, it uses different characters with LANG=en_GB.UTF-8 name ⟨email⟩. These characters are appropriate, but a lot of unicode fonts don't seem to have them. This is definitely a bug, since (as avg@ points out) you can no longer copy-paste the name address into an email client. AFAIK (judging from the Unicode group they're in) these characters are intended mainly for writing things like ENTER and CTRL+F1 in technical documentation. And we probably have that usage in other man pages. It is not clear to me if the problem is the use of these characters for angle quotes or the use of .Aq for email addresses. A few days ago, I switched my desktop to UTF-8, and I right away noticed that there are issues with the nroff output. Looking at, say, the rc(8) man page, I see that the `...` shell backquotes have been turned into pretty single quotes. Again, you can't copy-n-paste this any longer. -- Christian naddy Weisgerber na...@mips.inka.de ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: [PATCH]: today highlighting in [n]cal
Roman Divacky rdiva...@freebsd.org wrote: after addressing Simon's concerns here's a new patch: www.vlakno.cz/~rdivacky/cal2.patch I'd simply use the so/se (standout) capability rather than specifically asking for reverse video. If you somehow end up on an 1980s terminal where the two aren't synonymous, standout is what you want. -- Christian naddy Weisgerber na...@mips.inka.de ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: lzo2 shows insane speed gap
Bruce Cran br...@cran.org.uk wrote: I'm running 8.0-CURRENT amd64 here on a Turion64 X2 machine. Without malloc debugging (malloc.conf - aj) 'make test' takes 25s; after removing malloc.conf thus turning on debugging, it takes over 10 minutes. Wow! That. Is. It. Toggling malloc debugging option J makes the slow machines fast and vice versa. Athlon 64 X2 5200+ 2.6 GHz, FreeBSD 8.0-CURRENT amd64 ~60 min 19 seconds. I guess that falls under the obvious configuration differences to check, but since it usually doesn't cause a significant slowdown I completely forgot about it. Embarrassing. But still. Two orders of magnitude? That is a pathological case. -- Christian naddy Weisgerber na...@mips.inka.de ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
lzo2 shows insane speed gap
The archivers/lzo2 port runs a series of regression tests after the actual build. These tests show extremely divergent behavior on different machines. There are two types of machines: Type #1: Running the tests takes roughly the same time as configure and compile did, whether it's 30 seconds on a fast machine or 10 minutes on an old slow one. Type #2: Running the tests takes much, much, MUCH longer. I've tried this across alpha, amd64, i386, and sparc64, partially on FreeBSD, partially on OpenBSD. The operating system doesn't matter and there is no pattern related to endianness or 32/64 bits. You can find machines that are the same architecture (e.g. amd64) and are of similar overall speed (e.g. an Intel Xeon Xeon E5405 and an AMD Phenom 9350e) and one of these machines will be type #1 and the other will be #2 and take _a hundred_ times longer to run the tests. A hundred times. I have never seen anything like this before. On the slow machines, the tests also consume a lot of system time. I've seen figures from 20 to 50%. However, ktrace shows nothing out of the ordinary. My best guess at this time is that lzo2 somehow manages to induce crazy cache thrashing on some CPU models. Ideas and explanations welcome. -- Christian naddy Weisgerber na...@mips.inka.de ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: lzo2 shows insane speed gap
Mel fbsd.hack...@rachie.is-a-geek.net wrote: If the program itself doesn't directly cause the system time, do interrupt rates give any hint as to what does? systat -vmstat shows a conspicuously large number of traps, I think. (I'm short on comparable FreeBSD machines.) And to rule out the obvious, you did check swapping? No swapping. -- Christian naddy Weisgerber na...@mips.inka.de ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: lzo2 shows insane speed gap
Nate Eldredge: It might be good first to rule out compiler / library differences. Sure. Let's cut this short: Slow Athlon 64 X2 5200+ 2.6 GHz, FreeBSD 8.0-CURRENT amd64 ~60 min Phenom 9350e 2.0 GHz,OpenBSD 4.4-CURRENT amd64 ~80 min UltraSPARC-IIe 500 MHz (Blade 100), OpenBSD 4.4-CURRENT sparc64 10 h++ Fast Pentium 4 3.0 GHz, FreeBSD 6.4-RELEASE i386 36 s Xeon E5405 2.0 GHz (PowerEdge 1950), OpenBSD 4.4-CURRENT amd6447 s Alpha 21164A 500 MHz (AlphaPC164), OpenBSD 4.4-CURRENT alpha 9 min Let me draw your attention to the fact that the two amd64 systems that run different operating systems are both slow, whereas the two amd64 systems that run the same operating system (compiler, libraries) diverge in speed. Oh, and everybody is invited to run $ cd /usr/ports/archivers/lzo2 make and check for themselves. PS: The Blade 100 is still crunching as I write this... -- Christian naddy Weisgerber na...@mips.inka.de ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: VLAN offloads on FreeBSD 6.3 7.0
Yony Yossef [EMAIL PROTECTED] wrote: Second, my NIC is capable of holding a vlan table on HW, filtering vlans on it's own, now I need to find a way to update that HW table with added/deleted VLANs in order to use that VLAN filtering offload. If I may piggyback a question here: What is the use of a HW VLAN filter? In what scenario do we receive significant traffic of frames with our station address or multicast but not for any VLAN we have joined? -- Christian naddy Weisgerber [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Introducing me!!
Julian Elischer [EMAIL PROTECTED] wrote: My name is Ryan French. I am a Google Summer of Code participant this year, and for my project I will be implementing MPLS in FreeBSD. FWIW, OpenBSD has just started on this: Import MPLS (Multi Protocol Label Switching) MPLS support partly based on the (abandoned?) AYAME project. There has been a noted shortage in kuwus in freebsd.. for some reason. ^ Bed choice of word to dimonstrate the Kiwi accint, I thunk. Kiwi us pronounced wuth long e, not short i. :-) -- Christian naddy Weisgerber [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: OS choice
Dag-Erling Smørgrav [EMAIL PROTECTED] wrote: What is the usual or minimum hardware requirement? Is soekris box enough, or dual core or ASIC based platforms? A soekris box probably doesn't have the I/O bandwidth nor the CPU power to process a full BGP feed. Henning and [Bob] holding up a running soekris, the significance of this is that this little box with 128 MB of ram and a 266 Mhz Geode CPU has a full BGP Feed and routing table happily running on it http://bofh.cns.ualberta.ca/beck/pictures/pf2k4/img_1001.jpg -- Christian naddy Weisgerber [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: OpenCVS
Miguel Mendez [EMAIL PROTECTED] wrote: I've seen the OpenBSD guys have come up with a BSD-licensed CVS[1] that should be focused on security as well as features. Is there any chance that this could make it into FreeBSD's tree as well? OpenCVS is very much a work in progress at this point. Development has moved into the OpenBSD repository, but it is not hooked into builds yet. In fact, there hasn't even been a call for testing. it would help testing the code in another production environment. Any talk of OpenCVS in a production environment is premature. -- Christian naddy Weisgerber [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: concurrent scp transfers (and a testing methodology ?)
Joe Schmoe [EMAIL PROTECTED] wrote: However, I wonder how well this relates to how many ssh sessions (scp file transfers, specifically) that a FreeBSD server can handle. Can anyone throw out some basic numbers for this ? Assuming a 1ghz p3 and 2gigs of RAM, and assuming that everyone is transferring a totally different file. In LAN environments, scp is conspicuously CPU limited. A P3/1GHz will be able to push out a file at about 6MB/s. Divide by desired number of files. Just what transfer rates did you have in mind? I would think the major bottleneck would be disk I don't think so. If you have many concurrent transfers of different files spread out wildly over the disk, you might get the disk to thrash, but it isn't clear that it will still matter at this point. Check some random reads benchmarks for your vintage of disk. (like, does SMP help a lot here, or just a little ?) A lot, as far as SMP goes. Alternatively, a lowly VIA C3 Nehemiah with its on-core AES engine should happily beat your usual high-end P4/Athlon/etc at this task. (I don't know whether FreeBSD integrates the AES engine in userland. OpenBSD does.) -- Christian naddy Weisgerber [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Non-executable mappings now in NetBSD too
Tim Kientzle [EMAIL PROTECTED] wrote: The OpenBSD work on tightening up read/write/exec memory permissions looks interesting, but I wonder what impact it has on JIT technologies; do the current Java VMs or other incremental compilation engines require write+exec? You can disable W^X for individual executables (ld -Z). -- Christian naddy Weisgerber [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: BSD-licensed gzip, grep and diff families in OpenBSD
Arjan van Leeuwen [EMAIL PROTECTED] wrote: It seems that OpenBSD now has BSD licensed versions of the gzip, grep and diff families (see http://marc.theaimsgroup.com/?l=openbsd-miscm=105899089116252w=2). Wouldn't it be a good idea to import them into FreeBSD? Yes, maybe, no. gzip should be fine. grep is largely compatible with GNU grep but offers worse performance. Apparently much worse in some corner cases. diff lacks a lot of the extensions from the GNU version which everybody takes for granted, e.g. no -p, -x, or -I, and there's no sdiff. -- Christian naddy Weisgerber [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Replacing GNU grep revisited
Sean Farley [EMAIL PROTECTED] wrote: Reasons to consider for switching: For whatever little it's worth, OpenBSD just switched to freegrep (a somewhat modified version from NetBSD). They also dumped the GNU gzip implementation, after extending compress to substitute as /usr/bin/gzip. -- Christian naddy Weisgerber [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: anoncvs.freebsd.org reachability
In article [EMAIL PROTECTED], Lars Eggert [EMAIL PROTECTED] wrote: for the last couple of days I've been unable to cvs update my sources, because anoncvs.freebsd.org is unreachable: There are at least two other machines that offer this service: anoncvs.de.freebsd.org anoncvs2.de.freebsd.org(*) *) May see some service interruptions during the next couple of hours because I'm performing an OS update. -- Christian naddy Weisgerber [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: FreeBSD's sh: local builtin
Eugene Ossintsev [EMAIL PROTECTED] wrote: FreeBSD's sh has a builtin local for the functions. Is it a POSIX.2 feature No. or Bash influence? Korn Shell, more likely. It supposes that the classical shell doesn't have local at all. Correct. -- Christian naddy Weisgerber [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: FreeBSD's sh: local builtin
Chet Ramey: Korn Shell, more likely. It's bash. The Korn shell doesn't have it. ksh88 has a pre-defined alias local=typeset. -- Christian naddy Weisgerber [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: is this character encoding or corrupted text?
Dan Langille [EMAIL PROTECTED] wrote: http://docs.freebsd.org/cgi/getmsg.cgi?fetch=292893+0+archive/2001/cvs- all/20010429.cvs-all In the log, the name Matthias Kvppe appears. Is that the correct name? That is probably Matthias Köppe (ISO 8859-15) with the top bit cut off. Or Matthias Koeppe in transcription. My next question is how to properly handle these characters. First you need to figure what the original character was. Since you can't tag CVS logs and such with character sets, you'll then have to come up with an ASCII transcription according to the rules of the originating language. (Alternatively people could agree to use UTF-8, but FreeBSD support for that is painfully weak. And you'd still have to convert from whatever original character set to UTF-8.) -- Christian naddy Weisgerber [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: tar and nodump flag
Harti Brandt [EMAIL PROTECTED] wrote: Perhaps it makes sense to switch to star instead? The last version is Posix conform, supports extended headers and ACLs. According to the star developer (Joerg Schilling) GNU tar is severly broken. Unfortunately, star has it's own share of problems: - A highly idiosyncratic command syntax that is incompatible with traditional tar syntax. I think this is a killer. - It doesn't support incremental backups. That isn't a problem in itself, but it's a feature our GNU tar currently has and people probably don't want to lose. - An idiosyncratic build system. -- Christian naddy Weisgerber [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Status of Tekram DC-395 drivers
Gary Jennejohn [EMAIL PROTECTED] wrote: although I was using a Tekram 395 with the sym driver for a while. I very much doubt that. The DC-395 series are based on the Tekram S1040 chip which is not compatible with the Sym53C8xx chips. Maybe you are confusing this with some other Tekram adapters that are Sym-based. -- Christian naddy Weisgerber [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: fdescfs oddities
Chris Costello [EMAIL PROTECTED] wrote: I've done some work on fdescfs in -CURRENT a while back [...] While we are talking about fdesc(fs), how does it relate to devfs? I.e. will devfs make fdesc useless, or require it, or...? -- Christian "naddy" Weisgerber [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: BSD dlopen and such
Rafael Barrero [EMAIL PROTECTED] wrote: 0) Are native binaries for OpenBSD different from FreeBSD? Yes. -- Christian "naddy" Weisgerber [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Optimal UFS parameters
Matt Dillon [EMAIL PROTECTED] wrote: The default filesystem parameters are: newfs -f 1024 -b 8192 -i 8192 -c 16 ... -i 4096 -- Christian "naddy" Weisgerber [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Anybody want to review vi patch?
There's a bug in nvi 1.79. The options "noprint", "print", and
"octal" don't work properly. When these options are changed, the
routine that evaluates them is called before the option has been
set.
Do we have any people who know their way around the guts of nvi?
I've appended a patch, partly based on a change in nvi 1.81 where
this is fixed incompletely, and I'd like somebody to review this.
--
Christian "naddy" Weisgerber [EMAIL PROTECTED]
diff -ur /usr/src/contrib/nvi/common/options.c nvi/common/options.c
--- /usr/src/contrib/nvi/common/options.c Sat Apr 19 01:36:33 1997
+++ nvi/common/options.cSat Oct 21 13:06:06 2000
@@ -132,7 +132,7 @@
/* O_NUMBER4BSD */
{"number", f_reformat, OPT_0BOOL, 0},
/* O_OCTAL 4.4BSD */
- {"octal", f_print,OPT_0BOOL, 0},
+ {"octal", f_octal,OPT_0BOOL, 0},
/* O_OPEN 4BSD */
{"open",NULL, OPT_1BOOL, 0},
/* O_OPTIMIZE 4BSD */
diff -ur /usr/src/contrib/nvi/common/options_f.c nvi/common/options_f.c
--- /usr/src/contrib/nvi/common/options_f.c Fri Nov 1 07:45:38 1996
+++ nvi/common/options_f.c Sat Oct 21 13:11:14 2000
@@ -190,6 +190,34 @@
char *str;
u_long *valp;
{
+ /* Preset the value, needed for reinitialization of lookup table. */
+ if (o_set(sp, op-sp-opts, OS_STRDUP, str, 0))
+ return(1);
+
+ /* Reinitialize the key fast lookup table. */
+ v_key_ilookup(sp);
+
+ /* Reformat the screen. */
+ F_SET(sp, SC_SCR_REFORMAT);
+ return (0);
+}
+
+/*
+ * PUBLIC: int f_octal __P((SCR *, OPTION *, char *, u_long *));
+ */
+int
+f_octal(sp, op, str, valp)
+ SCR *sp;
+ OPTION *op;
+ char *str;
+ u_long *valp;
+{
+ /* Preset the value, needed for reinitialization of lookup table. */
+ if (*valp)
+ O_CLR(sp, op - sp-opts);
+ else
+ O_SET(sp, op - sp-opts);
+
/* Reinitialize the key fast lookup table. */
v_key_ilookup(sp);
diff -ur /usr/src/contrib/nvi/include/com_extern.h nvi/include/com_extern.h
--- /usr/src/contrib/nvi/include/com_extern.h Fri Nov 1 07:45:31 1996
+++ nvi/include/com_extern.hSat Oct 21 13:05:53 2000
@@ -157,6 +157,7 @@
int f_msgcat __P((SCR *, OPTION *, char *, u_long *));
int f_paragraph __P((SCR *, OPTION *, char *, u_long *));
int f_print __P((SCR *, OPTION *, char *, u_long *));
+int f_octal __P((SCR *, OPTION *, char *, u_long *));
int f_readonly __P((SCR *, OPTION *, char *, u_long *));
int f_recompile __P((SCR *, OPTION *, char *, u_long *));
int f_reformat __P((SCR *, OPTION *, char *, u_long *));
Re: mergemaster RFC (long)
Brian Somers [EMAIL PROTECTED] wrote:
First, the things I am definitely going to do. Christian "naddy"
Weisgerber has taken on the task of porting mm to openbsd.
I think it would be nice to aim to keep the two scripts exactly the
same, using `uname` when it's really necessary.
If I have interpreted the noises Theo has made correctly, he wants
mergemaster in the base tree. I don't think he'll keep a "case
`uname` ..." in there.
Most of the diff deals with two simple differences:
- mergemaster uses "read -p prompt" throughout. That fails for
OpenBSD's /bin/sh (pdksh), where "read -p" means something entirely
different.
- On OpenBSD, "install" is synonymous to "install -c". FreeBSD still
has the old behavior where plain "install" deletes the source file.
If we can get rid of those, the actual differences become more
visible.
Oh, and changing every instance of "FreeBSD" into "${OPSYS}" or
some such would remove another few diff lines.
I think having
IGNOREFILES="a b c"
isn't necessary when it's as easy to have
rm a b c
in your start script. It seems like overkill to handle ignored files
specifically.
Well, I don't know. Something like "IGNOREFILES=..." was the first
thing to come to my mind.
--
Christian "naddy" Weisgerber [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: truss -f, updated patch
Arun Sharma [EMAIL PROTECTED] wrote: http://sharmas.dhs.org/~adsharma/projects/freebsd/truss-diff.gz Those gratuitous whitespace and formatting changes are a pain... Related question: Currently, truss does very little parsing of syscall arguments. That table in syscalls.c looks anemic. Is there any interest in expanding this? I guess that's something I could take on, as it appears to be mostly grunt work. -- Christian "naddy" Weisgerber [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: PR's and patches
Garance A Drosihn [EMAIL PROTECTED] wrote: So, my dumb question is, how DO you pull patches out of a PR? lynx -dump vi to extract the relevant pre/pre part #!/usr/bin/sed -f s/amp;/\/g s/gt;//g s/lt;//g -- Christian "naddy" Weisgerber [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Double buffered cp(1)
Matthew Dillon [EMAIL PROTECTED] wrote: -pipe makes a significant difference since without it every source file being compiled creates several files in /tmp. Hasn't O'Brien recently said that in fact "-pipe" is already the default for our cc, so explicitly specifying the option doesn't do anything? -- Christian "naddy" Weisgerber [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: dutch keyboard map (+sort note)
(I think this should be taken to -questions.)
W.H.Scholten:
As there isn´t a dutch keymap for syscons,
^
That's an acute accent (the same diacritic as in 'é'), not an
apostrophe.
First, how do I enable/use dead keys?
Take a look at some of the provided *.acc.kbd keymaps.
There are several "dXXX" dead keys, where XXX is an abbreviation
(first three letters of the name) for the diacritic in questions.
An example entry for a dead acute accent to provide 'é'--I think
that's a character used in Dutch--could look like this:
dacu 180 ('e' 233) ('E' 201)
This means:
- define _d_ead key for _acu_te accent,
- the accent on its own is character 180 (´),
- combined with 'e' it gives character 233 (é),
- combined with 'E' it gives character 201 (É).
Secondly, the console screenmapping (iso88559-1- ibm) doesn´t seem to
work properly (I´ve set it with /stand/sysinstall)
Works fine here, if you use the VGA default (or explicitly load a
CP437 font) and load the iso-8859-1_to_cp437 screen map. Of course,
the screen map facility is mostly a fallback for users of MDA/HGA/CGA
cards where the font is fixed. If you have EGA/VGA, you want to
load a proper font instead.
E.g. if I enter the code 171 (« (guillemotleft)) then I actually see ½
(one half) which has code 189. What´s going on?
You didn't activate the ISO 8859-1 - CP437 screen map.
--
Christian "naddy" Weisgerber [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: Unicode on FreeBSD
I wrote: I also think the creating of a freebsd-i18n list is long overdue. I18N issues are largely lost among the traffic on -hackers and -questions, and it has become something of a specialty area I just got a note from our dear postmaster that freebsd-i18n will be created within the next couple of days. -- Christian "naddy" Weisgerber [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Unicode on FreeBSD
G. Adam Stanislav [EMAIL PROTECTED] wrote: Of course, it still remains to be seen if having Unicode support on the console is a Good Thing(TM). I don't see how it would be even possible, due to hardware limitations. The console can only support an 8-bit font (I mean 8-bit encoding). Actually, if you can spare an attribute bit you can handle 512 characters in text mode on a plain VGA card. pcvt(4) uses this to keep all of CP437, ISO Latin 1, various DEC character sets, and a range of definable characters available. I see the main way of supporting Unicode in providing libraries that programs can use to convert between Unicode and local display. ... and to handle UTF-8. Yes. -- Christian "naddy" Weisgerber [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Unicode on FreeBSD
Alex Belits [EMAIL PROTECTED] wrote: Not so. Unicode is a character map. One of many. It just happens to be the most inclusive one in existence. It is. However if you look at the current efforts of its "adoption", it is not used as one. It's touted as the solution to all language-related problems, as a replacement of language/charset labeling infrastructure Who says so? Certainly not the Unicode enthusiasts I have met. You are arguing against a strawman. Unicode takes care of character repertoire, code points, and (with UTF-*) encoding. In no way does it touch on language labeling. and as the necessary prerequisite for any multilingual text processing. A claim that would be obviously absurd. However, I do consider Unicode a sensible part of any new implementation. ISO 2022 (and what other dinosaurs that may be lurking in murky shadows) is a legacy solution that should die off. -- Christian "naddy" Weisgerber [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Unicode on FreeBSD
Alex Belits [EMAIL PROTECTED] wrote:
I have just asked, who will benefit from it. No one answered "I will" --
I WILL.
I want to be able to mention Henry Charri{e grave}re and
Stanis{l stroke}aw Lem in a single document and spell those names
correctly. Actually, that's a real world example. I already do on a web
page, and of course this is only possible because of the underlying
Unicode character set of HTML.
I want to be able to give a book title in Cyrillic or Greek.
I want to be able to quote from _Beowulf_.
I *desperately* want to use IPA rather than various ad-hoc ASCII
transcriptions.
--
Christian "naddy" Weisgerber [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: Unicode on FreeBSD
Anatoly Vorobey [EMAIL PROTECTED] wrote: What do you think? For what it's worth (me not being a committer and generally not on the productive side of things), I morally support this idea. To push certain buttons: what you are suggesting is to bring syscons up to what the Linux console already supports in this respect. - in raster modes (SC_PIXEL_MODE on, etc.) more than 256 characters can now be trivially drawn. [...] I should point out that what you have outlined is very limited Unicode support. It's great for the primary European application of Unicode, i.e. having an extended character set that combines a character repertoire previously not available from 8-bit character sets, e.g. the ability to write both French and Russian in the same text. Without double-width and combining characters it won't be nearly as useful for Asian users, though, so don't expect rampant enthusiasm from that corner. Whether "full" Unicode support is desirable in a console driver is another question. - the road is wide open for Unicode support in userland, through UTF-8. A UTF-8 capable xterm has been capable since, uh, last summer I think. It's in XFree86 4.0. The road is wide open already. It would be even more open, if the work done by the Linux people wasn't consistently GPLed and could be reused sigh. - The format of screen font files must be changed. Hardly an issue. You'll have an array of glyphs and an array which associates a Unicode code point with each glyph. In fact, you just might want to use the same format the latest Linux console tools have already pioneered for this purpose. - some rendering routines are slowed down due to the fact that simple 8-bit array lookups are no longer available for getting characters' information. This may be circumvented somewhat by smart searches/hash tables. Linux uses some kind of hash tables. I don't know the implementation details, but speedwise the overhead appears to be negligible. Hint: For anybody interested in unicodification, the linux-utf8 mailing list is a must-read. I also think the creating of a freebsd-i18n list is long overdue. I18N issues are largely lost among the traffic on -hackers and -questions, and it has become something of a specialty area since most people appear to be served well by the existing non-solutions. -- Christian "naddy" Weisgerber [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Proposed new Bourne shell init files
Doug Barton: export VAR=value The problem with that option is that it's not portable. It's just as portable as "set -o" and "alias". None of them are available in the original Bourne shell, all of them in the POSIX shell. alias r='fc -s' Hrrmm... ok. I have no experience with that, but I wouldn't object to its inclusion. It's a pre-defined alias in ksh where the entire POSIX history scheme is taken from. Roughly, it's the equivalent to the csh '!' history substitution, although less powerful. Use "r" to repeat the last command, "r cmd" to repeat the last command "cmd", and "r foo=bar ..." to effect a substitution on the recalled command line. -- Christian "naddy" Weisgerber [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Proposed new Bourne shell init files
Doug Barton: In my mind there is a difference between items that are freebsd-exclusive (like set -o and alias) and items that we have unique implementations of, like export. The latter are available on other platforms, and therefore, IMO we should follow the more generally accepted format. You're arguing from mistaken assumptions. "set -o" and "alias" are not in the least FreeBSD-exclusive. Nor do we have a unique implementation with "export VAR=value". These three features don't differ with respect to portability. To repeat: * They aren't part of the "original" Bourne shell (which was itself a moving target). * They were introduced with the Korn shell. * Later they were specified for the POSIX shell. * Every POSIX shell supports them. Whatever way you want to argue, if you want to stay coherent you have to treat these three features (and a bunch more) the same. And, considering the subject, I'd like to point out that FreeBSD's /bin/sh is not a Bourne shell clone but a POSIX shell. Extending that argument to either not take advantage of features unique to FreeBSD (silly and wasteful) or to doing everything FreeBSD'ish just because we can (teaches a bad lesson) goes too far in either direction for my taste. I think that's a bizarrely schizophrenic position, but anyway it isn't applicable to the actual shell features discussed above. -- Christian "naddy" Weisgerber [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Proposed new Bourne shell init files
Doug Barton [EMAIL PROTECTED] wrote: Commentary on my files. . . Using allexport instead of an explicit 'export' for every variable makes the file easier to read, and gives a novice user one less thing to worry about. I think Sue has a made a good argument against allexport. Also, from your reply to her I suspect you didn't know about export VAR=value which is what I use and would like to suggest. I added 'set -o emacs' to dot.shrc, it makes life much easier, FWIW, "set -E" does the same in fewer letters but is a FreeBSDism. I fully realize that treading in this area is likely to provoke lenghty arguments, goring of cows, etc. :) I suggest we use nails with square heads for the south side of the bike shed. # Search path for cd(1) CDPATH=.:$HOME Hmpf. # General aliases alias la='ls -A' alias lf='ls -AF' alias ll='ls -loaF' alias m=$PAGER alias g='egrep -i' These are *very much* a matter of taste. I don't like a single one of them, but then again I wouldn't want to force mine on anybody else. One alias I think worth considering is alias r='fc -s' to provide ksh-style history access. -- Christian "naddy" Weisgerber [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Unicode on FreeBSD
MikeM [EMAIL PROTECTED] wrote: Has anyone thought of Unicode support on FreeBSD? It has crossed my mind... I think that it is inevitable that eventually FreeBSD will *need* to support unicode if it wants to continue as a viable operating system in the future. Probably. The demand for Unicode support is currently rather limited, but I expect it to pick up somewhat once it is pervasive under Linux and applications programmers come to expect its availability. This means that it probably will need to be modified from the ground up. Not at all. Is there any way of implementing partial support, working in stages, untill it is fully supported? Just that. I suggest you read these documents: "UTF-8 and Unicode FAQ" by Markus Kuhn http://www.cl.cam.ac.uk/~mgk25/unicode.html "The Unicode HOWTO" by Bruno Haible ftp://ftp.ilog.fr/pub/Users/haible/utf8/Unicode-HOWTO.html "Unicode Fonts and Tools for X11" by Markus Kuhn http://www.cl.cam.ac.uk/~mgk25/ucs-fonts.html These are written for Linux but they are largely applicable to BSD in general and FreeBSD in particular, too. The practical relevance of Unicode has taken a huge leap forward when Thomas Dickey made xterm became capable of displaying UTF-8 encoded Unicode character streams and Markus Kuhn coordinated the creation of some suitable fonts. This work has been merged into XFree86 4.0. For those of us still relying on an older release or actually requiring an even newer version of xterm, I have made ports available: http://home.pages.de/~naddy/unix/freebsd/xterm.shar http://home.pages.de/~naddy/unix/freebsd/ucs-fixed.shar (Earlier versions of) these have been submitted in PRs #15545 and #15840, but for some reason they have never been committed. -- Christian "naddy" Weisgerber [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: empty lists in for
Max Khon [EMAIL PROTECTED] wrote: However, under Solaris 2.6: clone$uname -a SunOS clone 5.6 Generic_105181-13 sun4u sparc SUNW,Ultra-1-Engine clone$/bin/ksh clone$for i in ; do echo $i; done /bin/ksh: syntax error: `;' unexpected That's an old ksh88, which probably doesn't conform to POSIX anyway. -- Christian "naddy" Weisgerber [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Onstream?
Alan Batie [EMAIL PROTECTED] wrote: I just got an onstream scsi tape drive only to discover that I should've checked the archives because it don't work. Depends on the drive. If you got an Echo drive (SCxx), you're right. The ADR drives--yes, they all use ADR tape technology, but confusingly there's also a model line called "ADR"--on the other hand, are ordinary SCSI drives, according to the OnStream representative I talked to at CeBIT. For instance, they're certified to work with the plain Linux SCSI tape driver. A few days ago I asked whether anybody's running an ADR50 successfully off a FreeBSD box but received no response. Actually I'm not sure the ADR50 is in the stores yet. -- Christian "naddy" Weisgerber [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Localization and locale()?
Jason Simms [EMAIL PROTECTED] wrote: On Solaris, I can see what choices I have by running 'locale -a'. However, all my attempts to find a similar function on FreeBSD 3.4 have failed. Shrug There is no locale(1) command, true. You can find the available locales under /usr/share/locale. es_ES.ISO8859-1 pt.PT.ISO8859-1 en_US.ISO8859-1 Those are available. It's ...ISO_8859-1, though. Notice the underscore. And within my program (Perl), I need to use the setlocale() function imported from the POSIX module (actually, from the locale_h header file). Well, then do it. -- Christian "naddy" Weisgerber [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Cool little 100BaseTX switch - they're coming down in price
Sergey Babkin [EMAIL PROTECTED] wrote: At work I've got experience with 32-port D-Link 10/100 switched hub. It works fine except that it hangs occasionally (can be reset by power-cycling). So we don't buy them any more. Also at my pre-previous employer we had small 8-port 10Mpbs hubs from D-Link and they had the same problem, so it seems to be a family problem. I have a D-Link DSH-5 5-port 10/100 dualspeed hub here at home, and I'm reasonably happy with it. It certainly doesn't hang. One of the machines here has trouble negotiating a working 100Mbit/s link, but that's just as likely a problem of the Linux tulip driver. After a couple of months I put a drop of oil into the bearing of the cooling fan, which strongly suggested that treatment by the noises it was making. Somebody mentioned power supplies: Since I ordered the hub from the US but live in 230V-land, I had to experiment a bit with the transformers I had lying around. Eventually I ended up feeding the hub's power supply 120V/50Hz and it's happy with that. 100V/50Hz didn't work. This should move to -chat. -- Christian "naddy" Weisgerber [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: keeping termcap up to date
Kazutaka YOKOTA [EMAIL PROTECTED] wrote: In the past, it has been pointed out that some of the termcap entries needs updating. Indeed. I just noticed that screen still has trouble in xterm, due to a broken termcap entry. Would a committer please take care of PR #12209? -- Christian "naddy" Weisgerber [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
PAPERSIZE in /etc/make.conf?
Should we have a PAPERSIZE variable (A4 vs. letter) in /etc/make.conf? - groff has the paper size set as compile time option. - Various ports that now exist in two versions or require the user to define the paper size at build time could automatically pull the value in. -- Christian "naddy" Weisgerber [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
PAPERSIZE in /etc/make.conf?
Should we have a PAPERSIZE variable (A4 vs. letter) in /etc/make.conf? - groff has the paper size set as compile time option. - Various ports that now exist in two versions or require the user to define the paper size at build time could automatically pull the value in. -- Christian naddy Weisgerber na...@mips.rhein-neckar.de To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
