Boot hang with pcm
Current as of yesterday afternoon hangs trying to boot on my box with an OPTi931 soundcard installed. It prints the probe, and then hangs. With boot -v, the messages are pcm0: OPTi931 at port 0x5 34-0x537,0x380-0x38b,0x220-0x22f,0xe0c-0xe0f irq 5 drq 0,1 on isa0 mss_init: opti_offset=2 Yanking the card, or removing the driver from the kernel config allows the machine to boot fine. Unfortunatly, I just upgraded from a September 2000 vintage -current, so I don't know when this broke. David -- [EMAIL PROTECTED] Bipedalism is only a fad. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
nroff stopped working
I'm using -current from 3.0 w/out big problems over last years. But after last 3 make world man breaks: trying _ANY_ man give me an empty page but under .../man/man*/*.gz sources are good. Only formatted-compressed pages are wrong. Even the command: # gzip -cd /usr/share/man/man1/man.1.gz | nroff -man give me an empty page. Happens only to me? Can I send a PR? Something related to recent changes to nroff? Ciao++ Riccardo. PS: Any news about burncd? My PR are stalled? Last month I was unable only to close cd, now I am unable even to ask msinfo :-( To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cp -d dir patch for review (or 'xargs'?)
On Fri, Apr 20, 2001 at 03:14:10PM -0700, Mike Smith wrote: # # Folks, # # although there was much rejoicing, I think there's no need for a # new option to cp. Just use the toolbox, it's not too hard: # # (cat bigfilelist; echo destdir) | xargs cp # # Or even # # echo destdir bigfilelist # xargs cp bigfilelist # # should do the trick. # # No, it won't. Consider a list of files a, b, c, d. You create input to # xargs 'a b c d destdir', which it then splits into 'a b c' and 'd # destdir'. The first time cp is run, it will probably fail; the second # time only 'd' ends up where you expect it. You mean if bigfilelist list exceeds the -n limit of xargs (default 5000)? Yes, you'll be surprised then. It was a bit of POLA violation for me when I found xargs would by default use 5000 arg chunks and not all in one go. I'd rather get rid of kern.argmax and the limitations of the exec familiy. Yes, I'm dreaming :-) Regards, Jens -- Jens Schweikhardt http://www.schweikhardt.net/ SIGSIG -- signature too long (core dumped) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: nroff stopped working
Date: Sat, 21 Apr 2001 14:12:59 +0200 (CEST) From: Riccardo Torrini [EMAIL PROTECTED] I'm using -current from 3.0 w/out big problems over last years. But after last 3 make world man breaks: trying _ANY_ man give me an empty page but under .../man/man*/*.gz sources are good. Only formatted-compressed pages are wrong. I ended up removing all of the pre-formatted man pages, and things worked after that. PS: Any news about burncd? My PR are stalled? Last month I was unable only to close cd, now I am unable even to ask msinfo :-( I've been using burncd (though under -STABLE; haven't tried it under -CURRENT (yet)) successfully Cheers, david -- David H. Wolfskill [EMAIL PROTECTED] As a computing professional, I believe it would be unethical for me to advise, recommend, or support the use (save possibly for personal amusement) of any product that is or depends on any Microsoft product. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cp -d dir patch for review (or 'xargs'?)
On Fri, Apr 20, 2001 at 07:26:18PM -0700, Rodney W. Grimes wrote:
(cat bigfilelist; echo destdir) | xargs cp
I like this version of the patch!! It's much much cleaner than
hacking up cp or xargs, it even follows the unix principle of
using simple tools and glueing them togeather to do bigger
jobs, is unix implementation independent, and is very clear
in what it does.
It's clean, simple, and unfortunately, totally bogus.
Try:
echo 1 2 3 4 5 6 7 8 9 | xargs -n 4 echo
Now consider what would happen with the above suggested construct with
a very long file list.
bleck... try this for your sample:
$ (echo 1 2 3 4 5 6 7 8 9 | xargs -n 4) | while read x; do
echo -n $x; echo " dst"
done
1 2 3 4 dst
5 6 7 8 dst
9 dst
$
I don't see a problem with adding an option to cp to treat the first
argument as the target instead of the last argument. It's a simple
solution, the code change is simple, and it produces the exact desired
result. What's the problem?
It's yet another non-portable option.
I hate to appear rude, but has anybody in this discussion actually used
xargs for what it's meant to be used ?
How do you do this in a script:
cd /topdir; find . -type f | xargs -i {} cp {} /otherdir/.
Before anyone starts writing scripts, consider that {} will be
replaced by xargs with (roughly) ARG_MAX - 10 characters worth of the
stuff coming off the pipe. If your combined arguments plus
environment exceeds ARG_MAX execve(2) will give you E2BIG.
--
Rod Grimes - KD7CAX @ CN85sl - (RWG25) [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-current" in the body of the message
Re: your unsubscribe request
As you requested, you have been unsubscribed from 'fwd-newswire'. --- Return-Path: [EMAIL PROTECTED] () Received: from nova.sparklist.com ([207.250.144.28]) by nova.sparklist.com with SMTP (SparkLIST.com WIN32 version 4.1); Sat, 21 Apr 2001 08:37:20 -0500 From: [EMAIL PROTECTED] () To: fwd-newswire-request Subject: # Mail sent to leave-fwd-newswire was converted to these commands: unsubscribe end # This is the text of the message that triggered the action: Return-Path: [EMAIL PROTECTED] () Received: from nova.sparklist.com ([207.250.144.28]) by nova.sparklist.com with SMTP (SparkLIST.com WIN32 version 4.1); Sat, 21 Apr 2001 08:37:20 -0500 From: [EMAIL PROTECTED] () To: [EMAIL PROTECTED] Subject: your subscription request IP:203.55.242.168 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cp -d dir patch for review (or 'xargs'?)
On Sat, 21 Apr 2001 14:06:04 +0100, Brian Somers wrote:
How do you do this in a script:
cd /topdir; find . -type f | xargs -i {} cp {} /otherdir/.
for i in `find /path/to/source -type f`; do
cp $i /path/to/dest/
done
What's all the fuss about?
Ciao,
Sheldon.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: cp -d dir patch for review (or 'xargs'?)
Jens Schweikhardt [EMAIL PROTECTED] wrote: You mean if bigfilelist list exceeds the -n limit of xargs (default 5000)? Yes, you'll be surprised then. It was a bit of POLA violation for me when I found xargs would by default use 5000 arg chunks and not all in one go. I'd rather get rid of kern.argmax and the limitations of the exec familiy. Yes, I'm dreaming :-) Certainly, it would cause a whole lot of other problems, the smallest of which would be that people would be starting to write non-portable scripts that rely on the feature that there is no ARG_MAX limit. By the way, the -i and -I options of xargs are specified in the SUSv2 standard, and I think it would certainly be a good thing to comply with that. At least it would be a whole lot better than hacking a non-standard option into cp which would solve the problem for one particular case only, while fixing xargs would solve the whole class of problems. Putting that option into cp seems rather GNUish to me, but not very UNIXish. :-) Just my 2 Euro cents. Regards Oliver -- Oliver Fromme, secnetix GmbH Co KG, Oettingenstr. 2, 80538 Mnchen Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. "All that we see or seem is just a dream within a dream" (E. A. Poe) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Post-FILE size change upgrade
Hi folks, After downgrading to RELENG_4 for a while to prove to my team mates that 3 months of pain were the result of hardware instability and not features of HEAD, I'm ready to get back on the wagon. I didn't follow the FILE size change debarcle, because I assumed that the problem would be resolved by the time I was ready for -CURRENT again. However, the entry for 20010211 in UPDATING suggests that I was wrong: 20010211: The size of FILE was changed. This breaks upgrading. If you must upgrade, be prepared for pain. It also breaks almost all binaries that you've compiled on -current. You are warned Is this still true? Please note that I'm not taking a dig at anyone. I've always seen source upgrades to HEAD as a luxury and firmly believe that binary upgrades are the "correct answer for technical support". Please don't use this innocent question to start a flame war. Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cp -d dir patch for review (or 'xargs'?)
Sheldon Hearn [EMAIL PROTECTED] wrote:
On Sat, 21 Apr 2001 14:06:04 +0100, Brian Somers wrote:
How do you do this in a script:
cd /topdir; find . -type f | xargs -i {} cp {} /otherdir/.
for i in `find /path/to/source -type f`; do
cp $i /path/to/dest/
done
That can overflow your shell's command line limit (at the
"for" command). True, our /bin/sh doesn't has such a
limit, AFAIK, but there _are_ shells that do). Apart from
that it is extremely inefficient, because it runs a "cp"
for every single file. These are exactly the problems that
xargs is supposed to solve.
Actually I don't see any problem with Brian's approach
(provided that the -i option exists, of course).
xargs _does_ take the size of the environment into account,
as well as the size of all arguments, and it still leaves
much room (it only uses up to ARG_MAX - 2048 by default).
Oh by the way, in this particular example it is probably a
good idea to use cpio. This will even work with our xargs
(which doesn't support -i yet):
cd /topdir; find . -type f | cpio -dup /otherdir
should do exactly that job.
Regards
Oliver
--
Oliver Fromme, secnetix GmbH Co KG, Oettingenstr. 2, 80538 Mnchen
Any opinions expressed in this message may be personal to the author
and may not necessarily reflect the opinions of secnetix in any way.
"All that we see or seem is just a dream within a dream" (E. A. Poe)
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: cp -d dir patch for review (or 'xargs'?)
On 21-Apr-2001 Sheldon Hearn wrote:
On Sat, 21 Apr 2001 14:06:04 +0100, Brian Somers wrote:
How do you do this in a script:
cd /topdir; find . -type f | xargs -i {} cp {} /otherdir/.
for i in `find /path/to/source -type f`; do
cp $i /path/to/dest/
done
What's all the fuss about?
It looks like above construct will fail horribly if any of the files in /topdir
have names with spaces in them. Think MP3 collections :)
Ciao,
Sheldon.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
--
E-Mail: Alexander Kabaev [EMAIL PROTECTED]
Date: 21-Apr-2001
Time: 10:49:59
--
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Post-FILE size change upgrade
Date: Sat, 21 Apr 2001 16:49:24 +0200 From: Sheldon Hearn [EMAIL PROTECTED] After downgrading to RELENG_4 for a while to prove to my team mates that 3 months of pain were the result of hardware instability and not features of HEAD, I'm ready to get back on the wagon. I didn't follow the FILE size change debarcle, because I assumed that the problem would be resolved by the time I was ready for -CURRENT again. However, the entry for 20010211 in UPDATING suggests that I was wrong: 20010211: The size of FILE was changed. This breaks upgrading. If you must upgrade, be prepared for pain. It also breaks almost all binaries that you've compiled on -current. You are warned Is this still true? Well, I acquired my laptop in early March, got 4.2 running on it, then cloned the / /usr from that to another slice, and upgraded the clone to -CURRENT. I've been tracking both -STABLE -CURRENT (daily) since. I do not recall encountering any problems attributable to the above. Indeed, the only undesirable side-effect of the procedure has been that there was some cruft left over from 4.x -- the old kernel modules. Oh yeah; when I'm running -STABLE, I see that there is a populated /dev over on the -CURRENT side (that is hidden by the devfs mounted on /dev when I'm running -CURRENT). I suppose I could try wiping the cruft out; hasn't been enough of an issue to bother with, though. Cheers, david -- David H. Wolfskill [EMAIL PROTECTED] As a computing professional, I believe it would be unethical for me to advise, recommend, or support the use (save possibly for personal amusement) of any product that is or depends on any Microsoft product. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cp -d dir patch for review (or 'xargs'?)
Your comments have nothing to do with the issue at hand. Just wrap the first argument to cp in double-quotes, i.e. cp "$i" The point is, why bastardize tools to cope with areas beyond their focus and well within the focus of other tools? Ciao, Sheldon. Sorry for butting in. Adding new non-portable functionality to solve the problem which could be adequitely taken care of using existing and well known techniquies is not appropriate, I completely agree with you on that. -- E-Mail: Alexander Kabaev [EMAIL PROTECTED] Date: 21-Apr-2001 Time: 11:08:13 -- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cp -d dir patch for review (or 'xargs'?)
Sheldon Hearn [EMAIL PROTECTED] wrote: On Sat, 21 Apr 2001 16:51:24 +0200, Oliver Fromme wrote: That can overflow your shell's command line limit (at the "for" command). True, our /bin/sh doesn't has such a limit, AFAIK, but there _are_ shells that do). That's actually my point. What's being proposed is a non-standard extension to work around a problem on a system that already doesn't have the problem. Maybe I didn't make myself clear enough. We _do_ have a problem. Not all users use /bin/sh. Scripts needn't be written in /bin/sh, and xargs can be used interactively, too (I use it a lot). Just because _our_ xargs works fine with _our_ /bin/sh doesn't mean there is no problem. And then there's the gross efficiency problem. Try these alternatives and compare how long they take: for i in `find /usr/ports -type f`; do cat $i /dev/null done find /usr/ports -type f | xargs cat /dev/null The latter is a hell of a lot faster. (The example uses "cat" just because it works with xargs.) By the way, the first (inefficient) approach could be rewritten like this: find /usr/ports -type f | while read i; do cat $i /dev/null done This avoid the potential line limit problem, but of course it's just as inefficient. Regards Oliver -- Oliver Fromme, secnetix GmbH Co KG, Oettingenstr. 2, 80538 Mnchen Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. "All that we see or seem is just a dream within a dream" (E. A. Poe) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cp -d dir patch for review (or 'xargs'?)
On Sat, 21 Apr 2001 17:27:04 +0200, Oliver Fromme wrote: Not all users use /bin/sh. Scripts needn't be written in /bin/sh, and xargs can be used interactively, too (I use it a lot). Just because _our_ xargs works fine with _our_ /bin/sh doesn't mean there is no problem. So we have two problems: 1) Calling cp(1) repetitively is inefficient. 2) The argument list is too big for cp(1). Extending cp(1) will not solve (2). Extending xargs(1) will solve both. So why is an extension to cp(1) being proposed? Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: your unsubscribe request
As you requested, you have been unsubscribed from 'fwd-newswire'. --- Return-Path: [EMAIL PROTECTED] Received: from mailhost.sparknet.net ([207.67.22.123]) by nova.sparklist.com with SMTP (SparkLIST.com WIN32 version 4.1); Sat, 21 Apr 2001 11:01:40 -0500 Received: from don-oakes.sparklist.com (dhcp-client-26.sparklist.com [207.250.191.151]) by mailhost.sparknet.net (8.10.1/8.10.1) with ESMTP id f3LG3pI03813 for [EMAIL PROTECTED]; Sat, 21 Apr 2001 11:03:51 -0500 Message-Id: [EMAIL PROTECTED] X-Sender: (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Sat, 21 Apr 2001 10:56:03 -0500 To: fwd-newswire-request From: admin [EMAIL PROTECTED] Subject: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed # Mail sent to leave-fwd-newswire-2059525t was converted to these commands: unsubscribe fwd-newswire [EMAIL PROTECTED] confirm end # This is the text of the message that triggered the action: Return-Path: [EMAIL PROTECTED] Received: from mailhost.sparknet.net ([207.67.22.123]) by nova.sparklist.com with SMTP (SparkLIST.com WIN32 version 4.1); Sat, 21 Apr 2001 11:01:40 -0500 Received: from don-oakes.sparklist.com (dhcp-client-26.sparklist.com [207.250.191.151]) by mailhost.sparknet.net (8.10.1/8.10.1) with ESMTP id f3LG3pI03813 for [EMAIL PROTECTED]; Sat, 21 Apr 2001 11:03:51 -0500 Message-Id: [EMAIL PROTECTED] X-Sender: (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Sat, 21 Apr 2001 10:56:03 -0500 To: [EMAIL PROTECTED] From: admin [EMAIL PROTECTED] Subject: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
/bin/df set-gid operator
Hi, This is probably the wrong list, but I have no idea where else to ask, and -current is also affected, so ... I'm wondering why /bin/df is set-gid to the operator group by default. I have tried to remove the s bit, and it is still working fine. Looking at the source code didn't give me a clue either. -1- Am I missing something? What? -2- If I'm not missing anything, then shouldn't the BINMODE line be removed from src/bin/df/Makefile? -3- Shall I send-pr a patch? :-) Regards Oliver -- Oliver Fromme, secnetix GmbH Co KG, Oettingenstr. 2, 80538 Mnchen Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. "All that we see or seem is just a dream within a dream" (E. A. Poe) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: kernel core
On 21-Apr-01 David W. Chapman Jr. wrote: I just tried to do an installkernel on a new kernel I built and I got the same error except the last line changed to stopped atffs_dirpref+0x210movzbl0(%ECX,%EAX,1),%EAX Do I have any hope at recovering from this or should I start again with 4 and upgrade to -current. I'm assuming is a problem with the kernel and without being able to update the kernel and install a new one, I don't think I can fix it. You need to rebuild fsck and install it and fsck your filesystems. This is the dirpref changes biting you. Warner, we probably need an entry in UPDATING for the dirpref changes that warn people to build and install a new fsck before booting a dirpref kernel. -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.Baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: /bin/df set-gid operator
On Sat, 21 Apr 2001, Oliver Fromme wrote: I'm wondering why /bin/df is set-gid to the operator group by default. It's to df filesystems that aren't mounted. Try "df /dev/ad0s1a" (or whatever) as user nobody with chmod 555 /bin/df. -Paul. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: /bin/df set-gid operator
Paul Herman [EMAIL PROTECTED] wrote: On Sat, 21 Apr 2001, Oliver Fromme wrote: I'm wondering why /bin/df is set-gid to the operator group by default. It's to df filesystems that aren't mounted. Try "df /dev/ad0s1a" (or whatever) as user nobody with chmod 555 /bin/df. Ah, thanks for clueing me. :-) I didn't know that unprivileged users are supposed to be allowed to use df on non-mounted filesystems. I think I'll keep it at mode 555 on my machines. Regards Oliver -- Oliver Fromme, secnetix GmbH Co KG, Oettingenstr. 2, 80538 Mnchen Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. "All that we see or seem is just a dream within a dream" (E. A. Poe) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: /bin/df set-gid operator
On Sat, 21 Apr 2001, Oliver Fromme wrote:
Paul Herman [EMAIL PROTECTED] wrote:
On Sat, 21 Apr 2001, Oliver Fromme wrote:
I'm wondering why /bin/df is set-gid to the operator group
by default.
It's to df filesystems that aren't mounted. Try "df /dev/ad0s1a" (or
whatever) as user nobody with chmod 555 /bin/df.
Ah, thanks for clueing me. :-)
I didn't know that unprivileged users are supposed to be
allowed to use df on non-mounted filesystems.
I think I'll keep it at mode 555 on my machines.
This brings up a slightly related question: Now that "cooked" block
devices have been abolished, wouldn't it be a good idea to get rid of
the quick mount(2)/umount(2) of /tmp/df.XX to stat the file
system? Something like the following patch.
Not that it should ever get called anyway...
-Paul.
Index: df.c
===
RCS file: /home/ncvs/src/bin/df/df.c,v
retrieving revision 1.23.2.1
diff -u -r1.23.2.1 df.c
--- df.c2000/06/13 03:19:40 1.23.2.1
+++ df.c2001/04/21 18:02:18
@@ -208,40 +208,6 @@
} else if ((stbuf.st_mode S_IFMT) == S_IFCHR) {
rv = ufs_df(*argv, maxwidth) || rv;
continue;
- } else if ((stbuf.st_mode S_IFMT) == S_IFBLK) {
- if ((mntpt = getmntpt(*argv)) == 0) {
- mdev.fspec = *argv;
- mntpath = strdup("/tmp/df.XX");
- if (mntpath == NULL) {
- warn("strdup failed");
- rv = 1;
- continue;
- }
- mntpt = mkdtemp(mntpath);
- if (mntpt == NULL) {
- warn("mkdtemp(\"%s\") failed", mntpath);
- rv = 1;
- free(mntpath);
- continue;
- }
- if (mount("ufs", mntpt, MNT_RDONLY,
- mdev) != 0) {
- rv = ufs_df(*argv, maxwidth) || rv;
- (void)rmdir(mntpt);
- free(mntpath);
- continue;
- } else if (statfs(mntpt, statfsbuf) == 0) {
- statfsbuf.f_mntonname[0] = '\0';
- prtstat(statfsbuf, maxwidth);
- } else {
- warn("%s", *argv);
- rv = 1;
- }
- (void)unmount(mntpt, 0);
- (void)rmdir(mntpt);
- free(mntpath);
- continue;
- }
} else
mntpt = *argv;
/*
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: cp -d dir patch for review (or 'xargs'?)
From: Oliver Fromme [EMAIL PROTECTED] Subject: Re: cp -d dir patch for review (or 'xargs'?) Date: Sat, 21 Apr 2001 17:27:04 +0200 (CEST) Not all users use /bin/sh. Scripts needn't be written in /bin/sh ... Actually, just to jump in and correct this, scripts *should* be written in /bin/sh. That's a defacto Unix standard when it comes to writing shell scripts, just for uniformities sake, and even if you use tcsh or zsh as your personal shell one is always encouraged to write in straight POSIX-conformant /bin/sh for portable scripts. If one also needs to walk entirely outside the painted lines there then that's a good indication that maybe it should be written in perl. :) - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: /bin/df set-gid operator
Sorry to follow up on my own mail... On Sat, 21 Apr 2001, Paul Herman wrote: This brings up a slightly related question: Now that block devices have been abolished, wouldn't it be a good idea to get rid of the quick mount(2)/umount(2) of /tmp/df.XX to stat the file system? I see now that block type devices still pop up everywhere in the VFS system, so I'll just forget this and leave it up to the team that may someday totaly remove block device support from the kernel -- if that ever will happen. :-) -Paul. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: kernel core
You need to rebuild fsck and install it and fsck your filesystems. This is the dirpref changes biting you. Warner, we probably need an entry in UPDATING for the dirpref changes that warn people to build and install a new fsck before booting a dirpref kernel. Er. This really isn't very good; I can see all sorts of opportunities here for disk migration between -stable and -current systems causing massive headaches. I assume there's a better fix in the works, so that a "dirpref-touched" disk can be moved back to a pre-dirpref system? -- ... 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-current" in the body of the message
Re: cp -d dir patch for review (or 'xargs'?)
On Sat, 21 Apr 2001 14:06:04 +0100, Brian Somers wrote:
How do you do this in a script:
cd /topdir; find . -type f | xargs -i {} cp {} /otherdir/.
for i in `find /path/to/source -type f`; do
cp $i /path/to/dest/
done
What's all the fuss about?
Have you tried that for values of /path/to/source with lots of files ?
Something like
find blah | while read i; do cp $i /dest/.; done
is better, but it runs cp too many times.
Ciao,
Sheldon.
--
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-current" in the body of the message
Re: /bin/df set-gid operator
On Sat, 21 Apr 2001, Paul Herman wrote:
This brings up a slightly related question: Now that "cooked" block
devices have been abolished, wouldn't it be a good idea to get rid of
the quick mount(2)/umount(2) of /tmp/df.XX to stat the file
system? Something like the following patch.
No. This code is just unreachable because it still hasn't be changed
to mount "raw" block devices.
Note that in 4.4BSD, the mount(2)/unmount(2) code works without df
being setgid operator provided group operator can read the devices,
since mount(2) doesn't require superuser privilege in 4.4BSD. In
FreeBSD, mount privilege is controlled by the vfs.usermount sysctl
(default: off), so df must still be setgid operator to work on devices.
The mount() method is better because can work on work on all types of
filesystems that the kernel understands, while ufs_df() only works
for ufs.
Untested fixes:
Index: df.c
===
RCS file: /home/ncvs/src/bin/df/df.c,v
retrieving revision 1.24
diff -c -2 -r1.24 df.c
*** df.c2000/06/03 20:17:39 1.24
--- df.c2001/04/21 18:52:52
***
*** 108,112
voidusage __P((void));
! int aflag = 0, hflag, iflag, nflag;
structufs_args mdev;
--- 108,112
voidusage __P((void));
! int aflag, hflag, iflag, nflag;
structufs_args mdev;
***
*** 120,125
long mntsize;
int ch, err, i, maxwidth, rv, width;
! char *mntpt, *mntpath, **vfslist;
vfslist = NULL;
while ((ch = getopt(argc, argv, "abgHhikmnPt:")) != -1)
--- 120,126
long mntsize;
int ch, err, i, maxwidth, rv, width;
! char *fstype, *mntpath, *mntpt, **vfslist;
+ fstype = "ufs";
vfslist = NULL;
while ((ch = getopt(argc, argv, "abgHhikmnPt:")) != -1)
***
*** 163,166
--- 164,168
if (vfslist != NULL)
errx(1, "only one -t option may be specified.");
+ fstype = optarg;
vfslist = makevfslist(optarg);
break;
***
*** 206,213
continue;
}
! } else if ((stbuf.st_mode S_IFMT) == S_IFCHR) {
! rv = ufs_df(*argv, maxwidth) || rv;
! continue;
! } else if ((stbuf.st_mode S_IFMT) == S_IFBLK) {
if ((mntpt = getmntpt(*argv)) == 0) {
mdev.fspec = *argv;
--- 208,212
continue;
}
! } else if (S_ISBLK(stbuf.st_mode) || S_ISCHR(stbuf.st_mode)) {
if ((mntpt = getmntpt(*argv)) == 0) {
mdev.fspec = *argv;
***
*** 225,229
continue;
}
! if (mount("ufs", mntpt, MNT_RDONLY,
mdev) != 0) {
rv = ufs_df(*argv, maxwidth) || rv;
--- 224,228
continue;
}
! if (mount(fstype, mntpt, MNT_RDONLY,
mdev) != 0) {
rv = ufs_df(*argv, maxwidth) || rv;
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: cp -d dir patch for review (or 'xargs'?)
Jordan Hubbard [EMAIL PROTECTED] wrote: From: Oliver Fromme [EMAIL PROTECTED] Not all users use /bin/sh. Scripts needn't be written in /bin/sh ... Actually, just to jump in and correct this, scripts *should* be written in /bin/sh. It depends. I often happen to write zsh scripts, but only if I'm sure that they don't really have to be portable, and that I am the only one who will ever use them. When I was young, I also wrote a few tcsh scripts (*ouch*), but I discontinued doing that long ago. :-) I agree with you 100% that portable scripts should use /bin/sh and nothing else. And to come back on topic: Portable scripts also should _not_ assume that there are no limits on the length of shell commands. On the other hand, portable scripts can legitimately assume that xargs supports -i and -I, which ours doesn't. Regards Oliver PS: FWIW, I also write a lot of awk scripts, which is my favourite scripting language, but this is really getting off-topic ... -- Oliver Fromme, secnetix GmbH Co KG, Oettingenstr. 2, 80538 Mnchen Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. "All that we see or seem is just a dream within a dream" (E. A. Poe) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cp -d dir patch for review (or 'xargs'?)
And to come back on topic: Portable scripts also should _not_ assume that there are no limits on the length of shell commands. On the other hand, portable scripts can legitimately assume that xargs supports -i and -I, which ours doesn't. Agreed on both counts. I guess we should fix that. PS: FWIW, I also write a lot of awk scripts, which is my favourite scripting language, but this is really getting off-topic ... So do I, and you're right. :) - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cp -d dir patch for review (or 'xargs'?)
On Sat, 21 Apr 2001, Brian Somers wrote:
On Sat, 21 Apr 2001 14:06:04 +0100, Brian Somers wrote:
How do you do this in a script:
cd /topdir; find . -type f | xargs -i {} cp {} /otherdir/.
for i in `find /path/to/source -type f`; do
cp $i /path/to/dest/
done
What's all the fuss about?
Have you tried that for values of /path/to/source with lots of files ?
Something like
find blah | while read i; do cp $i /dest/.; done
is better, but it runs cp too many times.
cp is a bad example, since it usually does physical i/o which is much
slower than execve() of a program that is probably cached, especially
when the program is small and not dynamically linked.
Bruce
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: cp -d dir patch for review (or 'xargs'?)
Jordan Hubbard [EMAIL PROTECTED] writes:
And to come back on topic: Portable scripts also should
_not_ assume that there are no limits on the length of
shell commands. On the other hand, portable scripts can
legitimately assume that xargs supports -i and -I, which
ours doesn't.
Agreed on both counts. I guess we should fix that.
I don't have a copy of SuSv2 or anything else that defines -I and -i,
but from what I can gather, -i is the same as "-I {}" and -I allows
things like this:
dima@spike% ./xargs -I [] echo CMD LINE [] ARGS test
CMD LINE this is the contents of the test file ARGS
dima@spike% ./xargs -I [] echo CMD [] LINE ARGS test
CMD this is the contents of the test file LINE ARGS
dima@spike% ./xargs -I [] echo [] CMD LINE ARGS test
this is the contents of the test file CMD LINE ARGS
Does that mean everyone is blind and missed my arrogant cross-post of
the amazingly short patch to do this, or are we just interested in
discussing it and not testing the implementation? ;-)
FWIW, I'm not sure the patch is entirely correct; xargs' processing of
this stuff looks like black magic. It works, but I'm not sure if I
failed to cater to some other weird assumptions it makes. This is why
it'd help if someone would at least look at it.
Thanks,
Dima Dorfman
[EMAIL PROTECTED]
Index: xargs.c
===
RCS file: /st/src/FreeBSD/src/usr.bin/xargs/xargs.c,v
retrieving revision 1.9
diff -u -r1.9 xargs.c
--- xargs.c 1999/08/28 01:07:50 1.9
+++ xargs.c 2001/04/21 20:15:27
@@ -73,6 +73,8 @@
int cnt, indouble, insingle, nargs, nflag, nline, xflag, wasquoted;
char **av, *argp, **ep = env;
long arg_max;
+ int apargs = 0;
+ char **avv, *replstr = NULL;
/*
* POSIX.2 limits the exec line length to ARG_MAX - 2K. Running that
@@ -96,8 +98,14 @@
nline -= strlen(*ep++) + 1 + sizeof(*ep);
}
nflag = xflag = wasquoted = 0;
- while ((ch = getopt(argc, argv, "0n:s:tx")) != -1)
+ while ((ch = getopt(argc, argv, "0I:in:s:tx")) != -1)
switch(ch) {
+ case 'I':
+ replstr = optarg;
+ break;
+ case 'i':
+ replstr = "{}";
+ break;
case 'n':
nflag = 1;
if ((nargs = atoi(optarg)) = 0)
@@ -144,6 +152,13 @@
else {
cnt = 0;
do {
+ if (replstr strcmp(*argv, replstr) == 0) {
+ apargs = 1;
+ *argv++;
+ for (avv = argv; *avv; *avv++)
+ cnt += strlen(*avv) + 1;
+ break;
+ }
cnt += strlen(*bxp++ = *argv) + 1;
} while (*++argv);
}
@@ -211,6 +226,8 @@
if (xp == exp || p ebp || ch == EOF) {
if (xflag xp != exp p ebp)
errx(1, "insufficient space for arguments");
+ for (avv = argv; apargs *avv; *avv++)
+ strlen(*xp++ = *avv) + 1;
*xp = NULL;
run(av);
if (ch == EOF)
@@ -253,6 +270,8 @@
if (xflag)
errx(1, "insufficient space for arguments");
+ for (avv = argv; apargs *avv; *avv++)
+ strlen(*xp++ = *avv) + 1;
*xp = NULL;
run(av);
xp = bxp;
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: cp -d dir patch for review (or 'xargs'?)
On Sat, Apr 21, 2001 at 05:34:31PM +0200, Sheldon Hearn wrote: So we have two problems: 1) Calling cp(1) repetitively is inefficient. 2) The argument list is too big for cp(1). Extending cp(1) will not solve (2). Extending xargs(1) will solve both. So why is an extension to cp(1) being proposed? But extending cp does solve the problem. The proposal was to make % cp -d target src1 src2 ... srcN Be equivalent to; % cp src1 src2 ... srcN target This makes cp work with xargs; % cat ReallyBigListOfFiles | xargs cp -d target -Brian To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cp -d dir patch for review (or 'xargs'?)
Brian Dean [EMAIL PROTECTED] wrote: But extending cp does solve the problem. Only for cp. It wouldn't solve the problem for mv, ln and a bunch of other tools. Fixing it at _one_ place in xargs would solve all of that without touching a dozen tools. [...] This makes cp work with xargs; % cat ReallyBigListOfFiles | xargs cp -d target That's actually a bad example anyway, because you would use cpio in that case, not xargs|cp. It's also a bad example for using cat, but that's a different story. :-) cpio -dup target ReallyBigListOfFiles Regards Oliver -- Oliver Fromme, secnetix GmbH Co KG, Oettingenstr. 2, 80538 Mnchen Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. "All that we see or seem is just a dream within a dream" (E. A. Poe) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cp -d dir patch for review (or 'xargs'?)
So we have two problems: 1) Calling cp(1) repetitively is inefficient. 2) The argument list is too big for cp(1). Extending cp(1) will not solve (2). Extending xargs(1) will solve both. So why is an extension to cp(1) being proposed? I wasn't proposing that cp should be changed - I don't think it should. I'm just guilty of using a stale subject line :-/ Ciao, Sheldon. -- 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-current" in the body of the message
Re: cp -d dir patch for review (or 'xargs'?)
Dima Dorfman [EMAIL PROTECTED] wrote:
I don't have a copy of SuSv2 or anything else that defines -I and -i,
http://www.secnetix.de/~olli/susv2/xcu/xargs.html
but from what I can gather, -i is the same as "-I {}" and -I allows
things like this:
Not exactly. The difference is that the option-argument to
-i is optional and -- if present -- has to follow without
whitespace after the -i. This is a violation of the common
utility syntax guidelines, but has been adopted by SUSv2
because it was widely implemented.
So ``-i'' is the same as ``-I {}'', and ``-i[]'' (no space!)
is the same as ``-I []''.
Unfortunately, when you use -i or -I, then each line from
stdin is used as a signle argument, and the utility is
invoked once for every line, unless I misunderstand what
SUSv2 is saying. :-(
$ cat test
foo bar
baz bla
$ xargs -i echo XXX '{}' YYY test
XXX foo bar YYY
XXX baz bla YYY
$
Does that mean everyone is blind and missed my arrogant cross-post of
the amazingly short patch to do this, or are we just interested in
discussing it and not testing the implementation? ;-)
I must have missed it, and I think it's at least a good
start. :-)
The patch looks good. At leat it would solve the problem
which this thread is about, although I think it doesn't
comply with SUSv2.
Regards
Oliver
--
Oliver Fromme, secnetix GmbH Co KG, Oettingenstr. 2, 80538 Mnchen
Any opinions expressed in this message may be personal to the author
and may not necessarily reflect the opinions of secnetix in any way.
"All that we see or seem is just a dream within a dream" (E. A. Poe)
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: cp -d dir patch for review (or 'xargs'?)
I looked at your patches and immediately thought ``these patches
can't be right'' as I was expecting it to deal with things such as
xargs -I [] echo args are [], duplicated are []
I'm also dubious about the patches working for large volumes on
standard input. At this point I scrapped the email I was composing
'cos I didn't have time to look into it further :-/
I think it's important to test any patches with a large number of
large path names as input - so that ARG_MAX is reached before the
5000 argument limit and we can see that we don't end up getting E2BIG
because of an accidental overflow/miscalculation.
Sorry I don't have more time to spend on it :-/
I don't have a copy of SuSv2 or anything else that defines -I and -i,
but from what I can gather, -i is the same as "-I {}" and -I allows
things like this:
dima@spike% ./xargs -I [] echo CMD LINE [] ARGS test
CMD LINE this is the contents of the test file ARGS
dima@spike% ./xargs -I [] echo CMD [] LINE ARGS test
CMD this is the contents of the test file LINE ARGS
dima@spike% ./xargs -I [] echo [] CMD LINE ARGS test
this is the contents of the test file CMD LINE ARGS
Does that mean everyone is blind and missed my arrogant cross-post of
the amazingly short patch to do this, or are we just interested in
discussing it and not testing the implementation? ;-)
FWIW, I'm not sure the patch is entirely correct; xargs' processing of
this stuff looks like black magic. It works, but I'm not sure if I
failed to cater to some other weird assumptions it makes. This is why
it'd help if someone would at least look at it.
Thanks,
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-current" in the body of the message
Re: cp -d dir patch for review (or 'xargs'?)
Putting that option into cp seems rather GNUish to me, but not very UNIXish. :-) Yes. I think most people agree that changing cp is not good. Just my 2 Euro cents. Regards Oliver -- Oliver Fromme, secnetix GmbH Co KG, Oettingenstr. 2, 80538 Mnchen Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. "All that we see or seem is just a dream within a dream" (E. A. Poe) -- 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-current" in the body of the message
Re: cp -d dir patch for review (or 'xargs'?)
Dima Dorfman [EMAIL PROTECTED] wrote:
I don't have a copy of SuSv2 or anything else that defines -I and -i,
http://www.secnetix.de/~olli/susv2/xcu/xargs.html
but from what I can gather, -i is the same as "-I {}" and -I allows
things like this:
Not exactly. The difference is that the option-argument to
-i is optional and -- if present -- has to follow without
whitespace after the -i. This is a violation of the common
utility syntax guidelines, but has been adopted by SUSv2
because it was widely implemented.
So ``-i'' is the same as ``-I {}'', and ``-i[]'' (no space!)
is the same as ``-I []''.
I don't think we should adopt these semantics. I'm coming around to
Dima's -Y option - which must have an argument.
Unfortunately, when you use -i or -I, then each line from
stdin is used as a signle argument, and the utility is
invoked once for every line, unless I misunderstand what
SUSv2 is saying. :-(
I guess that settles it then. This is a dumb restriction and doesn't
seem to fit in very well with how xargs works. Again, Dima's idea is
IMHO superior.
But as I said in my other follow-up, I'm not convinced that the patch
deals with ARG_MAX overflows properly (I may be wrong though).
--
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-current" in the body of the message
Re: kernel core
On 21-Apr-01 Mike Smith wrote: You need to rebuild fsck and install it and fsck your filesystems. This is the dirpref changes biting you. Warner, we probably need an entry in UPDATING for the dirpref changes that warn people to build and install a new fsck before booting a dirpref kernel. Er. This really isn't very good; I can see all sorts of opportunities here for disk migration between -stable and -current systems causing massive headaches. I agree. I assume there's a better fix in the works, so that a "dirpref-touched" disk can be moved back to a pre-dirpref system? I hope so. I'm not sure if it is feasible, but it would be nice if the kernel would do a sanity check on the dirpref values in the superblock and fall back to defaults if they aren't sane. -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.Baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cp -d dir patch for review (or 'xargs'?)
Brian Somers [EMAIL PROTECTED] writes: I looked at your patches and immediately thought ``these patches can't be right'' as I was expecting it to deal with things such as xargs -I [] echo args are [], duplicated are [] It deals with it. It conveniently ignores the second '[]' :-). Seriosly though, what do you expect it to do in this case? It can either read some more from stdin, or use the same input it used for the first case of '[]'. I also can't think of a case when either one of these would be useful. I guess the only reason we would want this is if SUSv2 defines it, but even that may not matter since we probably won't support the silly '-i[nospace]' semantic (other than being silly, I can't think of how to implement it without writing a custom getopt() facility). I'm also dubious about the patches working for large volumes on standard input. At this point I scrapped the email I was composing 'cos I didn't have time to look into it further :-/ I think it's important to test any patches with a large number of large path names as input - so that ARG_MAX is reached before the 5000 argument limit and we can see that we don't end up getting E2BIG because of an accidental overflow/miscalculation. Any advice on testing this (you did write rev. 1.9 of xargs.1, after all)? I created a file with 4500 words like this: /this/is/a/very/long/path/name/because/I/am/testing/some/posix/limit/10 which ended up being 330 kB. It ran the `utility' multiple times like I expected it to. That said, I don't know what kind of failure mode to expect. I.e., if the patch is wrong, should it have failed with something like, "xargs: exec: argument list too long", or would it just produce incorrect output (which I didn't really check for)? Thanks, Dima Dorfman [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Post-FILE size change upgrade
On Sat, Apr 21, 2001 at 04:49:24PM +0200, Sheldon Hearn wrote: Is this still true? I don't believe so; I updated from 4.3-RC to 5.0-CURRENT on this machine and didn't have to do anything special (except set NOMAN, because I was being studly and updating using 'make all' instead of 'make world', and the bsd.*.mk changes to use MAN hadn't been backported yet -- this shouldn't affect you if you're making world). Kris PGP signature
Changing df [device] behaviour (Re: /bin/df set-gid operator)
On Sun, 22 Apr 2001, Bruce Evans wrote: In FreeBSD, mount privilege is controlled by the vfs.usermount sysctl (default: off), so df must still be setgid operator to work on devices. The mount() method is better because can work on work on all types of filesystems that the kernel understands, while ufs_df() only works for ufs. [patch] Although I like the idea of being able to df unmounted, non-ufs filesystems, I think the tradeoff might be too harsh. Non-root users aren't allowed to mount(2) at all if vfs.usermount=0, operator or no operator -- that is, in this case, df would fail for non-root users. -Paul. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
