bug#13353: Coreutils-8.20 mips build broken
On 01/03/2013 09:45 PM, Marko Lindqvist wrote: 8.20 fails on mips with lots of unable to emulate 'TI' errors That sounds like a compiler problem of some sort. right whift count = width of type warnings from src/factor.c. First error comes from line 766. What's the output of 'cc -E' for that file, using the same flags as is used for 'cc -c'? This will help us track down what's shifting what.
bug#13354: sort: File Merge Order is Suboptimal with Many Passes
Over a year ago, I was working with sort on some large input files. I noticed a performance problem that related to the number of temp files being used for sort runs. As I recall, I'd also seen the problem prior to that, but this was the first time I took an opportunity to diagnose the problem in detail. (As for why I waited so long to finally report it, more below.) From what I recall, it tended to want to do 8-way merges on my system. If the input file was just big enough, it would wind up with 9 files left over toward the end. It would merge the largest 8 files in another pass, and then do one final merge to combine the now-huge temp file with the one, likely very tiny temp file still remaining. I found that the extra pass added a lot of extra time to the sort. If I bumped up the memory buffer to increase the initial run sizes so that I got rid of one temp file, I could shave at least a few minutes off the total run time: The little extra memory made a disproportionate difference, and I could attribute it directly to the extra merge pass at the end that was avoided. At the time I reasoned that it would make the most sense to merge temp files at the very beginning to reduce the number just enough to have a bunch of --batch-size merge passes after that until the end. In this case, if the extra temp file at the end was 10 MB, then each merge pass would have to process 10 MB more. Over 4 merge passes, say, that's 40 MB extra to read. But the benefit is saving the final merge pass with 10 MB plus something a WHOLE log bigger than 40 MB, if it's big enough to require 4 merge passes to combine it all in the first place! I held off on reporting the bug because I wanted to see what Knuth had to say on the subject. Well, tonight I finally went to the library and looked through volume 3 to see his advice. :) In section 5.4.9 he basically echoes my thinking. In the simple case where all runs were the same length, he recommends a queue to track the files to process, with N files pulled from the front of the queue and the merged output added to the back. But, he says to add a number of dummy empty files to the front queue. The net effect is that fewer than N files are merged the first time. Looking at the merge function in sort.c, it appears that it can merge both temp files and input files all at the same time. With that, we probably want an enhancement to that algorithm, which Knuth called Huffman's method (referencing something in chapter 2). For files or sort runs of varying sizes, Knuth says to use a priority queue, to merge the smallest N files at each pass. He also says to add a number of 0-length dummy files at the front of the priority queue so that the first merge pass grabs fewer than N files. If I understand his formula correctly, he suggests to add (1-F) % (N-1) dummy runs, where N is --batch-size and F is the starting number of files. To get it ideal, we'd need a priority queue implementation here, maybe a heap or something. (Irony of having to maintain a sorted list of files in a sort program is duly noted...) It would be an improvement, though, to handle merging a smaller batch of files at the beginning, the equivalent of adding 0-byte dummy files at the front. That might be quicker to implement, unless there's a GPL'd heap library lying around somewhere... Jason B. -- Half the harm that is done in this world is due to people who want to feel important. -- T. S. Eliot
bug#13354: sort: File Merge Order is Suboptimal with Many Passes
On 01/04/2013 04:07 AM, Jason Bucata wrote: Over a year ago, I was working with sort on some large input files. I noticed a performance problem that related to the number of temp files being used for sort runs. As I recall, I'd also seen the problem prior to that, but this was the first time I took an opportunity to diagnose the problem in detail. (As for why I waited so long to finally report it, more below.) From what I recall, it tended to want to do 8-way merges on my system. If the input file was just big enough, it would wind up with 9 files left over toward the end. It would merge the largest 8 files in another pass, and then do one final merge to combine the now-huge temp file with the one, likely very tiny temp file still remaining. I found that the extra pass added a lot of extra time to the sort. If I bumped up the memory buffer to increase the initial run sizes so that I got rid of one temp file, I could shave at least a few minutes off the total run time: The little extra memory made a disproportionate difference, and I could attribute it directly to the extra merge pass at the end that was avoided. At the time I reasoned that it would make the most sense to merge temp files at the very beginning to reduce the number just enough to have a bunch of --batch-size merge passes after that until the end. In this case, if the extra temp file at the end was 10 MB, then each merge pass would have to process 10 MB more. Over 4 merge passes, say, that's 40 MB extra to read. But the benefit is saving the final merge pass with 10 MB plus something a WHOLE log bigger than 40 MB, if it's big enough to require 4 merge passes to combine it all in the first place! I held off on reporting the bug because I wanted to see what Knuth had to say on the subject. Well, tonight I finally went to the library and looked through volume 3 to see his advice. :) In section 5.4.9 he basically echoes my thinking. In the simple case where all runs were the same length, he recommends a queue to track the files to process, with N files pulled from the front of the queue and the merged output added to the back. But, he says to add a number of dummy empty files to the front queue. The net effect is that fewer than N files are merged the first time. Looking at the merge function in sort.c, it appears that it can merge both temp files and input files all at the same time. With that, we probably want an enhancement to that algorithm, which Knuth called Huffman's method (referencing something in chapter 2). For files or sort runs of varying sizes, Knuth says to use a priority queue, to merge the smallest N files at each pass. He also says to add a number of 0-length dummy files at the front of the priority queue so that the first merge pass grabs fewer than N files. If I understand his formula correctly, he suggests to add (1-F) % (N-1) dummy runs, where N is --batch-size and F is the starting number of files. To get it ideal, we'd need a priority queue implementation here, maybe a heap or something. (Irony of having to maintain a sorted list of files in a sort program is duly noted...) It would be an improvement, though, to handle merging a smaller batch of files at the beginning, the equivalent of adding 0-byte dummy files at the front. That might be quicker to implement, unless there's a GPL'd heap library lying around somewhere... There is a little heap lib already used by sort: http://git.sv.gnu.org/gitweb/?p=coreutils.git;a=blob;f=gl/lib/heap.c;hb=HEAD Would that suffice? thanks, Pádraig.
bug#13353: Coreutils-8.20 mips build broken
On 4 January 2013 10:51, Paul Eggert egg...@cs.ucla.edu wrote: On 01/03/2013 09:45 PM, Marko Lindqvist wrote: 8.20 fails on mips with lots of unable to emulate 'TI' errors That sounds like a compiler problem of some sort. I've tried to find proper gcc documentation clearly stating which architectures TImode is available, but found none. There's old emails discussing the possibility of implementing TImode to MIPS, but it's not clear to me what's the current status is even supposed to be. right whift count = width of type warnings from src/factor.c. First error comes from line 766. This warning is likely to follow from the error above, and not to be separate issue. - ML
bug#13353: Coreutils-8.20 mips build broken
On 01/04/2013 05:45 AM, Marko Lindqvist wrote:
I've tried to update coreutils version used in OpenEmbedded. I've been
building for x86, arm, and mips architectures. Coreutils-8.19 builds
fine for all three, but 8.20 fails on mips with lots of unable to
emulate 'TI' errors and right whift count = width of type warnings
from src/factor.c. First error comes from line 766.
That's umul_ppmm() which is coming from longlong.h
#if (defined (__mips) __mips = 3) W_TYPE_SIZE == 64
#if __GMP_GNUC_PREREQ (4,4)
#define umul_ppmm(w1, w0, u, v) \
do { \
typedef unsigned int __ll_UTItype __attribute__((mode(TI)));\
__ll_UTItype __ll = (__ll_UTItype)(u) * (v);\
w1 = __ll 64;\
w0 = __ll; \
} while (0)
#endif
I've only gcc (RAYS 4.3.0-4.rays0) 4.3.1 20080501 (prerelease)
on an ICT Loongson-2 V0.3 FPU V0.1
but that allows me to check various macros to key on
$ for abi in 32 o64 n32 64; do
for cpu in mips1 mips2 mips3 mips4 mips32 mips32r2 mips64; do
echo - $cpu/$abi
cpp -mabi=$abi -march=$cpu -dM /dev/null |
grep -Ei __mips |LP|_MPIS_SZ
done
done
- mips1/32
#define __mips 1
- mips2/32
#define __mips 2
- mips3/32
#define __mips 3
- mips4/32
#define __mips 4
- mips32/32
#define __mips 32
- mips32r2/32
#define __mips 32
- mips64/32
#define __mips 64
- mips1/o64
cc1: error: '-march=mips1' is not compatible with the selected ABI
- mips2/o64
cc1: error: '-march=mips2' is not compatible with the selected ABI
- mips3/o64
#define __mips 3
- mips4/o64
#define __mips 4
- mips32/o64
cc1: error: '-march=mips32' is not compatible with the selected ABI
- mips32r2/o64
cc1: error: '-march=mips32r2' is not compatible with the selected ABI
- mips64/o64
#define __mips 64
- mips1/n32
cc1: error: '-march=mips1' is not compatible with the selected ABI
- mips2/n32
cc1: error: '-march=mips2' is not compatible with the selected ABI
- mips3/n32
#define __mips 3
- mips4/n32
#define __mips 4
- mips32/n32
cc1: error: '-march=mips32' is not compatible with the selected ABI
- mips32r2/n32
cc1: error: '-march=mips32r2' is not compatible with the selected ABI
- mips64/n32
#define __mips 64
- mips1/64
cc1: error: '-march=mips1' is not compatible with the selected ABI
- mips2/64
cc1: error: '-march=mips2' is not compatible with the selected ABI
- mips3/64
#define __LP64__ 1
#define _LP64 1
#define __mips 3
- mips4/64
#define __LP64__ 1
#define _LP64 1
#define __mips 4
- mips32/64
cc1: error: '-march=mips32' is not compatible with the selected ABI
- mips32r2/64
cc1: error: '-march=mips32r2' is not compatible with the selected ABI
- mips64/64
#define __LP64__ 1
#define _LP64 1
#define __mips 64
Notice that the macro in longlong.h checks __mips 3
but note that that can be 32 or 64 dependent on --march.
In any case it looks like we also need to key on _LP64.
So could you try the following patch.
With your compiler options it will probably avoid
the code in longlong.h, or you may also like to
try -mabi=64 --march=from-abi if appropriate.
diff src/longlong.h.orig src/longlong.h
1240c1240
#if (defined (__mips) __mips = 3) W_TYPE_SIZE == 64
---
#if (defined (__mips) __mips = 3) W_TYPE_SIZE == 64 defined (_LP64)
thanks,
Pádraig.
bug#13030: factor: infinite loop on Linux/powerpc
On 11/29/2012 08:08 PM, Pádraig Brady wrote: On 11/29/2012 07:36 PM, Torbjorn Granlund wrote: Pádraig Brady p...@draigbrady.com writes: -#if HAVE_HOST_CPU_FAMILY_powerpc W_TYPE_SIZE == 64 +#if HAVE_HOST_CPU_FAMILY_powerpc W_TYPE_SIZE == 64 defined (_LP64) #if !defined (_LONG_LONG_LIMB) /* _LONG_LONG_LIMB is ABI=mode32 where adde operates on 32-bit values. So use adde etc only when not _LONG_LONG_LIMB. */ Thanks, I suppose it might be much better to make W_TYPE_SIZE not be set to a size not supported by the present ABI. That way, we will avoid longlong.h divergence. So that's a bit in contradiction to: http://bugs.gnu.org/12754#20 So you're suggesting that this would be safest? diff --git a/src/factor.c b/src/factor.c index 6d1d17a..d2a4158 100644 --- a/src/factor.c +++ b/src/factor.c @@ -126,11 +126,11 @@ /* Make definitions for longlong.h to make it do what it can do for us */ /* bitcount for uintmax_t */ -# if UINTMAX_MAX == UINT32_MAX +# if ULONG_MAX == UINT32_MAX # define W_TYPE_SIZE 32 -# elif UINTMAX_MAX == UINT64_MAX +# elif ULONG_MAX == UINT64_MAX # define W_TYPE_SIZE 64 -# elif UINTMAX_MAX == UINT128_MAX +# elif ULONG_MAX == UINT128_MAX # define W_TYPE_SIZE 128 # endif In this particular case that would enable the 32 bit ppc assembly in longlong.h If you do the above, you hit run time assertions like: $ factor 2123123123123123123123 factor: factor.c:974: mulredc2: Assertion `(a1 (32 - 1)) == 0' failed. 3276700:Aborted which makes sense as we're using uintmax_t throughout factor.c. But something general is required here rather than fixing up every architecture. I've just noticed that sparc v9 in 32 bit mode will also loop for ever with the above command with what's in place in longlong.h at present. So what I'm going to do is pull all the _LP64 amendments to longlong.h and instead avoid it completely with this in factor.c: diff --git a/src/factor.c b/src/factor.c index 473eee7..95451a5 100644 --- a/src/factor.c +++ b/src/factor.c @@ -118,7 +118,14 @@ #endif #ifndef USE_LONGLONG_H -# define USE_LONGLONG_H 1 +/* With the way we use longlong.h, it's only safe to use + when UWtype = UHWtype, as there were various cases + (as can be seen in the history for longlong.h) where + for example, _LP64 was required to enable W_TYPE_SIZE==64 code, + to avoid compile time or run time issues. */ +# if LONG_MAX == INTMAX_MAX +# define USE_LONGLONG_H 1 +# endif #endif #if USE_LONGLONG_H That works for i686 x86_64 and sparcv7 and sparcv9 at least. thanks, Pádraig.
bug#13354: sort: File Merge Order is Suboptimal with Many Passes
On Fri, Jan 04, 2013 at 11:01:50AM +, P�draig Brady wrote: On 01/04/2013 04:07 AM, Jason Bucata wrote: To get it ideal, we'd need a priority queue implementation here, maybe a heap or something. (Irony of having to maintain a sorted list of files in a sort program is duly noted...) It would be an improvement, though, to handle merging a smaller batch of files at the beginning, the equivalent of adding 0-byte dummy files at the front. That might be quicker to implement, unless there's a GPL'd heap library lying around somewhere... There is a little heap lib already used by sort: http://git.sv.gnu.org/gitweb/?p=coreutils.git;a=blob;f=gl/lib/heap.c;hb=HEAD Would that suffice? thanks, Pádraig. Oh, good to know. If you're asking me, I'm sure it's fine, though I guess it's up to whoever will write the fix. I don't know what it would take for me to be able to get a copyright disclaimer from my employer, so I'm probably not in a position to develop a patch for this myself. I'm hoping some established developer will see this and be able to step in. Jason B. -- Half the harm that is done in this world is due to people who want to feel important. -- T. S. Eliot
bug#13353: Coreutils-8.20 mips build broken
On 4 January 2013 14:12, Pádraig Brady p...@draigbrady.com wrote: So could you try the following patch. diff src/longlong.h.orig src/longlong.h 1240c1240 #if (defined (__mips) __mips = 3) W_TYPE_SIZE == 64 --- #if (defined (__mips) __mips = 3) W_TYPE_SIZE == 64 defined (_LP64) thanks, Pádraig. Yes, that works. Thank you. - ML
bug#13353: Coreutils-8.20 mips build broken
On 01/04/2013 04:23 PM, Marko Lindqvist wrote: On 4 January 2013 14:12, Pádraig Brady p...@draigbrady.com wrote: So could you try the following patch. diff src/longlong.h.orig src/longlong.h 1240c1240 #if (defined (__mips) __mips = 3) W_TYPE_SIZE == 64 --- #if (defined (__mips) __mips = 3) W_TYPE_SIZE == 64 defined (_LP64) thanks, Pádraig. Yes, that works. Thank you. OK cool. I think I'll use this more general patch instead. thanks, Pádraig. diff --git a/src/factor.c b/src/factor.c index 473eee7..95451a5 100644 --- a/src/factor.c +++ b/src/factor.c @@ -118,7 +118,14 @@ #endif #ifndef USE_LONGLONG_H -# define USE_LONGLONG_H 1 +/* With the way we use longlong.h, it's only safe to use + when UWtype = UHWtype, as there were various cases + (as can be seen in the history for longlong.h) where + for example, _LP64 was required to enable W_TYPE_SIZE==64 code, + to avoid compile time or run time issues. */ +# if LONG_MAX == INTMAX_MAX +# define USE_LONGLONG_H 1 +# endif #endif #if USE_LONGLONG_H
bug#13357: removing stale pr news in manual
2013-01-04 Karl Berry k...@gnu.org
* coreutils.texi (pr invocation): remove list of ancient news
items; the main documentation already covers what is needed.
--- /tmp/ORIG/coreutils.texi2013-01-04 09:17:09.0 -0800
+++ /tmp/coreutils.texi 2013-01-04 09:20:20.0 -0800
@@ -2269,32 +2269,2 @@
-The following changes were made in version 1.22i and apply to later
-versions of @command{pr}:
-@c FIXME: this whole section here sounds very awkward to me. I
-@c made a few small changes, but really it all needs to be redone. - Brian
-@c OK, I fixed another sentence or two, but some of it I just don't understand.
-@ - Brian
-@itemize @bullet
-
-@item
-Some small @var{letter options} (@option{-s}, @option{-w}) have been
-redefined for better @acronym{POSIX} compliance. The output of some further
-cases has been adapted to other Unix systems. These changes are not
-compatible with earlier versions of the program.
-
-@item
-Some @var{new capital letter} options (@option{-J}, @option{-S}, @option{-W})
-have been introduced to turn off unexpected interferences of small letter
-options. The @option{-N} option and the second argument @var{last_page}
-of @samp{+FIRST_PAGE} offer more flexibility. The detailed handling of
-form feeds set in the input files requires the @option{-T} option.
-
-@item
-Capital letter options override small letter ones.
-
-@item
-Some of the option-arguments (compare @option{-s}, @option{-e},
-@option{-i}, @option{-n}) cannot be specified as separate arguments from the
-preceding option letter (already stated in the @acronym{POSIX} specification).
-@end itemize
-
The program accepts the following options. Also see @ref{Common options}.
Diff finished at Fri Jan 4 09:20:23
bug#13358: removing @acronym from manual
Didn't we conclude it was better to avoid @acronym and the consequent
ugly rendering in browsers? (Except in cases where it's actually
useful, which is never in the coreutils manual.)
I'm sure we did so for @sc. Unfortunately I cannot separate patches for
@sc and @acronym since they are often used in the same text.
As a side note, there were a number of inconsistent uses -- sometimes
@acronym{GNU}, sometimes @sc{gnu}, sometimes GNU, etc. This is one of
the reasons why I feel it's better to simply avoid them; it's a whole
lot of trouble to actually get it right, and (IMHO) it's not anywhere
near worth the hassle.
k
2013-01-04 Karl Berry k...@gnu.org
* coreutils.texi: avoid @acronym and @sc; they are unnecessary.
--- /tmp/ORIG/coreutils.texi2013-01-04 09:20:20.0 -0800
+++ /tmp/coreutils.texi 2013-01-04 09:26:47.0 -0800
@@ -274,3 +274,3 @@
* Output formatting in ptx:: Types of output format, and sizing the fields
-* Compatibility in ptx:: The @acronym{GNU} extensions to @command{ptx}
+* Compatibility in ptx:: The GNU extensions to @command{ptx}
@@ -505,5 +505,5 @@
-@cindex @acronym{POSIX}
+@cindex POSIX
The @sc{gnu} utilities documented here are mostly compatible with the
-@acronym{POSIX} standard.
+POSIX standard.
@cindex bugs, reporting
@@ -586,3 +586,3 @@
@cindex output @sc{nul}-byte-terminated lines
-Output a zero byte (@acronym{ASCII} @sc{nul}) at the end of each line,
+Output a zero byte (ASCII @sc{nul}) at the end of each line,
rather than a newline. This option enables other programs to parse the
@@ -741,3 +741,3 @@
* Special built-in utilities:: @command{break}, @command{:}, @dots{}
-* Standards conformance:: Conformance to the @acronym{POSIX} standard.
+* Standards conformance:: Conformance to the POSIX standard.
@end menu
@@ -757,3 +757,3 @@
success. Failure is indicated by a nonzero value---typically
-@samp{1}, though it may differ on unusual platforms as @acronym{POSIX}
+@samp{1}, though it may differ on unusual platforms as POSIX
requires only that it be nonzero.
@@ -949,3 +949,3 @@
@samp{k} and the ISO/IEC 8-13 prefix is @samp{Ki}, but tradition and
-@acronym{POSIX} use @samp{k} to mean @samp{KiB}.
+POSIX use @samp{k} to mean @samp{KiB}.
@item MB
@@ -1049,3 +1049,3 @@
@samp{SIG}@. The case of the letters is ignored. The following signal names
-and numbers are supported on all @acronym{POSIX} compliant systems:
+and numbers are supported on all POSIX compliant systems:
@@ -1070,3 +1070,3 @@
Other supported signal names have system-dependent corresponding
-numbers. All systems conforming to @acronym{POSIX} 1003.1-2001 also
+numbers. All systems conforming to POSIX 1003.1-2001 also
support the following signals:
@@ -1105,3 +1105,3 @@
@noindent
-@acronym{POSIX} 1003.1-2001 systems that support the @acronym{XSI} extension
+POSIX 1003.1-2001 systems that support the XSI extension
also support the following signals:
@@ -1126,3 +1126,3 @@
@noindent
-@acronym{POSIX} 1003.1-2001 systems that support the @acronym{XRT} extension
+POSIX 1003.1-2001 systems that support the XRT extension
also support at least eight real-time signals called @samp{RTMIN},
@@ -1144,3 +1144,3 @@
Should the command interpret it as a user name or as an ID@?
-@acronym{POSIX} requires that @command{chown} and @command{chgrp}
+POSIX requires that @command{chown} and @command{chgrp}
first attempt to resolve the specified string as a name, and
@@ -1318,3 +1318,3 @@
the symbolic link. Although it may seem surprising that such behavior
-be the default, it is required by @acronym{POSIX} and is consistent with
+be the default, it is required by POSIX and is consistent with
other parts of that standard.
@@ -1394,3 +1394,3 @@
more quickly, and hence damage more files before an alert user can
-interrupt them. Tradition and @acronym{POSIX} require these commands
+interrupt them. Tradition and POSIX require these commands
to operate recursively on @file{/}, so they default to
@@ -1416,3 +1416,3 @@
Here is a list of the special built-in utilities that are standardized
-by @acronym{POSIX} 1003.1-2004.
+by POSIX 1003.1-2004.
@@ -1437,11 +1437,11 @@
In a few cases, the @sc{gnu} utilities' default behavior is
-incompatible with the @acronym{POSIX} standard. To suppress these
+incompatible with the POSIX standard. To suppress these
incompatibilities, define the @env{POSIXLY_CORRECT} environment
-variable. Unless you are checking for @acronym{POSIX} conformance, you
+variable. Unless you are checking for POSIX conformance, you
probably do not need to define @env{POSIXLY_CORRECT}.
-Newer versions of @acronym{POSIX} are occasionally incompatible with older
-versions. For example, older versions of @acronym{POSIX} required the
+Newer versions of POSIX are occasionally incompatible with older
+versions. For example, older versions of POSIX required the
command @samp{sort +1} to sort based on the second and succeeding
-fields
bug#13357: removing stale pr news in manual
On 01/04/2013 05:33 PM, Karl Berry wrote: * coreutils.texi (pr invocation): remove list of ancient news items; the main documentation already covers what is needed. pushed thanks, Pádraig.
bug#13358: removing @acronym from manual
On 01/04/2013 05:33 PM, Karl Berry wrote:
Didn't we conclude it was better to avoid @acronym and the consequent
ugly rendering in browsers? (Except in cases where it's actually
useful, which is never in the coreutils manual.)
I'm sure we did so for @sc. Unfortunately I cannot separate patches for
@sc and @acronym since they are often used in the same text.
As a side note, there were a number of inconsistent uses -- sometimes
@acronym{GNU}, sometimes @sc{gnu}, sometimes GNU, etc. This is one of
the reasons why I feel it's better to simply avoid them; it's a whole
lot of trouble to actually get it right, and (IMHO) it's not anywhere
near worth the hassle.
k
2013-01-04 Karl Berry k...@gnu.org
* coreutils.texi: avoid @acronym and @sc; they are unnecessary.
--- /tmp/ORIG/coreutils.texi2013-01-04 09:20:20.0 -0800
+++ /tmp/coreutils.texi 2013-01-04 09:26:47.0 -0800
It seems you're using an older version, as Jim already did this:
http://git.sv.gnu.org/gitweb/?p=coreutils.git;a=commit;h=26db95c
thanks,
Pádraig.
bug#13360: removing @sc from manual
(Continuing on from 13358).
It seems you're using an older version,
So I was. Argh.
as Jim already did this:
http://git.sv.gnu.org/gitweb/?p=coreutils.git;a=commit;h=26db95c
He replaced @acronym. @sc should go too.
k
2013-01-04 Karl Berry k...@gnu.org
* coreutils.texi: avoid @sc; it is unnecessary.
@@ -3,3 +3,3 @@
@setfilename coreutils.info
-@settitle @sc{gnu} Coreutils
+@settitle GNU Coreutils
@@ -138,3 +138,3 @@
@copying
-This manual documents version @value{VERSION} of the @sc{gnu} core
+This manual documents version @value{VERSION} of the GNU core
utilities, including the standard programs for text and file manipulation.
@@ -154,3 +154,3 @@
@titlepage
-@title @sc{gnu} @code{Coreutils}
+@title GNU @code{Coreutils}
@subtitle Core GNU utilities
@@ -471,3 +471,3 @@
* Time of day items::9:20pm
-* Time zone items:: @sc{est}, @sc{pdt}, @sc{gmt}
+* Time zone items:: EST, PDT, GMT, @dots{}}
* Day of week items::Monday and others
@@ -502,3 +502,3 @@
basic concepts in a way suitable for novices. Thus, if you are interested,
-please get involved in improving this manual. The entire @sc{gnu} community
+please get involved in improving this manual. The entire GNU community
will benefit.
@@ -506,3 +506,3 @@
@cindex POSIX
-The @sc{gnu} utilities documented here are mostly compatible with the
+The GNU utilities documented here are mostly compatible with the
POSIX standard.
@@ -585,4 +585,4 @@
@opindex --null
-@cindex output @sc{nul}-byte-terminated lines
-Output a zero byte (ASCII @sc{nul}) at the end of each line,
+@cindex output NUL-byte-terminated lines
+Output a zero byte (ASCII NUL) at the end of each line,
rather than a newline. This option enables other programs to parse the
@@ -669,3 +669,3 @@
writing identical descriptions for each of the programs, they are
-described here. (In fact, every @sc{gnu} program accepts (or should accept)
+described here. (In fact, every GNU program accepts (or should accept)
these options.)
@@ -774,3 +774,3 @@
-Some @sc{gnu} programs (at least @command{cp}, @command{install},
+Some GNU programs (at least @command{cp}, @command{install},
@command{ln}, and @command{mv}) optionally make backups of files
@@ -848,3 +848,3 @@
-Some @sc{gnu} programs (at least @command{df}, @command{du}, and
+Some GNU programs (at least @command{df}, @command{du}, and
@command{ls}) display sizes in ``blocks''. You can adjust the block size
@@ -1272,3 +1272,3 @@
However, this doesn't move files whose names begin with @samp{.}.
-If you use the @sc{gnu} @command{find} program, you can move those
+If you use the GNU @command{find} program, you can move those
files too, with this command:
@@ -1284,3 +1284,3 @@
The following example removes those limitations and requires both
-@sc{gnu} @command{find} and @sc{gnu} @command{xargs}:
+GNU @command{find} and GNU @command{xargs}:
@@ -1304,3 +1304,3 @@
-Some @sc{gnu} programs (at least @command{cp} and @command{mv}) allow you to
+Some GNU programs (at least @command{cp} and @command{mv}) allow you to
remove any trailing slashes from each @var{source} argument before
@@ -1382,3 +1382,3 @@
legitimate uses for such a command,
-@sc{gnu} @command{rm} normally declines to operate on any directory
+GNU @command{rm} normally declines to operate on any directory
that resolves to @file{/}. If you really want to try to remove all
@@ -1436,3 +1436,3 @@
@vindex POSIXLY_CORRECT
-In a few cases, the @sc{gnu} utilities' default behavior is
+In a few cases, the GNU utilities' default behavior is
incompatible with the POSIX standard. To suppress these
@@ -1451,3 +1451,3 @@
@vindex _POSIX2_VERSION
-The @sc{gnu} utilities normally conform to the version of POSIX
+The GNU utilities normally conform to the version of POSIX
that is standard for your system. To cause them to conform to a
@@ -1882,3 +1882,3 @@
least @var{bytes} consecutive ASCII graphic characters,
-followed by a zero byte (ASCII @sc{nul}).
+followed by a zero byte (ASCII NUL).
Prefixes and suffixes on @var{bytes} are interpreted as for the
@@ -1980,3 +1980,3 @@
The next several options are shorthands for format specifications.
-@sc{gnu} @command{od} accepts any combination of shorthands and format
+GNU @command{od} accepts any combination of shorthands and format
specification options. These options accumulate.
@@ -2768,3 +2768,3 @@
@cindex BSD @command{tail}
-@sc{gnu} @command{tail} can output any amount of data (some other versions of
+GNU @command{tail} can output any amount of data (some other versions of
@command{tail} cannot). It also has no @option{-r} option (print in
@@ -2774,3 +2774,3 @@
typically 32 KiB@. A more reliable and versatile way to reverse files is
-the @sc{gnu} @command{tac} command.
+the GNU @command{tac} command.
@@ -3492,3 +3492,3 @@
those named in file @var{file}; each name being terminated by a zero byte
-(ASCII @sc{nul}).
+(ASCII NUL).
This is useful
bug#13360: removing @sc from manual
[adding gnulib]
On 01/04/2013 04:39 PM, Karl Berry wrote:
(Continuing on from 13358).
It seems you're using an older version,
So I was. Argh.
as Jim already did this:
http://git.sv.gnu.org/gitweb/?p=coreutils.git;a=commit;h=26db95c
He replaced @acronym. @sc should go too.
If that's the case, then we should enhance gnulib's
maint.mk:sc_texinfo_acronym syntax-checker to also flag @sc{ as an
undesirable sequence, to make it easier to avoid re-introducing problems
in packages that enable that rule.
--
Eric Blake eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
