[PATCH] tests: add a test of cp --preserve=links
Just add a test... Before, we tested -L only with symlinked a and b (the primary case, since -L makes cp dereference symlinks). This also tests with them hard-linked. From 3cc091a2afe244d222156e1d62e73b3fe612b2d7 Mon Sep 17 00:00:00 2001 From: Jim Meyering [EMAIL PROTECTED] Date: Wed, 19 Nov 2008 19:16:34 +0100 Subject: [PATCH] tests: add a test of cp --preserve=links * tests/cp/link-preserve: Add a case and comments. --- tests/cp/link-preserve | 18 -- 1 files changed, 12 insertions(+), 6 deletions(-) diff --git a/tests/cp/link-preserve b/tests/cp/link-preserve index 309c051..fbde3ff 100755 --- a/tests/cp/link-preserve +++ b/tests/cp/link-preserve @@ -48,9 +48,17 @@ b_inode=`ls -i c/b|sed 's,c/.*,,'` test $a_inode = $b_inode || fail=1 # -- -rm -rf a b c d -mkdir d -(cd d; touch a; ln -s a b) +# Ensure that -L makes cp follow the b-a symlink +# and translates to hard-linked a and b in the destination dir. +rm -rf a b c d; mkdir d; (cd d; touch a; ln -s a b) +cp --preserve=links -R -L d c +a_inode=`ls -i c/a|sed 's,c/.*,,'` +b_inode=`ls -i c/b|sed 's,c/.*,,'` +test $a_inode = $b_inode || fail=1 +# -- + +# Same as above, but starting with a/b hard linked. +rm -rf a b c d; mkdir d; (cd d; touch a; ln a b) cp --preserve=links -R -L d c a_inode=`ls -i c/a|sed 's,c/.*,,'` b_inode=`ls -i c/b|sed 's,c/.*,,'` @@ -58,9 +66,7 @@ test $a_inode = $b_inode || fail=1 # -- # Ensure that --no-preserve=links works. -rm -rf a b c d -mkdir d -(cd d; touch a; ln a b) +rm -rf a b c d; mkdir d; (cd d; touch a; ln a b) cp -dR --no-preserve=links d c a_inode=`ls -i c/a|sed 's,c/.*,,'` b_inode=`ls -i c/b|sed 's,c/.*,,'` -- 1.6.0.4.1021.g4320 ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Bug#412688: cp -la takes big amounts of memory
Jim Meyering [EMAIL PROTECTED] wrote:
This is following up on http://bugs.debian.org/412688.
I realized that with --preserve=link --link, cp can do much better
on the memory front. It can avoid saving a lot of data that it
normally needs to reconstruct hard-link relationships.
Whereas before this patch, cp -al would use heap space proportional to the
size of the input tree, now it uses minimal (and constant) heap space.
In the first example, (copying 1 empty short-named files, each with
two links and 5k empty directories) the patched cp uses less than 10%
of the space required by the pre-patch version.
Here's an example that demonstrates the improvement:
rm -rf a b e f (mkdir a cd a seq 1 \
| xargs touch seq 10001 15000|xargs mkdir); \
cp -a a b; mkdir e; mv a b e
valgrind --tool=massif --massif-out-file=old -- cp -al e f
rm -rf f
valgrind --tool=massif --massif-out-file=new -- ./cp -al e f
As I'm composing this message, I realize I really should write
a test for this, too. We'll see.
I wrote the test and have just pushed the patch below.
Since it creates 40k files and directories, I've classified
it as expensive, which means it will be skipped unless you set
RUN_EXPENSIVE_TESTS=yes in the environment. It also relies on a working
ulimit -v.
From 3ece0355d52e41a1b079c0c46477a32250278c11 Mon Sep 17 00:00:00 2001
From: Jim Meyering [EMAIL PROTECTED]
Date: Wed, 19 Nov 2008 19:36:45 +0100
Subject: [PATCH] cp: use far less memory in some cases
cp --link was remembering many name,dev,inode triples unnecessarily.
cp was doing the same, even without --link, for every directory in the
source hierarchy, while it can do its job with entries merely for the
command-line arguments. Prompted by a report from Patrick Shoenfeld.
Details http://thread.gmane.org/gmane.comp.gnu.coreutils.bugs/15081.
* src/copy.c (copy_internal): Refrain from remembering
name,dev,inode for most files, when invoked via cp --link.
Record an infloop-avoidance triple for each directory specified
on the command line, not for each directory in the source tree.
Don't record a dir-triple when x-hard_link is set.
* NEWS (Buf fixes): Mention it.
* tests/cp/link-heap: New file. Test for cp's lowered memory usage.
* tests/Makefile.am (TESTS): Add link-heap.
---
NEWS |2 ++
src/copy.c | 36 +---
tests/Makefile.am |1 +
tests/cp/link-heap | 41 +
4 files changed, 65 insertions(+), 15 deletions(-)
create mode 100755 tests/cp/link-heap
diff --git a/NEWS b/NEWS
index cbea67c..360cb4b 100644
--- a/NEWS
+++ b/NEWS
@@ -10,6 +10,8 @@ GNU coreutils NEWS-*-
outline -*-
** Bug fixes
+ cp uses much less memory in some situations
+
seq 9223372036854775807 9223372036854775808 now prints only two numbers
on systems with extended long double support and good library support.
Even with this patch, on some systems, it still produces invalid output,
diff --git a/src/copy.c b/src/copy.c
index bc1b20e..c9c79a1 100644
--- a/src/copy.c
+++ b/src/copy.c
@@ -1411,6 +1411,10 @@ copy_internal (char const *src_name, char const
*dst_name,
we can arrange to create a hard link between the corresponding names
in the destination tree.
+ When using the --link (-l) option, there is no need to take special
+ measures, because (barring race conditions) files that are hard-linked
+ in the source tree will also be hard-linked in the destination tree.
+
Sometimes, when preserving links, we have to record dev/ino even
though st_nlink == 1:
- when in move_mode, since we may be moving a group of N hard-linked
@@ -1429,27 +1433,29 @@ copy_internal (char const *src_name, char const
*dst_name,
- likewise for -L except that it applies to all files, not just
command line arguments.
- Also record directory dev/ino when using --recursive. We'll use that
- info to detect this problem: cp -R dir dir. FIXME-maybe: ideally,
- directory info would be recorded in a separate hash table, since
- such entries are useful only while a single command line hierarchy
- is being copied -- so that separate table could be cleared between
- command line args. Using the same hash table to preserve hard
- links means that it may not be cleared. */
+ Also, with --recursive, record dev/ino of each command-line directory.
+ We'll use that info to detect this problem: cp -R dir dir. */
if (x-move_mode src_sb.st_nlink == 1)
{
earlier_file = src_to_dest_lookup (src_sb.st_ino, src_sb.st_dev);
}
- else if ((x-preserve_links
-(1 src_sb.st_nlink
- || (command_line_arg
-x-dereference == DEREF_COMMAND_LINE_ARGUMENTS)
- || x-dereference == DEREF_ALWAYS))
- || (x-recursive S_ISDIR (src_mode)))
+ else if
Re: Bug#505979: ls output format option
martin f krafft [EMAIL PROTECTED] wrote: Package: coreutils Version: 6.10-6 Severity: wishlist File: /bin/ls I wish ls supported something like ls --format='%n %s %u %t' or somesuch so that I can select which columns I actually want in the output, and still have their width be formatted properly as ls does now. In fact, such an option could probably replace many of the other options, like -g or -s. Then please chime in on the recent upstream thread discussing a proposed patch to do just that: http://thread.gmane.org/gmane.comp.gnu.coreutils.bugs/14977 ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [PATCH]: ls: add --user-format option for user defined format
Pádraig Brady wrote: Ondřej Vašík wrote: Let's do some summary, feel free to add/comment items if you have something not mentioned here: What patched ls --user-format can and upstream find -printf not: 1) colored files by LS_COLORS or automatically if requested 2) could be used simply as ls alias for normal users - as they could still specify additional ls options like time-style, quoting-style, sorting style, blocksize, units and other things without modifying format string 6) Automated column width computation (in find -printf you have to hardcode the column width in %N.NX syntax yourself, otherwise there is no defined human-readable column structure.) I guess points #1, #2, #6 are the most important things, as #1 and #2 makes the output more user friendly and #6 generally readable by human Right. As I see it ls output is tuned for human consumption, while find is tuned for further consumption by other scripts/utils. Exactly - I have the same opinion and I wrote it in the previous email ... and as humans do differ and they could have different wishes about format of output, I would expect something to tune output in ls - without processing through awk/sed/whatever utilities. In my experience I've only needed to tweak output like this to ease the subsequent processing in scripts/utils. I.E. I've never needed it in ls, I'm quite sure that you (and Jim) never needed that option. Otherwise it would had been already implemented. In my case it is slightly different. I never needed that option, but I sometimes wished to have it. For me is ls -l too verbose and other ls formats too simple. I would like to have something like with format colored_name_with_link (owner:group:filetype:octalmode) Human-readable_size - so e.g. bar (bar :root:-:0664) 24K baz (baz :root:-:0664) 100K bazlink - ./baz (root:root:l:0777)5 foo (foo :foo :-:0664) 10K That would be enough for me in most cases (octal form is enough for me, in most cases I don't need ACL char, number of links and mostly not even the time). Now I have to parse things out of very verbose long format (and every user has to parse it). Easy, but I wish to have another choice - and this choice could be --user-format option. I'm not sure it's worth duplicating this in ls (adding a lot of interface for all users to parse and most ignore). You are right, it is a lot of interface for all users to parse. So probably user-format description should be removed from --help completely - and there should be only pointer that format is described in info documentation. Greetings, Ondrej signature.asc Description: Toto je digitálně podepsaná část zprávy ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [PATCH]: chmod - do inform about using different mode than requested with SGID/SUID/sticky bits without permissions to change them
Jim Meyering wrote: Ondřej Vašík [EMAIL PROTECTED] wrote: as reported in https://bugs.launchpad.net/ubuntu/+source/coreutils/+bug/187315 by Aaron Toponce , chmod could display confusing messages when used for SGID/SUID/sticky bits without permissions to change them. e.g. with non-root sudoers user following scenario mkdir tmp;sudo chown .root tmp;ls -ld tmp;chmod -v 2755 tmp;ls -ld tmp; would lead to: drwxrwxr-x 2 Reset root 4096 24. říj 17.33 tmp mode of `tmp' changed to 2755 (rwxr-sr-x) drwxr-xr-x 2 Reset root 4096 24. říj 17.33 tmp So user is informed that sticky bit was set even if it was not. So, rather than trying to fix --changes, I'm leaning towards starting the process to remove it altogether. From chmod, chown, and chgrp. This may seem extreme, until you realize that the option is inherently inaccurate in some cases. And the only way it can be accurate is if PROG --changes ... were to stat each file after operating on it. Of course, I wouldn't do that for real. We'd have to first deprecate the targeted options, making any use provoke a warning, and then -- years later -- un-document and finally, remove them. And I probably wouldn't even deprecate --verbose. What do you think? Throwing out --changes should be ok, if user wants to be informed, he can parse verbose output easily and common case is to use it without verbose mode at all. Anyway --verbose output is affected by this issue as well, so I would prefer to 1) depricate --changes option as it could be substituted by --verbose and grep 2) fix the verbose output to show correct output in every case where it is possible. E.g. if the stat fails, it should inform the user that the mode/owner/whatever is unknown. E.g. SGID bit case or stat failed is the thing where user should be informed in verbose mode about something unusual. Greetings, Ondrej signature.asc Description: Toto je digitálně podepsaná část zprávy ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [PATCH] Add getlimits utility for use in tests
Pádraig Brady wrote:
First pass of tool to be used in test scripts
internal to the coreutils project.
Take 2. Previous one added erroneous '-' chars to
output depending on what was in memory.
From 31bf300f0ff2ab5b786bd6951e30a47e3c2db08c Mon Sep 17 00:00:00 2001
From: =?utf-8?q?P=C3=A1draig=20Brady?= [EMAIL PROTECTED]
Date: Thu, 20 Nov 2008 11:02:15 +
Subject: [PATCH] Add getlimits utility for use in tests
* src/getlimits.c: A utility to print
platform dependents limits in a format
suitable for use in shell scripts.
* src/Makefile.am: Add getlimits to list
of utilities to build but not install
---
src/Makefile.am |2 +-
src/getlimits.c | 186 +++
2 files changed, 187 insertions(+), 1 deletions(-)
create mode 100644 src/getlimits.c
diff --git a/src/Makefile.am b/src/Makefile.am
index 097cc7a..159f3e5 100644
--- a/src/Makefile.am
+++ b/src/Makefile.am
@@ -44,7 +44,7 @@ EXTRA_PROGRAMS = \
bin_PROGRAMS = $(OPTIONAL_BIN_PROGS)
-noinst_PROGRAMS = setuidgid
+noinst_PROGRAMS = setuidgid getlimits
noinst_HEADERS = \
chown-core.h \
diff --git a/src/getlimits.c b/src/getlimits.c
new file mode 100644
index 000..ca5906f
--- /dev/null
+++ b/src/getlimits.c
@@ -0,0 +1,186 @@
+/* getlimits - print various platform dependent limits.
+ Copyright (C) 2008 Free Software Foundation, Inc.
+
+ This program is free software: you can redistribute it and/or modify
+ it under the terms of the GNU General Public License as published by
+ the Free Software Foundation, either version 3 of the License, or
+ (at your option) any later version.
+
+ This program is distributed in the hope that it will be useful,
+ but WITHOUT ANY WARRANTY; without even the implied warranty of
+ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ GNU General Public License for more details.
+
+ You should have received a copy of the GNU General Public License
+ along with this program. If not, see http://www.gnu.org/licenses/. */
+
+/* Written by Pádraig Brady */
+
+#include config.h /* sets _FILE_OFFSET_BITS=64 etc. */
+#include limits.h
+#include stdio.h
+#include stdlib.h
+#include string.h
+#include ctype.h
+#include sys/types.h
+
+#include system.h
+#include error.h
+#include long-options.h
+
+#define PROGRAM_NAME getlimits
+
+#define AUTHORS proper_name_utf8 (Padraig Brady, P\303\241draig Brady)
+
+#ifndef TIME_T_MAX
+# define TIME_T_MAX TYPE_MAXIMUM (time_t)
+#endif
+
+#ifndef TIME_T_MIN
+# define TIME_T_MIN TYPE_MINIMUM (time_t)
+#endif
+
+#ifndef SSIZE_MIN
+# define SSIZE_MIN TYPE_MINIMUM(ssize_t)
+#endif
+
+#ifndef PID_T_MIN
+# define PID_T_MIN TYPE_MINIMUM (pid_t)
+#endif
+
+/* These are not interesting to print.
+ * Instead of these defines it would be nice to be able to do
+ * #ifdef (TYPE##_MIN) in function macro below. */
+# define SIZE_MIN 0
+# define UCHAR_MIN 0
+# define UINT_MIN 0
+# define ULONG_MIN 0
+# define UINTMAX_MIN 0
+# define UID_T_MIN 0
+# define GID_T_MIN 0
+
+static void
+usage (int status)
+{
+ if (status != EXIT_SUCCESS)
+fprintf (stderr, _(Try `%s --help' for more information.\n),
+ program_name);
+ else
+{
+ printf (_(\
+Usage: %s\n\
+),
+ program_name);
+
+ fputs (_(\
+Output platform dependent limits in a format useful for shell scripts.\n\
+\n\
+), stdout);
+ fputs (HELP_OPTION_DESCRIPTION, stdout);
+ fputs (VERSION_OPTION_DESCRIPTION, stdout);
+ emit_bug_reporting_address ();
+}
+ exit (status);
+}
+
+/* Add absolute values of ascii decimal strings.
+ * Strings can have leading spaces.
+ * If any string has a '-' it's preserved in the output:
+ * I.E.
+ *1 + 1 - 2
+ * -1 + -1 - -2
+ * -1 + 1 - -2
+ *1 + -1 - -2
+ */
+static char*
+decimal_ascii_add(const char* str1, const char* str2)
+{
+ int len1=strlen(str1);
+ int len2=strlen(str2);
+ int rlen=MAX(len1, len2)+3; /* space for extra digit or sign + NUL */
+ char* result = xmalloc(rlen);
+ char* rp=result+rlen-1;
+ const char* d1=str1+len1-1;
+ const char* d2=str2+len2-1;
+ int carry = 0;
+ *rp = '\0';
+
+ while (1)
+{
+ char c1 = (d1str1 ? ' ' : (*d1=='-' ? ' ' : *d1--));
+ char c2 = (d2str2 ? ' ' : (*d2=='-' ? ' ' : *d2--));
+ char t1 = c1 + c2 + carry; /* ASCII digits are BCD */
+ if (!isdigit(c1) !isdigit(c2) !carry)
+break;
+ carry = t1 '0'+'9' || t1 == ' '+'9'+1;
+ t1 += 6 * carry;
+ *--rp = (t1 0x0F) | 0x30; /* top nibble to ASCII */
+}
+ if ((d1=str1 *d1=='-') || (d2=str2 (d2=='-')))
+*--rp = '-';
+
+ if (rp != result)
+memmove(result, rp, rlen-1);
+
+ return result;
+}
+
+int
+main(int argc, char **argv)
+{
+ char limit[64]; /* big enough for 128 bit at least */
+ char* oflow;
+
+ initialize_main (argc, argv);
+ set_program_name (argv[0]);
+ setlocale (LC_ALL, );
+ bindtextdomain (PACKAGE, LOCALEDIR);
+ textdomain (PACKAGE);
+
+ initialize_exit_failure (EXIT_FAILURE);
+
Re: [PATCH]: chmod - do inform about using different mode than requested with SGID/SUID/sticky bits without permissions to change them
Ondřej Vašík [EMAIL PROTECTED] wrote: Jim Meyering wrote: Ondřej Vašík [EMAIL PROTECTED] wrote: as reported in https://bugs.launchpad.net/ubuntu/+source/coreutils/+bug/187315 by Aaron Toponce , chmod could display confusing messages when used for SGID/SUID/sticky bits without permissions to change them. e.g. with non-root sudoers user following scenario mkdir tmp;sudo chown .root tmp;ls -ld tmp;chmod -v 2755 tmp;ls -ld tmp; would lead to: drwxrwxr-x 2 Reset root 4096 24. říj 17.33 tmp mode of `tmp' changed to 2755 (rwxr-sr-x) drwxr-xr-x 2 Reset root 4096 24. říj 17.33 tmp So user is informed that sticky bit was set even if it was not. So, rather than trying to fix --changes, I'm leaning towards starting the process to remove it altogether. From chmod, chown, and chgrp. This may seem extreme, until you realize that the option is inherently inaccurate in some cases. And the only way it can be accurate is if PROG --changes ... were to stat each file after operating on it. Of course, I wouldn't do that for real. We'd have to first deprecate the targeted options, making any use provoke a warning, and then -- years later -- un-document and finally, remove them. And I probably wouldn't even deprecate --verbose. What do you think? Throwing out --changes should be ok, if user wants to be informed, he can parse verbose output easily and common case is to use it without verbose mode at all. Anyway --verbose output is affected by this issue as well, so I would prefer to 1) depricate --changes option as it could be substituted by --verbose and grep 2) fix the verbose output to show correct output in every case where it is possible. E.g. if the stat fails, it should inform the user that the mode/owner/whatever is unknown. E.g. SGID bit case or stat failed is the thing where user should be informed in verbose mode about something unusual. Actually, I was thinking of making --verbose output *less* informative, so that it can be truthful, albeit less informative, without adding extra stat/lstat calls. Sort of like chcon, which says simply changing security context of FILE While I do see the down-side of doing that, it seems better to print less information, with a guarantee of no lies, than to print usually-true messages along with the occasional untruth. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [PATCH] Add getlimits utility for use in tests
Pádraig Brady [EMAIL PROTECTED] wrote:
Pádraig Brady wrote:
First pass of tool to be used in test scripts
internal to the coreutils project.
Take 2. Previous one added erroneous '-' chars to
output depending on what was in memory.
...
+#include ctype.h
Thanks!
Just a few nits...
How about
#include c-ctype.h
and then use c_isdigit instead of isdigit?
Also, please filter it all through indent --no-tabs.
+#include sys/types.h
+
+#include system.h
+#include error.h
+#include long-options.h
+
+#define PROGRAM_NAME getlimits
+
+#define AUTHORS proper_name_utf8 (Padraig Brady, P\303\241draig Brady)
+
+#ifndef TIME_T_MAX
+# define TIME_T_MAX TYPE_MAXIMUM (time_t)
+#endif
+
+#ifndef TIME_T_MIN
+# define TIME_T_MIN TYPE_MINIMUM (time_t)
+#endif
+
+#ifndef SSIZE_MIN
+# define SSIZE_MIN TYPE_MINIMUM(ssize_t)
Use consistent, one-space indentation.
You can use cppi to automate this check.
+#endif
...
+#define print_int(TYPE) \
+ snprintf(limit, sizeof(limit), %PRIuMAX, (uintmax_t)TYPE##_MAX); \
+ if ((oflow = decimal_ascii_add(limit, 1))) { \
in case indent doesn't deal with this, you should:
- put each opening curly brace on a line by itself
- make most of the backslashes line up: it's more readable that way
- add spaces around operators, after ,, and before each opening parenthesis
if ((oflow = decimal_ascii_add (limit, 1))) \
{\
printf (#TYPE_MAX=%s\n, limit); \
...
+ printf(#TYPE_MAX=%s\n, limit); \
+ printf(#TYPE_OFLOW=%s\n, oflow); \
+ free(oflow); \
+ } \
+ if (TYPE##_MIN) { \
+ snprintf(limit, sizeof(limit), %PRIdMAX, (intmax_t)TYPE##_MIN); \
+ if ((oflow = decimal_ascii_add(limit, -1))) { \
+printf(#TYPE_MIN=%s\n, limit); \
+printf(#TYPE_UFLOW=%s\n, oflow); \
+free(oflow); \
+ } \
+ }
+
+ /* Variable sized ints */
+ print_int(CHAR);
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [PATCH] Add getlimits utility for use in tests
Pádraig Brady wrote:
Pádraig Brady wrote:
First pass of tool to be used in test scripts
internal to the coreutils project.
Take 2. Previous one added erroneous '-' chars to
output depending on what was in memory.
Take 3 passes `make syntax-check`
EBUSY,
Pádraig.
From 741e43bb686382f2d9d46ed634d731934235ec59 Mon Sep 17 00:00:00 2001
From: =?utf-8?q?P=C3=A1draig=20Brady?= [EMAIL PROTECTED]
Date: Thu, 20 Nov 2008 11:02:15 +
Subject: [PATCH] Add getlimits utility for use in tests
* src/getlimits.c: A utility to print
platform dependents limits in a format
suitable for use in shell scripts.
* src/Makefile.am: Add getlimits to list
of utilities to build but not install.
Also add it to the list linked with libiconv
po/PORTFILES.in: Add getlimits to translation list.
---
po/POTFILES.in |1 +
src/Makefile.am |4 +-
src/getlimits.c | 181 +++
3 files changed, 185 insertions(+), 1 deletions(-)
create mode 100644 src/getlimits.c
diff --git a/po/POTFILES.in b/po/POTFILES.in
index 8a6e541..9bd8c43 100644
--- a/po/POTFILES.in
+++ b/po/POTFILES.in
@@ -62,6 +62,7 @@ src/factor.c
src/false.c
src/fmt.c
src/fold.c
+src/getlimits.c
src/group-list.c
src/groups.c
src/head.c
diff --git a/src/Makefile.am b/src/Makefile.am
index 097cc7a..a6bc229 100644
--- a/src/Makefile.am
+++ b/src/Makefile.am
@@ -44,7 +44,7 @@ EXTRA_PROGRAMS = \
bin_PROGRAMS = $(OPTIONAL_BIN_PROGS)
-noinst_PROGRAMS = setuidgid
+noinst_PROGRAMS = setuidgid getlimits
noinst_HEADERS = \
chown-core.h \
@@ -82,6 +82,7 @@ LDADD = libver.a ../lib/libcoreutils.a $(LIBINTL) ../lib/libcoreutils.a
cat_LDADD = $(LDADD)
df_LDADD = $(LDADD)
du_LDADD = $(LDADD)
+getlimits_LDADD = $(LDADD)
ptx_LDADD = $(LDADD)
split_LDADD = $(LDADD)
timeout_LDADD = $(LDADD)
@@ -160,6 +161,7 @@ cat_LDADD += $(LIBICONV)
cp_LDADD += $(LIBICONV)
df_LDADD += $(LIBICONV)
du_LDADD += $(LIBICONV)
+getlimits_LDADD += $(LIBICONV)
ptx_LDADD += $(LIBICONV)
split_LDADD += $(LIBICONV)
timeout_LDADD += $(LIBICONV)
diff --git a/src/getlimits.c b/src/getlimits.c
new file mode 100644
index 000..5467e59
--- /dev/null
+++ b/src/getlimits.c
@@ -0,0 +1,181 @@
+/* getlimits - print various platform dependent limits.
+ Copyright (C) 2008 Free Software Foundation, Inc.
+
+ This program is free software: you can redistribute it and/or modify
+ it under the terms of the GNU General Public License as published by
+ the Free Software Foundation, either version 3 of the License, or
+ (at your option) any later version.
+
+ This program is distributed in the hope that it will be useful,
+ but WITHOUT ANY WARRANTY; without even the implied warranty of
+ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ GNU General Public License for more details.
+
+ You should have received a copy of the GNU General Public License
+ along with this program. If not, see http://www.gnu.org/licenses/. */
+
+/* Written by Pádraig Brady */
+
+#include config.h /* sets _FILE_OFFSET_BITS=64 etc. */
+#include stdio.h
+#include sys/types.h
+
+#include system.h
+#include long-options.h
+
+#define PROGRAM_NAME getlimits
+
+#define AUTHORS proper_name_utf8 (Padraig Brady, P\303\241draig Brady)
+
+#ifndef TIME_T_MAX
+# define TIME_T_MAX TYPE_MAXIMUM (time_t)
+#endif
+
+#ifndef TIME_T_MIN
+# define TIME_T_MIN TYPE_MINIMUM (time_t)
+#endif
+
+#ifndef SSIZE_MIN
+# define SSIZE_MIN TYPE_MINIMUM(ssize_t)
+#endif
+
+#ifndef PID_T_MIN
+# define PID_T_MIN TYPE_MINIMUM (pid_t)
+#endif
+
+/* These are not interesting to print.
+ * Instead of these defines it would be nice to be able to do
+ * #ifdef (TYPE##_MIN) in function macro below. */
+# define SIZE_MIN 0
+# define UCHAR_MIN 0
+# define UINT_MIN 0
+# define ULONG_MIN 0
+# define UINTMAX_MIN 0
+# define UID_T_MIN 0
+# define GID_T_MIN 0
+
+static void
+usage (int status)
+{
+ if (status != EXIT_SUCCESS)
+fprintf (stderr, _(Try `%s --help' for more information.\n),
+ program_name);
+ else
+{
+ printf (_(\
+Usage: %s\n\
+),
+ program_name);
+
+ fputs (_(\
+Output platform dependent limits in a format useful for shell scripts.\n\
+\n\
+), stdout);
+ fputs (HELP_OPTION_DESCRIPTION, stdout);
+ fputs (VERSION_OPTION_DESCRIPTION, stdout);
+ emit_bug_reporting_address ();
+}
+ exit (status);
+}
+
+/* Add absolute values of ascii decimal strings.
+ * Strings can have leading spaces.
+ * If any string has a '-' it's preserved in the output:
+ * I.E.
+ *1 + 1 - 2
+ * -1 + -1 - -2
+ * -1 + 1 - -2
+ *1 + -1 - -2
+ */
+static char*
+decimal_ascii_add(const char* str1, const char* str2)
+{
+ int len1=strlen(str1);
+ int len2=strlen(str2);
+ int rlen=MAX(len1, len2)+3; /* space for extra digit or sign + NUL */
+ char* result = xmalloc(rlen);
+ char* rp=result+rlen-1;
+ const char* d1=str1+len1-1;
+ const char* d2=str2+len2-1;
+ int carry = 0;
+ *rp = '\0';
+
+ while (1)
+{
+
Re: [PATCH]: chmod - do inform about using different mode than requested with SGID/SUID/sticky bits without permissions to change them
Jim Meyering wrote: Ondřej Vašík [EMAIL PROTECTED] wrote: Throwing out --changes should be ok, if user wants to be informed, he can parse verbose output easily and common case is to use it without verbose mode at all. Anyway --verbose output is affected by this issue as well, so I would prefer to 1) depricate --changes option as it could be substituted by --verbose and grep 2) fix the verbose output to show correct output in every case where it is possible. E.g. if the stat fails, it should inform the user that the mode/owner/whatever is unknown. E.g. SGID bit case or stat failed is the thing where user should be informed in verbose mode about something unusual. Actually, I was thinking of making --verbose output *less* informative, so that it can be truthful, albeit less informative, without adding extra stat/lstat calls. Sort of like chcon, which says simply changing security context of FILE While I do see the down-side of doing that, it seems better to print less information, with a guarantee of no lies, than to print usually-true messages along with the occasional untruth. For me verbose mode is something useful to track problems. Therefore I do prefer more informations there. Common usage of chown/chmod/chgrp/chcon utilities is without --verbose/--changes mode, so it would affect very low (close to zero) amount of users anyway. I guess burden of of additional stat/lstat calls could be acceptable for some kind of very verbose mode as it doesn't affect common users at all and makes tracking of problems easier. Even for the price of potentially untruth informations in very rare cases - if that risk is mentioned in documentation. Greetings, Ondřej signature.asc Description: Toto je digitálně podepsaná část zprávy ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [PATCH]: chmod - do inform about using different mode than requested with SGID/SUID/sticky bits without permissions to change them
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Ondřej Vašík on 11/20/2008 5:51 AM: For me verbose mode is something useful to track problems. Therefore I do prefer more informations there. Common usage of chown/chmod/chgrp/chcon utilities is without --verbose/--changes mode, so it would affect very low (close to zero) amount of users anyway. Would a double --verbose make sense? 'chown --verbose' merely prints a generic message that it changed a mode, while 'chown --verbose --verbose' re-stats the file and prints the updated mode? - -- Don't work too hard, make some time for fun as well! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkklYpYACgkQ84KuGfSFAYBUJQCgxmL56WzzZqZ7XSff0ppzqWmJ uiEAn0xawzIQ2rzDFGxy2zppXEwkfHp+ =FO7X -END PGP SIGNATURE- ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [PATCH]: ls: add --user-format option for user defined format
Ondřej Vašík [EMAIL PROTECTED] wrote: Pádraig Brady wrote: Ondřej Vašík wrote: Let's do some summary, feel free to add/comment items if you have something not mentioned here: What patched ls --user-format can and upstream find -printf not: 1) colored files by LS_COLORS or automatically if requested 2) could be used simply as ls alias for normal users - as they could still specify additional ls options like time-style, quoting-style, sorting style, blocksize, units and other things without modifying format string 6) Automated column width computation (in find -printf you have to hardcode the column width in %N.NX syntax yourself, otherwise there is no defined human-readable column structure.) I guess points #1, #2, #6 are the most important things, as #1 and #2 makes the output more user friendly and #6 generally readable by human Right. As I see it ls output is tuned for human consumption, while find is tuned for further consumption by other scripts/utils. Exactly - I have the same opinion and I wrote it in the previous email ... and as humans do differ and they could have different wishes about format of output, I would expect something to tune output in ls - without processing through awk/sed/whatever utilities. In my experience I've only needed to tweak output like this to ease the subsequent processing in scripts/utils. I.E. I've never needed it in ls, I'm quite sure that you (and Jim) never needed that option. Otherwise it would had been already implemented. In my case it is slightly different. I never needed that option, but I sometimes wished to have it. For me Actually, ever since find got its -printf option, I've thought of adding the same to ls. But the size of the code addition as well as the logistics (this was before gnulib) were off-putting, not to mention the fact that this is ls, after all. That combined to make the overall cost/benefit ratio appear way too high. Here are my questions: - is it worthwhile to add a --printf option to ls? I don't like the --user-format name) - if so, should it use use a find -printf-compatible format string or one compatible to stat --printf? Either way, it'll need a few extensions. I'm still on the fence. On the one hand, I don't like to bloat ls further, even if it ends up using code that's shared with GNU find. On the other, I understand and sympathize with the desire to make ls output more useful/readable. Finally, if investing in ls, I'd rather invest in converting it to use fts for its hierarchy traversal. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [PATCH]: chmod - do inform about using different mode than requested with SGID/SUID/sticky bits without permissions to change them
Eric Blake [EMAIL PROTECTED] wrote: According to Ondřej Vašík on 11/20/2008 5:51 AM: For me verbose mode is something useful to track problems. Therefore I do prefer more informations there. Common usage of chown/chmod/chgrp/chcon utilities is without --verbose/--changes mode, so it would affect very low (close to zero) amount of users anyway. Would a double --verbose make sense? 'chown --verbose' merely prints a generic message that it changed a mode, while 'chown --verbose --verbose' re-stats the file and prints the updated mode? I like it. Sounds like a fine compromise. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [PATCH]: chmod - do inform about using different mode than requested with SGID/SUID/sticky bits without permissions to change them
Eric Blake [EMAIL PROTECTED] writes: Would a double --verbose make sense? --verbose=2 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: [PATCH]: chmod - do inform about using different mode than requested with SGID/SUID/sticky bits without permissions to change them
Andreas Schwab wrote: Eric Blake [EMAIL PROTECTED] writes: Would a double --verbose make sense? --verbose=2 Rather than some level-numbers I do prefer --verbose and --verbose=high ... Ondřej signature.asc Description: Toto je digitálně podepsaná část zprávy ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [PATCH]: ls: add --user-format option for user defined format
Jim Meyering wrote: Actually, ever since find got its -printf option, I've thought of adding the same to ls. But the size of the code addition as well as the logistics (this was before gnulib) were off-putting, not to mention the fact that this is ls, after all. That combined to make the overall cost/benefit ratio appear way too high. Here are my questions: - is it worthwhile to add a --printf option to ls? I don't like the --user-format name) - if so, should it use use a find -printf-compatible format string or one compatible to stat --printf? Either way, it'll need a few extensions. So there would be 3 large interfaces to try and find commonalities in and maintain. I'm still on the fence. On the one hand, I don't like to bloat ls further, even if it ends up using code that's shared with GNU find. On the other, I understand and sympathize with the desire to make ls output more useful/readable. Finally, if investing in ls, I'd rather invest in converting it to use fts for its hierarchy traversal. I'm on the fence too, but more on the bottom rung. I don't think the interface pollution cost to the benefit gained is worth it. ls -l has good defaults for me. Infrequently I want other info which other options to ls, or stat provide already. I'm also reminded of http://examples.oreilly.com/upt2/#sls The main use case there is for processing by scripts, which find --printf is sufficient for now. Going forward I would add extra formats to `find --printf`, with a view to keeping them in sync with `stat --printf`. cheers, Pádraig. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [PATCH] Add getlimits utility for use in tests
Take 4 attached
From 54322f168c42cd7f4bb4f62081a4866d18598a41 Mon Sep 17 00:00:00 2001
From: =?utf-8?q?P=C3=A1draig=20Brady?= [EMAIL PROTECTED]
Date: Thu, 20 Nov 2008 11:02:15 +
Subject: [PATCH] Add getlimits utility for use in tests
* src/getlimits.c: A utility to print
platform dependent limits in a format
suitable for use in shell scripts.
* src/Makefile.am: Add getlimits to list
of utilities to build but not install.
Also add it to the list linked with libiconv
* po/POTFILES.in: Add getlimits to translation list.
---
po/POTFILES.in |1 +
src/Makefile.am |4 +-
src/getlimits.c | 180 +++
3 files changed, 184 insertions(+), 1 deletions(-)
create mode 100644 src/getlimits.c
diff --git a/po/POTFILES.in b/po/POTFILES.in
index 8a6e541..9bd8c43 100644
--- a/po/POTFILES.in
+++ b/po/POTFILES.in
@@ -62,6 +62,7 @@ src/factor.c
src/false.c
src/fmt.c
src/fold.c
+src/getlimits.c
src/group-list.c
src/groups.c
src/head.c
diff --git a/src/Makefile.am b/src/Makefile.am
index 097cc7a..a6bc229 100644
--- a/src/Makefile.am
+++ b/src/Makefile.am
@@ -44,7 +44,7 @@ EXTRA_PROGRAMS = \
bin_PROGRAMS = $(OPTIONAL_BIN_PROGS)
-noinst_PROGRAMS = setuidgid
+noinst_PROGRAMS = setuidgid getlimits
noinst_HEADERS = \
chown-core.h \
@@ -82,6 +82,7 @@ LDADD = libver.a ../lib/libcoreutils.a $(LIBINTL) ../lib/libcoreutils.a
cat_LDADD = $(LDADD)
df_LDADD = $(LDADD)
du_LDADD = $(LDADD)
+getlimits_LDADD = $(LDADD)
ptx_LDADD = $(LDADD)
split_LDADD = $(LDADD)
timeout_LDADD = $(LDADD)
@@ -160,6 +161,7 @@ cat_LDADD += $(LIBICONV)
cp_LDADD += $(LIBICONV)
df_LDADD += $(LIBICONV)
du_LDADD += $(LIBICONV)
+getlimits_LDADD += $(LIBICONV)
ptx_LDADD += $(LIBICONV)
split_LDADD += $(LIBICONV)
timeout_LDADD += $(LIBICONV)
diff --git a/src/getlimits.c b/src/getlimits.c
new file mode 100644
index 000..7b4c3be
--- /dev/null
+++ b/src/getlimits.c
@@ -0,0 +1,180 @@
+/* getlimits - print various platform dependent limits.
+ Copyright (C) 2008 Free Software Foundation, Inc.
+
+ This program is free software: you can redistribute it and/or modify
+ it under the terms of the GNU General Public License as published by
+ the Free Software Foundation, either version 3 of the License, or
+ (at your option) any later version.
+
+ This program is distributed in the hope that it will be useful,
+ but WITHOUT ANY WARRANTY; without even the implied warranty of
+ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ GNU General Public License for more details.
+
+ You should have received a copy of the GNU General Public License
+ along with this program. If not, see http://www.gnu.org/licenses/. */
+
+/* Written by Pádraig Brady */
+
+#include config.h /* sets _FILE_OFFSET_BITS=64 etc. */
+#include stdio.h
+#include sys/types.h
+
+#include system.h
+#include c-ctype.h
+#include long-options.h
+
+#define PROGRAM_NAME getlimits
+
+#define AUTHORS proper_name_utf8 (Padraig Brady, P\303\241draig Brady)
+
+#ifndef TIME_T_MAX
+# define TIME_T_MAX TYPE_MAXIMUM (time_t)
+#endif
+
+#ifndef TIME_T_MIN
+# define TIME_T_MIN TYPE_MINIMUM (time_t)
+#endif
+
+#ifndef SSIZE_MIN
+# define SSIZE_MIN TYPE_MINIMUM(ssize_t)
+#endif
+
+#ifndef PID_T_MIN
+# define PID_T_MIN TYPE_MINIMUM (pid_t)
+#endif
+
+/* These are not interesting to print.
+ * Instead of these defines it would be nice to be able to do
+ * #ifdef (TYPE##_MIN) in function macro below. */
+#define SIZE_MIN 0
+#define UCHAR_MIN 0
+#define UINT_MIN 0
+#define ULONG_MIN 0
+#define UINTMAX_MIN 0
+#define UID_T_MIN 0
+#define GID_T_MIN 0
+
+static void
+usage (int status)
+{
+ if (status != EXIT_SUCCESS)
+fprintf (stderr, _(Try `%s --help' for more information.\n),
+ program_name);
+ else
+{
+ printf (_(\
+Usage: %s\n\
+), program_name);
+
+ fputs (_(\
+Output platform dependent limits in a format useful for shell scripts.\n\
+\n\
+), stdout);
+ fputs (HELP_OPTION_DESCRIPTION, stdout);
+ fputs (VERSION_OPTION_DESCRIPTION, stdout);
+ emit_bug_reporting_address ();
+}
+ exit (status);
+}
+
+/* Add absolute values of ascii decimal strings.
+ * Strings can have leading spaces.
+ * If any string has a '-' it's preserved in the output:
+ * I.E.
+ *1 + 1 - 2
+ * -1 + -1 - -2
+ * -1 + 1 - -2
+ *1 + -1 - -2
+ */
+static char *
+decimal_ascii_add (const char *str1, const char *str2)
+{
+ int len1 = strlen (str1);
+ int len2 = strlen (str2);
+ int rlen = MAX (len1, len2) + 3; /* space for extra digit or sign + NUL */
+ char *result = xmalloc (rlen);
+ char *rp = result + rlen - 1;
+ const char *d1 = str1 + len1 - 1;
+ const char *d2 = str2 + len2 - 1;
+ int carry = 0;
+ *rp = '\0';
+
+ while (1)
+{
+ char c1 = (d1 str1 ? ' ' : (*d1 == '-' ? ' ' : *d1--));
+ char c2 = (d2 str2 ? ' ' : (*d2 == '-' ? ' ' : *d2--));
+ char t1 = c1 + c2 + carry;/* ASCII digits are BCD */
+ if (!c_isdigit (c1)
Re: Possible bug with grep/sed/tail?
A) # tail trace.txt | grep com - WORKS: produces output B) # tail trace.txt | grep com | cat - WORKS: produces output C) # tail -f trace.txt | grep com - WORKS: produces output, then waits and reports new lines D) # tail -f trace.txt | grep com | cat - FAILS: no output from existing lines, never gets new data To me, it seems completely counterintuitive that A, B, and C would work, but D does not. Each line of input read by tail should be passed to STDOUT, which is then read as STDIN by grep/sed, then passed to STDOUT and read by cat. It should not matter if tail is done reading the output or not, as clearly that works fine in case C. Buffering occurs line by line in cases A and C, in bigger blocks in cases B and D. So the data is stuck in grep (or sed's) buffers until enough of it is produced. If it is never produced, it is stuck unless sed/grep see an end-of-file condition on stdin -- which they do with tail, but not with tail -f. Paolo ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [PATCH]: ls: add --user-format option for user defined format
Jim Meyering wrote:
- is it worthwhile to add a --printf option to ls?
I don't like the --user-format name)
You know my opinion ... I guess it is worthwhile, as the consumer of
ls output is generally human and human wishes do differ. I'm ok with
--printf option, you are right - it would be better to keep conventions.
- if so, should it use use a find -printf-compatible format string
or one compatible to stat --printf? Either way, it'll need a few
extensions.
I guess it should use find -printf style with some extensions. As ls
doesn't change much, I guess there will be not so many changes in the
interface in future. Some extensions would be necessary, some things,
maybe they could be mentioned explicitly in findutils and ls. Anyway it
is bad that there are already two different tools and interfaces (stat
--printf and find --printf) for exactly the same thing... as both are
usable only in scripts. Adding option to ls means human readability.
Additionally it would be good to unify stat --printf and find -printf
format at least for the %{filename} style format which was proposed as
possible future extension.
I'm still on the fence. On the one hand, I don't like to bloat
ls further, even if it ends up using code that's shared with GNU find.
On the other, I understand and sympathize with the desire to make ls
output more useful/readable.
There were already some wishes/requests to add that feature to ls.
Additionally - as I said, if the implementation of ls --printf option
would be improved (and I think it could be improved easily), it could
even simplify the ls.c code, as format options could be replaced just by
--printf format strings - so functions like print_with_commas,
print_horizontal, print_many_per_line and others could be removed
completely.
As Pádraig mentioned there are some implementations of 'ls-like'
utilities doing the same (sls, limo and maybe others) - always
mentioning that the utility is add-on to ls - simply because users
expect that feature from ls. And I guess it would be better to have it
centralized in ls...
Finally, if investing in ls, I'd rather invest in converting it to use
fts for its hierarchy traversal.
As the base code for ls --printf option (almost) exists, I hope I'll
be able to change the options (and to amend documentation) quite quickly
if the option with the objections from the discussion (at the moment I
guess verbosity on --help, different format from find -printf, name of
that option) will be generally accepted. Changing ls to use fts seems to
take much more time for me at the moment. But good TODO task...
Greetings,
Ondřej
signature.asc
Description: Toto je digitálně podepsaná část zprávy
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Possible bug with grep/sed/tail?
Paolo Bonzini wrote: A) # tail trace.txt | grep com - WORKS: produces output B) # tail trace.txt | grep com | cat - WORKS: produces output C) # tail -f trace.txt | grep com - WORKS: produces output, then waits and reports new lines D) # tail -f trace.txt | grep com | cat - FAILS: no output from existing lines, never gets new data To me, it seems completely counterintuitive that A, B, and C would work, but D does not. Each line of input read by tail should be passed to STDOUT, which is then read as STDIN by grep/sed, then passed to STDOUT and read by cat. It should not matter if tail is done reading the output or not, as clearly that works fine in case C. Buffering occurs line by line in cases A and C, in bigger blocks in cases B and D. So the data is stuck in grep (or sed's) buffers until enough of it is produced. If it is never produced, it is stuck unless sed/grep see an end-of-file condition on stdin -- which they do with tail, but not with tail -f. This is a common pain in the neck. I wrote up a detailed description of the issue: http://www.pixelbeat.org/programming/stdio_buffering/ Note grep has a --line-buffered option which may help you. In general if you have a tool in the middle of a pipe line it will need a way to control the line buffering. There is a patch at the bottom of the page above which gives that control to cut. It's probably useful to add this functionality to all coreutil filters. I still need to be convinced that glibc is not the correct place for this. If it was there then any users of stdio could be controlled. Pádraig. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Possible bug with grep/sed/tail?
On Thu, 20 Nov 2008, David Corlette wrote: Hello there, Wow, that's quite a cross-post you have there. Thoughts? Is there some limitation of which I am not aware that prevents this from working? Where does the data go in case D? It's all to do with buffering. The data is being held in a buffer, and not being flushed to the next stage of the pipeline. You see, the middle process can only see its stdin and stdout, and neither are terminals, so it reverts to an efficient mode of operation of not bothering to flush its output buffers. If you could tell the middle processes that they are actually outputting to an interactive terminal, then they would flush the output as soon as they generate it. Is there currently a way to do that? This problem has certainly caught me out in the past (admittedly about ten years ago). Matthew -- To most people, solutions mean finding the answers. But to chemists, solutions are things that are still all mixed up. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
[PATCH] Don't do unneccesary memory copies in dd.
I was surprised that dd did memcpy() by default,
which one can see using:
ltrace -e memcpy dd if=/dev/zero of=/dev/null count=10
Now if you specify bs=512 for example
a memcpy() is not done, which seems inconsistent to me.
What about the attached patch to not do a
memory copy in any of the combinations where
ibs = obs, and conversions are not done?
cheers,
Pádraig.
From 3bf7a447aa0b2339915cb5abe4d17919224c88dc Mon Sep 17 00:00:00 2001
From: =?utf-8?q?P=C3=A1draig=20Brady?= [EMAIL PROTECTED]
Date: Thu, 20 Nov 2008 22:49:02 +
Subject: [PATCH] Don't do unneccesary memory copies in dd.
* src/dd.c: If output buffer size would be
the same size as the input buffer, just use
a single buffer to avoid redundant memory copy.
---
src/dd.c |9 ++---
1 files changed, 2 insertions(+), 7 deletions(-)
diff --git a/src/dd.c b/src/dd.c
index f598e44..e1e38e9 100644
--- a/src/dd.c
+++ b/src/dd.c
@@ -998,13 +998,11 @@ scanargs (int argc, char *const *argv)
{
invalid |= ! (0 n n = MAX_BLOCKSIZE (INPUT_BLOCK_SLOP));
input_blocksize = n;
- conversions_mask |= C_TWOBUFS;
}
else if (operand_is (name, obs))
{
invalid |= ! (0 n n = MAX_BLOCKSIZE (OUTPUT_BLOCK_SLOP));
output_blocksize = n;
- conversions_mask |= C_TWOBUFS;
}
else if (operand_is (name, bs))
{
@@ -1036,15 +1034,12 @@ scanargs (int argc, char *const *argv)
if (blocksize)
input_blocksize = output_blocksize = blocksize;
- /* If bs= was given, both `input_blocksize' and `output_blocksize' will
- have been set to positive values. If either has not been set,
- bs= was not given, so make sure two buffers are used. */
- if (input_blocksize == 0 || output_blocksize == 0)
-conversions_mask |= C_TWOBUFS;
if (input_blocksize == 0)
input_blocksize = DEFAULT_BLOCKSIZE;
if (output_blocksize == 0)
output_blocksize = DEFAULT_BLOCKSIZE;
+ if (input_blocksize != output_blocksize)
+conversions_mask |= C_TWOBUFS;
if (conversion_blocksize == 0)
conversions_mask = ~(C_BLOCK | C_UNBLOCK);
--
1.5.3.6
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Possible bug with grep/sed/tail?
It's probably useful to add this functionality to all coreutil filters. Wouldn't it suffice to add buffer control options to cat, rather than every program? I still need to be convinced that glibc is not the correct place for this. If it was there then any users of stdio could be controlled. Maybe so, but the chances of any such change actually getting into glibc seem rather small in practice to me. Maybe a gnulib module, if someone is volunteering to write the code :). karl ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Possible bug with grep/sed/tail?
Pádraig Brady wrote:
It's probably useful to add this functionality to all coreutil filters.
I still need to be convinced that glibc is not the correct place for this.
If it was there then any users of stdio could be controlled.
It has been said before in previous threads but I want to re-state that
this is possible in a very simple and general way with the LD_PRELOAD facility:
$ echo '__attribute__((constructor)) void f() { setvbuf (stdout, NULL, _IOLBF,
0); }' | \
gcc -include stdio.h -x c - -fPIC -shared -o linebuf.so
$ ( while true; do echo foo; sleep 1; done ) | LD_PRELOAD=./linebuf.so grep
foo | cat
foo
foo
foo
... # immediate output
Brian
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
