Re: Feature Request: du --dir-with-slash
Thomas Guettler wrote: Pádraig Brady schrieb: Thomas Guettler wrote: Hi, I use du -ax / | sort -rn /var/tmp/du-`date --iso` to get the sorted total size of all files and directories. Unfortunately you can't see a difference between a directory and a file in the output. It would be nice if the directories would be added by a slash. 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? Pádraig. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Feature Request: du --dir-with-slash
Jim Meyering wrote: 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. agree Besides, the cost[*]/benefit ratio of adding trailing slashes by default looks way too high. [*] in potential portability hassles. I.e., people could easily come to rely on the GNU df's trailing slashes, and then inadvertently write non-portable scripts. Ah, forwards compatibility. I hadn't considered that. Therefore the correct path (pardon the pun) is to get POSIX to update the standard if this is in fact deemed an improvement warranting that, and work from there. 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: The wrapper is awkward, but it's better than a new option. So probably best to do nothing here as you suggest. thanks for the clarifications, Pádraig. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Feature Request: du --dir-with-slash
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. Besides, the cost[*]/benefit ratio of adding trailing slashes by default looks way too high. [*] in potential portability hassles. I.e., people could easily come to rely on the GNU df's trailing slashes, and then inadvertently write non-portable scripts. 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: http://thread.gmane.org/gmane.comp.gnu.coreutils.bugs/12895/focus=12896 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. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
[bug #22505] id command fails to retrieve group info when nss_ldap is used
Follow-up Comment #2, bug #22505 (project coreutils): Regarding nss_ldap, I guess that this was a bug in nss_ldap it was setting errno explicitly to ENOENT. That problem should be fixed with the latest nss_ldap release (260). Probably the NSS module handling nisplus has the same problem. ___ Reply to this item at: http://savannah.gnu.org/bugs/?22505 ___ Nachricht geschickt von/durch Savannah http://savannah.gnu.org/ ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Feature Request: du --dir-with-slash
Thomas Guettler wrote: 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: The wrapper is awkward, but it's better than a new option. So probably best to do nothing here as you suggest. I know that it easy to use the 'du -a' and pipe the output to a check if it is a directory. But if you have a lot of files, it really matters if you touch a files twice. And this solution does not count the size of directories. find / -xdev -printf %k\t%p%y\n | sed 's/d$/\//;t; s/.$//;' | LC_ALL=C sort -rn -k1,1 Oops true. How about (I realize this is getting protracted): find / -xdev -printf %p%y\n | sed 's/d$/\//;t; s/.$//;' | tr '\n' '\0' | xargs -r0 du -s | LC_ALL=C sort -rn -k1,1 thanks, Pádraig. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Feature Request: du --dir-with-slash
Pádraig Brady schrieb:
Thomas Guettler wrote:
Hi,
I use du -ax / | sort -rn /var/tmp/du-`date --iso` to get the sorted
total size of all
files and directories.
Unfortunately you can't see a difference between a directory and a file
in the output. It would be nice if the directories would be added by a
slash.
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.
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
--- src/du.c~ 2007-11-25 14:23:31.0 +0100
+++ src/du.c 2008-03-10 10:12:35.206483708 +0100
@@ -139,6 +139,9 @@
/* If true, output the NUL byte instead of a newline at the end of each line. */
static bool opt_nul_terminate_output = false;
+/* If true, output directories with a trailing slash */
+static bool opt_dir_with_slash = false;
+
/* If true, print a grand total at the end. */
static bool print_grand_total = false;
@@ -216,6 +219,7 @@
{si, no_argument, NULL, HUMAN_SI_OPTION},
{max-depth, required_argument, NULL, MAX_DEPTH_OPTION},
{null, no_argument, NULL, '0'},
+ {dir-with-slash, no_argument, NULL, 'z'},
{no-dereference, no_argument, NULL, 'P'},
{one-file-system, no_argument, NULL, 'x'},
{separate-dirs, no_argument, NULL, 'S'},
@@ -321,6 +325,9 @@
--summarize\n\
), stdout);
fputs (_(\
+ -z, --dir-with-slash append a slash to directories.\n\
+), stdout);
+ fputs (_(\
--timeshow time of the last modification of any file in the\n\
directory, or any of its subdirectories\n\
--time=WORD show time as WORD instead of modification time:\n\
@@ -437,7 +444,7 @@
/* Print size (and optionally time) indicated by *PDUI, followed by STRING. */
static void
-print_size (const struct duinfo *pdui, const char *string)
+print_size (const struct duinfo *pdui, const char *string, FTSENT *ent)
{
print_only_size (pdui-size);
if (opt_time)
@@ -445,7 +452,10 @@
putchar ('\t');
show_date (time_format, pdui-tmax);
}
- printf (\t%s%c, string, opt_nul_terminate_output ? '\0' : '\n');
+ printf (\t%s%s%c, string,
+ ent opt_dir_with_slash IS_DIR_TYPE(ent-fts_info) ? / : ,
+ opt_nul_terminate_output ? '\0' : '\n'
+ );
fflush (stdout);
}
@@ -607,7 +617,7 @@
if ((IS_DIR_TYPE (ent-fts_info) level = max_depth)
|| ((opt_all level = max_depth) || level == 0))
-print_size (dui_to_print, file);
+print_size (dui_to_print, file, ent);
return ok;
}
@@ -653,7 +663,7 @@
}
if (print_grand_total)
-print_size (tot_dui, _(total));
+print_size (tot_dui, _(total), NULL);
return ok;
}
@@ -697,7 +707,7 @@
for (;;)
{
int oi = -1;
- int c = getopt_long (argc, argv, DEBUG_OPT 0abchHklmsxB:DLPSX:,
+ int c = getopt_long (argc, argv, DEBUG_OPT 0abchHklmsxB:DLPSX:z,
long_options, oi);
if (c == -1)
break;
@@ -825,6 +835,10 @@
}
break;
+case 'z':
+ opt_dir_with_slash = true;
+ break;
+
case FILES0_FROM_OPTION:
files_from = optarg;
break;
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Feature Request: du --dir-with-slash
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: The wrapper is awkward, but it's better than a new option. So probably best to do nothing here as you suggest. I know that it easy to use the 'du -a' and pipe the output to a check if it is a directory. But if you have a lot of files, it really matters if you touch a files twice. And this solution does not count the size of directories. find / -xdev -printf %k\t%p%y\n | sed 's/d$/\//;t; s/.$//;' | LC_ALL=C sort -rn -k1,1 I agree that a single letter option is maybe not needed, but a --dir-with-slash would be good. 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
Re: Feature Request: du --dir-with-slash
Thomas Guettler [EMAIL PROTECTED] wrote: 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: The wrapper is awkward, but it's better than a new option. So probably best to do nothing here as you suggest. I know that it easy to use the 'du -a' and pipe the output to a check if it is a directory. But if you have a lot of files, it really matters if you touch a files twice. And this solution does not count the size of directories. find / -xdev -printf %k\t%p%y\n | sed 's/d$/\//;t; s/.$//;' | LC_ALL=C sort -rn -k1,1 I agree that a single letter option is maybe not needed, but a --dir-with-slash would be good. If you really want this feature, yet cannot afford the access-files-twice approach, consider processing du -a0 output so as to transform file names like these: a/b/c/file a/b/c a/b a into this: a/b/c/file a/b/c/ a/b/ a/ i.e., in iterating through names, when dirname($prev) == $name, append a / to $name. However, that would not annotate the name of an empty directory. $ mkdir -p a/b/c/d a/empty $ du -a0 a|perl -MFile::Basename -0ne 'chomp; $s=/^\d+\t(.*)/ (defined $prev ? dirname ($prev) eq $1 : 0) ? / : ; print $_$s\n; $prev = $1' 0 a/empty 0 a/b/c/d 0 a/b/c/ 0 a/b/ 0 a/ ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Feature Request: du --dir-with-slash
Pádraig Brady wrote: find / -xdev -printf %p%y\n | sed 's/d$/\//;t; s/.$//;' | tr '\n' '\0' | xargs -r0 du -s | LC_ALL=C sort -rn -k1,1 Note that will give the output you want but will be very inefficient :( So Jim's method is the best compromise for the moment. Pádraig. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: AW: cp -p does not work if normal users are allowed to chown files
PHILIPP, Axel, Dr. [EMAIL PROTECTED] wrote:
Jim Meyering [mailto:[EMAIL PROTECTED] wrote:
This is relatively
low priority, since very few people care about systems configured to
allow regular users to use chown. If you don't hear back
from someone
after a couple weeks, please ping the mailing list. ]
I agree. Otherwise the problem should have been detected earlier. So I
tried to produce a patch by myself. It does pass some simple tests, but
I am not sure whether it is wellbehaved in all possible situations.
Anyhow, I hope it can help as starting point.
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
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.
Here's a possibility:
You can maintain this as a separate patch (or better, as a git branch --
then just rebase periodically), advertise it, and if you find enough
people to use and test it, perhaps you will resubmit it in a year or two,
with testimonials.
If you pursue this (and as a prerequisite, if it's ever to have a chance
at being accepted for inclusion), I suggest that you write a few test
scripts to exercise as much of the changed behavior as you can.
Sorry not even to review the code, but I hope you understand,
Jim
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [PATCH] mkdir/split: send --verbose output to stdout + [PATCH]: same for rmdir/install
Jim Meyering wrote: ... So you'll have to make the three .c files include the new .h, and you'll have to adjust src/Makefile.am to link the new .c file to each of those three programs. ... Then, create the file patch like this: git format-patch --stdout --signoff HEAD~1 patch and mail that file to the list. Ok, hopefully fixed your objections from that mail and from the discussion off the list, patch is in attachement. Greetings, Ondrej Vasik prog-vfprintf.patch Description: application/mbox 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
AW: cp -p does not work if normal users are allowed to chown files
Jim Meyering [mailto:[EMAIL PROTECTED] wrote:
This is relatively
low priority, since very few people care about systems configured to
allow regular users to use chown. If you don't hear back
from someone
after a couple weeks, please ping the mailing list. ]
I agree. Otherwise the problem should have been detected earlier. So I
tried to produce a patch by myself. It does pass some simple tests, but
I am not sure whether it is wellbehaved in all possible situations.
Anyhow, I hope it can help as starting point.
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.
--- coreutils-6.10/src/copy.h.ori 2008-01-05 23:58:25.0
+0100
+++ coreutils-6.10/src/copy.h 2008-03-10 09:24:09.413606000 +0100
@@ -140,6 +140,10 @@
bool preserve_ownership;
bool preserve_mode;
bool preserve_timestamps;
+ /* additional entries needed for unrestricted chown fix */
+ uid_t cp_uid;
+ gid_t cp_gid;
+ bool force_suid_transfer; /* used for sgid as well */
/* Enabled for mv, and for cp by the --preserve=links option.
If true, attempt to preserve in the destination files any
--- coreutils-6.10/src/cp.c.ori 2008-01-11 12:19:53.0 +0100
+++ coreutils-6.10/src/cp.c 2008-03-10 14:29:28.540002000 +0100
@@ -287,7 +287,11 @@
struct dir_attr *p;
char *dst_name; /* A copy of CONST_DST_NAME we can
change. */
char *src_name; /* The source name in `dst_name'. */
+ bool mode_already_changed;/* if mode has to be changed before
ownership
+ in case of unrestricted chown */
+ mode_t src_mode;
+ mode_already_changed=false;
ASSIGN_STRDUPA (dst_name, const_dst_name);
src_name = dst_name + src_offset;
@@ -314,8 +318,29 @@
}
}
+ /* unrestricted chown fix. chmod before chown if necessary */
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 */
+ if (x-preserve_mode)
+ {
+ if (copy_acl (src_name, -1, dst_name, -1, src_mode) !=
0)
+return false;
+ }
+ else if (p-restore_mode)
+ {
+ if (lchmod (dst_name, src_mode) != 0)
+ {
+ error (0, errno, _(failed to preserve permissions
for %s),
+quote (dst_name));
+ return false;
+ }
+ }
+ mode_already_changed=true;
+ }
if (lchown (dst_name, p-st.st_uid, p-st.st_gid) != 0)
{
if (! chown_failure_ok (x))
@@ -330,21 +355,25 @@
}
}
+ if ( !mode_already_changed) {
+ 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 );
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;
}
else if (p-restore_mode)
{
- if (lchmod (dst_name, p-st.st_mode) != 0)
+ if (lchmod (dst_name, src_mode) != 0)
{
error (0, errno, _(failed to preserve permissions for
%s),
quote (dst_name));
return false;
}
}
-
+ }
dst_name[p-slash_offset] = '/';
}
return true;
@@ -463,7 +492,12 @@
(src_mode ~S_IRWXUGO) != 0. However, common practice
is
to ask mkdir to copy all the CHMOD_MODE_BITS, letting
mkdir
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)
{
error (0, errno, _(cannot make directory %s),
@@ -781,6 +815,11 @@
x-symbolic_link = false;
x-set_mode = false;
x-mode = 0;
+ /* unrestricted chown fix */
+ x-cp_uid=geteuid();
+ x-cp_gid=getegid();
+ x-force_suid_transfer=false;
+ /* may introduce long option
problem with command sort after uniq -c
Hello, I met a problem with the sort command : I've used the uniq command with the -c option to count some numbers, and then applying sort -n don't sort lines by numeric order of the first field. Here is an example (my sort version is 5.97) : $ cat bug_sort | sort -n 1320 51970 1692 12345 22681 8060 26063 8649 2668 33603 3487 44496 4350 23246 47013 8000 5447 2 81724 5000 If I add a non-numeric and non-space character between the 2 fields, sort -n works properly : $ cat bug_sort | sed s/\([0-9]\) \([0-9]\)/\1 -\2/ | sort -n 1320 -51970 1692 -12345 2668 -33603 3487 -44496 4350 -23246 5447 -2 22681 -8060 26063 -8649 47013 -8000 81724 -5000 With only spaces between the 2 fields, sort -n read 1 number per line and use it to do the sort : 2668 33603 is read as 266833603. With this consideration, the result of sort is correct, but it's not what I expected (and I didn't see this behaviour in the documentation). Regards, Damien -- Damien ANCELIN INRIA - ENS-Lyon, LIP (RESO) Bureau 322 Sud Tel : +33 4 72 72 85 02 ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: problem with command sort after uniq -c
On Mon, 10 Mar 2008, Damien ANCELIN wrote: I met a problem with the sort command : I've used the uniq command with the -c option to count some numbers, and then applying sort -n don't sort lines by numeric order of the first field. Here is an example (my sort version is 5.97) : $ cat bug_sort | sort -n 1320 51970 1692 12345 22681 8060 26063 8649 2668 33603 3487 44496 4350 23246 47013 8000 5447 2 81724 5000 You don't say which locale your environment is configured to use for sorting, but I'd bet it's one which treats whitespace differently to how you expect. With only spaces between the 2 fields, sort -n read 1 number per line and use it to do the sort : 2668 33603 is read as 266833603. With this consideration, the result of sort is correct, but it's not what I expected (and I didn't see this behaviour in the documentation). The command sort -n treats the whole line as the sort key. Specifying sort -k1,1n will use just the first field, in ascending numerical order. Cheers, Phil ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: problem with command sort after uniq -c
Damien ANCELIN [EMAIL PROTECTED] writes: I met a problem with the sort command : I've used the uniq command with the -c option to count some numbers, and then applying sort -n don't sort lines by numeric order of the first field. Here is an example (my sort version is 5.97) : $ cat bug_sort | sort -n This is a useless use of cat, you can just redirect sort's standard input from the file. 1320 51970 1692 12345 22681 8060 26063 8649 2668 33603 3487 44496 4350 23246 47013 8000 5447 2 81724 5000 I assume that you use the fr_FR locale. In this locale a number can be grouped with a space, thus it is considered part of the number. If you want to be sure that sort only considers the first field as sort key you should use -k1,1 to limit it. The default is to always use the the whole line as sort key, and sort -n will take as much as possible from the key to match a number. 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: problem with command sort after uniq -c
Andreas Schwab wrote on 10-03-08 19:54: Damien ANCELIN [EMAIL PROTECTED] writes: I met a problem with the sort command : I've used the uniq command with the -c option to count some numbers, and then applying sort -n don't sort lines by numeric order of the first field. Here is an example (my sort version is 5.97) : $ cat bug_sort | sort -n This is a useless use of cat, you can just redirect sort's standard input from the file. True, but such constructs do happen. What might have been the case here, and which is a situation that I find myself in sometimes, is this: you want to do 'filter1 FILE | filter2' (or 'filter1 FILE | filter2'). Somehow the output isn't what's to be expected. You investigate, and part of that is temporarily substituting filter1 for plain cat and the command becomes 'cat FILE | filter2'. Most of the time this is on the command-line. bjd ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [PATCH] mkdir/split: send --verbose output to stdout + [PATCH]: same for rmdir/install
Ondřej Vašík [EMAIL PROTECTED] wrote: Ok, hopefully fixed your objections from that mail and from the discussion off the list, patch is in attachement. Thank you! I've made a few name changes by transforming the patch before applying it, so that the function name and file name match, and so that the new files are named prog-fprintf.[ch]. I shouldn't have suggested prog-printf.c: it takes a FILE* parameter like *f*printf. perl -pe \ 's/PROG_PRINTF_H/PROG_FPRINTF_H/;s/prog_vfprintf/prog_fprintf/;s/prog-printf\./prog-fprintf\./g' Doing it that way has the nice side effect of adjusting the log entries at the same time. Oops. Trying to apply, I see that there are still trailing blanks: $ git am /t/prog-vfprintf.patch Applying install, rmdir: write --verbose output to stdout, not stderr. .dotest/patch:23: trailing whitespace. install, mkdir, rmdir and split now write --verbose output to stdout, .dotest/patch:37: trailing whitespace. Display to standard error all status updates as sterilization proceeds. .dotest/patch:147: trailing whitespace. /* prog-fprintf.c - common formating output functions and definitions .dotest/patch:171: trailing whitespace. /* Display program name followed by variable list. .dotest/patch:189: trailing whitespace. /* prog-fprintf.h - common formating output functions and definitions warning: 5 lines add whitespace errors. so I backed out that patch: $ git reset --hard HEAD^ removed the trailing blanks it would have added, $ perl -pi -e 's/^(\+.*?) +$/$1/' /t/prog-vfprintf.patch and reapplied, and this time git am succeeded. But then make syntax-check failed like this: ... src/prog-fprintf.c Makefile.maint: the above files do not include config.h make: *** [sc_require_config_h] Error 1 I fixed that, and ran make syntax-check again. Failed with this: prog_fprintf the above functions should have static scope make[1]: *** [sc_tight_scope] Error 1 To fix that, my policy is that you must mark the declaration extern, to tell the test that you really do intend to make it public. I did that, but to my surprise, it was not enough. I still got the same make syntax-check failure. Investigation shows that since this is the first such function declared in coreutils/src/*.h, the sc_tight_scope rule didn't cover it. It searched for extern function declarations only in $(SOURCES), which doesn't happen to include that new .h file. The existing search wouldn't have found it anyhow, since it's all on one line, as is standard for a prototype in a .h file. So I fixed the rule to accommodate the new extern-function-in-.h, and now, *finally*, make syntax-check passes. The only other change was to move #include stdio.h from the .c file into the .h file, since the declaration uses the stdio.h-provided FILE type. Here's what I expect to push: - Subject: [PATCH] install, rmdir: write --verbose output to stdout, not to stderr. * src/install.c (announce_mkdir): Write verbose output to stdout, not to stderr. * src/mkdir.c (announce mkdir): Use prog_fprintf for verbose output. * src/prog-fprintf.c (prog_fprintf): New function and file. * src/prog-fprintf.h: New file. * src/rmdir.c (main): Write verbose output to stdout, not to stderr. Quote directory name in a diagnostic. * src/rmdir.c (remove_parents): Write verbose output to stdout, not to stderr. * doc/coreutils.texi: Mention that shred verbose output is to stderr. * NEWS: Mention the changes. Signed-off-by: Ondřej Vašík [EMAIL PROTECTED] Signed-off-by: Jim Meyering [EMAIL PROTECTED] --- NEWS |3 ++- doc/coreutils.texi |2 +- src/Makefile.am|6 +- src/install.c |5 +++-- src/mkdir.c| 16 ++-- src/prog-fprintf.c | 37 + src/prog-fprintf.h | 24 src/rmdir.c|7 --- 8 files changed, 78 insertions(+), 22 deletions(-) create mode 100644 src/prog-fprintf.c create mode 100644 src/prog-fprintf.h diff --git a/NEWS b/NEWS index a738dab..948bced 100644 --- a/NEWS +++ b/NEWS @@ -40,7 +40,8 @@ GNU coreutils NEWS-*- outline -*- ** Consistency - mkdir and split now write --verbose output to stdout, not stderr. + install, mkdir, rmdir and split now write --verbose output to stdout, + not to stderr. * Noteworthy changes in release 6.10 (2008-01-22) [stable] diff --git a/doc/coreutils.texi b/doc/coreutils.texi index df6792d..f161c4d 100644 --- a/doc/coreutils.texi +++ b/doc/coreutils.texi @@ -8190,7 +8190,7 @@ If a file has multiple links, only the named links will be removed. @itemx --verbose @opindex -v @opindex --verbose -Display status updates as sterilization proceeds. +Display to standard error all status updates as sterilization proceeds. @item -x @itemx --exact diff --git a/src/Makefile.am b/src/Makefile.am index c85f853..44d802e 100644 --- a/src/Makefile.am +++
Re: problem with command sort after uniq -c
Bauke Jan Douma wrote: What might have been the case here, and which is a situation that I find myself in sometimes, is this: you want to do 'filter1 FILE | filter2' (or 'filter1 FILE | filter2'). Somehow the output isn't what's to be expected. You investigate, and part of that is temporarily substituting filter1 for plain cat and the command becomes 'cat FILE | filter2'. Most of the time this is on the command-line. On your own command line is fine. It is your command line. No one else would ever see it. The objections come in when people write these into scripts and into test cases and share these around to other people. Many people have a belief that cat into a pipe is the only way to do it. I have seen hundreds of lines written this way in a single script! It is a misunderstanding. Educating users to improve their programming abilities is just one of the many burdens that must be endured, or else endure the endless burden of even more programs written poorly with these misconceptions. Bob ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
