Re: Feature Request: du --dir-with-slash
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 don't think it's worth an option TBH. >> How about we do this iff POSIXLY_CORRECT environment variable is not set? >> > > Hi Pádraig, > > I don't like to encourage the use of POSIXLY_CORRECT, > and fear such a change might end up doing that. > Me, too. I want to add slashes only if the user explicitly asks for it. > Besides, the cost[*]/benefit ratio of adding trailing slashes by > default looks way too high. > > I agree. > I'm very dubious about adding this as an option. > Do you really think an option is warranted for this, > considering you can already get the desired behavior > with a small wrapper, as I demonstrated: > > Since old versions of du didn't support --files-from I already wrote a small implementation in python some time ago. But it would be nice to have it in GNU du. > By the way, someone's mail server (Thomas', I think) refused mail from my > IP address last time, and I'm not bothering to reroute to accommodate it. > I forwarded your complain to our provider. I am sorry. If you think that a one letter option is not worth it, I am happy with only a long option, too. Thomas -- Thomas Güttler, http://www.tbz-pariv.de/ Bernsdorfer Str. 210-212, 09126 Chemnitz, Tel.: 0371/5347-917 TBZ-PARIV GmbH Geschäftsführer: Dr. Reiner Wohlgemuth Sitz der Gesellschaft: Chemnitz Registergericht: Chemnitz HRB 8543 ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
[PATCH] Generalize GNUmakefile, ...
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 tools, when possible. export PATH = $(shell echo "`pwd`/tests:$$PATH") # Remove the autoreconf-provided INSTALL, so that we regenerate it. _autoreconf = autoreconf -i -v && rm -f INSTALL -- Thus, for autoconf, making this change would induce no functional difference. (for coreutils, it also fixes a tiny bug: it would fail to remove $(srcdir)/autom4te.cache in VPATH builds) I'll send an autoconf patch separately. Here's the coreutils change: === Generalize GNUmakefile, ... ...so that it can be used unmodified by autoconf. * GNUmakefile: Include optional file, GNUmakefile.cfg. Autoconf will use this to override _autoreconf and to export PATH. (_autoreconf): Define. (_dummy): cd to $(srcdir) before removing autom4te.cache. Signed-off-by: Jim Meyering <[EMAIL PROTECTED]> --- GNUmakefile |9 ++--- 1 files changed, 6 insertions(+), 3 deletions(-) diff --git a/GNUmakefile b/GNUmakefile index 719cfad..9404222 100644 --- a/GNUmakefile +++ b/GNUmakefile @@ -38,12 +38,15 @@ ifeq ($(_have-Makefile),yes) # Make tar archive easier to reproduce. export TAR_OPTIONS = --owner=0 --group=0 --numeric-owner +# Some projects override e.g., _autoreconf here. +-include GNUmakefile.cfg + include Makefile -_curr-ver := $(VERSION) +_autoreconf ?= autoreconf # Ensure that $(VERSION) is up to date for dist-related targets, but not -# for others: running autoreconf and recompiling everything isn't cheap. +# for others: rerunning autoreconf and recompiling everything isn't cheap. ifeq (0,$(MAKELEVEL)) _is-dist-target = $(filter-out %clean, \ $(filter dist% alpha beta major,$(MAKECMDGOALS))) @@ -52,7 +55,7 @@ ifeq (0,$(MAKELEVEL)) $(srcdir)/.tarball-version) ifneq ($(_curr-ver),$(VERSION)) $(info INFO: running autoreconf for new version string: $(_curr-ver)) - _dummy := $(shell rm -rf autom4te.cache; (cd $(srcdir) && autoreconf)) + _dummy := $(shell cd $(srcdir) && rm -rf autom4te.cache && $(_autoreconf))) endif endif endif -- 1.5.4.4.482.g5f904 ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [PATCH] Generalize GNUmakefile, ...
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: > -- > # Build with our own versions of these tools, when possible. > export PATH = $(shell echo "`pwd`/tests:$$PATH") > > # Remove the autoreconf-provided INSTALL, so that we regenerate it. > _autoreconf = autoreconf -i -v && rm -f INSTALL > -- > > Thus, for autoconf, making this change would induce no functional difference. > (for coreutils, it also fixes a tiny bug: it would fail to remove > $(srcdir)/autom4te.cache in VPATH builds) > > I'll send an autoconf patch separately. Here it is: (NB: here I've changed the -include line to specify "$(srcdir)/GNUmakefile.cfg", for VPATH builds) Use a more general GNUmakefile. * GNUmakefile: Sync from coreutils. * Makefile.am (EXTRA_DIST): Add GNUmakefile.cfg. * GNUmakefile.cfg: New file. Signed-off-by: Jim Meyering <[EMAIL PROTECTED]> --- GNUmakefile | 15 ++- GNUmakefile.cfg |7 +++ Makefile.am |3 ++- 3 files changed, 15 insertions(+), 10 deletions(-) create mode 100644 GNUmakefile.cfg diff --git a/GNUmakefile b/GNUmakefile index e22015b..3ea4cf8 100644 --- a/GNUmakefile +++ b/GNUmakefile @@ -38,14 +38,15 @@ ifeq ($(_have-Makefile),yes) # Make tar archive easier to reproduce. export TAR_OPTIONS = --owner=0 --group=0 --numeric-owner -# Build with our own versions of these tools, when possible. -export PATH = $(shell echo "`pwd`/tests:$$PATH") +# Some projects override e.g., _autoreconf here. +-include $(srcdir)/GNUmakefile.cfg include Makefile +_autoreconf ?= autoreconf + # Ensure that $(VERSION) is up to date for dist-related targets, but not -# for others: rerunning autoconf and recompiling everything isn't cheap. -# Remove the autoreconf-provided INSTALL, so that we regenerate it. +# for others: rerunning autoreconf and recompiling everything isn't cheap. ifeq (0,$(MAKELEVEL)) _is-dist-target = $(filter-out %clean, \ $(filter dist% alpha beta major,$(MAKECMDGOALS))) @@ -54,11 +55,7 @@ ifeq (0,$(MAKELEVEL)) $(srcdir)/.tarball-version) ifneq ($(_curr-ver),$(VERSION)) $(info INFO: running autoreconf for new version string: $(_curr-ver)) - _dummy := $(shell\ - cd $(srcdir)\ - && rm -rf autom4te.cache \ - && autoreconf -i -v \ - && rm -f INSTALL) + _dummy := $(shell cd $(srcdir) && rm -rf autom4te.cache && $(_autoreconf))) endif endif endif diff --git a/GNUmakefile.cfg b/GNUmakefile.cfg new file mode 100644 index 000..be213f4 --- /dev/null +++ b/GNUmakefile.cfg @@ -0,0 +1,7 @@ +# This file is '-include'd into GNUmakefile. + +# Build with our own versions of these tools, when possible. +export PATH = $(shell echo "`pwd`/tests:$$PATH") + +# Remove the autoreconf-provided INSTALL, so that we regenerate it. +_autoreconf = autoreconf -i -v && rm -f INSTALL diff --git a/Makefile.am b/Makefile.am index 57e7509..d2eed2e 100644 --- a/Makefile.am +++ b/Makefile.am @@ -25,7 +25,8 @@ ACLOCAL_AMFLAGS = -I m4 EXTRA_DIST = ChangeLog.0 ChangeLog.1 ChangeLog.2 \ BUGS \ -GNUmakefile Makefile.maint Makefile.cfg \ +GNUmakefile GNUmakefile.cfg +Makefile.maint Makefile.cfg \ build-aux/git-version-gen \ config/announce-gen config/prev-version.txt -- 1.5.4.4.482.g5f904 ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [PATCH] Generalize GNUmakefile, ...
-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)/GNUmakefile.cfg | | include Makefile But once you fix that, it looks okay to me to install. - -- Don't work too hard, make some time for fun as well! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkfXzoUACgkQ84KuGfSFAYB4hQCePm4sq3F3XZnw05A1I/IvBvJ8 2swAn1Y+ufRS6I/LUZgbSOQMKYhowrLc =d4Cr -END PGP SIGNATURE- ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [PATCH] Generalize GNUmakefile, ...
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. Thanks. Pesky VPATH users ;-) > | +-include $(srcdir)/GNUmakefile.cfg > | > | include Makefile > > But once you fix that, it looks okay to me to install. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [ADD TO FAQ] : cut : using space as input delimiter
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 the manual. I will add something to the FAQ since this has come up a few times. Thanks for the future users I have a generated numeric data file, to be plotted using gnuplot. The fields are separated with spaces. Before plotting, I need to do some basic line/text processing, using 'cut' and 'join'. 'cut' isn't the best tool to cut fields. 'awk' is better. Yes, even though I am a windows user ;-), I heard about awk, but I needed something quick, and didn't want to spent time on learning the syntax. My needs seemed simple. But I'll take a look at awk for sure as soon as I have some time. # data 1 1.1 1.3 1.4 2 1.2 1.5 1.6 ... Unfortunatly, I can't manage to use the space character as input separator for 'cut'. I read the coreutils FAQ, the manual (5.3.0), p.43, but I understand (and tried) that this is not possible. The problem is that the fields are separated by TWO spaces not one space. This means that in the above there are SEVEN fields not four. Field 2 that you want to cut is an empty field. You would want field 3 instead. 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. Quote the whole 'd' option: Yes. Or quote just the delimiter. Either way is exactly the same to [...] Another solution is using 'unexpand' to replace spaces by tabs Yes. 'cut' was really designed to work on TAB separated fields. Using 'unexpand' to get to TAB separated fields is in the spirit of the way cut is designed to work. Today if 'cut' were designed again it would probably be using a comma by default because .csv files are more common today than TAB separate fields. I would be inclined to go this way because then things are more obvious because the delimiters are visible. I agree, the only reason I used space as a delimitor is that it is the default separator for gnuplot, and that I was to lazy to find the command to tell it to use another separator. But I really better like .csv style. Sebastien Kramm ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [ADD TO FAQ] : cut : using space as input delimiter
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, leading space is significant. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [ADD TO FAQ] : cut : using space as input delimiter
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... But this isn't source code. Source code is stream oriented with inband control. Cut works with data files. Compressing runs of multiple delimiters together would make it impossible to handle empty fields. This is the same as for csv files. The file format is in design an X-Y grid of rows and columns of which some cells may be empty. Bob ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [ADD TO FAQ] : cut : using space as input delimiter
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, for example, leading space is significant. Yes but in Python the design of using whitespace for control has been its most controversial aspect. Bob ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
AW: cp -p does not work if normal users are allowed to chown files
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. Since this is a deviation from current
> behaviour I made
> > it dependent on (the new variable) force_suid_transfer=false
> > Rationale: let cp --preserve=mode,time behave for non-root users on
> > systems with unrestricted chown behave like cp -p on systems with
> > restricted chown.
> > (iii) added some more caution with respect to temporary permissions.
>
> Thanks for the patch.
> However my first reaction (not even reading it) is that it looks
> far too big to be acceptable, considering it would change an already
If your main concern is the size of the patch I have 2 comments.
1. The first attempt followed a strict "never use gotos" philisophy,
which led to code doubling.I have changed that, the new patch is much
smaller.
2. A nearly identical change has to be applied in 3 functions:
re_protect,
copy_reg and copy_internal. This puts a lower bound on the size of the
patch.
The modified patch is appended.
> tricky and sensitive part of cp -- and all that, solely for
> the benefit
> of the very few systems on which regular users can chown files.
> That seems to put the risk/benefit ratio off the scale.
And I want to draw your attention to the other two changes proposed,
which are not limited to the unrestricted chown case.
1. The permissions of already existing destinations are trimmed before
the overwriting begins, not just before a chown.
2. POSIX cp will never transfer suid/sgid bits to another user.
coreutils cp currently does it with --preserve=mode. I believe that is
dangerous, especially in a recursive copy, and therefore i propose
to change that behaviour - at least unless the transfer of suid/sgid
bits is explicitely requested.
>
> Here's a possibility:
> You can maintain this as a separate patch (or better, as a
> git branch --
I do not believe that a public code fork is a good solution.
> [...]
> Jim
>
Mit freundlichen Gruessen / Best Regards
Axel PHILIPP Geb. 044/557
Dr. rer. nat., Dipl. Phys.
MTU Aero Engines GmbH
Informationswirtschaft/Entwicklungssysteme (FIE)
Information Management/Engineering Systems (FIE)
Dachauer Str. 665
80995 Muenchen
Germany
Tel +49 (0)89 1489-4715
Fax +49 (0)89 1489-97533
mailto:[EMAIL PROTECTED]
--- coreutils-6.10/src/copy.h.ori 2008-01-05 23:58:25.0
+0100
+++ coreutils-6.10/src/copy.h 2008-03-11 15:08:22.491546400 +0100
@@ -142,2 +142,5 @@
bool preserve_timestamps;
+ /* additional entries needed for "unrestricted chown" fix */
+ uid_t cp_uid;
+ bool force_suid_transfer; /* used for sgid as well */
--- coreutils-6.10/src/cp.c.ori 2008-01-11 12:19:53.0 +0100
+++ coreutils-6.10/src/cp.c 2008-03-11 15:24:15.434264400 +0100
@@ -289,2 +289,5 @@
char *src_name; /* The source name in `dst_name'. */
+ bool mode_changed_first;/* if mode has to be changed before
ownership
+ in case of unrestricted chown */
+ mode_t src_mode;
@@ -316,4 +319,14 @@
+ /* "unrestricted chown" fix. chmod before chown if necessary */
+ mode_changed_first=false;
if (x->preserve_ownership)
{
+ if ( x->cp_uid != 0 && p->st.st_uid != x->cp_uid )
+ {
+ src_mode = p->st.st_mode & ~(S_ISUID | S_ISGID );
+ /* the following chown will clear these bits anyway */
+ mode_changed_first=true;
+ goto change_mode_first;
+ }
+change_owner:
if (lchown (dst_name, p->st.st_uid, p->st.st_gid) != 0)
@@ -332,5 +345,10 @@
+ if ( !mode_changed_first) {
+ src_mode=p->st.st_mode;
+ if ( ! x->preserve_ownership && x->cp_uid != p->st.st_uid &&
!x->force_suid_transfer )
+src_mode &= ~(S_ISUID | S_ISGID );
+change_mode_first:
if (x->preserve_mode)
{
- if (copy_acl (src_name, -1, dst_name, -1, p->st.st_mode) != 0)
+ if (copy_acl (src_name, -1, dst_name, -1, src_mode) != 0)
return false;
@@ -339,3 +357,3 @@
{
- if (lchmod (dst_name, p->st.st_mode) != 0)
+ if (lchmod (dst_name, src_mode) != 0)
{
@@ -346,3 +364,4 @@
}
-
+if (mode_changed_first) goto change_owner;
+ }
dst_name[p->slash_offset] = '/';
@@ -465,3 +484,8 @@
decide what to do with S_ISUID | S_ISGID | S_ISVTX. */
+ /* i prefer to be on the save side, so clear S_ISGID */
mkdir_mode = src_mode & CHMOD_MODE_BITS &
~omitted_permissions;
+ if ( !x->preserve_ownership && !x->force_suid_transfer ||
+ !x->preserve_mode )
+ mkdir_mode &= ~S_ISGID;
+
if (mkdir (dir, mkdir_mode) != 0)
@@ -783,2 +807,6 @@
x->mode = 0;
+ /* "unrestricted chown" fix */
+ x->cp_uid=
Re: [PATCH] Generalize GNUmakefile, ...
-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 latest coreutils/autoconf/m4 GNUmakefile to gnulib, to make it easier to share. But gnulib already provides build-aux/GNUmakefile as part of the maintainer-makefile module, added by Simon a while ago (and originally borrowed from coreutils). Differences between the two: the gnulib version uses maint.mk rather than Makefile.maint as its file of maintainer-specific rules, and includes maint.mk as part of the module the gnulib version makes the existence of maint-cfg.mk (cf. Makefile.cfg) option, rather than required the coreutils version uses build-aux/git-version-gen to form nice intra-release version numbering, while minimizing when a full autoreconf must be performed to pick up the latest version number the gnulib version uses '.DEFAULT_GOAL:=' rather than 'all:' when Makefile is not present to trigger the error message about needing to run configure in all cases, rather than just a few the coreutils version conditionally uses AC_CONFIG_LINKS in configure.ac, along with EXTRA_DIST and distclean-local in Makefile.am, to support GNUmakefile usage even in VPATH builds Is it worth trying to re-merge these two approaches, since they forked from a common ancestor? At this point, I'm thinking of having two modules, one that distributes just GNUmakefile, and leaving maintainer-makefile to depend on the new module and just provide maint.mk. ~ The new module could then add the configure.ac and Makefile.am rules for VPATH builds. We'd have to figure out how to choose between the names maint.mk vs. Makefile.maint. And since GNUmakefile is placed in build-aux by gnulib-tool, each package that uses it would need to either use bootstrap to move it to the top-level directory, or commit a symlink in the top-level directory that points to where gnulib-tool will dump it in build-aux. Ultimately, a tarball must have GNUmakefile in the top-level directory if it is going to issue the helpful reminder to run configure for users that have GNU make and just unpacked the tarball. - -- Don't work too hard, make some time for fun as well! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkfYo5YACgkQ84KuGfSFAYBmvACgisklluWTsj8Z0KDqSkzF0koN R8oAn0PiWBaQuXssfXHd94JNyPDnZjBb =g2MD -END PGP SIGNATURE- ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
[PATCH] Fix bug when attempting to echo special sequences literally.
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 elegant. :)
This was patched against the 03/12/08 coreutils GIT version; however,
echo.c doesn't appear to have changed substantively for years.
=== BEGIN PATCH ===
--- echo.c.orig2008-03-13 01:33:08.0 -0400
+++ echo.c2008-03-13 01:35:04.0 -0400
@@ -145,6 +145,7 @@
parse_long_options (argc, argv, PROGRAM_NAME, PACKAGE_NAME, VERSION,
usage, AUTHORS, (char const *) NULL);
+ char first=1;
--argc;
++argv;
@@ -154,6 +155,14 @@
char const *temp = argv[0] + 1;
size_t i;
+if (first == 1) {
+ first = 0;
+ if (temp[0] == '-')
+--argc;
+++argv;
+goto just_echo;
+}
+
/* If it appears that we are handling options, then make sure that
all of the options specified are actually valid. Otherwise, the
string should just be echoed. */
=== END PATCH ===
Regards,
- A.
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [PATCH] Fix bug when attempting to echo special sequences literally. -- [RESUBMISSION]
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, AUTHORS, (char const *) NULL);
+ char first=1;
--argc;
++argv;
@@ -154,6 +155,15 @@
char const *temp = argv[0] + 1;
size_t i;
+if (first == 1) {
+ first = 0;
+ if (temp[0] == '-') {
+--argc;
+++argv;
+goto just_echo;
+ }
+}
+
/* If it appears that we are handling options, then make sure that
all of the options specified are actually valid. Otherwise, the
string should just be echoed. */
=== END PATCH ===
Adam Rosenwald wrote:
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 elegant. :)
This was patched against the 03/12/08 coreutils GIT version; however,
echo.c doesn't appear to have changed substantively for years.
=== BEGIN PATCH ===
--- echo.c.orig2008-03-13 01:33:08.0 -0400
+++ echo.c2008-03-13 01:35:04.0 -0400
@@ -145,6 +145,7 @@
parse_long_options (argc, argv, PROGRAM_NAME, PACKAGE_NAME, VERSION,
usage, AUTHORS, (char const *) NULL);
+ char first=1;
--argc;
++argv;
@@ -154,6 +155,14 @@
char const *temp = argv[0] + 1;
size_t i;
+if (first == 1) {
+ first = 0;
+ if (temp[0] == '-')
+--argc;
+++argv;
+goto just_echo;
+}
+
/* If it appears that we are handling options, then make sure that
all of the options specified are actually valid. Otherwise, the
string should just be echoed. */
=== END PATCH ===
Regards,
- A.
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
