Re: adding a new function to libc
In message [EMAIL PROTECTED], Daniel Hemmerich writes : Any comments, suggestions, swears concerning adding a new function, strndup(), to libc? Well, the obvious potential concern is that str[a-z]* is reserved namespace, and what if a future spec has a *different* strndup? So that instead of permitting it to attempt to allocate a large chunk of memory, it is possible to give it a max length. Well, this one is clearly wrong, because if you have a string of max_len, it isn't terminated. -s To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: FreeBSD 4.3 crashing with USB hub attached...
On Fri, May 11, 2001 at 07:54:26PM -0400, Shannon wrote: For the second boot I unplugged the USB hub. This time everything was fine... I'm sending this mail from the FreeBSD machine's console. Replying to my own post: The problem is the Logitech joystick, not the hub itself. Every time I boot with the joystick plugged in, FreeBSD 4.3 pukes. I've testing most other things with 4.3 on my hardware, and nothing else seems amiss. It's just like 4.2 except that no version prior to 4.3 would crash because of (or triggered by rather) a USB device. The joystick is a force-feedback model (Logi Formula Force), but is otherwise just your average every day USB joystick. -- If you tell the truth, you don't have to remember anything -- Mark Twain __ Charles Shannon Hendrix s h a n n o n @ w i d o m a k e r . c o m To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: subscribe
I guess we could, but somebody would have to do it. :) - Jordan From: David O'Brien [EMAIL PROTECTED] Subject: Re: subscribe Date: Fri, 11 May 2001 18:34:57 -0700 On Fri, May 11, 2001 at 05:01:13PM -0700, Jordan Hubbard wrote: Argh! I'm sorry folks, I almost always remember to delete the cc line when I send somebody that particular form letter so as not to spam the list myself, but this time I forgot to do that before typing the send command. Bad Jordan, no cookie! Why is it we can't have majordomo filter these out and send the people your form reponce. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: xargs(1) replstr patch
I'd suggest going ahead and committing it ASAP - before people start ``discussing'' it again :oI Feel free to blame me for reviewing it !!! Folks, The attached patch adds a replacement string feature to xargs(1). There's a full description in the man page update (also attached), but the following should demonstrate the new functionality: dima@spike% ./xargs -J [] echo CMD LINE [] ARGS test CMD LINE this is the contents of the test file ARGS dima@spike% ./xargs -J [] echo CMD [] LINE ARGS test CMD this is the contents of the test file LINE ARGS dima@spike% ./xargs -J [] echo [] CMD LINE ARGS test this is the contents of the test file CMD LINE ARGS This is similar to, but not identical to, the -I option described in SUSv2. The latter allows the replstr ([] above) to be attached to other arguments, and appear multiple times. Furthermore, it implies '-n 1'. Although the features are similar, they can solve different problems; even if -I is implemented later, this (-J) would still be useful. -J also doesn't have the performance implications attached with -I. There was a nice, long thread about this on current a few weeks ago (topic: Re: cp -d dir patch for review (or 'xargs'?)). It was rather inconclusive, but nobody managed to come up with a way to *properly* and *easily* imitate this functionality. Writing a script to do this *properly* (i.e., handle environment growth) isn't as easy as it sounds (although it's possible, of course). The patch is a joint effort between myself and Garance Dorsihn (gad). Comments? Suggestions? Thanks in advance, Dima Dorfman [EMAIL PROTECTED] [.] -- Brian [EMAIL PROTECTED]brian@[uk.]FreeBSD.org http://www.Awfulhak.org brian@[uk.]OpenBSD.org Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: kernel boot up problem
You don't have to change anything; IRQ sharing is allowed by PCI (and in fact, unless you change the slot the card is in, you can't change one without changing the other). Thanks for the reply. I first tried to change the IRQ from the BIOS. I saw that the IRQ of both the cards changes together. The machine has 4 CPUs and I am booting from CPU #1. The bios shows 4 PCI slots. The Plug and Play OS entry in the BIOS is set to No. Any help will be greatly appreciated. Thanks, --Ashish -Original Message- From: Paul Halliday [mailto:[EMAIL PROTECTED]] Sent: Thursday, May 10, 2001 9:49 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: kernel boot up problem [EMAIL PROTECTED] wrote: Hi: I am using FreeBSD 3.3 on a proprietary machine. The problem is that a T1 card (which is a PCI device) conflicts with an in-built PCI Intel Ethernet 10/100 card (fxp0). Please let me know me if I have to modify the T1 driver. You can probably change the builtins defaults from your bios. -- Paul H. === Don't underestimate the power of stupid people in large groups. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: xargs(1) replstr patch
Seconded :) G'luck, Peter -- Do you think anybody has ever had *precisely this thought* before? On Sat, May 12, 2001 at 11:04:42AM +0100, Brian Somers wrote: I'd suggest going ahead and committing it ASAP - before people start ``discussing'' it again :oI Feel free to blame me for reviewing it !!! Folks, The attached patch adds a replacement string feature to xargs(1). There's a full description in the man page update (also attached), but the following should demonstrate the new functionality: dima@spike% ./xargs -J [] echo CMD LINE [] ARGS test CMD LINE this is the contents of the test file ARGS dima@spike% ./xargs -J [] echo CMD [] LINE ARGS test CMD this is the contents of the test file LINE ARGS dima@spike% ./xargs -J [] echo [] CMD LINE ARGS test this is the contents of the test file CMD LINE ARGS This is similar to, but not identical to, the -I option described in SUSv2. The latter allows the replstr ([] above) to be attached to other arguments, and appear multiple times. Furthermore, it implies '-n 1'. Although the features are similar, they can solve different problems; even if -I is implemented later, this (-J) would still be useful. -J also doesn't have the performance implications attached with -I. There was a nice, long thread about this on current a few weeks ago (topic: Re: cp -d dir patch for review (or 'xargs'?)). It was rather inconclusive, but nobody managed to come up with a way to *properly* and *easily* imitate this functionality. Writing a script to do this *properly* (i.e., handle environment growth) isn't as easy as it sounds (although it's possible, of course). The patch is a joint effort between myself and Garance Dorsihn (gad). Comments? Suggestions? Thanks in advance, Dima Dorfman [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Question about building source
David Mr. Hackers O'Brien wrote: On Thu, May 10, 2001 at 08:28:41AM -0700, Terry Lambert wrote: If it doesn't work as you have said, make release' also _doesn't_ work; we cannot make a distribution. Obviously, it's wrong:) I think you are missing the facts: ... o Look in /usr/share/bsd.prog.mk for .if defined(DESTDIR); it overrides my compiler defaults for the values of CFLAGS and CXXINCLUDES. This makes them _WRONG_: ... The BSD .mk files insist on using the wrong .mk files; I don't know how much clearer I can make it?!? I went thru this last month -- bsd.*.mk assumes /usr/src and the base compilers. Peroid. People didn't want to accept that, but you are giving more proof of it. If you want to change the assumptions of about the base system, you have to be willing to change bsd.*.mk. Peroid. It's trivial to fix. I've posted the patches twice, now; I've had the problem since 3.x, when I was working at Whistle, and first had the problem, after fixing threaded exception handling in g++ with Jeremy Allison. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
SSH Must Die
This whole ssh B.S. is very annoying. After an upgrade from 4.2 to 4.3 using a CDROM boot plus upgrade menu option, SSH stops working, for no good reason (_any_ reason is no good). It complains about RSA not being in libcrypto, even though nm shows that that claim is full of crap. Yes, I have /dev/random, and yes, I have it in my kernel, even though it makes my boots slow as hell. How do I update the whole thing, so that the problem goes away? Alternately, can we rip it bodily out of FreeBSD, and flush it down the toilet? -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: kernel boot up problem
[EMAIL PROTECTED] wrote:
Thanks for the reply. I first tried to change the IRQ from
the BIOS. I saw that the IRQ of both the cards changes
together. The machine has 4 CPUs and I am booting from CPU
#1. The bios shows 4 PCI slots. The Plug and Play OS entry
in the BIOS is set to No.
Any help will be greatly appreciated.
Since you are using FreeBSD 3.3, you will not be able to
fix this in software, unless you are willing to upgrade.
The fact that changing the interrupt in the BIOS changed
both of them tells me that you are using PCI cards, and
that you changesd the INT {A|B|C|D} mapping to the ISA
interrupt number, and didn't change the card setting.
The only way to make sure that interrupts do not conflict
is to permit them to be reassigned, if the cards support
this (many do not) and the BIOS supports it (you will have
to enable Plug-N-Play, which will probably break other
things, since 3.3 is not a PnP OS).
There are two possibilities:
1) You are sticking the card in a slot that shares
an interrupt with another slot; for most modern
systems, this means you are using slot 5, since
there are only 4 PCI interrupts; if you are not
using all the slots, then the easy answer is to
move the card (modern systems make slot 1 use
INT A, slot 2 use INT B, and so on -- cascading
interrupts between slots -- and this wraps around,
beginning with slot 5). If all your slots are
full, you will have to get rid of one of your
cards, or upgrade your OS.
2) You are using an old motherboard. Old motherboards
did not cascade interrupts, and relied on the card
jumpers to select interrupts. Given the vintage of
your FreeBSD installation, this might be the case;
if so, change the jumper settings on your cards, or
upgrade your motherboard. Note: If you are using
an old motherboard that doesn't cascade the PCI
interrupts, it's also extremely likely that it can
only handle 2 bus masters (e.g. Intel Mercury and
Saturn chipsets, etc.), so you are flirting with
disaster, anyway.
-- Terry
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: adding a new function to libc
Daniel Hemmerich wrote: Any comments, suggestions, swears concerning adding a new function, strndup(), to libc? So that instead of permitting it to attempt to allocate a large chunk of memory, it is possible to give it a max length. How about just knowing what you are passing to the function before you call it, so that it isn't a problem? FWIW, I didn't like some of the Linux libc and kernel function extensions of similar ilk which were brought into FreeBSD, either: sloppy programmers should learn to ask people Would you like fries with that?, and stay away from computers. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: kernel boot up problem
Mike Smith wrote: You don't have to change anything; IRQ sharing is allowed by PCI (and in fact, unless you change the slot the card is in, you can't change one without changing the other). [ ... ] I am using FreeBSD 3.3 on a proprietary machine. ** -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: SSH Must Die
On Sat 2001-05-12 (04:24), Terry Lambert wrote: This whole ssh B.S. is very annoying. After an upgrade from 4.2 to 4.3 using a CDROM boot plus upgrade menu option, SSH stops working, for no good reason (_any_ reason is no good). It complains about RSA not being in libcrypto, even though nm shows that that claim is full of crap. Yes, I have /dev/random, and yes, I have it in my kernel, even though it makes my boots slow as hell. 4.3 doesn't have device random, or any way of building without it. How is it changing the speed of your boot? I've actually just done a 4.3 CD upgrade, but not from 4.2, and it worked. Can you give the modification times of your libcrypto and ssh, and make sure you're executing /usr/bin/ssh. And the output of 'ld /usr/bin/ssh'. Perhaps truss an ssh to a host and disconnect immediately. It might be failing after trying to open or read from /dev/urandom. Can you give the output of 'ls -l /dev/*random'? Maybe someone will have something useful to go on from the information above instead of it doesn't work. Neil -- Neil Blakey-Milner [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: adding a new function to libc
To follow myself up: Any comments, suggestions, swears concerning adding a new function, strndup(), to libc? So that instead of permitting it to attempt to allocate a large chunk of memory, it is possible to give it a max length. How about just knowing what you are passing to the function before you call it, so that it isn't a problem? There might actually be tiny value in such a function, but not the way you've written it. The value would be in avoiding the strlen() call prior to the malloc(), which would permit a single traversal of the string, relative to the standard strdup() function, which always ens up doing two traversals (one to get the length, and a second to do the copy). See the strncpy() sources. The downside risk would be that you could end up allocating too much memory, e.g.: charstring[BIGFREAKINGARRAY]; char*s; ... s = strndup( string, BIGFREAKINGARRAY); So it seems to me that the people who would want to use it would probably end up shooting themselves anyway. Something that seems more useful would be an asnprintf(), and you could (ab)use it to get the same functionality, but in this case more useful still doesn't mean generally useful. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: SSH Must Die
On Saturday 12 May 2001 06:24, Terry Lambert wrote: This whole ssh B.S. is very annoying. After an upgrade from 4.2 to 4.3 using a CDROM boot plus upgrade menu option, SSH stops working, for no good reason (_any_ reason is no good). You did make the needed additions to /etc/pam.conf, didn't you? It complains about RSA not being in libcrypto, even though nm shows that that claim is full of crap. Yes, I have /dev/random, and yes, I have it in my kernel, even though it makes my boots slow as hell. How do I update the whole thing, so that the problem goes away? Alternately, can we rip it bodily out of FreeBSD, and flush it down the toilet? -- Terry What would we use for remote command line access if that happened? Josh To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: adding a new function to libc
Hello Daniel Hemmerich!
Sat, May 12, 2001 at 02:10:45, dan (Daniel Hemmerich) wrote about adding a new
function to libc:
Any comments, suggestions, swears concerning adding a new function,
strndup(), to libc?
So that instead of permitting it to attempt to allocate a large chunk of
memory, it is possible to give it a max length.
Really, one should not use C-style null-terminated strings
except situations where they are nesessary (e.g. kernel interface)
because they all are too longfied nightmare, due to brain-damaged
interface and high inefficiency. Recent libc changes - adding
strlcpy() and strlcat() - were motivated AFAIU with well-grounded
fear to find *selves in BugTraq top list of buggy platforms, and with
aspiration to get rid of KR crap - strcpy(), etc. (There is no
such object as unlimited string buffer; there are limited buffer
and NUL-terminated constant string. strcpy() was designed to work
with wrong unlimited string buffer concept and hence it must die.
The same for its sisters such as strncat().)
strndup(), in any of common-possible interpretations, is danger because
caller cannot get info whether source string were longer (and copy is cut)
or not. You can use such cutting actively in rare cases, e.g. debugging
printing, but for sensitive work such _silent_ cutting can produce
only bugs, not any useful thing. I cannot see any reason to include
such danger function to libc.
The most concrete factor is that your code is buggy because if
source string is longer than max_len, destination string is not
terminated with NUL properly. And it is inefficient: there is no
need to waste processor time and cache cells to read unuseful data
in strlen().
Hence, I'll think the better implementation is
char*
strndup( const char* src, size_t max_len )
{
size_t len = strnlen( src, max_len );
char* ret = malloc( len + 1 );
if( ret ) {
strncpy( ret, src, len );
ret[ len ] = 0;
}
return ret;
}
Here strnlen() is used which is non-standard but I saw it in ~4 quite
different projects (e.g. Linux kernel) with identical interface
and result value; a variant of implementation follows:
/* This is candidate to have optimized assembler variant */
size_t strnlen( const char* src, size_t max )
{
size_t n;
while( n max *src != '\0' )
n++;
return n;
}
char *
strndup(str, max_len)
const char *str;
size_t max_len;
{
size_t len;
char *copy;
len = strlen(str) + 1;
if (len max_len)
len = max_len;
if ((copy = malloc(len)) == NULL)
return (NULL);
memcpy(copy, str, len);
return (copy);
}
--
Daniel Hemmerich
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
/netch
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: adding a new function to libc
On Sat, May 12, 2001 at 05:05:44PM +0300, Valentin Nechayev wrote:
Hello Daniel Hemmerich!
[snip]
Here strnlen() is used which is non-standard but I saw it in ~4 quite
different projects (e.g. Linux kernel) with identical interface
and result value; a variant of implementation follows:
/* This is candidate to have optimized assembler variant */
size_t strnlen( const char* src, size_t max )
{
size_t n;
while( n max *src != '\0' )
n++;
return n;
}
I really hope you meant *src++ there :)
G'luck,
Peter
--
If there were no counterfactuals, this sentence would not have been paradoxical.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: SSH Must Die
Sat, May 12, 2001 at 04:24:29, tlambert2 (Terry Lambert) wrote about SSH Must Die: This whole ssh B.S. is very annoying. After an upgrade from 4.2 to 4.3 using a CDROM boot plus upgrade menu option, SSH stops working, for no good reason (_any_ reason is no good). It complains about RSA not being in libcrypto, even though nm shows that that claim is full of crap. Yes, I have /dev/random, and yes, I have it in my kernel, even though it makes my boots slow as hell. Oh. The random device which needs entropy seed is -current artifact, isn't it? On -current, I watched identical problem with mystical ssh brokenness, with No RSA support in libcrypto and libssl message from ssh, after when all possible underwater stones were verified (including /dev/random and /dev/urandom, respect to markm@ reply). Unfortunately I had to make this system working in any way before I could do any diagnose, and it was completely rebuilt to RELENG_4. But, your case seems to be another. How do I update the whole thing, so that the problem goes away? Alternately, can we rip it bodily out of FreeBSD, and flush it down the toilet? Do you know another SSH implementation with good license? /netch To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: SSH Must Die
ssh works just fine for me in 4.3. You must be doing something wrong. - Jordan From: Terry Lambert [EMAIL PROTECTED] Subject: SSH Must Die Date: Sat, 12 May 2001 04:24:29 -0700 This whole ssh B.S. is very annoying. After an upgrade from 4.2 to 4.3 using a CDROM boot plus upgrade menu option, SSH stops working, for no good reason (_any_ reason is no good). It complains about RSA not being in libcrypto, even though nm shows that that claim is full of crap. Yes, I have /dev/random, and yes, I have it in my kernel, even though it makes my boots slow as hell. How do I update the whole thing, so that the problem goes away? Alternately, can we rip it bodily out of FreeBSD, and flush it down the toilet? -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: adding a new function to libc
Daniel Hemmerich [EMAIL PROTECTED] writes:
Any comments, suggestions, swears concerning adding a new function,
strndup(), to libc?
See src/crypto/heimdal/lib/roken/strndup.c :-)
char *
strndup(str, max_len)
const char *str;
size_t max_len;
{
size_t len;
char *copy;
len = strlen(str) + 1;
if (len max_len)
len = max_len;
if ((copy = malloc(len)) == NULL)
return (NULL);
memcpy(copy, str, len);
return (copy);
}
Doesn't work for a non-terminated str and doesn't 0-terminate the
return string when str is too long.
/assar
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: SSH Must Die
On Sat, May 12, 2001 at 07:23:20AM -0700, Jordan Hubbard wrote: ssh works just fine for me in 4.3. You must be doing something wrong. - Jordan From: Terry Lambert [EMAIL PROTECTED] Subject: SSH Must Die Date: Sat, 12 May 2001 04:24:29 -0700 This whole ssh B.S. is very annoying. After an upgrade from 4.2 to 4.3 using a CDROM boot plus upgrade menu option, SSH stops working, for no good reason (_any_ reason is no good). It complains about RSA not being in libcrypto, even though nm shows that that claim is full of crap. Yes, I have /dev/random, and yes, I have it in my kernel, even though it makes my boots slow as hell. How do I update the whole thing, so that the problem goes away? Alternately, can we rip it bodily out of FreeBSD, and flush it down the toilet? Exactly how is rpping it out of FreeBSD supposed to make ssh work? I think I had similar problems at some point between 4.2-R and 4.3-R. At some (fairly late IIRC) point inbetween the version numbers of some of the crypto libraries was increased. After a buildworld I had both lib.so.1 and lib.so.2 installed in /usr/lib. I think deleting/moving one of them (the .so.1 one IIRC) and then doing a new build/installworld with 'COMPAT4X=yes' in /etc/make.conf made things work correctly. I am afraid I don't remember the details exactly but it might be a starting point. -- Insert your favourite quote here. Erik Trulsson [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Jetzt gewinnen, in über 100 Gewinnspielen!
Falls unerwünscht, bitte sofort löschen! Gewinn24.de meldet Sie jeden Monat bei über 100 der besten Gewinnspiele im Internet an. Sie sparen mit Gewinn24.de eine Menge Zeit und Geld. Für maximal 2,- DM pro Monat sind Sie dabei und haben jeden Monat Gewinnchancen auf viele tolle Preise im Gesamtwert von mehreren Millionen DM. http://www.Gewinn24.de/index.php3?partner=7294 *Bei Beschwerden bitte an [EMAIL PROTECTED] * To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: adding a new function to libc
Any comments, suggestions, swears concerning adding a new function, strndup(), to libc? Many very good programmers I know carry around a library of useful functions (and usually don't bother about inclusion in libc). So I would suggest first you should keep this function in your own library for a few years and *only* then, and only if from experience you truly think it to be generally useful should you propose it for inclusion in a standard library. And *when* you do that you should a) present a correct version of the function (not a buggy one as you did here) and, more importantly b) a clear explanation of its function including how boundary conditions are handled. For your own library you don't have to jump through these hoops; this is necessary only when you want to let loose one of your favorite functions on unsuspecting libc users! Then the function behavior must be fully and carefully specified. Even for your own use, as was suggested by Valentin Nechayev, the strangely named function strnlen(str, max) is a better lower level function since it guarantees str won't be traversed beyond max chars and it is likely to be useful in more situations. As suggested by Terry Lambert, `asnprintf' would be another alternative. meta-comment Though IMHO these string functions have sprouted like weeds, for very little added functionality. The fact str[a-z]* is reserved namespace should tell you how bad the situation is. What is needed is a decent unicode string library, derived from the collective experience with perl scripts. Unicode strings should be counted instead of null terminated so we are talking about a brand new set of functions. May be such a library can be standardized in a future standards effort after some experience with it. /meta comment To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: xargs(1) replstr patch
At 8:37 PM -0700 5/11/01, Dima Dorfman wrote: Garance A Drosihn [EMAIL PROTECTED] writes: When I install this man page on -stable, and do a 'man xargs', that last line is displayed to the user as: /bin/ls -1d [A-Z]* | xargs -J [] cp -rp /bin/ls0 0/bin/ls1 ... Old versions of mdoc (read: anything before about a month ago) had a silly limit on the number of arguments. This isn't a problem on any recent -current or -stable. Okay, I updated my -stable machine, and the man page does display fine now. looks good. -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: SSH Must Die
Jordan Hubbard wrote: ssh works just fine for me in 4.3. You must be doing something wrong. I used that sysinstall thing Jordan wrote to upgrade from a 4.2 to a 4.3 system. Is that what I'm doing wrong? ;^). -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: SSH Must Die
Erik Trulsson wrote: Exactly how is rpping it out of FreeBSD supposed to make ssh work? I don't necessarily want it to work or not work, I just want it to quit being a pain in my backside. If it can't be made to upgrade correctly, then ripping it out also satisfies the criteria necessary to achieve the intended goal. I think I had similar problems at some point between 4.2-R and 4.3-R. At some (fairly late IIRC) point inbetween the version numbers of some of the crypto libraries was increased. After a buildworld I had both lib.so.1 and lib.so.2 installed in /usr/lib. I think deleting/moving one of them (the .so.1 one IIRC) and then doing a new build/installworld with 'COMPAT4X=yes' in /etc/make.conf made things work correctly. I am afraid I don't remember the details exactly but it might be a starting point. Yes, I see multiple installed copies of the libraries on my system. Since this is a cDROM from a make release, I expected to see that for compatability reasons. Are you saying that if I install the new compat4 stuff from the 4.3 CDROM, the problem will solve itself? I am willing to try that, but won't be able to tell you what happened until Monday. Thanks, -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: SSH Must Die
j wrote: On Saturday 12 May 2001 06:24, Terry Lambert wrote: This whole ssh B.S. is very annoying. After an upgrade from 4.2 to 4.3 using a CDROM boot plus upgrade menu option, SSH stops working, for no good reason (_any_ reason is no good). You did make the needed additions to /etc/pam.conf, didn't you? What additions are necessary between 4.2 and 4.3? I was under the impression that sysinstall was supposed to just do the right thing, and don't hassle me? If you have a dead chicken I should wave over my keyboard, hand it over! 8-). Alternately, can we rip it bodily out of FreeBSD, and flush it down the toilet? What would we use for remote command line access if that happened? I was always partial to telnet, but then I haven't really taken enough methamphetamines in my life (and the few I have taken were given to me by doctors) to make me as extraorfdinarily paranoid as most people seem to be these days. Of course, the idea that I'm being increasingly surrounded by mentally unstable speed freaks might be considered a paranoid fantasy by some, I suppose... 8-p. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: SSH Must Die
On Saturday 12 May 2001 18:40, Terry Lambert wrote: j wrote: On Saturday 12 May 2001 06:24, Terry Lambert wrote: This whole ssh B.S. is very annoying. After an upgrade from 4.2 to 4.3 using a CDROM boot plus upgrade menu option, SSH stops working, for no good reason (_any_ reason is no good). You did make the needed additions to /etc/pam.conf, didn't you? What additions are necessary between 4.2 and 4.3? I was under the impression that sysinstall was supposed to just do the right thing, and don't hassle me? If you have a dead chicken I should wave over my keyboard, hand it over! 8-). Make sure you have these lines in /etc/pam.conf sshdauthsufficient pam_skey.so sshdauthrequiredpam_unix.so try_first_pass sshdsession requiredpam_permit.so These lines are not in 4.2-rel and they are needed in 4.3-rel. Have fun. Josh To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: SSH Must Die
On Sat, May 12, 2001 at 04:31:29PM -0700, Terry Lambert wrote: Erik Trulsson wrote: Exactly how is rpping it out of FreeBSD supposed to make ssh work? I don't necessarily want it to work or not work, I just want it to quit being a pain in my backside. If it can't be made to upgrade correctly, then ripping it out also satisfies the criteria necessary to achieve the intended goal. I think I had similar problems at some point between 4.2-R and 4.3-R. At some (fairly late IIRC) point inbetween the version numbers of some of the crypto libraries was increased. After a buildworld I had both lib.so.1 and lib.so.2 installed in /usr/lib. I think deleting/moving one of them (the .so.1 one IIRC) and then doing a new build/installworld with 'COMPAT4X=yes' in /etc/make.conf made things work correctly. I am afraid I don't remember the details exactly but it might be a starting point. Yes, I see multiple installed copies of the libraries on my system. Since this is a cDROM from a make release, I expected to see that for compatability reasons. Are you saying that if I install the new compat4 stuff from the 4.3 CDROM, the problem will solve itself? I am willing to try that, but won't be able to tell you what happened until Monday. The compat4 stuff should install libraries in /usr/lib/compat/ After you have installed those, make sure that libraries found in /usr/lib/compat/ are not also installed in /usr/lib/ (E.g. if you have both /usr/lib/compat/libssl.so.1 and /usr/lib/libssl.so.1 then you should delete the latter.) And then you should use ldconfig or reboot to make sure that the right libraries are found. At least that fixed it for me but YMMV. (Might work with just removing the duplicate libraries from /usr/lib, except that if you have any binaries linked against the older versions they will probably stop working.) (No, I don't know why it wouldn't work with the older libraries residing in /usr/lib/ . It should have worked as I understand things. Well, everything works fine for me now anyway.) -- Insert your favourite quote here. Erik Trulsson [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: SSH Must Die
I used that sysinstall thing Jordan wrote to upgrade from a 4.2 to a 4.3 system. Is that what I'm doing wrong? ;^). Probably! Anybody would be the first to tell you that sysinstall's upgrade feature only gets you there unassisted maybe 3 times out of 5. The contents of /etc are side-stepped around, for example, they're not merged by any stretch of the imagination and I think there are a whole bunch of disclaimers in sysinstall to that effect. - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: SSH Must Die
On Sat, May 12, 2001 at 04:24:48PM -0700, Terry Lambert wrote: Jordan Hubbard wrote: ssh works just fine for me in 4.3. You must be doing something wrong. I used that sysinstall thing Jordan wrote to upgrade from a 4.2 to a 4.3 system. Is that what I'm doing wrong? ;^). sysinstall does a very minimal job of merging the contents of /etc. Certainly it could be improved (mergemaster works nicely when you have the source tree around). Your patches would be appreciated. Kris PGP signature
Re: adding a new function to libc
On Sat, May 12, 2001 at 02:10:45AM -0400, Daniel Hemmerich wrote:
Any comments, suggestions, swears concerning adding a new function,
strndup(), to libc?
So that instead of permitting it to attempt to allocate a large chunk of
memory, it is possible to give it a max length.
#include stdio.h
int main(int argc, char **argv) {
char *p;
asprintf(p, %.*s, 100, argv[1]);
printf(%s %d\n, p, strlen(p));
}
Kris
PGP signature
