bug#56524: doc: timezone offset conversion/info
I installed the attached patch to Gnulib Thanks. +Simple POSIX rules like this can also specify nonzero Greenwich offsets. Nothing about this seems "simple" to me :). Anyway. +More-complex POSIX TZ strings can specify simple daylight saving There shouldn't be a hyphen after "More". --thanks again, karl.
bug#56524: doc: timezone offset conversion/info
Suppose I have a date in UTC, and I want to "convert" it to a given UTC offset, say UTC-4. Based on the date --help msg and examples, etc., I was under the impression that the idiom is TZ= date -d 'TZ="" ' Thus, in my case: $ TZ=UTC-4 date -d 'TZ="UTC" 2022-07-24 15:00' The output is: Sun Jul 24 19:00:00 UTC 2022 It adds 4 hours instead of subtracting. Why? I'm probably missing something completely obvious, but maybe the doc could explain this. If I use a tz name that is currently UTC-4, it subtracts as expected: $ TZ=America/New_York date -d 'TZ="UTC" 2022-07-24 15:00' Sun Jul 24 11:00:00 EDT 2022 Also, if I interchange the input/output tz settings, it subtracts as expected: $ TZ=UTC date -d 'TZ="UTC-4" 2022-07-24 15:00' Sun Jul 24 11:00:00 UTC 2022 Overall, I suggest another example in the "Examples of date" node. I know UTC offsets are often not the best thing to be using, but sometimes that's the data we're given and we have to work with it. Related: I also suggest explicitly saying how to specify UTC offsets, because it is not clear. For one, apparently UTC+0430 is invalid since it doesn't affect the output (no error message, which I guess is standard): $ TZ=UTC+0430 date -d 'TZ="UTC" 2022-07-24 15:00' Sat Jul 23 15:00:00 UTC 2022 whereas with a colon it works as expected (well, given the above, that it subtracts with a positive offset): $ TZ=UTC+04:30 date -d 'TZ="UTC" 2022-07-24 15:00' Sun Jul 24 10:30:00 UTC 2022 If the offset syntax is documented anywhere, I couldn't find it. Sorry. BTW, in neither case did --debug clarify anything for me. In fact, it confused me more, because the output seemingly did not include anything about the offset at all, just reporting "UTC". This is with coreutils 8.30 (from Alma Linux 8) on x86_64, though I doubted that it was version-dependent, so confess I didn't try the latest release. --thanks, karl.
bug#54586: dd conv options doc
The dd Texinfo doc says, for the conv= option (https://gnu.org/s/coreutils/manual/html_node/dd-invocation.html) 'fdatasync' Synchronize output data just before finishing. This forces a physical write of output data. 'fsync' Synchronize output data and metadata just before finishing. This forces a physical write of output data and metadata. Weirdly, these descriptions are inducing quite a bit of FUD in me. Why would I ever want the writes to be incomplete after running dd? Seems like that is dd's whole purpose. Well, I suppose it is too late to make such a radical change as forcing a final sync. In which case I suggest adding another sentence along the lines of "If these options are not specified, the data will be physically written when the system schedules the syncs, ordinarily every few seconds" (correct?). "You can also manually sync the output filesystem yourself afterwards (xref sync)." Otherwise it feels uncertain when or whether the data will be physically written, or how to look into it further. As for "metadata", what does dd have to do with metadata? My wild guess is that this is referring to filesystem metadata, not anything about dd specifically. Whatever the case, I suggest adding a word or two to the doc to give a clue. Further, why would I want data to be synced and not metadata? Seems like fdatasync and fsync should both do both; or at least document that normally they'd be used together. Or, if there is a real-life case where a user would want one and not the other, how about documenting that? My imagination is failing me, but presumably these seemingly-undesirable options were invented for a reason. BTW, I came across these options on a random page discussing dumping a .iso to a USB drive; the example was dd if=foo.iso of=/dev/sde conv=fdatasync .. seems now like fsync should also have been given, for certainty. --thanks, karl.
bug#43162: chgrp clears setgid even when group is not changed
So partly this is a platform issue I was on centos7. (I don't observe your problem on my Fedora 31 box, for example). Maybe there is hope for a future centos, then. adding a run-time option to the chown and chgrp commands. Not sure it's worth it. Agreed about not being worth it. Oh well. --thanks, karl.
bug#43162: chgrp clears setgid even when group is not changed
Is it necessary for chgrp to clear setgid on directories even when the group is not actually changed? In my life at least, it is rather annoying. --thanks, karl. $ mkdir foo $ chmod g+s foo $ ls -ld foo drwxrwsr-x 2 karl root 6 Sep 1 10:36 foo/ $ chgrp root foo $ ls -ld foo drwxrwxr-x 2 karl root 6 Sep 1 10:36 foo/
bug#31873: head/tail --help K != N
It's just an idea, and a tiny one at that, but I was momentarily perplexed by the lines like -n, --lines=[-]K in head --help, making it look like the number is given in kilobytes, when I knew that was not correct :). So I suggest replacing K with N in the --help messages when the metavar is standing for just a number, especially/only a number that takes a suffix. FWIW ... --best, karl.
bug#30963: ls -fA -> still . and ..
$ mkdir foo $ cd foo $ \ls -fA . .. $ I rather expected this output to be empty. -f enables -a, fine, but it seems like the -A should override the -a, since it's specified after? I guess it has nothing to do with -f in particular. \ls -aA also shows . and ..; maybe it shouldn't? Not sure, though ... --thanks, karl.
bug#23677: sort --debug not ignoring punctuation when sort does
They are not ignored, just considered only secondary, if the first order characters didn't provide an ordering. Ok. One would have no clue of that, either, from the --debug output. sort obviously knows the exact rules defined by the locale, or it couldn't do its job. How about a way to dump the rules in some human-readable way? (In sort or another utility or a separate program or whatever.) Similar to how James Youngman found a way to write out regex definitions in Texinfo ... just a wish ... -karl
bug#23677: sort --debug not ignoring punctuation when sort does
Consider this two-line input file: M !z M /a (! = ASCII 33; / = ASCII 47.) Locale-dependent sort with debug: LC_ALL=en_US.UTF-8 sort --debug -k2 /tmp/foo Output: sort: using âen_US.UTF-8â sorting rules .. M /a ___ M !z ___ Due to the locale rules, the punctuation characters are being ignored (presumably), or ! would sort before / (as it does with the LC_ALL=C sort). Therefore it seems the debug output would be closer to reality if it was: M /a _ _ M !z _ _ (I think; I'm not sure if all blanks are ignored in the locale sort, or just multiple blanks collapsed to one.) I realize that, in terms of mere string parsing, the punctuation is included in the sort key. But when a character is not actually used for sorting, and the --debug output says it is, that seems suboptimal. (Especially when the rules are, for all practical purposes, undocumented.) I also realize it is not necessarily feasible to change, even if there's agreement on changing it. @curmudgeon How anyone can do anything useful with en_US.UTF-8 sort is beyond me ... @end curmudgeon Ok, no more from me in this area, you can be glad to know. --karl
bug#23665: spaces in keys: doc, --debug in LC_ALL=C
Just to verify, the surprising result is in C locale? Yes. as collating rules for UTF-8 make leading spaces less significant. Yes, which is a different problem, in itself. Let me ask this: Are the collation rules for en_US.UTF-8 documented or even reasonably comprehensively described anywhere? Or just buried in the bowels of libc code? I looked online and found nothing usable (surprisingly). I can add the above example to the documentation Yes please. The C example. It can probably be cut down to two lines and "foo" vs. "bar" or whatever. (also possibly to the FAQ or Gotcha pages?). What do you think? You (or Paul, Jim, Bob, ...) would know better than me what deserves to be on those pages (wherever they are). My feeling would be yes. Along with mentioning --debug to, well, debug such things. How about "leading blanks are significant in sort key [...]" ? I'm not sure what you mean by [...]. The %lu? Are you proposing to just add the word "sort"? That's not needed IMHO. What I was thinking was something like this: sort: leading blanks are significant in key 1 [-k 2]; consider also specifying 'b' Since this is debugging output, the more information the better, in theory, seems to me. Maybe it is not feasible. No biggie. (in http://lingrok.org/xref/coreutils/src/sort.c#2439 ) I don't see the change. Sorry. --thanks, karl.
bug#23665: spaces in keys: doc, --debug in LC_ALL=C
Consider this three-line source file, say /tmp/foo: M Build/zfile M Master/mfile MM Build/afile There are two spaces after the M on the first two lines (and no trailing spaces on any line). I was trying to sort on the second "field". I run LC_ALL=en_US.UTF-8 sort --debug -k 2 /tmp/foo # or -k 2,2 et al. And get the nicely explanatory output for the "surprising" result: sort: using âen_US.UTF-8â sorting rules sort: leading blanks are significant in key 1; consider also specifying 'b' MM Build/afile ... However, if I run that same command in the C locale: LC_ALL=C sort --debug -k 2 /tmp/foo # or -k 2,2 et al. the output lacks that crucial commentary line: sort: leading blanks are significant ... But the information is just as valid in C as in UTF-8, so far as I can see. Thus it would be nice for it to be present. It would also be nice if the definition of "key 1" was stated. Awfully easy to misread that as "field 1". More importantly, I urge that the documentation for sort give an example of this. The idea that following blanks after the first become part of the next field is highly counter-intuitive. The information is implicitly there in "non-blank to blank transition", but it is a common confounding of expectations and deserves explicit mention, IMHO. (If it's there, sorry, I didn't see it.) This is with coreutils 8.25 (from original source). Thanks, Karl
bug#17087: cp -i/yes gets ignored
So I responded with 2 reasons why we might not make 'y' imply '-f' for unwritable files. P@, I'm afraid those reasons did not make sense to me. Can you restate? Sorry. To restate my own idea: from my (not so) naive user's point of view, going to the trouble of typing y RET is the most forceful expression possible of the desired behavior, namely that I want the darn file to get copied. So, if cp -f would work, I would like answering y to work. (And, I believe the other user's request amounts to saying if cp -f would not work, then don't even bother to ask me. I don't feel strongly about that request. :) code complexity it never a reason for not doing something. I suspect we all agree ... in theory :). Thanks, karl
bug#17087: cp -i/yes gets ignored
Well, I concur that the new wording is an improvement in that it reduces expectations, but is it really so impractical to get the behavior that is actually to be desired? I expect the sources are much too advanced for it to be something like force++; after getting the y response :), but maybe ... something ... ? The current behavior is noticeably frustrating, because it seems so unnecessarily stupid. http://lists.gnu.org/archive/html/bug-coreutils/2007-03/msg00130.html Thus, I also agree with that person's frustration in the other direction, although for me it is the situation that I complained about that comes up far more often -- unnecessarily failing to overwrite writable files, rather than unnecessarily asking about unwritable files. But I'm not volunteering to write a patch, and I know the logic in this area is a maze of twisty little passages, some alike and some different, so ... thanks, k
bug#17087: cp -i/yes gets ignored
I find it annoying that explicitly answering y to an interactive prompt in cp can get ignored: $ touch foo $ chmod 444 foo $ cp -i /etc/issue foo cp: try to overwrite 'foo', overriding mode 0444 (r--r--r--)? y cp: cannot create regular file 'foo': Permission denied It seems to me, in terms of UI, that this is clearly at least as forceful (I would say more so) than -f, which does do the overwrite. Also, both mv -i and rm -i already perform their action on a readonly file when told yes. So simple consistency is another argument that cp should do the same. Jim told me once that this behavior is specified by POSIX. Hardly surprising. Can we DTRT here by default and reserve the stupid behavior for POSIXLY_CORRECT? Curmudgeonly, Karl
bug#16802: @w for long option names
Something like the attached patch? Exactly. Thanks. It gets rid of most @kbd instances, too. I don't think @kbd should ever be used with option names. (Aside from actual examples of command lines being typed as input. :) karl
bug#16802: @w for long option names
In a couple places, coreutils.texi uses @w around (bare) long option
names. These are the ones I noticed:
621:@item @w{@kbd{--strip-trailing-slashes}}
1268:The @w{@kbd{--target-directory}} (@option{-t}) option allows the
@command{cp},
1312:operating on it. The @w{@kbd{--strip-trailing-slashes}} option enables
I'm guess the point is to avoid line breaks at the internal hyphens
(there would/should never be line breaks at leading hyphens). In which
case, a cleaner/more general approach would be
@allowcodebreaks false
Then there is no need for sprinkling @w throughout the source.
We added that in Texinfo 4.11, released 2007.
(It belatedly occurs to me that we should make @option, specifically,
always disallow line breaks at hyphens.)
karl
bug#16803: @kbd for long option names?
I just realized that, at some point, the coreutils manual started using
@kbd for long option names, as in:
@item -b
@itemx @w{@kbd{--backup}[=@var{method}]}
Why? Semantically, long option names are not keyboard input.
Practically, I find the result pretty suboptimal in the printed output,
at least, since the -b is typeset in upright typewriter and --backup in
slanted typewriter, even though they are synonyms.
I'm happy to send a patch to remove all the @kbd's if you'll accept it,
but I imagine you had a reason to insert them in the first place.
Surely I didn't use them when I translated some of the original
descriptions?! Can't say I remember [anything] with 100% certainty :).
karl
bug#15529: paste documentation tweak
I suggest the following small change to the paste node in the
documentation. Sorry I don't have the git-fu to give you the patch in
that format.
2013-10-04 Karl Berry k...@gnu.org
* coreutils.texi (paste invocation): Move synopsis to
above existing example; add second example for standard input.
--- ORIG/coreutils.texi 2013-02-11 01:37:28.0 -0800
+++ coreutils.texi 2013-10-04 16:31:13.602509258 -0700
@@ -5963,3 +5963,9 @@
-For example:
+Synopsis:
+
+@example
+paste [@var{option}]@dots{} [@var{file}]@dots{}
+@end example
+
+Example:
@@ -5979,8 +5985,2 @@
-Synopsis:
-
-@example
-paste [@var{option}]@dots{} [@var{file}]@dots{}
-@end example
-
The program accepts the following options. Also see @ref{Common options}.
@@ -6019,2 +6019,10 @@
+Here is another example, to paste together consecutive lines from
+standard input, with a delimiter of a space:
+
+@example
+$ cat num2 | paste -d - -
+1 2
+@end example
+
@exitstatus
Diff finished at Fri Oct 4 16:31:15
bug#13495: Compilation fails on Mac OS X 10.8.0
1. This code isn't used - due to the combination of #if's. Sorry if I'm missing the point here, but FWIW, my suggestion for cpp-related debugging is to take the line from make for compiling the file and change it to: gcc -E -dD -o foobar ...copy rest of cmdline from make output... Then foobar will have the #define statements, in the context of the regular preprocessed output, so you can see what is #defining what and why. http://gcc.gnu.org/onlinedocs/gcc/Preprocessor-Options.html (at -dCHARS, toward the end.) (Or similar, for other compilers. Sorry, I don't recall if you're using gcc.) Best, karl
bug#13371: removing @acronym from manual
the latest Texinfo documentation (from the 4.13.93 pretest) says
nothing about that
On the contrary, I added (brief) text to both the acronym and Smallcaps
nodes giving caveats about using @acronym and @sc quite a while ago.
It's been in all the pretests. I've retweaked that text again just now,
though, so I'm glad you mentioned it.
Anyway, avoiding them is not official requirement, not at all. Not even
an official recommendation. I just came to the conclusion when people
asked my advice some years ago -- I observed that whenever a manual
tries to use @acronym or @sc for normal all-caps abbreviations, such as
GNU, in practice the commands are not used consistently (as we have
just seen in the coreutils case).
Since there's no special benefit to using @acronym{GNU} or @sc{gnu} over
just plain GNU, it's merely about typographic preferences, my
suggestion was that it was better to avoid the whole issue, simplify the
source, and go with GNU.
Nevertheless, if a GNU manual wants to use them, that is fine by me.
k
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#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#11427: cp 8.16 not writing through, writing over
Create dangling symlink: $ ln -s foo bar Attempt to write over it with cp: $ \cp -i /etc/issue bar cp: not writing through dangling symlink 'bar' In the past, it would ask me if I wanted to replace bar. (As desired.) The error message makes me think that it is thinking I am writing through a dangling symlink to a directory. But that gets a different error message, which seems fine: $ \cp -i /etc/issue bar/baz cp: cannot create regular file 'bar/baz': No such file or directory coreutils 8.16, compiled from original source on CentOS 5.8 (libc 2.5, it seems). karl
Re: btwowc(EOF) hang with gcc 4.4.2
Hi Andreas, It still works, that's what fixincludes is for. If that does not work for you then this is a different bug. My understanding is that fixincludes is automatically run these days. So all I did was run configure --prefix=/usr/local/gnu --enable-languages=c,c++ \ make \ make install (Well, after unpacking mpfr, and being grateful that they support having mpfr in the source tree.) The only wchar.h I see that got installed is /usr/local/gnu/include/c++/4.4.2/tr1/wchar.h, which is presumably irrelevant to C compilation. I guess I can double-check and then try to report that bug. BTW, this is on CentOS 5.4 = RHEL whatever. gcc version 4.1.2 20080704 (Red Hat 4.1.2-46) Thanks, Karl
Re: btwowc(EOF) hang with gcc 4.4.2
It's definitely a compiler problem. That extern inline asm alias trickery The gcc people say that the behavior is correct; not a bug. (I don't understand all of their replies, but the conclusion seems clear.) http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42440 I don't know if there is a way to change the configure test so it is robust against this particular problem. k
Re: btwowc(EOF) hang with gcc 4.4.2
Hi Alan, Thanks for the explanation. So the problem boils down to: your gcc is too new for your glibc. Downgrade one or upgrade the other. Ok, that was more or less what I understood also. But it is very depressing. It means it is no longer possible to install the current gcc from sources and use it reliably, independently of whatever gcc the system provides (usually much older, with plenty of different bugs introduced, etc.), something which has always worked before for me since day one of gcc. (In my experience it's never been possible to install the current glibc from sources and have it actually work, so that's not an option.) A big step backwards in my view. All because of optimization to the nth degree of one tiny fn that is useless in all my (and my users') life anyway. Sigh. Oh well, life goes on. Thanks again, Karl
btwowc(EOF) hang with gcc 4.4.2
Hi Jim and all,
On a CentOS 5.4 system, compiling with gcc 4.4.2, configure goes into an
infinite loop here:
checking whether btowc(EOF) is correct...
Running gdb on conftest gets a backtrace like this:
#0 0x080491d1 in btowc (__c=-1) at /usr/include/wchar.h:331
#1 0x08049431 in btowc () at /usr/include/wchar.h:332
#2 main () at conftest.c:276
Where that line 331 is:
331 { return (__builtin_constant_p (__c) __c = '\0' __c = '\x7f'
This does not happen with other versions of gcc. I can't tell if it's a
gcc bug or a system include file bug or something actually in coreutils,
but here's the report anyway. It was pretty unsettling to have
configure hang.
k
symlinks and targets are not the same file
[coreutils 8.1, gnu/linux] $ touch foo $ ln -s foo lnk $ \cp --no-dereference foo lnk cp: `foo' and `lnk' are the same file Well, no, they're not. I expected the file foo to overwrite the symlink lnk. I can imagine that error without --no-dereference, but with it ... ? Thanks, k
Re: copyright years: mass-update every January 1
While at it, why not standardize everything to 4 digits Sounds like a good idea to me FWIW. The 2-digit years came about because rms optimized it with lawyers umpteen years ago. When I questioned him about it more recently (maybe only .3umpteen years :), he went back to the lawyers and this time the advice was to always use four-digit years. As usual with these matters, there is no pressing need to go back and change all the existing notices, but the more that get converted to the currently-standard form, the better. k
nohup causes clisp startup to sigsegv
Running nohup from coreutils 7.4, GNU clisp crashes on startup: nohup /home/karl/src/clisp/clisp-build/clisp -q -norc -c ../../../../../utils/xindy/rte/ordrules/ordrulei.lsp -o ordrulei.fas nohup: ignoring input and appending output to `nohup.out' Segmentation fault The output from clisp is below, indicating stack overflow. The input file is tiny (2k) and about as trivial as one can imagine, just making a few definitions. Attaching it. Of course the crash happens with any lsp input file, as far as I can tell. It makes no difference whether the nohup is put in the background or not. I've tried increasing the stack space with ulimit. No difference. Not even the numbers in the crash output about number of bytes allocated/in use/free change. Running clisp directly, without nohup, works fine. Running nohup from coreutils 5.2.1 (actually /usr/bin/nohup Red Hat WS4) also works fine. Normal output below also. Here are the lines around 527 of eval.d: /* we used to start a new driver() here, but this is wrong because it does not clean up SP back_trace, just STACK, see https://sourceforge.net/tracker/?func=detailatid=101355aid=1448744group_id=1355 we probably cannot even do NOTREACHED - the STACK is bad. */ fprintf(stderr,\n[%s:%d] reset() found no driver frame (sp=0x%x-0x%x)\n, __FILE__,__LINE__,(aint)SP_anchor,(aint)SP()); abort(); This is with clisp 2.44.1 that I compiled myself a year or so ago. I don't know if it will reproduce with different versions of clisp, or if versions of other things might be relevant. ? Thanks, Karl --- Failing output: *** - Program stack overflow. RESET [/home/karl/src/clisp/clisp-2.44.1/src/eval.d:527] reset() found no driver frame (sp=0xbfffdc00-0xbfffd814) *** - handle_fault error2 ! address = 0x7019 not in [0x20240004,0x204aadc4) ! SIGSEGV cannot be cured. Fault address = 0x7019. Permanently allocated: 92096 bytes. Currently in use: 4194664 bytes. Free space: 473272 bytes. -- Successful output: ;; Compiling file /home/texlive/karl/Build/source/utils/xindy/rte/ordrules/ordrulei.lsp ... ;; Wrote file /home/texlive/karl/Build/source/Work/utils/xindy/rte/ordrules/ordrulei.fas ;; Wrote file /home/texlive/karl/Build/source/Work/utils/xindy/rte/ordrules/ordrulei.c 0 errors, 0 warnings ordrulei.lsp Description: Binary data ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: inetutils ChangeLog doc/Makefile.am doc/inetuti...
After the patch I installed to inetutils [1], Which is good, thanks. So in gnulib, I propose we deprecated 'fdl' and ask maintainers to depend directly on 'fdl-1.3' or whatever version they need. Thoughts? Makes sense to me. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Bugs in unexpand(1) version 6.10
$ ls --version ls (GNU coreutils) 6.12 Packaged by ... some distro string here ... That looks like the right place to me. I'd be tempted to put a blank line between Packaged by ... and Copyright Please include a url to your downstream coreutils package in the distro string. This seems fine, but can we also include the information in --help, which is what we did when we amended the coding standards a few days ago? For instance, grep 2.5.4 --help ends with: Report bugs to: bug-g...@gnu.org GNU Grep home page: http://www.gnu.org/software/grep/ General help using GNU software: http://www.gnu.org/gethelp/ I suggest having another line such as Gentoo Grep home page and bug reports: http://whatever between Report bugs to and GNU Grep home page. Perhaps even the address in Report bugs to: should be changed also. Perhaps that same line should be used in --version and --help. I assume we're trying to get across the same information. karl ___ 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
coreutils.texi node comm/ptx/tsort node ordering
Either the menu or the node ordering should be changed. And the tsort background node should be mentioned, or perhaps made a subsection of tsort invocation. * comm invocation:: Compare two sorted files line by line. * ptx invocation:: Produce a permuted index of file contents. * tsort invocation::Topological sort. ... @node comm invocation ... @node tsort invocation ... @node tsort background ... @node ptx invocation Perhaps makeinfo should warn about such mismatches, but meanwhile ... karl ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
mv missing destination operand message
I don't know if you want to make this tiny change, but: $ mv foo mv: missing destination file operand after `/u/karl/tmp/paper.ltx' The destination operand doesn't have to be a file, it is often a directory. So I suggest deleting file. Not that I will argue if you decide not to :). karl ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [Coreutils-announce] coreutils-6.11 released
If not, I'll be happy to do it. Please! Thanks, k ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Bug#388684: coreutils: info ls opens the man page, not the info documentation
Maybe the better fix would be renaming all the nodes in coreutils.texi to comply with this convention? I think the node names should stay as they are. The convention is either Invoking xxx or xxx invocation. http://www.gnu.org/prep/standards/html_node/Manual-Structure-Details.html I originally named the nodes in the coreutils manual (well, it was the three *utils at the time) using the latter so that completion would work better. (Aside: a depressing number of GNU manuals don't follow either convention; standalone info has a ton of special cases built into it. :() As for the original report: | Emit info coreutils 'PROG invocation' into the man page, | rather than just info PROG. The latter would often fail | or simply display the man page. I suppose it is more reliable to say info coreutils 'PROG invocation', although it seems a shame to replace a simple command with a more complex one. What this report really says to me is that the dir file was not correctly created by the Debian (or whatever) installation process. If you actually install the coreutils manual in the normal way, you will get dir file entries for all the programs, and info PROG will then work fine. karl ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Bug#388684: coreutils: info ls opens the man page, not the info documentation
jimm info simply displays the first node it finds with a name matching jimm pr. In my case, it is currently the PreScript node of a2ps.info. What? That makes no sense to me at all. Info doesn't look inside every info file randomly looking for nodes to match. It has to be in a dir file. karl ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Bug#388684: coreutils: info ls opens the man page, not the info documentation
mstone The debian install-info routine (IIRC) predates the gnu install-info, That wasn't my understanding, but I never actually researched it. I was not aware of any Debian ii at the time that rms wrote GNU ii (I was maintaining Texinfo by then -- 1996), but then, I probably wouldn't have been. Anyway, whatever. The situation is what it is. and hasn't been updated to recognize certain directives in newer info files. The main directive (START-INFO-DIR-ENTRY) has been there basically since the beginning of Info, not just install-info. I am pretty sure Debian ii recognizes it, otherwise it wouldn't do anything useful at all. Something else must be going on. Like, they don't install the coreutils manual. Whatever ... Unfortunately, the gnu install-info isn't a drop in replacement for debian one, either. Fortunately, after years of talk between me and various Debian people, a new volunteer (Ben Asselstine) has implemented all of the Debian ii behavior in GNU ii. I'm working towards a new Texinfo release now, primarily because of that work. Of course Debian ii will continue to exist for many years, in all the existing releases at least. jimm (it seems it's been at least two years, now). More like a decade. karl ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
printf --help
The --help message for printf (coreutils 6.9) starts with this: Usage: /usr/local/gnu/bin/printf FORMAT [ARGUMENT]... or: /usr/local/gnu/bin/printf OPTION Print ARGUMENT(s) according to FORMAT. --help display this help and exit --version output version information and exit I'd like to suggest a tiny change, something like: Print ARGUMENT(s) according to FORMAT, or execute according to OPTION: Right now, there's nothing explicitly saying that --help and --version are the options. I admit it's unlikely to be a point of confusion (especially for anyone who can figure out how to invoke coreutils printf in the first place :), but is there any harm in saying it explicitly? Thanks for coreutils :). karl ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
coreutils bootstrap cvs -z3
The bootstrap script in coreutils hardwires -z3 in the cvs call:
cvs -z3 -q -d ${CVS_PREFIX}cvs.savannah.gnu.org:/cvsroot/gnulib co gnulib ||
Could you leave that up to the installer? On one of my servers, due to
firewalls (I guess), compressed cvs traffic does not work reliably. I
doubt I'm the only one stuck with that problem.
(Yes, it's obviously trivial to modify the script, but ...)
Thanks,
k
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: YYYYMMDD HHMMSS [TZ] ?
It already supports -MM-DD HH:MM:SS (also with TZ). I know, and I am glad, but as I wrote in my original message, the forms without punctuation would also be useful (to me anyway) to support. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: YYYYMMDD HHMMSS [TZ] ?
date -d can understand MMDD HHMM [TZ]. Would MMDD HHMMSS [TZ] be possible? Hmm, does the first form actually work for you? You're right, with the TZ it doesn't. Sorry for my confusion. date -d '20070507 1138' is ok, date -d '20070507 1138 -0700' is invalid. Supporting YYYMMDD HHMMSS (without the TZ) would be useful too, if the TZ causes extra complications (easy to imagine). since the code is pretty funky at this point. I think it has been since day 1 :). But date -d is still such a great thing ... thanks, k ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
YYYYMMDD HHMMSS [TZ] ?
date -d can understand MMDD HHMM [TZ]. Would MMDD HHMMSS [TZ] be possible? I'd love it if MMDD.HHMMSS and/or MMDD.HHMMSS.TZ could be supported too (this is a very convenient format since it's a number that can be sorted), but I think I already asked for that and it was problematic for some reason. So the form with the spaces is the next choice ... Thanks, Karl ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: date -d YYYYMMDD.HHMM
treats MMDD.HHMM as a count of seconds to the nearest 10,000th of It does? $ date -d 20070307.1010 date: invalid date `20070307.1010' coreutils 6.7. This error message is the reason I felt it was worth taking up your time with at all; if it already had/has an alternative interpretation, then it's certainly not worth dealing with. Thanks, k ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
date -d YYYYMMDD.HHMM
Would it hard for date -d to accept MMDD.HHMM as well as MMDD HHMM? I often use the period, since then it's a number that can at least be compared ... Thanks, karl ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
ls -s --help description, coreutils 6.3
With coreutils 6.3, ls --help says: -s, --size with -l, print size of each file, in blocks Unless I'm missing something, -s is honored even without -l: $ \ls -s nihaya.png 4 nihaya.png And this behavior seems fine? So I suggest changing help text to something like this: -s, --size prepend size of each file, in blocks Happy blocking, k ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: OT: latest stable version not recommended
with http://directory.fsf.org/gzip.html; no mention there)... which, of 1.3.5 is mentioned on that Directory page as the (devel) release. Anyway, I wrote rms about the lack of official releases in recent decades. k ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
defaults in join doc
I ran across some notes from 10 or so years ago reminding me that the
list of defaults in the join documentation might be more readable as an
itemized list. Better late than never, maybe. Here's a diff:
*** /usr/local/gnu/src/coreutils-5.3.0/doc/ORIG/coreutils.texi Fri Jan 7
12:09:47 2005
--- /usr/local/gnu/src/coreutils-5.3.0/doc/coreutils.texi Sun Aug 14
16:38:53 2005
***
*** 4670,4678
@end example
! The defaults are: the join field is the first field in each line;
! fields in the input are separated by one or more blanks, with leading
! blanks on the line ignored; fields in the output are separated by a
! space; each output line consists of the join field, the remaining
fields from @var{file1}, then the remaining fields from @var{file2}.
The program accepts the following options. Also see @ref{Common options}.
--- 4670,4682
@end example
! The defaults are:
! @itemize
! @item the join field is the first field in each line;
! @item fields in the input are separated by one or more blanks, with leading
! blanks on the line ignored;
! @item fields in the output are separated by a space;
! @item each output line consists of the join field, the remaining
fields from @var{file1}, then the remaining fields from @var{file2}.
+ @end itemize
The program accepts the following options. Also see @ref{Common options}.
Diff finished at Sun Aug 14 16:40:49
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: copyright message with(out) directives
+the GNU General Public License http://www.gnu.org/licenses/gpl.html.\n\ I've never seen a url in this message before, for any program. Not that I object, I guess it makes sense, but it seems new? You said you found this in the coding standards, but I'm not seeing it ... ? Not that it's a big deal. Thanks, karl ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [bug-gnulib] Re: getopt and Solaris 10
GNU getopt tries to do too much when it reorders the commandline and therefor needs the + as a workaround. I don't suppose it matters at this point, but I fail to see the connection here. You can tell GNU getopt to REQUIRE_ORDER instead of PERMUTE without using +, either directly or setting POSIXLY_CORRECT in various ways. See the __ordering enum in getopt_int.h, for example. (Seems like you probably already know this, so maybe it's unsuitable somehow, if so, sorry for the noise.) Also, I don't agree that it is doing too much to have PERMUTE be the default for GNU. It is very useful for most programs. cvs has exceptional command-line parsing needs. Happy hacking, karl ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: mktexpk: non-POSIX compliant use of tail
_POSIX2_VERSION in unistd.h, in descending order of importance. One of the great things about GNU software in the past was that it basically behaved the same (as much as possible) independent of the host system. It did not gratuitiously change behavior based on system settings. Thus, it seems like this new reliance on _POSIX_VERSION to determine functionality (installation options are no problem) is a step backwards. Thomas has coreutils 5.3.0 on a relatively modern (GNU/)Linux system. I have coreutils 5.3.0 on a relatively modern (GNU/)Linux system. Yet they behave noticeably differently. This never used to be the case. I can't see who it helps to do it this way. Determining whether something like tail -10 is supported seems like a choice that could be made by the system builder, eg, someone at Red Hat; and then, isn't it better if individuals installing coreutils-5.3.0.tar.gz always get the same behavior, regardless of what the system builder decided? I can't think of any other package that behaves like this. A simple portable equivalent to tail -1 is sed -n '$p'. That sounds like an excellent answer for mktexpk. Thanks. (You weren't persistent enough. :-) I never even got an automated acknowledgement on any comment I sent on, let alone any human feedback, so I figured it was a black hole, and stopped bothering. [compromise] Well, I'm glad to hear it, I guess, although from what you describe the result is nearly nil. And tail -1 is just one example. It's worth emphasizing that this compromise wouldn't affect portable POSIX applications, as they still won't be able to rely on tail -1. You don't want to hear this, just ignore me, but I can't stop myself from saying it one more time. flame on POSIX was supposed to be about portability and unifying the different Unix variations. It did a good job for many years. Then, IMHO, it should have disbanded. But no, it had to go on and start prescribing new behavior the way Unix should have been design, instead of codifying existing practice of the way Unix *is*. As a result, these backward-incompatibilities in recent versions of POSIX have vastly *decreased* portability and usability. In the past, tail -10 worked. It always worked. It worked on every Unix system anyone cared about (at least the couple of dozen or so that I used). Then POSIX comes along, and, *in the name of portability*, says oh no, you've been doing it wrong all these years, now you must use tail -n 10. The result is bad for everyone. tail -n 10 cannot be used in truly portable scripts (as opposed to merely POSIX portable ones), because it will not work on older systems. tail -10 cannot be used because it won't work on new systems that strictly conform to POSIX's madness. So nothing can be used. And this is an improvement? Well, nothing can be done about POSIX, but then there's the whole GNU situation. GNU is supposed to be about what is best *for users*. Not blindly kowtow to standardized stupidity. The coding standards explicitly say this. And yet one of the important packages in GNU is also one of the most POSIX-submissive. What harm can there be in *GNU* tail always accepting tail -10? I do not buy the you have to support only the strictly POSIX way or you encourage unportability argument; indeed, it seems to me that if you do it the strictly POSIX way you are *maximizing* the chance of being unportable. Oh well, you and Jim have heard all this stuff from me too often already, and I know you don't agree, and no one else can do anything about it. I'll shut up now (I can hear the sigh of relief :) and go crawl back into my hole. flame, and everything else, off karl ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: mktexpk: non-POSIX compliant use of tail
I wonder if dropping this kind of compatibility with old UNIX systems is done for a good reason. Don't get me started! (I have complained about precisely these backward-incompatibilities in POSIX many times, to zero effect.) mktexpk from tetex 3.0 uses tail -1, which is not POSIX compliant, and does not work with GNU coreutils 5.3.0. In this particular case ... tail -1 works for me with coreutils 5.3.0. $ tail -1 /etc/issue $ tail --version tail (GNU coreutils) 5.3.0 ... ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: date -d 'Jun 05 23:59:59 GMT+00:00 2006'
The .us whois server outputs dates in this stupid (subject) format. Can date reasonably recognize them? I think it could, if only GMT and/or UTC is used. Sounds fine. From the .us whois server, I have only ever seen that exact format, always with GMT+00:00. For example: $ whois dredging.us ... Domain Registration Date:Thu Jun 27 02:47:46 GMT+00:00 2002 Domain Expiration Date: Sun Jun 26 23:59:59 GMT+00:00 2005 Domain Last Updated Date:Mon Jun 14 17:58:18 GMT+00:00 2004 However, we'd need to know how to interpret the sign; does GMT+07:00 mean 7 hours ahead of UTC (e.g., Vietnam) or 7 hours behind (e.g., Arizona)? I think it's safe to assume + would be ahead, eg, Vietnam. When does + ever mean behind? (I've never seen that particular craziness, but I suppose I'm not surprised.) Is the format documented anywhere? I took a quick look (www.neustar.us) and didn't find anything. I'd be very surprised to see a domain registrar actually document something technical ... Thanks, karl ___ Bug-coreutils mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/bug-coreutils
coreutils 5.0: misalignment of `Used' with df -m
Maybe this is brokenness in the POSIX spec, but it looks to me like the `Used' heading should be shifted over three spaces or so with df -mP: $ df -mP Filesystem 1048576-blocks Used Available Capacity Mounted on /dev/hdb331497 6789 23109 23% / /dev/hdb1 48541 419 9% /boot /dev/hdb482977 22502 56260 29% /u ... (This is coreutils on Linux, as you can tell :) (I noticed this because I usually have alias df=df -P so I always get one line per filesystem...) Thanks, karl ___ Bug-coreutils mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-coreutils
