Hi,
I have put
D47743 - Adds a new mountport mount option for NFS
D47849 - Man page update for the above
on reviews.freebsd.org.
I listed "manpages" for review of it, but if anyone would
like to take a look at it, please do.
I'd particularly like to get the man page patch reviewed.
Thanks in ad
Hi,
I just put a patch on phabricator (D45814) that adds support for multiple
sets of options for different hosts/networks to the ZFS sharenfs property.
(It is based loosely on a patch in bugzilla PR#147881, now 14 years old.)
I have listed a couple of reviewers, but please feel free to review it
On 5/30/14, 10:44 AM, Doug Ambrisko wrote:
On Thu, Sep 19, 2013 at 03:04:46PM -0400, John Baldwin wrote:
| On Tuesday, September 17, 2013 6:21:10 am Gleb Smirnoff wrote:
| > Hi!
| >
| > When system is writing a kernel core dump, it issues watchdog
| > pat wdog_kern_pat(WD_LASTVAL). If ipmi i
On Thu, Sep 19, 2013 at 03:04:46PM -0400, John Baldwin wrote:
| On Tuesday, September 17, 2013 6:21:10 am Gleb Smirnoff wrote:
| > Hi!
| >
| > When system is writing a kernel core dump, it issues watchdog
| > pat wdog_kern_pat(WD_LASTVAL). If ipmi is in action, it registers
| > ipmi_wd_event()
On Friday, September 20, 2013 1:44:52 am Gleb Smirnoff wrote:
> John,
>
> On Thu, Sep 19, 2013 at 03:04:46PM -0400, John Baldwin wrote:
> J> > When system is writing a kernel core dump, it issues watchdog
> J> > pat wdog_kern_pat(WD_LASTVAL). If ipmi is in action, it registers
> J> > ipmi_wd_e
John,
On Thu, Sep 19, 2013 at 03:04:46PM -0400, John Baldwin wrote:
J> > When system is writing a kernel core dump, it issues watchdog
J> > pat wdog_kern_pat(WD_LASTVAL). If ipmi is in action, it registers
J> > ipmi_wd_event() as event for watchdog. Thus ipmi_wd_event() is
J> > called in dumpi
On Tuesday, September 17, 2013 6:21:10 am Gleb Smirnoff wrote:
> Hi!
>
> When system is writing a kernel core dump, it issues watchdog
> pat wdog_kern_pat(WD_LASTVAL). If ipmi is in action, it registers
> ipmi_wd_event() as event for watchdog. Thus ipmi_wd_event() is
> called in dumping contex
I ran into a very similar problem on stable/9. During a reboot, the
system paniced because the watchdog slept when called from the syncer.
I solved it by dropping the sync mutex in the syncer before patting
the watchdog. It might be a more general solution that would also
solve your problem. My
Hi!
When system is writing a kernel core dump, it issues watchdog
pat wdog_kern_pat(WD_LASTVAL). If ipmi is in action, it registers
ipmi_wd_event() as event for watchdog. Thus ipmi_wd_event() is
called in dumping context.
The problem is that ipmi_wd_event() calls into ipmi_set_watchdog(),
tha
I'm sure there's lots of errors, so be gentle. :) It does work though,
so that's a plus.
Doug
--
This .signature sanitized for your protectionIndex: savecore.8
===
RCS file: /usr/local/ncvs/src/sbin/savecore/savecore.8,v
retrie
On Fri, Aug 01, 2003 at 06:12:13AM +0400, Andrey Chernov wrote:
> On Fri, Aug 01, 2003 at 12:02:04 +1000, Tim Robbins wrote:
>
> > 8 bits by casting to char. Using charcoll() to sort char arrays may
> > work on little endian machines, but may not on big endian machines.
>
> s->set is array of in
On Fri, Aug 01, 2003 at 12:02:04 +1000, Tim Robbins wrote:
> 8 bits by casting to char. Using charcoll() to sort char arrays may
> work on little endian machines, but may not on big endian machines.
s->set is array of ints, not array of chars. In any case thanx for
looking.
> Also, watch out fo
On Fri, Aug 01, 2003 at 04:44:08AM +0400, Andrey Chernov wrote:
> @@ -208,10 +210,18 @@
> if ((func)(cnt))
> *p++ = cnt;
> *p = OOBCH;
> + n = p - cp->set;
>
> s->cnt = 0;
> - s->state = SET;
> s->set = cp->set;
> + if (strcmp(s->
This patch address two problems.
1st one is relatively minor: according our own manpage, upper and lower
classes must be sorted, but currently not.
2nd one is serious:
tr '[:lower:]' '[:upper:]'
(and vice versa) currently works only if upper and lower classes
have exact the same number
On Sun, Feb 16, 2003 at 20:16:43 -0500, Garance A Drosihn wrote:
>
> to indicate localhost. Andrey provided a patch which allows OPIE
> to keep that standard (to OPIE) meaning. Could people try his
> patch and then explain why it does not solve the problem they are
> trying to solve?
The problem
At 3:48 PM + 2/16/03, Mark Murray wrote:
"Andrey A. Chernov" writes:
> On Sun, Feb 16, 2003, Dag-Erling Smorgrav wrote:
> > "Andrey A. Chernov" <[EMAIL PROTECTED]> writes:
> > Admins with no /etc/opieaccess AFFECTED!
>
> Admins with no /etc/opieaccess IDIOTS for not running mergemaster!
On Mon, Feb 17, 2003 at 01:51:20 +0300, Andrey A. Chernov wrote:
> properly). If you tune opiezed+pamified apps to work as you need, pure
> opized stops working and vice versa.
In this phrase I mean documented OPIE tuning of OPIE config files (old
way), without any new additions and requirements,
On Sun, Feb 16, 2003 at 15:39:51 -0600, Juli Mallett wrote:
>
> Can you explain how this stops purely opieized apps from working? I was
> under the impression the implicit case was still there, we just have a
> more explicit contract with the OPIE system.
This is not pure situation but mix with
"David O'Brien" writes:
> On Sun, Feb 16, 2003 at 07:11:49PM +, Mark Murray wrote:
> > In the case where an application is OPIEised and not PAMised, we
> > need to figure out something; PAMizing such apps is not terribly
> > hard. If any of them are in the base system, then this situation
> > i
* De: "Andrey A. Chernov" <[EMAIL PROTECTED]> [ Data: 2003-02-16 ]
[ Subjecte: Re: OPIE breakage: backout & patch for review ]
> On Sun, Feb 16, 2003 at 19:11:49 +, Mark Murray wrote:
> >
> > In the case where an application is OPIEised and not
On Sun, Feb 16, 2003 at 07:11:49PM +, Mark Murray wrote:
> In the case where an application is OPIEised and not PAMised, we
> need to figure out something; PAMizing such apps is not terribly
> hard. If any of them are in the base system, then this situation
> is a bug in its own right. If they
On Sun, Feb 16, 2003 at 19:11:49 +, Mark Murray wrote:
>
> In the case where an application is OPIEised and not PAMised, we
> need to figure out something; PAMizing such apps is not terribly
> hard. If any of them are in the base system, then this situation
We are not in the situation to forc
"David O'Brien" writes:
> > With a suitable "HEADS UP!" and appropriate changes to the documentation,
> > might is be possible to move _all_ policy control into PAM, instead of
> > having it split between OPIE and PAM?
>
> Nope. What about opieized, but not pamized applications?
> OPIE needs to a
On Sun, Feb 16, 2003 at 03:48:20PM +, Mark Murray wrote:
> "Andrey A. Chernov" writes:
> > On Sun, Feb 16, 2003 at 12:06:36 +0100, Dag-Erling Smorgrav wrote:
> > > "Andrey A. Chernov" <[EMAIL PROTECTED]> writes:
> > > > Admins with no /etc/opieaccess AFFECTED!
> > >
> > > Admins with no /etc/o
"Andrey A. Chernov" writes:
> On Sun, Feb 16, 2003 at 12:06:36 +0100, Dag-Erling Smorgrav wrote:
> > "Andrey A. Chernov" <[EMAIL PROTECTED]> writes:
> > > Admins with no /etc/opieaccess AFFECTED!
> >
> > Admins with no /etc/opieaccess IDIOTS for not running mergemaster!
>
> Moreover, admins WITH
On Sun, Feb 16, 2003 at 12:06:36 +0100, Dag-Erling Smorgrav wrote:
> "Andrey A. Chernov" <[EMAIL PROTECTED]> writes:
> > Admins with no /etc/opieaccess AFFECTED!
>
> Admins with no /etc/opieaccess IDIOTS for not running mergemaster!
Moreover, admins WITH old /etc/opieaccess (i.e. without your lin
On Sun, Feb 16, 2003 at 12:16:27 +0100, Dag-Erling Smorgrav wrote:
>
> My message <[EMAIL PROTECTED]> dated 2003-02-16
> 00:46:27 CET contained all the information you needed.
If you mean that quote from it:
"This behaviour was very surprising to people who wanted to prevent OPIE
users from usi
In message <[EMAIL PROTECTED]>, "Andrey A. Chernov" writes:
>> Please take this to private email.
>
>I not see enough good will from des side for it.
Then please just stop.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer
On Sun, Feb 16, 2003 at 11:21:15 +, Mark Murray wrote:
>
> Does the ""-as-localhost-alias break other PAM modules?
No, it is local variable for that module.
> In what way does "localhost" or NULL break OPIE?
Look into any pre-PAM code which use OPIE, like login code. Host (rhost)
is only s
"Andrey A. Chernov" writes:
> On Sun, Feb 16, 2003 at 11:01:43 +0100, Dag-Erling Smorgrav wrote:
> > "Andrey A. Chernov" <[EMAIL PROTECTED]> writes:
> > > [...]
> >
> > Please disregard. Andrey does not know what he's talking about and
> > ignores any attempt at explaining what the real issue is
Dag-Erling Smorgrav writes:
> "Andrey A. Chernov" <[EMAIL PROTECTED]> writes:
> > Admins with no /etc/opieaccess AFFECTED!
>
> Admins with no /etc/opieaccess IDIOTS for not running mergemaster!
POLA. We don't want to burn our user/admins.
M
--
Mark Murray
iumop ap!sdn w,I idlaH
To Unsubscribe:
On Sun, Feb 16, 2003 at 12:06:36 +0100, Dag-Erling Smorgrav wrote:
> "Andrey A. Chernov" <[EMAIL PROTECTED]> writes:
> > Admins with no /etc/opieaccess AFFECTED!
>
> Admins with no /etc/opieaccess IDIOTS for not running mergemaster!
First of all, there are many years of existen OPIE administratio
"Andrey A. Chernov" <[EMAIL PROTECTED]> writes:
> But... Nonsense from my side happens only because
> 1) I see the breakage.
> 2) Seen breakage, I try to guess what des means, when he made it,
> having no information from des.
> 3) If I guess it (with no information) incorrectly, it not means
> th
On Sun, Feb 16, 2003 at 11:58:57 +0100, [EMAIL PROTECTED] wrote:
> In message <[EMAIL PROTECTED]>, "Andrey A. Chernov" writes:
> >On Sun, Feb 16, 2003 at 13:27:38 +0300, Andrey A. Chernov wrote:
> >>
> >> Unless you specify exact details of what I ignore, I'll be forced to
> >> treat your reply a
"Andrey A. Chernov" <[EMAIL PROTECTED]> writes:
> Admins with no /etc/opieaccess AFFECTED!
Admins with no /etc/opieaccess IDIOTS for not running mergemaster!
DES
--
Dag-Erling Smorgrav - [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the b
In message <[EMAIL PROTECTED]>, "Andrey A. Chernov" writes:
>On Sun, Feb 16, 2003 at 13:27:38 +0300, Andrey A. Chernov wrote:
>>
>> Unless you specify exact details of what I ignore, I'll be forced to
>> treat your reply as NO REVIEW and commit this changes.
>
>Well, after numerous exchanges of n
On Sun, Feb 16, 2003 at 13:27:38 +0300, Andrey A. Chernov wrote:
>
> Unless you specify exact details of what I ignore, I'll be forced to
> treat your reply as NO REVIEW and commit this changes.
Well, after numerous exchanges of nonsense messages a bit of details comes
from des, so I correct my
On Sun, Feb 16, 2003 at 11:01:43 +0100, Dag-Erling Smorgrav wrote:
> "Andrey A. Chernov" <[EMAIL PROTECTED]> writes:
> > [...]
>
> Please disregard. Andrey does not know what he's talking about and
> ignores any attempt at explaining what the real issue is and what real
> users want.
Unless you
"Andrey A. Chernov" <[EMAIL PROTECTED]> writes:
> [...]
Please disregard. Andrey does not know what he's talking about and
ignores any attempt at explaining what the real issue is and what real
users want.
DES
--
Dag-Erling Smorgrav - [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTE
On Sun, Feb 16, 2003 at 04:41:58 +0300, Andrey A. Chernov wrote:
> des tries to fix OPIE config to add
> additional things here not needed by standard OPIE setup at all.
To be more specific, exact breakage after des is:
Old non-PAMified OPIE variant: localhost allowed even there is no
/etc/opiea
Background: recently des tries to fight problem that OPIE not sense
localhost when called from PAM, but does it incorrectly. Moreover, he
tries to fix OPIE config instead of fixing PAM bug: PAM not follows OPIE
API.
In non-PAM environment OPIE always sense localhost because its host
variable alway
Problems addressed:
1) options.print_lastlog was not honored.
2) "Last login: ..." was printed twice.
3) "copyright" was not printed
4) No newline was before motd.
--- session.c.old Sat Jun 29 17:22:56 2002
+++ session.c Fri Jul 12 05:02:50 2002
@@ -752,14 +752,14 @@
retu
On Wed, Jul 10, 2002 at 19:55:19 +0200, Dag-Erling Smorgrav wrote:
> Neither fix is correct. The correct solution is to remove the kludge
> in auth-passwd.c that tries to use PAM for password authentication.
I agree completely. My fix was quick & dirty workaround only and not
planned as a full
Neither fix is correct. The correct solution is to remove the kludge
in auth-passwd.c that tries to use PAM for password authentication.
DES
--
Dag-Erling Smorgrav - [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
On Wed, Jul 10, 2002 at 09:37:24 -0700, Gregory Neil Shapiro wrote:
> The problem seems to be the addition of opieaccess to the PAM
> configuration.
Not to PAM, but more strictly, to PAMified sshd. Addition of it to other
PAMified programs works as expected.
> With that addition, in -CURRENT,
If I may suggest a fix that will probably make everyone happy...
The problem seems to be the addition of opieaccess to the PAM
configuration. With that addition, in -CURRENT, unless a user creates
/etc/opieaccess and adds explicit "permit" lines, plain text passwords will
not be accepted if OPIE
On Wed, Jul 10, 2002 at 15:37:11 +0200, Dag-Erling Smorgrav wrote:
> making any sense at all. If your config file really disables all
> authentication methods except PasswordAuthentication, then OPIE
> *never* worked for you, because it *cannot* be implemented over the
> SSH PaswordAuthentication
Please review this patch, it fix one reported problem:
--- cc_tools/auto-host.h.bakSat May 18 16:30:17 2002
+++ cc_tools/auto-host.hMon May 27 19:23:37 2002
@@ -87,7 +87,7 @@
/* #undef ssize_t */
/* Define if cpp should also search $prefix/include. */
-#define PREFIX_INCLUDE_DIR
memset() in opiechallenge() really is not needed because it is the very
first thing opielookup() does being entered, i.e. look at this:
int opielookup FUNCTION((opie, principal), struct opie *opie AND char *principal)
{
int i;
memset(opie, 0, sizeof(struct opie));
...
And then the patch inc
This patch implements syscall wrappers for Giant around various
subsystems. It is intended to allow more developers to work on -current,
in the main tree, by allowing the various Giant pushdown works in
progress to be comitted to the main tree.
This patch implements sysctl va
Garance A Drosihn <[EMAIL PROTECTED]> writes:
> At 1:19 PM -0700 4/21/01, Dima Dorfman wrote:
> >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? ;-)
>
Brian Somers <[EMAIL PROTECTED]> wrote:
>> If I'm not mistaken, the size of the environment is already
>> taken into account by the xargs utility (subtracted from
>> ARG_MAX). So this isn't an issue at all.
>
> Unless xargs runs a command with lots of arguments and that command
> increase
> Rodney W. Grimes <[EMAIL PROTECTED]> wrote:
> > > 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
Rodney W. Grimes <[EMAIL PROTECTED]> wrote:
> > 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)
> No rain here, it is ARG_MAX - 2048:
> -s size
> Set the maximum number of bytes for the command line length pro-
> vided to utility. The sum of the length of the utility name and
> the arguments passed to utility (including NULL terminators) will
>
> > > 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-portabl
> On Sun, 22 Apr 2001 13:16:31 +0100, Brian Somers wrote:
> > > On Sat, 21 Apr 2001 20:04:31 +0100, Brian Somers wrote:
> > > > > 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
> > >
At 1:19 PM -0700 4/21/01, Dima Dorfman wrote:
>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? ;-)
Well, I'm in the middle of a massive reorganization of
a
rohrbach@WM:datasink[~]68% tar cf /dev/null src/
rohrbach@WM:datasink[~]69% find src|wc -l
2552
rohrbach@WM:datasink[~]70% du -sk src
32258 src
rohrbach@WM:datasink[~]71% mkdir src2
rohrbach@WM:datasink[~]72% time find src -exec cp {} src2 \;
find src -exec cp {} src2 ; 0.31s user 7.55s sy
Brian Somers([EMAIL PROTECTED])@2001.04.20 11:29:15 +:
> find something | xargs cp {} target_directory
>
> or
>
> find something | xargs -i '[]' cp '[]' target_directory
>
or
find something -exec cp {} target_directory \;
from find(1):
-exec utility [argument ...];
True
On Sun, 22 Apr 2001 13:16:31 +0100, Brian Somers wrote:
> > On Sat, 21 Apr 2001 20:04:31 +0100, Brian Somers wrote:
> > > > 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
> > > > techn
On Sat, 21 Apr 2001 20:04:31 +0100, Brian Somers wrote:
> > 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.
>
> And I
> On Sat, 21 Apr 2001 20:04:31 +0100, Brian Somers wrote:
> > > 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.
>
> 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 se
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 '[]' :-).
> 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 diff
> 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 München
> Any opinions expr
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 e
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
> 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 change
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 xarg
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
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 does
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/des
> 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 t
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 z
> 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.
And I'm still waiting to see those well known techniques.
> --
> 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 trie
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 *sh
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 tw
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
> 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 butti
On Sat, 21 Apr 2001 10:52:05 -0400, Alexander Kabaev wrote:
> > 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 i
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
exten
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
>
> W
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/
> don
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
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:
> > 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 an
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 dest
> 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
> 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.
>
> 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 simp
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
>
> 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
I like this version of the patch!! It's much much cleaner than
hacking up cp or xargs, it even follows th
[ attempting to consolidate two identical threads into one ]
Brian Somers <[EMAIL PROTECTED]> writes:
> I agree - the script idea doesn't seem right.
>
> If {} isn't allowed to implicitly mean ``all the arguments that'll
> fit'', then I'd vote for using -i (a version that does full grouping)
>
>
> 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
Jens Schweikhardt wrote:
> 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.
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.
Regards,
Jens
--
Jens Schwei
< said:
> '-y[replstr]' (no blank after -y).
Prohibited by POSIX. The `xargs' utility ``shall'' follow the Utility
Syntax Guidelines.
> so I don't know how we go about adding options to it.
POSIX is clear on this issue: the implementation may add any options
it wishes, provided that those opt
Dima Dorfman wrote:
> Garance A Drosihn <[EMAIL PROTECTED]> writes:
> > Or maybe something to indicate where the list of arguments
> > should go in a command. Hrm. Let's say '-Y replstr' or
> > '-y[replstr]' (no blank after -y). If no [replstr] is
> > given on -y, it defaults to the two charac
1 - 100 of 160 matches
Mail list logo
