> Date: 6 Nov 2000 16:56:30 -0600
> From: Reid Madsen <[EMAIL PROTECTED]>
>
> I also thought about using the _POSIX_ARG_MAX and ARG_MAX symbols to determine
> when the xargs approach was really needed. If the command line is within
> limits, then
>
> $(xargs cmd, list)
>
> w
> I will look at it. It would be nice if it were generalized to Windows
> platforms, where people occasionally ask for what passes for here-doc
> support for the Windows command.com.
This won't be clean, everyone is asking for something vaguely similar
but implemented in a completely different
> Date: Mon, 6 Nov 2000 17:45:45 -0500
> From: "Paul D. Smith" <[EMAIL PROTECTED]>
>
> %% Reid Madsen <[EMAIL PROTECTED]> writes:
>
> >> Also, it might be a Good Thing to try to integrate the temporary file
> >> with the ^C handling in GNU make so that the temp file was removed even
%% Reid Madsen <[EMAIL PROTECTED]> writes:
>> Also, it might be a Good Thing to try to integrate the temporary file
>> with the ^C handling in GNU make so that the temp file was removed even
>> if the user used ^C. And, any creation of temp files needs to be
>> hardened to avoid DOS, etc
> Date: Mon, 6 Nov 2000 17:34:38 -0500
> From: "Paul D. Smith" <[EMAIL PROTECTED]>
>
> %% Regarding Re: GNU enhancement -- $(xargs cmd, list); you wrote:
>
> rm> So, you guys up to adding this in the next release? Or will I
> rm> always have to go back and hack it in myself?
>
>
%% Regarding Re: GNU enhancement -- $(xargs cmd, list); you wrote:
rm> So, you guys up to adding this in the next release? Or will I
rm> always have to go back and hack it in myself?
I will look at it. It would be nice if it were generalized to Windows
platforms, where people occasionally
Thanks for your comments...
We've now gone live with the following changes:
static int xargs_file_count = 0;
static char *
func_xargs(o, argv, funcname)
char *o;
char **argv;
const char* funcname;
{
char filename[256];
FILE* f
Gotcha... more portable.
Reid
> From: "Howard Chu" <[EMAIL PROTECTED]>
> Date: Mon, 6 Nov 2000 13:24:40 -0800
> MIME-Version: 1.0
> Content-Type: text/plain;
> charset="iso-8859-1"
> Content-Transfer-Encoding: 7bit
> X-Priority: 3 (Normal)
> X-MSMail-Priority: Normal
> X-Mailer:
Try "xargs command < tmpfile" instead of "cat tmpfile | xargs command" ...
-- Howard Chu
Chief Architect, Symas Corp. Director, Highland Sun
http://www.symas.com http://highlandsun.com/hyc
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED
Well, I've got a prototype up and running and IMHO it's quite cool.
All changes are in function.c. The net of the changes are:
* Added support for:
$(xargs command, list)
which is expanded to:
cat | xargs command; rm -f
* Added 'func_xargs' as shown below:
static i
> Date: Mon, 6 Nov 2000 10:54:13 -0500
> From: "Paul D. Smith" <[EMAIL PROTECTED]>
>
> This can't work; remember that make passes each line whole to a
> subshell. If the line is too long for any individual shell invocation,
> then chopping it up and sending it to one subshell will certain
Your xargs feature sounds useful, but your bug example is flawed. Remember
that the
shell does all wildcard expansion in Unix. For most problem cases, your
echo *.xx | xargs command
commandline would fail for the same reason that
command *.xx
would fail. Just wanted to make sure the actual probl
%% Reid Madsen <[EMAIL PROTECTED]> writes:
rm> Consider the following:
rm> ARGS=$(wildcard *.xx)
rm> target:
rm> command $(ARGS)
rm> The above only works if the length of the resulting command line
rm> is within system limits. From the shell, you can solve this by:
Consider the following:
ARGS=$(wildcard *.xx)
target:
command $(ARGS)
The above only works if the length of the resulting command line is within
system limits. From the shell, you can solve this by:
echo *.xx | xargs command
But the above does not work in make be
%% "Edouard G. Parmelan" <[EMAIL PROTECTED]> writes:
egp> I have made a patch for that on 31 July 1999. FSF have received my
egp> assignment since few months. Did you said that my patch will go
egp> directly to /dev/null ?
I have it already, and I plan on looking at it for the next major
Paul D. Smith wrote:
> %% [EMAIL PROTECTED] writes:
>
> ws> @F does not work (Linux Intel x86 only).
> ws> (No problems on other platforms with the same or older make versions)
>
> Again, I find this very hard to believe. Are you sure you're using GNU
> make on those other platforms? I si
16 matches
Mail list logo