Jim Meyering schrieb:
> Pádraig Brady <[EMAIL PROTECTED]> wrote:
>
>> Thomas Guettler wrote:
>>
>>> Thank you for being interested. I wrote a patch which makes the slash
>>> optional:
>>>
>>> src/du --help:
>>> ...
>>> -z, --dir-with-slash append a slash to directories.
>>>
>> I
Hi,
I'm planing to make the following change in coreutils
so that autoconf can then use the exact same GNUmakefile.
The only difference for autoconf would be that it would
also require a new file, GNUmakefile.cfg, with this content:
--
# Build with our own versions of these to
Jim Meyering <[EMAIL PROTECTED]> wrote:
> I'm planing to make the following change in coreutils
> so that autoconf can then use the exact same GNUmakefile.
>
> The only difference for autoconf would be that it would
> also require a new file, GNUmakefile.cfg, with this content:
> --
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Jim Meyering on 3/12/2008 6:20 AM:
|
| Here it is:
| (NB: here I've changed the -include line to specify
| "$(srcdir)/GNUmakefile.cfg", for VPATH builds)
$(srcdir) isn't defined until after Makefile is included...
| +-include $(srcdir)/
Eric Blake <[EMAIL PROTECTED]> wrote:
> According to Jim Meyering on 3/12/2008 6:20 AM:
> |
> | Here it is:
> | (NB: here I've changed the -include line to specify
> | "$(srcdir)/GNUmakefile.cfg", for VPATH builds)
>
> $(srcdir) isn't defined until after Makefile is included...
You're right. Than
Hello, thanks for your response,
Bob Proulx a écrit :
seb_kramm wrote:
I have search about an hour on how to tell 'cut' to use space as input
delimiter, finally found out alone ! Below is the question I was about to
post, and the solution. I suggest adding this "trick" to the FAQ, or even
to
seb_kramm <[EMAIL PROTECTED]> writes:
> Ah. Is that a problem ? I mean, when I talk about the space character as a
> field-separator, to me, it's the same if there is 1 or 2 or more
> spaces. Like in a source code, it doesn't matter how much spaces or tabs
> there are.
In python, for example, lea
seb_kramm wrote:
> Ah. Is that a problem ? I mean, when I talk about the space character as a
> field-separator, to me, it's the same if there is 1 or 2 or more spaces.
Yes. That seems to be the problem here.
> Like in a source code, it doesn't matter how much spaces or tabs there are.
Ah...
Andreas Schwab wrote:
> seb_kramm writes:
> > Ah. Is that a problem ? I mean, when I talk about the space character as a
> > field-separator, to me, it's the same if there is 1 or 2 or more
> > spaces. Like in a source code, it doesn't matter how much spaces or tabs
> > there are.
>
> In python, f
Jim Meyering [mailto:[EMAIL PROTECTED] wrote:
> "PHILIPP, Axel, Dr." <[EMAIL PROTECTED]> wrote:
> > Changes are:
> > (i) change mode before ownership if non-root user specifies preserve
> > ownership.
> > (ii) do not transfer special bits if preserve mode is
> specified without
> > preserve owner.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
[adding gnulib]
According to Jim Meyering on 3/12/2008 5:39 AM:
| Hi,
Hi Jim, Simon, others,
|
| I'm planing to make the following change in coreutils
| so that autoconf can then use the exact same GNUmakefile.
Hmm. I was about to try to add the
Try using echo to output the string '-e' or '-E' or '-n' literally. You
can't. Furthermore try executing `echo -e [-eEn]...`. Nothing but a
blank line.
The patch below utilizes a familiar technique (used, e.g., in grep) to
escape arguments; however, admittedly it can be rendered more elegan
I left out some curly braces. Here's the working patch:
=== BEGIN PATCH ===
--- echo.c.orig2008-03-13 01:59:22.0 -0400
+++ echo.c2008-03-13 01:59:37.0 -0400
@@ -145,6 +145,7 @@
parse_long_options (argc, argv, PROGRAM_NAME, PACKAGE_NAME, VERSION,
usage, A
13 matches
Mail list logo
