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
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
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
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
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
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
$ 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,
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
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
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
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
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
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 ...
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
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
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
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
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
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
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
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
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
(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
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
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 \
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
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
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
[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
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
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
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.
___
$ 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.
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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:
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
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
+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
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
_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
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
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
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
56 matches
Mail list logo
