Re: bug in yesno()?
Eric Blake [EMAIL PROTECTED] writes: Should yesno() be setting the properties of stdin to be unbuffered for the duration of the getline(), so that the rest of stdin is not consumed too early? That would make the code less portable/reliable, I think, and would slow things down. POSIX does not require the behavior that you want. Solaris 10 'rm' behaves like GNU rm here. (Can you tell which way I'm leaning? :-) ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
du and --exclude --exclude-from
du (coreutils) 5.2.1 # du /home/reind --exclude=/home/reind # du /home/reind -X exclude.txt with exclude.txt: /home/reind Both of the above do not work as they should. They do not exclude the above directories. Sincerely, [EMAIL PROTECTED] ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: rm issue
Eric Blake [EMAIL PROTECTED] wrote: According to Jim Meyering on 2/17/2006 9:14 AM: No. Those who want `short' can use -I. Although --ask-once does sound nice, I want to keep things minimal, in case we end up providing similar functionality for other commands, where adding a long-named synonym might make an existing abbreviation ambiguous -- --ask-once would do just that to cp --a(rchive). With that, here goes. Changes from the first submittal: --interactive without WHEN defaults to -i, NEWS and coreutils.texi touched up to match this change, and 2 test files are added. ChangeLog: 2006-02-18 Eric Blake [EMAIL PROTECTED] * TODO (rm): Implement rm -I. * NEWS: Document it, along with change to rm --interactive. Thanks. Applied. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: rm issue
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Jim Meyering on 2/20/2006 6:06 AM:
ChangeLog:
2006-02-18 Eric Blake [EMAIL PROTECTED]
* TODO (rm): Implement rm -I.
* NEWS: Document it, along with change to rm --interactive.
Thanks. Applied.
I missed one spot of documentation, and introduced a typo. Please apply
this followon patch:
ChangeLog:
2006-02-20 Eric Blake [EMAIL PROTECTED]
* man/rm.x: Update documentation to match previous patch.
doc/ChangeLog:
2006-02-20 Eric Blake [EMAIL PROTECTED]
* coreutils.texi (rm invocation): Fix typo in last patch.
(paste invocation): Fix whitespace.
- --
Life is short - so eat dessert first!
Eric Blake [EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFD+fBF84KuGfSFAYARAmt4AJ9QfW6fRoeGkX2BkkadTu2uwts5KgCgxPyK
BKml8zPZNGyWXn3rkvHrNoA=
=JwGh
-END PGP SIGNATURE-
Index: doc/coreutils.texi
===
RCS file: /sources/coreutils/coreutils/doc/coreutils.texi,v
retrieving revision 1.312
diff -u -p -r1.312 coreutils.texi
--- doc/coreutils.texi 20 Feb 2006 13:01:51 - 1.312
+++ doc/coreutils.texi 20 Feb 2006 16:35:15 -
@@ -4679,7 +4679,7 @@ c
$ paste num2 let3
1 a
2 b
-c
+ @ c
@end example
Synopsis:
@@ -7331,7 +7331,7 @@ If the @option{-I} or @option{--interact
and there are more than three files or the @option{-r}, @option{-R},
or @option{--recursive} are given, then @command{rm} prompts the user
for whether to proceed with the entire operation. If the response is
-not affirmitive, the entire command is aborted.
+not affirmative, the entire command is aborted.
Otherwise, if a file is unwritable, standard input is a terminal, and
the @option{-f} or @option{--force} option is not given, or the
Index: man/rm.x
===
RCS file: /sources/coreutils/coreutils/man/rm.x,v
retrieving revision 1.6
diff -u -p -r1.6 rm.x
--- man/rm.x21 Sep 2004 07:53:54 - 1.6
+++ man/rm.x20 Feb 2006 16:35:15 -
@@ -8,11 +8,19 @@ documents the GNU version of
removes each specified file. By default, it does not remove
directories.
.P
-If a file is unwritable, the standard input is a tty, and
-the \fI\-f\fR or \fI\-\-force\fR option is not given,
+If the \fI\-I\fR or \fI\-\-interactive\=once\fR option is given,
+and there are more than three files or the \fI\-r\fR, \fI\-R\fR,
+or \fI\-\-recursive\fR are given, then
.B rm
-prompts the user for whether to remove the file. If the response
-is not affirmative, the file is skipped.
+prompts the user for whether to proceed with the entire operation. If
+the response is not affirmative, the entire command is aborted.
+.P
+Otherwise, if a file is unwritable, standard input is a terminal, and
+the \fI\-f\fR or \fI\-\-force\fR option is not given, or the
+\fI\-i\fR or \fI\-\-interactive\=always\fR option is given,
+.B rm
+prompts the user for whether to remove the file. If the response is
+not affirmative, the file is skipped.
.SH OPTIONS
[SEE ALSO]
chattr(1), shred(1)
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: du and --exclude --exclude-from
du (coreutils) 5.2.1 The latest stable version of coreutils is 5.94 - consider upgrading: http://lists.gnu.org/archive/html/bug-coreutils/2006-02/msg00078.html # du /home/reind --exclude=/home/reind # du /home/reind -X exclude.txt with exclude.txt: /home/reind Both of the above do not work as they should. They do not exclude the above directories. Exclusion is intended for files not listed on the command line. By listing the directory explicitly, you are bypassing the exclusion check for that directory. -- Eric Blake ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Bug#351601: coreutils: minor formatting issue in the mv an cp manpages
Eric Blake [EMAIL PROTECTED] wrote: According to Jim Meyering on 2/18/2006 12:44 AM: Nicolas François [EMAIL PROTECTED] wrote: ... I've found some other similar issues in install.c, join.c, pr.c, and uniq.c I'm attaching a patch for Makefile.maint Thanks again! I switched it to use grep's -E, so there aren't so many backslashes and made it fit within 80 columns. Jim, I thought at one point you planned on mirroring all savannah posts to this mailing list, but this was the first I had heard of this issue. Maybe you just turned on patch mirroring, but forgot bug mirroring? I see four messages in this thread, before yours: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] and they all Cc'd [EMAIL PROTECTED] Hmm... then it hit me. I hadn't checked the bug-coreutils approval queue in a while, and maybe no one else had, either. Yep. Nicolas' message was there, along with a couple others and a few pages worth of spam. Thanks for the prod. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: rm issue
Eric Blake [EMAIL PROTECTED] wrote: I missed one spot of documentation, and introduced a typo. Please apply this followon patch: ChangeLog: 2006-02-20 Eric Blake [EMAIL PROTECTED] * man/rm.x: Update documentation to match previous patch. doc/ChangeLog: 2006-02-20 Eric Blake [EMAIL PROTECTED] * coreutils.texi (rm invocation): Fix typo in last patch. (paste invocation): Fix whitespace. Applied. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: comparing string with regular expression using test command in unix
Hi, I want to compare a variable holding *string* with the *regular expression *. Is it possible to do in unix with a single command? Can we use test command in UNIX to compare a *string *with the *regular expression*? if so please provide an example for that. This sort of question generally implies that it would be well worth your investment in a good book on Unix shell programming. In coreutils, 'info expr' may prove enlightening. For example, $ foo=bar $ expr $foo : 'ba*' echo found || echo not found 2 found $ expr $foo : 'ca*' echo found || echo not found 0 not found Outside of the realm of coreutils, there are other techniques. For example, in /bin/sh, you can do glob matching (instead of regular expressions) like this: $ case $foo in ba*) echo found ;; *) echo not found ;; esac found Or use the regular expressions in sed: $ echo $foo | sed -ne '/ba*/p' bar $ echo $foo | sed -ne '/ca*/p' $ Or several other ideas. Hopefully this gives you some ideas. SASKEN BUSINESS DISCLAIMER This message may contain confidential, proprietary or legally Privileged information. In case you are not the original intended Recipient of the message, you must not, directly or indirectly, use, Disclose, distribute, print, or copy any part of this message and you are requested to delete it and inform the sender. Sorry, but this email is now in the public domain. You should consider using an account that does not have such unenforceable disclaimers when posting to public mailing lists. -- Eric Blake ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: sort on multicolumn files
On Thu, 16 Feb 2006, P Kensche wrote: I use 4.5.3 from coreutils 5.93 and have a problem with sort. This is a common issue, due to certain locale settings which influence sorting behaviour. Please see: http://www.gnu.org/software/coreutils/faq/coreutils-faq.html#Sort-does-not-sort-in-normal-order_0021 Anyway - in this combination of outputs sort unusable in combination with join (which is exactly what I tried to do). Did you mean to sort on the whole line? -k requires two fields, and if only one is given, the default is to consider all subsequent fields. Cheers, Phil ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
sort on multicolumn files
Hello, I use 4.5.3 from coreutils 5.93 and have a problem with sort. File a: a-1 1 a 0 is sorted by sort -k 1 a to a 0 a-1 1 In contrast file b: a a B a-1 b G is sorted by sort -k 1 b to a-1 b G a a B I assume that the sorting of file b is not correct (because it is not lexicographical?). Anyway - in this combination of outputs sort unusable in combination with join (which is exactly what I tried to do). Is this a bug? Regard, Philip ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: comparing string with regular expression using test command in unix
N Gandhi Raja [EMAIL PROTECTED] writes: I want to compare a variable holding *string* with the *regular expression *. Is it possible to do in unix with a single command? Yes, with expr. $ info coreutils 'String expressions' 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: comparing string with regular expression using test command in unix
On Friday 17 February 2006 05:23, N Gandhi Raja wrote: I want to compare a variable holding *string* with the *regular expression *. Is it possible to do in unix with a single command? Can we use test command in UNIX to compare a *string *with the *regular expression*? if so please provide an example for that. `test` does not support regexes, but you can use either `expr` or bash-3.0+ supports regex comparison using the =~ operator -mike ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: comparing string with regular expression using test command in unix
N Gandhi Raja [EMAIL PROTECTED] writes: Can we use test command in UNIX to compare a *string *with the *regular expression*? No. You might look at 'expr' or 'awk' instead. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: sort on multicolumn files
P Kensche [EMAIL PROTECTED] writes:
is sorted by sort -k 1 a
In general, that's not correct since it sorts by fields 1 through N,
whereas 'join' sorts only by field 1. You need to use sort -k 1b,1
instead. So, as far as I can tell, you haven't found a bug.
However, `-k 1b,1' isn't immediately obvious, and the documentation
should be improved here. I installed the following patch to try to
improve things. Thanks for reporting the problem.
2006-02-20 Paul Eggert [EMAIL PROTECTED]
* doc/coreutils.texi (join invocation): Mention `sort -k 1b,1'.
* src/join.c (usage): Likewise.
Documentation problem reported by Philip Kensche.
--- doc/coreutils.texi 20 Feb 2006 16:50:11 - 1.313
+++ doc/coreutils.texi 21 Feb 2006 02:50:39 -
@@ -4738,11 +4738,11 @@ lines that have identical join fields.
join [EMAIL PROTECTED]@dots{} @var{file1} @var{file2}
@end example
[EMAIL PROTECTED] LC_COLLATE
Either @var{file1} or @var{file2} (but not both) can be @samp{-},
meaning standard input. @var{file1} and @var{file2} should be
sorted on the join fields.
[EMAIL PROTECTED] LC_COLLATE
Normally, the sort order is that of the
collating sequence specified by the @env{LC_COLLATE} locale. Unless
the @option{-t} option is given, the sort comparison ignores blanks at
@@ -4750,7 +4750,14 @@ the start of the join field, as in @code
@option{--ignore-case} option is given, the sort comparison ignores
the case of characters in the join field, as in @code{sort -f}.
-However, as a GNU extension, if the input has no unpairable lines the
+The @command{sort} and @command{join} commands should use consistent
+locales and options if the output of @command{sort} is fed to
[EMAIL PROTECTED] You can use a command like @samp{sort -k 1b,1} to
+sort a file on its default join field, but if you select a non-default
+locale, join field, separator, or comparison options, then you should
+do so consistently between @command{join} and @command{sort}.
+
+As a GNU extension, if the input has no unpairable lines the
sort order can be any order that considers two fields to be equal if and
only if the sort comparison described above considers them to be equal.
For example:
@@ -4841,6 +4848,8 @@ option---are subject to the specified @v
@item -t @var{char}
Use character @var{char} as the input and output field separator.
Treat as significant each occurrence of @var{char} in the input file.
+Use @samp{sort -t @var{char}}, without the @option{-b} option of
[EMAIL PROTECTED], to produce this ordering.
@item -v @var{file-number}
Print a line for each unpairable line in file @var{file-number}
--- src/join.c 18 Feb 2006 07:22:01 - 1.144
+++ src/join.c 21 Feb 2006 02:50:40 -
@@ -167,6 +167,7 @@ the remaining fields from FILE1, the rem
separated by CHAR.\n\
\n\
Important: FILE1 and FILE2 must be sorted on the join fields.\n\
+E.g., use `sort -k 1b,1' if `join' has no options.\n\
), stdout);
printf (_(\nReport bugs to %s.\n), PACKAGE_BUGREPORT);
}
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
