bug#71307: Mention recommended styles

[Dan Jacobson]

(info "(coreutils) sort invocation")

First problem. We see e.g.,
"try the ‘--debug’ option"
but '--debug' is not clickable.
If we want to go to its section to read more,
the best we can do is isearch-forward for it.

Next problem. We read

 Also note that the ‘n’ modifier was applied to the field-end
 specifier for the first key. It would have been equivalent to
 specify ‘-k 2n,2’ or ‘-k 2n,2n’. All modifiers except ‘b’ apply to
 the associated _field_, regardless of whether the modifier
 character is attached to the field-start and/or the field-end part
 of the key specifier.

Make sure to mention the recommended style, yes, even though both work
the same.

In fact the style shown all over the page 2,2n isn't the best! I think
you should change all the examples to 2n,2.

Why? Well, think about it, for say 2,5n.. We instruct you to start at
field 2, then go to field 5, and only then do we remember to tell you we
want our sort to be numeric. Sure, the program waits until it gets all
the facts before proceeding. But internally it is actually doing 2n and
then 5, no matter what we gave it, so in fact allowing people to write
2,5n is just an unfortunate choice that now must be grandfathered along
not to break scripts. What's so bad about it? Well one day the program
could have been made even a tiny bit faster by not needing the extra
step of cleaning up for loose input standards.

Anyway just like we specify our meals and seat preferences before
stepping on the plane, and not when getting off, the 2n,2 2n,5 style is
better to recommend.

Coreutils 9.4.

bug#71171: ls -U, -f: document the other half of the story too

[Dan Jacobson]

Man ls says:
   -U do not sort; list entries in directory order
Please make it say:
   -U do not sort; list entries in the order they were given on
   the command line, and files within directories using their
   directories' order

And on (info "(coreutils) Sorting the output") please change:

‘-U’
‘--sort=none’
 Do not sort; list the files in whatever order they are stored in
 the directory.  (Do not do any of the other unrelated things that
 ‘-f’ does.)  This can be useful when listing large directories,
 where sorting can take some time.

to instead say:

‘-U’
‘--sort=none’
 Do not sort; list the files in the order they were given on the
 command line, and files within directories in whatever order they
 are stored in the directory. (Do not do any of the other unrelated
 things that ‘-f’, above, does.) This can be useful when listing
 large directories, where sorting can take some time.

Proof:

$ echo $PATH | tr -s : \\n
/home/jidanni/bin
/usr/local/sbin
/usr/local/bin
/usr/local/games
/usr/sbin
/usr/bin
/usr/games
/sbin
/bin
$ echo $PATH | tr -s : \\n | xargs ls -Uogd
drwxr-xr-x 1   632 05-24 05:47 /home/jidanni/bin
drwxr-xr-x 1 0 04-17 12:34 /usr/local/sbin
drwxr-xr-x 1 0 04-17 12:34 /usr/local/bin
drwxr-xr-x 1 0 04-17 12:34 /usr/local/games
drwxr-xr-x 1  6028 05-23 07:42 /usr/sbin
drwxr-xr-x 1 19542 05-23 20:01 /usr/bin
drwxr-xr-x 1 0 01-29 05:20 /usr/games
lrwxrwxrwx 1 8 04-17 12:34 /sbin -> usr/sbin
lrwxrwxrwx 1 7 04-17 12:34 /bin -> usr/bin

Above, -U thankfully allows me to keep the output in the order I gave it!

Wait,
man ls:
 -f list all entries in directory order

Same problems all over again with -f documentation.

So please also update the man ls and Info ls "-f" discussions to include
the command line order, as I did above for -U. Thanks.

ls (GNU coreutils) 9.4

bug#70876: Making join Info examples easier to test

[Dan Jacobson]

Today I tried to run these examples on
(info "(coreutils) Paired and unpaired lines")
it says:
 All examples below use the following two (pre-sorted) input files:

 $ cat file1  $ cat file2
 a 1  a A
 b 2  c C

How about instead, something like
echo a 1 > file1
echo b 2 >> file1

echo a A > file2
echo c C >> file2

That way the user could create the files themselves without much hassle.
Just pipe that part of the page into the shell.

You can even still have the cats after the creation.
But please remember to just use one column.

bug#70874: Don't use two column Info examples, e.g. for join

[Dan Jacobson]

I would say please give up attempting two column examples, e.g., on
(info "(coreutils) Paired and unpaired lines")

Yes, they look great in the standalone Info reader,
$ info

But in emacs -Q -f info
we start to see problems.
And then e.g., using https://www.jidanni.org/comp/configuration/.emacs
things look worse

bug#70873: join --return-error-if-any-unmatched-lines

[Dan Jacobson]

join should have an option to return an error value in the shell's $?
if any lines are not matched.

Currently the man page doesn't even mention a return value. So it is not
set in stone yet.

Currently one must save -v output in a file then use test -s do detect
if there were any non-matched lines. And then exit one script with
non-zero. Big hassle.

join (GNU coreutils) 9.4

bug#70532: sort: Mention counting fields from the end

[Dan Jacobson]

> "PB" == Pádraig Brady  writes:
PB> All good suggestions. I'll at least add an example along the lines of:

PB>   awk '{print $NF, $0}' | sort -k1,1 | cut -f2- -d' '

OK, also say what it's doing. Not everybody knows awk.

Also join(1) needs a tip added. Users might want to join on
e.g., the second to last field on a variable-number-of-fields file.

bug#70601: join(1) info page -o: too hazy at first

[Dan Jacobson]

The join main page is really clear,

   -o FORMAT
  obey FORMAT while constructing output line

A base hit on the first pitch. The info page on the other hand,

‘-o FIELD-LIST’
‘-o auto’
 If the keyword ‘auto’ is specified, infer the output format from
 the first line in each file.  This is the same as the default
 output format but also ensures the same number of fields are output
 for each line.  Missing fields are replaced with the ‘-e’ option
 and extra fields are discarded.

even after reading down to here, hasn't tipped the user off that it is
talking about the output format! It's its turn up to bat but it's still
drinking coffee in the bullpen.

In fact FIELD-LIST vs FORMAT make the user double check that they are
actually looking at the same commands' documentation.

bug#70600: trailing whitespace spotted in join info pages

[Dan Jacobson]

The join info pages have tons of trailing whitespace.
sed s/$/$/ reveals:

‘sort -u file1 file2’Union of unsorted files$
 $
‘sort file1 file2 | uniq -d’ Intersection of unsorted files$
 $
‘sort file1 file1 file2 | uniq -u’   Difference of unsorted files$
 $
‘sort file1 file2 | uniq -u’ Symmetric Difference of unsorted$
 files$

Or in emacs
(progn
  (setq-default show-trailing-whitespace t)
  (info "(coreutils) Set operations"))
will drive home the point.
Same with some other pages in that manual.

Why bad? It says that whatever typesetting program you are using, is
like a broken Xerox machine that is spitting out extra blank pages,
wasting paper. Even if we're rich so who cares.

bug#70599: join vs. numeric order

[Dan Jacobson]

(info "(coreutils) Sorting files for join") needs to talk about numeric
order.

$ seq 111|join --check-order - /dev/null
join: -:10: is not sorted: 10

So the info manual needs to mention 'Even though your files might be in
perfect "sort --numeric-sort" order, you need to make them into plain
"sort" order first. Sorry. At least you'll get the same number of joins.'

Or, add a new join -n option. The join man page could now say:
'-n: use numeric comparisons. Note sort order also needs to be "sort -n" order.'

And / or mention how the user might tinker with LC_NUMERIC and / or
LC_COLLATE to somehow achieve numeric sorting...

bug#70532: sort: Mention counting fields from the end

[Dan Jacobson]

In (info "(coreutils) sort invocation") be sure to add an example of a
way or workaround for counting fields from the end of the line. E.g., we
want to sort on the last field, but don't know for sure how many fields
a line might contain. E.g., sort by surname, when lines consist of First
[Middle...] Surname. perl -a uses $F[-1]. so maybe sort(1) could also
use a negative field number. Same for character number.

sort (GNU coreutils) 9.4

bug#67619: stty on Chromebook

[Dan Jacobson]

Seen on Chromebook:
$ stty speed
38400
$ stty speed 1200
38400
$ stty speed 1200
1200

coreutils 9.4

bug#67543: mv -i e/a f/a g: asks bad

[Dan Jacobson]

Here the program should think ahead,
so that it won't ask a question that
it could already know the answer to.
$ mkdir e f g
$ touch e/a f/a
$ mv -i e/a f/a g
mv: overwrite 'g/a'? y
mv: will not overwrite just-created 'g/a' with 'f/a'

I'm not sure what it should do. Just don't have it ask things that will
turn out different that it could already know would happen.
mv (GNU coreutils) 9.4

bug#62492: Note each util's URL on their Info pages too, not just man page

[Dan Jacobson]

Just the other day I wanted to tell my friends about e.g., the uniq
command. I wanted to "share" it with them.

OK on (info "(coreutils) uniq invocation") there is no "share" URL.

However on
$ man uniq
there is!:

   Full documentation 
   or available locally via: info '(coreutils) uniq invocation'

Therefore on each coreutils individual Info page please be sure to also
note that utils' URL.

bug#62249: uniq -D long option name missing from man page

[Dan Jacobson]

man uniq has all the other long option names, except for -D's

   -d, --repeated
  only print duplicate lines, one for each group

   -D print all duplicate lines

   --all-repeated[=METHOD]
  like  -D,  but  allow  separating  groups  with  an  empty line;
  METHOD={none(default),prepend,separate}

One needs to see (info "(coreutils) uniq invocation") to find it.
Please add it to the man page.

bug#61696: Warn about sort --numeric-sort --unique data loss

[Dan Jacobson]

At (info "(coreutils) sort invocation") it says
  For example, ‘sort -n -u’ inspects only the value of the initial
  numeric string when checking for uniqueness, whereas ‘sort -n | uniq’
  inspects the entire line. *Note uniq invocation::.

OK, but you still need to add a warning about data loss.

Here's a shell script:

k="3 Billy
17 Villy
4 Nibblesberg
3 Philbert
3 Billy"
c=sort
echo We sort the students [$c]
echo "$k" | $c
c="sort --numeric-sort"
echo Oh my gosh, we must use [$c]
echo "$k" | $c
c="sort --numeric-sort --unique"
echo Yuck, let\'s eliminate the duplicates too [$c]
echo "$k" | $c
echo Oops, we caused \"data loss\". Good thing we noticed it.
c="sort --unique" d="sort --numeric-sort"
echo Let\'s try it the right way: [$c \| $d]
echo "$k" | $c | $d

Running it shows:
We sort the students [sort]
17 Villy
3 Billy
3 Billy
3 Philbert
4 Nibblesberg
Oh my gosh, we must use [sort --numeric-sort]
3 Billy
3 Billy
3 Philbert
4 Nibblesberg
17 Villy
Yuck, let's eliminate the duplicates too [sort --numeric-sort --unique]
3 Billy
4 Nibblesberg
17 Villy
Oops, we caused "data loss". Good thing we noticed it.
Let's try it the right way: [sort --unique | sort --numeric-sort]
3 Billy
3 Philbert
4 Nibblesberg
17 Villy

Sure, you might say, "That's already mentioned" (in the fine print). "The
reader just needs to put 2 + 2 together in their heads." Yes, but
anyway, the document needs to drive home the point more.

Maybe the man page should say so too.

bug#61467: Don't assume short/long options for error messages

[Dan Jacobson]

$ sort --human-numeric-sort -nr
sort: options '-hn' are incompatible

Say instead:
sort: options --human-numeric-sort (-h), and --numeric-sort (-n), are 
incompatible.

Else some projects might be delayed by days, as some people need to
email other people to ask...

"Can't blame me. That's not what I typed. I typed -nr, not -hn. Sue me."

bug#61248: uniq --unique needs examples

[Dan Jacobson]

BV> While an example is always nice, isn't the last part of the above
BV> exactly telling what it's doing?

That is for experts to know. The rest of us need examples,
sort of like your idea, (please modify):

$ echo a a a b c c b b d b | xargs --max-args=1 | uniq --unique
b
d
b

bug#61248: uniq --unique needs examples

[Dan Jacobson]

uniq INFO page says:
‘-u’
‘--unique’
 Discard the last line that would be output for a repeated input
 group.  When used by itself, this option causes ‘uniq’ to print
 unique lines, and nothing else.

This really needs some examples, to help people understand what it means.

bug#52453: Full timezone name

[積丹尼 Dan Jacobson]

>>>>> "PE" == Paul Eggert  writes:
PE> On 12/12/21 07:27, 積丹尼 Dan Jacobson wrote:
>> Also mention something about how to get the full timezone name.

PE> Unfortunately at the coreutils level that information is not available
PE> in any portable or reliable way.

OK. Good. At the bottom of the page do mention that.
Else people wonder why it is not one of the choices.

bug#52453: Full timezone name

[積丹尼 Dan Jacobson]

On (info "(coreutils) Time conversion specifiers")

‘%Z’
 alphabetic time zone abbreviation (e.g., ‘EDT’), or nothing if no
 time zone is determinable.  See ‘%z’ for how it is determined.

Also mention something about how to get the full timezone name.

E.g., show instead of CST: Central Standard Time, or China Standard Time, or
China Central Standard Time, etc.

bug#51288: Break date SYNOPSIS into two sections

[積丹尼 Dan Jacobson]

On the 'date' man and info pages,

SYNOPSIS
   date [OPTION]... [+FORMAT]
   date [-u|--utc|--universal] [MMDDhhmm[[CC]YY][.ss]]

Synopses:

 date [OPTION]... [+FORMAT]
 date [-u|--utc|--universal] [ MMDDhhmm[[CC]YY][.ss] ]

please break these down into:

printing the date:

 date [OPTION]... [+FORMAT]

setting the date:

 date [-u|--utc|--universal] [ MMDDhhmm[[CC]YY][.ss] ]
 date [-s|--set] DATESTR

else the user in a panic to set the date, will try
# date -s 10140110
date: cannot set date: Invalid argument
Mon Jan 10 00:00:00 LMT 1014
Instead of
$ date10140110

Only on
(info "(coreutils) Setting the time")
is the mystery revealed. P.S., on that page you should mention the
MMDDhhmm... string again, not just its components.

bug#50694: ls and cpio's idea of "six months ago" are slightly different

[積丹尼 Dan Jacobson]

What a headache.
"Six months ago" means slightly different things to cpio and ls.
And ls documents do say exactly what,
and cpio documents don't even say six months.

$ cat prover
set -eu
cd /tmp
for i in `seq 170 190`
do
touch -d "$i days ago" x
{
env - ls -l x|tr -s ' '
ls x|cpio -o 2>&-|cpio -tv 2>&-|tr -s ' '
} > z
if test `sort -u z|wc -l` != 1
then cat z; echo
fi
done
$ sh prover
-rw-r--r-- 1 jidanni jidanni 0 Mar 23 12:47 x
-rw-r--r-- 1 jidanni jidanni 0 Mar 23 2021 x

-rw-r--r-- 1 jidanni jidanni 0 Mar 22 12:47 x
-rw-r--r-- 1 jidanni jidanni 0 Mar 22 2021 x

So two things that should look the same ... don't.

What's worse is there is no option to change cpio's date format.

Well then just change ls's date format to match cpio's right?
Well yes, but then there is no way to change ls's idea of six months,
even if we examined cpio's source code to find out what it uses.

$ ls --version
ls (GNU coreutils) 8.32
Copyright (C) 2020 Free Software Foundation, Inc.

$ cpio --version
cpio (GNU cpio) 2.13
Copyright (C) 2017 Free Software Foundation, Inc.

bug#49764: tr invocation INFO page missing list of options

[積丹尼 Dan Jacobson]

(info "(coreutils) tr invocation")
all the options don't appear together on the same page.
Only the man page's DESCRIPTION has them all together.

bug#49503: Mention workarounds, so one could achieve the Debian version sorting algorithm

[積丹尼 Dan Jacobson]

(info "(coreutils) Differences from the official Debian Algorithm") and
(info "(coreutils) Minus/Hyphen and Colon characters")
could mention workarounds, so one could indeed achieve the Debian
Algorithm.
Or mention the only way is to use
dpkg --compare-versions
(on pairs only.)

bug#48248: tr docs: mention what to expect now vs. future

[積丹尼 Dan Jacobson]

(info "(coreutils) tr invocation") says
   Currently ‘tr’ fully supports only single-byte characters.
   Eventually it will support multibyte characters; when it does, the ‘-C’

And the man page has no warning at all. #BUG. Please add one.

BTW,

$ echo 哇|tr 哇 123
123

It works fine! (People will think.)

Therefore be sure to mention just when it will start failing, with real 
examples,

$ echo 哇|tr 哇 1
111
$ echo 哇|tr 哇 1234
123
$ echo 哇哇|tr 哇 1234
123123
$ echo 哇哇姑五湖|tr 哇 1234
1231231__五湖

$ echo "22°56'52.2\"N 121°14'09.3\"E" | tr ° d
22dd56'52.2"N 121dd14'09.3"E

Also on the INFO page, give examples of, for the same input,
what to expect now, and what to expect in the future.

bug#47891: sort --numeric-sort-Extra-Strength

[積丹尼 Dan Jacobson]

Let's face it, sort, no matter what --option, or LC_... value,
just can't achieve this order:

3－1號邊
3號之1
3號之2
30

What's the miracle kid (me) doing right that sort(1) just can't sort
out yet?

Mom told me "Just sort by numbers."

See https://www.jidanni.org/geo/house_numbering/sorting/ in your spare time.

bug#47859: Additional seq outlandish example: seq 0 dangers

[積丹尼 Dan Jacobson]

On (info "(coreutils) seq invocation") we read
   Be careful when using ‘seq’ with outlandish values: otherwise you
   may...

Here's another 'fun/sad/DDOS yourself' example you might add:

One day I wrote a Makefile,
m:
seq 0 9|sed s/$$/號.html/|xargs make
but before using it, I though I'll just test with one item,
m:
seq 0  |sed s/$$/號.html/|xargs make
well of course... as seq prints nothing here,
this triggered a massive ever growing recursive loop...

Yes, all my fault for picking 0. I'll pick 1 next time.

P.S., perhaps document how to get seq to cough up just "0". One way I
found was:
$ seq 0 1 0
0

bug#47858: Document that FULLWIDTH DIGITs boggle coreutils brain currently

[積丹尼 Dan Jacobson]

(info "(coreutils) Correct/Incorrect ordering and Expected/Unexpected results")
needs to "admit" or "at least mention" that "coreutils just hasn't thought 
about FULLWIDTH
DIGITs yet." I.e., Europeans are in luck. East Asians are out of luck.

$ seq 9 11|sort
10
11
9
$ seq 9 11|sort -n
9
10
11
$ seq 9 11|sort -V
9
10
11

$ echo -e ９\\n１０\\n１１|sort
１０
１１
９
$ echo -e ９\\n１０\\n１１|sort -V
１０
１１
９
$ echo -e ９\\n１０\\n１１|sort -n
１０
１１
９

$ unicode ９
U+FF19 FULLWIDTH DIGIT NINE
UTF-8: ef bc 99 UTF-16BE: ff19 Decimal:  Octal: \0177431
９
Category: Nd (Number, Decimal Digit); East Asian width: F (fullwidth)
Unicode block: FF00..FFEF; Halfwidth and Fullwidth Forms
Numeric value: 9
Digit value: 9
Bidi: EN (European Number)

Decomposition:  0039

Nope, LC_ALL=zh_TW.UTF-8 didn't help.
sort (GNU coreutils) 8.32

bug#47700: Backup options vs. file extensions

[積丹尼 Dan Jacobson]

(info "(coreutils) Backup options") is great, except,
it needs examples of how one can preserve file extension with it.

E.g., x.jpg~ messes up plenty of viewers, but x~.jpg is fine.
Same with numbered backups.

So the page should discuss this problem, and mention workarounds.

bug#47703: Mention if ln -s needs -r, or ln -r needs -s

[積丹尼 Dan Jacobson]

man ln says:

   -r, --relative
  create symbolic links relative to link location

   -s, --symbolic
  make symbolic links instead of hard links

Does -s need -r,
or   -r need -s?

Hard to tell from the man page.

Had to find out the 'hard' way.

Please mention the answer on the man page.

Thanks.

bug#47702: wc man page: first you are talking about bytes, then you are talking about characters

[積丹尼 Dan Jacobson]

Man wc says

   Print newline, word, and byte counts for each FILE, and a total line if
   more than one FILE is specified.  A word is a non-zero-length  sequence
   of characters delimited by white space.

first you are talking about bytes, then you are talking about
characters.

So for the latter, please say
characters (not bytes)
or
characters (same as bytes)
or just
bytes
Yes, even if explained in the INFO file.
Thanks.

bug#47701: Add ln --dry-run

[積丹尼 Dan Jacobson]

$ ln -rbsv ~/Downloads/*/95*[0-9].jpg xiangpianjibentu
'xiangpianjibentu/95212025.jpg' -> 
'../../../../Downloads/ViewLarge_Draw_files/95212025.jpg'
'xiangpianjibentu/95212033.jpg' -> 
'../../../../Downloads/ViecccwLarge_Draw_files/95212033.jpg'
'xiangpianjibentu/95212025.jpg~' ~ 'xiangpianjibentu/95212025.jpg' -> 
'../../../../Downloads/ViewLarge_Draw_files/95212025.jpg'
'xiangpianjibentu/95212026.jpg' -> 
'../../../../Downloads/ViewLargeddd_Draw_files/95212026.jpg'
'xiangpianjibentu/95212034.jpg' -> 
'../../../../Downloads/ViewLargvvve_Draw_files/95212034.jpg'
'xiangpianjibentu/95212045.jpg' -> 
'../../../../Downloads/ViewxxxLarge_Draw_files/95212045.jpg'

Wow, that was a pretty fancy result.

However the only way to find out what will happen is to cross one's
fingers and run the command and hope for the best.

So perhaps add a --dry-run.

It would print (when -v is used), but not do, the above.

(Except probably for the one backup file.)

Anyway, we all know that sometimes ln syntax is tricky,
so perhaps add --dry-run.

bug#47353: Numbered backups also need kept-new-versions else will grow out of control

[積丹尼 Dan Jacobson]

All I am saying is 'to acknowledge the hazards'... 'Advisory on
prolonged use'. 'Note about health effects of unattended use.'

For all the user knows reading
(info "(coreutils) Backup options")
maybe numbered backups even just means one backup, numbered ...1.

bug#47353: Numbered backups also need kept-new-versions else will grow out of control

[積丹尼 Dan Jacobson]

> "CE" == Chris Elvidge  writes:

CE> So 'use common sense to limit disk space used' has to be stated in the
CE> manual?

Hmmm, yes.
And also mention in the manual that e.g., emacs has methods to trim
these automatically, but coreutils hasn't implemented them yet.

Else users will write elaborate programs to do it, thinking that nobody
thought about it yet.

bug#47353: Numbered backups also need kept-new-versions else will grow out of control

[Dan Jacobson]

Or (info "(coreutils) Backup options") should "admit" that "Numbered
backups need to be trimmed occasionally by the user, lest the fill up
the disk."

bug#47352: Numbered backups also need kept-new-versions else will grow out of control

[Dan Jacobson]

(info "(coreutils) Backup options") has "numbered",
but without a corresponding limit factor, these can grow beyond belief.

So coreutils also needs a way to say like emacs does:

kept-new-versions is a variable defined in ‘files.el’.
Documentation:
Number of newest versions to keep when a new numbered backup is made.
Includes the new backup.  Must be greater than 0.

bug#46346: wc --human-readable or --verbose

[積丹尼 Dan Jacobson]

wc needs a --verbose option. Else one is forced to do:

$ file=e.html; echo $file:; for i in bytes chars lines words; do echo -en 
$i:\\t; wc --$i < $file; done
e.html:
bytes:  31655
chars:  29141
lines:  643
words:  1275

I mean sometimes we want to send the output to a real person, and
currently all wc makes is:

$ wc e.html
  643  1275 31655 e.html
$ file=e.html; for i in bytes chars lines words; do wc --$i < $file; done
31655
29141
643
1275

So there needs to be a --verbose or --human-readable like du(1)... oops
I don't mean saying 234M... yet.

bug#46060: Offer ls --limit=...

[積丹尼 Dan Jacobson]

> "PE" == Paul Eggert  writes:
PE> That argument would apply to any program, no? "cat", "diff", "sh",
PE> "node",

PE> Not sure why "ls" needs a convenience flag that would complicate the
PE> documentation and maintenance and be so rarely useful.

OK, then I'll close the bug then.

bug#46060: Offer ls --limit=...

[積丹尼 Dan Jacobson]

E.g.,
"What is API pagination? Some APIs, such as Contacts can return millions
of results. We obviously can't return all of them at once, so we need to
return a subset - or a page - at a time. This technique is called paging
and is common to most APIs. Paging can be implemented in many different
ways, some better than others."
Anyway, this ls command was built in the early years of computer science...

bug#46060: Offer ls --limit=...

[積丹尼 Dan Jacobson]

Sure, it is against the https://en.wikipedia.org/wiki/Unix_philosophy, but
just like SQL has LIMIT,
and
$ unicode --help
  -m MAXCOUNT, --max=MAXCOUNT
Maximal number of codepoints to display...

Just like "we want to stop pollution at the source", not always "clean up after 
it".

bug#46060: Offer ls --limit=...

[積丹尼 Dan Jacobson]

I hereby propose "ls --limit=..."

$ ls --limit=1 # Would only print one result item:
A

You might say:
"Jacobson, just use "ls|sed q". Closed: Worksforme."

Ah, but I am talking about items, not lines:

$ ls
A  B  C  D
E  F  G  H
I  J  K  L
$ ls -C|sed 2q
A  B  C  D
E  F  G  H
$ ls -C --limit=2
AB
$ ls--limit=2
AB

Indeed, directories might be huge. And any database command already has
a --limit option these days, and does not rely on a second program to
trim its output because it can't control itself. Indeed, on some remote
connections one would only want to launch one program, not two. Thanks.

bug#44975: Warn that fold will wreck UTF-8

[積丹尼 Dan Jacobson]

On (info "(coreutils) fold invocation") warn that fold will wreck UTF-8
files, shattering any multibyte character that unfortunately lies near
its chopper.

(GNU coreutils) 8.32

bug#44959: date error message should say -I

[積丹尼 Dan Jacobson]

Well OK, but when and when not to use the "=" is not revealed by the
otherwise detailed error messages. So unless the user checks the manual,
they will never "get it".

bug#44960: date --expose-flags

[積丹尼 Dan Jacobson]

date +%Y-%m-%dT%H:%M:%S%z
^I meant %:z

> Then one needn't use trial and error

(Driving my point home.)

bug#44960: date --expose-flags

[積丹尼 Dan Jacobson]

I got this brilliant idea.
Let's say one likes the output of

$ date --iso-8601=seconds
2020-11-30T21:15:47+08:00

but wants to know "how you did it?"

Hmmm, no assistance from
$ date --iso-8601=seconds --debug
2020-11-30T21:15:50+08:00

Ah, if only there were a:
$ date --iso-8601=seconds --expose-flags
date +%Y-%m-%dT%H:%M:%S%z

Then one needn't use trial and error to figure out the template being
used behind the scenes!

date (GNU coreutils) 8.32

bug#44959: date error message should say -I

[積丹尼 Dan Jacobson]

$ date -I=seconds
date: invalid argument ‘=seconds’ for ‘--iso-8601’

Hey, that is a valid argument for --iso-8601. (But not for -I, so say
that instead.)

Here is a real invalid argument:

$ date --iso-8601=secondsz
date: invalid argument ‘secondsz’ for ‘--iso-8601’

date (GNU coreutils) 8.32

bug#44770: chown: warn about the dot when encountering it

[積丹尼 Dan Jacobson]

Maybe print warning messages when encountering the dot,
(info "(coreutils) chown invocation")
Else Grandpa won't ever know,
https://github.com/scop/bash-completion/issues/468
until one day when it's too late...
(And his program starts messing things up on some other system.)

bug#40943: nl: add way to exclude matching lines from getting numbered!

[積丹尼 Dan Jacobson]

(info "(coreutils) nl invocation") says
 ‘pBRE’
  number only lines that contain a match for the basic regular
  expression BRE.  *Note Regular Expressions: (grep)Regular
  Expressions.

OK, but add a new functionality:
 ‘PBRE’
  Do NOT number lines that contain a match for the basic regular
  expression BRE.  *Note Regular Expressions: (grep)Regular
  Expressions.

$ nl --version
nl (GNU coreutils) 8.30

bug#40942: Clean up mailing list confusion on web page

[積丹尼 Dan Jacobson]

https://www.gnu.org/software/coreutils/ mentions coreut...@gnu.org and
bug-coreutils@gnu.org (and the term mailing list and the term bug tracker
many times, all intertwined and perhaps repeating.)

Maybe only mention each one once, with a description of what they are
below it.

So that would be a total of two items.

bug#40633: Document / implement sorting via absolute value

[積丹尼 Dan Jacobson]

(info "(coreutils) sort invocation")
should mention how to sort via absolute value,
or add an option to do it.
Currently one must use e.g.,
$ seq -2 2|perl -pe 's/^(-)(.*)/$2$1/;' | sort -n
0
1
1-
2
2-

bug#40363: date: add Julian day number output format

[積丹尼 Dan Jacobson]

date(1) should add "Julian day number" or the "Astronomical day
number" (see (info "(emacs) Calendar Systems") output format.

Else for crontab(5) one must do
   # Run once per 48 hours (every other day), even across week, month, and 
year boundaries:
   33 22 * * * expr $(date +\%s) / 60 / 60 / 24 \% 2 > /dev/null && 
echo Check the toilet tissue.

Instead of just
   33 22 * * * expr $(date +\%J) \% 2 > /dev/null && echo Check the 
toilet tissue.
(assuming %J is the Julian day number.)

Currently you have day of the week, day of the month, day of the year,
seconds from second #1. Years from year #1, but no days from "day #1".

bug#39613: stat(1) shouldn't call permissions "Access..."

[積丹尼 Dan Jacobson]

(info "(coreutils) stat invocation") says,
   • %a - Access rights in octal (note ‘#’ and ‘0’ printf flags)
   • %A - Access rights in human readable form

But man find says,
   -perm mode
  File's permission bits are exactly mode (octal or symbolic).  
Since an exact match is required,  if
  you want to use this form for symbolic modes, you may have to 
specify a rather complex mode string.
  For example `-perm g=w' will only match files which have mode 
0020 (that is, ones for  which  group
  write  permission is the only permission set).  It is more likely 
that you will want to use the `/'
  or `-' forms, for example `-perm -g=w', which matches any file 
with group  write  permission.   See
  the EXAMPLES section for some illustrative examples.

   -perm -mode
  All  of  the  permission bits mode are set for the file.  
Symbolic modes are accepted in this form,
  and this is usually the way in which you would want to use them.  
You must specify `u', `g' or  `o'
  if you use a symbolic mode.  See the EXAMPLES section for some 
illustrative examples.

   -perm /mode
  Any  of  the  permission bits mode are set for the file.  
Symbolic modes are accepted in this form.
  You must specify `u', `g' or `o' if you use a symbolic mode.  See 
the EXAMPLES section for some il‐
  lustrative  examples.   If no permission bits in mode are set, 
this test matches any file (the idea
  here is to be consistent with the behaviour of -perm -000).

   -perm +mode
  This is no longer supported (and has been deprecated since 2005). 
 Use -perm /mode instead.


So stat's man and Info pages shouldn't use "Access" to talk about them.
Especially as it pretty much means something else:

   -readable
  Matches files which are readable by the current user.  This takes 
into account access control lists
  and other permissions artefacts which the -perm test ignores.  
This test makes use of the access(2)
  system call, and so can be fooled by NFS servers which do UID 
mapping  (or  root-squashing),  since
  many  systems  implement access(2) in the client's kernel and so 
cannot make use of the UID mapping
  information held on the server.

bug#39017: Mention more about uniq failure exit status

[積丹尼 Dan Jacobson]

(info "(coreutils) uniq invocation") says
   An exit status of zero indicates success, and a nonzero value
   indicates failure.

The user wonders:
"Failure to make a file unique because it was already unique?"
Be more explicit.

bug#38780: date: next feb 11

[積丹尼 Dan Jacobson]

date -d should add a way to say "next feb 11" or "next 2/11" etc.
E.g., at(1) knows we are always talking about the coming Feb. 11,
and not the one that has already passed in the current year.
Just like we can say "next Friday" and "last Friday" currently.

bug#36220: ls -l: maddening mixed left right justifications with numeric ids

[積丹尼 Dan Jacobson]

> "PE" == Paul Eggert  writes:
PE> On 6/17/19 8:12 AM, Pádraig Brady wrote:

PE> I prefer the current ("maddening") behavior, as it gives the reader a
PE> useful signal that the user is numeric rather than textual. This is
PE> particularly important when a user name consists entirely of digits,
PE> which is allowed on some systems. In that case, left alignment of a
PE> string like "" means it's a textual user name, whereas right
PE> alignment means it's a numeric user ID. Admittedly the disambiguation
PE> is not perfect (as there is no cue when the user name has the maximum
PE> width) but it's helpful in common practice.

PE> I thought this was all documented somewhere - at least, it was a
PE> conscious decision when I wrote that code long ago.

Indeed all you need to do would me mention the logic there on INFO "ls"
and we would realize that this was actually a feature.

bug#36220: ls -l: maddening mixed left right justifications with numeric ids

[積丹尼 Dan Jacobson]

> "PB" == Pádraig Brady  writes:
PB> to know if it was a common issue, as I've not encountered it at least.

Well as the anbox Android emulator could possibly become very popular,
ls should be ready for a big influx of numeric ids.

bug#36220: ls -l: maddening mixed left right justifications with numeric ids

[Dan Jacobson]

Some files might only have numeric user ids,

# ls -l
-rw-r--r-- 1  777 root   0 06-15 10:14 a
-rw-r--r-- 1 root 77 0 06-15 10:11 b
-rw-r--r-- 1 root root   0 06-15 10:12 c
-rw-r--r-- 1 root777 0 06-15 10:12 d

Well it turns out an undocumented feature is that numeric ids are
justified in the opposite direction of regular ids.

Makes sense, however it wreaks havoc in the above mixed situations.

The only way to get columns to line up in such mixed situations is

# ls -ln
-rw-r--r-- 1 777  0 0 06-15 10:14 a
-rw-r--r-- 1   0 77 0 06-15 10:11 b
-rw-r--r-- 1   0  0 0 06-15 10:12 c
-rw-r--r-- 1   0777 0 06-15 10:12 d

but that sacrifices the names.

Well at least on (info "(coreutils) What information is listed") at

‘-n’
‘--numeric-uid-gid’
 Produce long format directory listings, but display numeric user
 and group IDs instead of the owner and group names.

document that "Note that numeric ids are always right justified."

ls (GNU coreutils) 8.30

bug#35748: Add cut FIELD-LIST examples

[積丹尼 Dan Jacobson]

> "EB" == Eric Blake  writes:
EB> No need to open a second bug to tell us that the first was not a problem
EB> after all. I'm merging the two bugs in the database, and marking the
EB> issue closed.

It takes several minutes before the bug number is created, so there is a
tradeoff between proper vs. speedy followups.

bug#35748: Add cut FIELD-LIST examples

[積丹尼 Dan Jacobson]

Oh, I see, it is mentioned above it.
Sure wish "(see above)" was there.

bug#35747: Add cut FIELD-LIST examples

[積丹尼 Dan Jacobson]

On (info "(coreutils) cut invocation")

with no examples for

   ‘-f FIELD-LIST’
   ‘--fields=FIELD-LIST’
Select for printing only the fields listed in FIELD-LIST.  Fields
are separated by a TAB character by default.  Also print any line
that contains no delimiter character, unless the ‘--only-delimited’
(‘-s’) option is specified.

one might even one is to put tabs in our FIELD-LIST, or maybe dashes or
commas. And maybe ranges are not supported, etc.

bug#35343: sort: printing characters: define

[積丹尼 Dan Jacobson]

Well all I know is e.g., perl's man perlrecharclass is
more detailed than
(info "(coreutils) Character sets") section,
(which (info "(coreutils) sort invocation") perhaps should also link to.)
Anyways, coreutils should at least link to a definite statement...

bug#35431: Mention "cp -l a b is exactly equivalent to ln a b"

[積丹尼 Dan Jacobson]

On (info "(coreutils) cp invocation") at

   ‘-l’
   ‘--link’
Make hard links instead of copies of non-directories.

Mention

"Exactly equivalent to ln."

or

 "cp -l a b is exactly equivalent to ln a b."

Or if not, mention why.

bug#35343: sort: printing characters: define

[積丹尼 Dan Jacobson]

(info "(coreutils) sort invocation") says

‘-i’
‘--ignore-nonprinting’
 Ignore nonprinting characters.  The ‘LC_CTYPE’ locale determines
 character types...

Well this leaves the user high and dry trying to figure out what you
mean by printing characters.

Is SPC a printing character he wonders. It makes the printer head
advance one unit, whereas ESC doesn't.

So at least mention the ASCII range [A-Z...] of what your are talking
about. It would only take up a word or two of the INFO page.

Anyway, each program might have their own idea of "printing characters"
as well as grandpa down the hall's definition. So the user is left unsure.

bug#35336: date should respect TIME_STYLE too

[積丹尼 Dan Jacobson]

All the other utilities respect the environment variable ‘TIME_STYLE’,
except date(1) itself! Date should be no different...

bug#35335: touch --verbose

[積丹尼 Dan Jacobson]

Say, rm, cp, mv have --verbose.
How about for touch too?
Then one wouldn't need
$ set -x; touch /tmp/{a,b,c}.el; set +x
+ touch /tmp/a.el /tmp/b.el /tmp/c.el
to see what it was touching or not.

bug#34988: mv: check before asking users useless questions

[積丹尼 Dan Jacobson]

> "LSS" == Leslie S Satenstein  writes:
LSS> Did you consider that more than one terminal can be open, and at the
LSS> second terminal, "b" could be renamed before replying to the mv
LSS> command?

I don't know about all that. Let's hope the designers consider all aspects.

bug#34664: Mention wc default action on man page

[積丹尼 Dan Jacobson]

Well
> Print  newline,  word,  and  byte  counts
might sound like
> Play movies, audio files, and even ...

Sort of like a list of capabilities.

> "PB" == Pádraig Brady  writes:
PB> I'm confused. It says 'bytes', and means it.
PB> One has to specify -m to select characters.

But OK, fine.

bug#34670: Implement "seq infinity"

[積丹尼 Dan Jacobson]

I can do
$ sleep infinity
so why not
$ seq infinity
also?

bug#34669: Document sleep infinity

[積丹尼 Dan Jacobson]

$ man sleep | grep -ic infinity
0
$ sleep --help | grep -ic infinity
0
$ info sleep | grep -ic infinity
0
$ /bin/sleep infinity #But it still works, so please document it.

bug#34664: Mention wc default action on man page

[積丹尼 Dan Jacobson]

INFO says
   By default, ‘wc’ prints three counts: the newline, words, and byte
and wc --help even more so.

Alas man wc doesn't say if what we are looking at is bytes or
characters, so kindly mention the default on the man page!

bug#34488: Add sort --limit, or document workarounds for sort|head error messages

[積丹尼 Dan Jacobson]

Thanks for working on this guys, hopefully users will one day no longer
be faced with (yes, seemingly) random errors.
$ ls -l | sed 2!d
drwxr-xr-x 14 jidanni jidanni  4096 2016-12-24  AndroidMisc
$ ls -l | sed 2q
total 157780
drwxr-xr-x 14 jidanni jidanni  4096 2016-12-24  AndroidMisc
ls: write error: Broken pipe

bug#34490: console the user that his -n in sort --debug -n was seen

[積丹尼 Dan Jacobson]

> "PB" == Pádraig Brady  writes:
PB> Fair point. I'm thinking of this extra qualification:

PB>   sort: text ordering performed using ‘en_IE.UTF-8’ sorting rules
Maybe say  'LC_CTYPE=en_IE.UTF-8' 
sorting rules

PB>   sort: text ordering performed using simple byte comparison

sort: text ordering performed using simple byte (LC_CTYPE=C) comparison
or something like that.

bug#34488: Add sort --limit, or document workarounds for sort|head error messages

[積丹尼 Dan Jacobson]

(I recall I heard about 50 years ago when pipe buffers first came to
Unix they were supposed to be invisible to the user...)

bug#34475: Mention even more worries for test -a

[積丹尼 Dan Jacobson]

By the way
https://lists.gnu.org/archive/html/bug-bash/2019-02/msg00052.html
says "... contradictory description in the coreutils info document."

bug#34488: Add sort --limit, or document workarounds for sort|head error messages

[積丹尼 Dan Jacobson]

> "EB" == Eric Blake  writes:

>> And no fair saying "just save the output" (could be big) "into a file
>> first, and do head(1) or sed(1) on that."

EB> If you have an app that exits noisily on write failures to an early-exit
EB> pipe, your solutions are to quit ignoring SIGPIPE, or to change the
EB> pipeline to consume all of the output instead of exiting early and
EB> causing write failure.

OK, it seems that indeed it would then be best to document:

 If you want to make sure no such errors occur on large output,
 instead of
 $ sort | head
 use
 $ sort > file; head file

as an _easy to remember_ alternative amongst the many.

And OK put this in some general place, and have the sort, etc. pages
link to it. Thanks.

bug#34490: console the user that his -n in sort --debug -n was seen

[積丹尼 Dan Jacobson]

Can you please have assure the user in that message it makes
that it has indeed seen his -n/--numeric-sort.

$ sort --debug
sort: using simple byte comparison
$ sort --debug --numeric-sort
sort: using simple byte comparison
    unchanged. User gets nervous.

sort (GNU coreutils) 8.30. Sorry we discussed this before but kinda hard to 
find...

bug#34488: Add sort --limit, or document workarounds for sort|head error messages

[積丹尼 Dan Jacobson]

> "AG" == Assaf Gordon  writes:
AG> The errors are not "random" - they happen because you explicitly
AG> cut short the output of a program.

Well the user thinks "hey I cut short 5 lines, 45 lines, 495 lines, and
then one I got a job at a big company and cut short 4995 lines and got
this error message just when the boss was looking."

So be sure to mention it. Thanks.

bug#34488: Add sort --limit, or document workarounds for sort|head error messages

[積丹尼 Dan Jacobson]

Things start out cheery, but quickly get ugly,

$ for i in 9 99 999  9; do seq $i|sort -n|sed 5q|wc -l; done
5
5
5
5
sort: write failed: 'standard output': Broken pipe
sort: write error
5
sort: write failed: 'standard output': Broken pipe
sort: write error

Therefore, kindly add a sort --limit=n,
and/or on (info "(coreutils) sort invocation")
admit the problem, and give some workarounds, lest
our scripts occasionally spew error messages seemingly randomly,
just when the boss is looking.

And no fair saying "just save the output" (could be big) "into a file
first, and do head(1) or sed(1) on that."

bug#34475: Mention even more worries for test -a

[積丹尼 Dan Jacobson]

First, on the test(1) man page, at


   EXPRESSION1 -a EXPRESSION2
  both EXPRESSION1 and EXPRESSION2 are true

   EXPRESSION1 -o EXPRESSION2
  either EXPRESSION1 or EXPRESSION2 is true


Say instead

   EXPRESSION1 -a EXPRESSION2
  both EXPRESSION1 and EXPRESSION2 are true (See warning NOTE 
below.)

   EXPRESSION1 -o EXPRESSION2
  either EXPRESSION1 or EXPRESSION2 is true (See warning NOTE 
below.)

else users who never make it down to the "fine print at bottom" will
blithefully use them a lifetime without ever an inkling of the dangers!

(Indeed on (info "(coreutils) Connectives for test")
you discuss the dangers first, before even letting the users eyeballs
touch the syntax!)

Also on both man and info pages you need to warn of portability worries,
e.g., in bash we see -a and -o do even more things.

$ help test|egrep -- ' -(a|o) '
  -a FILETrue if file exists.
  -o OPTION  True if the shell option OPTION is enabled.
  EXPR1 -a EXPR2 True if both expr1 AND expr2 are true.
  EXPR1 -o EXPR2 True if either expr1 OR expr2 is true.

bug#34347: At least add 2nd comm error message after output

[積丹尼 Dan Jacobson]

(info "(coreutils) comm invocation")

"Before ‘comm’ can be used, the input files must be sorted"
 
"If an input file is diagnosed as being unsorted, the ‘comm’ command
will exit with a nonzero status (and the output should not be used).
 ^

"Forcing ‘comm’ to process wrongly sorted input files ... is not
guaranteed to produce any particular output. The output will probably
not correspond with whatever you hoped it would be."

OK, so I would change the default.

The new default should be: before producing even a line of output,
check both files. If either of them is in order, print the error
message, and exit non-zero... _without any line of output!_

Because currently,

$ seq 55 > 5
$ seq 55 |tac > 5r
$ comm 5 5r
just causes the error messages to fly off the screen, leaving only the
savvy user, who checks exit values, to have any inkling that there is a
problem, and he should not order futher warships, airplanes, etc. based
on the results after all.

OR, be so kind as to add a second error message after all the output is
printed, so it won't fly off the screen.

bug#34026: mention that long options aren't always as good as short options

[積丹尼 Dan Jacobson]

Yes do warn in the manual, as here root (so no $HOME) expected tilde
expansion... Thanks.

bug#34026: mention that long options aren't always as good as short options

[積丹尼 Dan Jacobson]

On (info "(coreutils) Common options")
mention that, though clearer, long options aren't always as good as short 
options,
$ touch --reference=~jidanni/.pcmanx /cf/pcmanx_time
touch: failed to get attributes of '~jidanni/.pcmanx/pcmanx': No such file or 
directory
Unless one removes the '=':
$ touch --reference ~jidanni/.pcmanx/pcmanx /cf/pcmanx_time
$
(due to the shell helping out with "~...")

bug#34009: warn that mkdir --mode doesn't affect parents created

[積丹尼 Dan Jacobson]

On man mkdir

   -m, --mode=MODE
  set file mode (as in chmod), not a=rwx - umask

   -p, --parents
  no error if existing, make parent directories as needed

do warn that --mode doesn't affect any parents created.

$ mkdir --mode 700 -p /tmp/g/h/i
$ find /tmp/g -ls
55795  0 drwxr-xr-x   3 jidanni  jidanni60 Jan  7 23:30 /tmp/g
55796  0 drwxr-xr-x   3 jidanni  jidanni60 Jan  7 23:30 /tmp/g/h
55797  0 drwx--   2 jidanni  jidanni40 Jan  7 23:30 
/tmp/g/h/i

Also warn on (info "(coreutils) mkdir invocation") more directly. Thanks.

bug#26902: good invalid dates vs. bad invalid dates

[積丹尼 Dan Jacobson]

Maybe it should try to pass on to the user at least an error code:
Invalid date: error code 0754,
or even better, an mention of what error it hit.

bug#33025: Add examples of why one would want to "sort" something "randomly"

[積丹尼 Dan Jacobson]

> "AG" == Assaf Gordon  writes:

AG> (It doesn't deal with "why", that is left to the users to decide when
AG> they need it, but it shows clear examples of how to use it).

Maybe add "For example, you might want to hear your songs in a fresh fun
order. Or make sure your program still works even if the moms come
between or after the pops..."
https://www.google.com/search?q=reasons+for+random+order

bug#33577: ls lacks null terminator option

[積丹尼 Dan Jacobson]

Fine. Put a message on top of (info "(coreutils) ls invocation")
saying that your pipes are better.

bug#33577: ls lacks null terminator option

[積丹尼 Dan Jacobson]

Are you saying you want to enhance find(1) to sort its output?

bug#33577: ls lacks null terminator option

[積丹尼 Dan Jacobson]

Don't let that ls colors stuff fool you. It originally didn't have that.

bug#33577: ls lacks null terminator option

[積丹尼 Dan Jacobson]

(Probably The Unix Programming Environment by K & P.)

bug#33577: ls lacks null terminator option

[積丹尼 Dan Jacobson]

Bob, I remember from my K Unix book that ls can be used in scripts.
In fact that is why
$ ls
acts different than
$ ls | cat

Plus there are lots of things ls can do that find cannot.

For instance sorting.

How are you going to do
$ ls -t
with find?

bug#33577: ls lacks null terminator option

[積丹尼 Dan Jacobson]

For files with blanks in their names,
one shouldn't need this workaround:
$ ls -t | tr \\n \\0 | xargs -0 more > /tmp/z.txt
Please add a --print0 option. like find(1) has.

ls (GNU coreutils) 8.30

bug#23302: mention what are nonprinting characters

[積丹尼 Dan Jacobson]

Good! You need to then tie all the documentation you found, into the
coreutils documentation, as the official declaration of what you mean.
Just like "man perlrecharclass - Perl Regular Expression Character
Classes" does. I mean one cannot just hope the user will "Google" and
then land on "Wikipedia" and hope what is there is 100% the same.

bug#23302: mention what are nonprinting characters

[積丹尼 Dan Jacobson]

Yes but every program has slightly different sets of non-printing
characters, so they need to list them exactly.

bug#21349: acknowledged by developer (Re: bug#21349: who shows no users nowadays on Debian)

[積丹尼 Dan Jacobson]

(Today on Debian I see
$ who
jidanni  pts/02018-10-25 06:26 (:0)
So maybe this is fixed.)

bug#18479: acknowledged by developer ()

[積丹尼 Dan Jacobson]

As you can see, the Subject got damaged somehow when sending this
message to me.

(Subject: Re: bug#18479 acknowledged by developer ())

> "GbTS" == GNU bug Tracking System  writes:
GbTS> This is an automatic notification regarding your bug report
GbTS> #18479: date -d 'today - month',
GbTS> which was filed against the coreutils package.

GbTS> Thank you for your report, which has now been closed.
GbTS> You can view the full report at
GbTS> http://debbugs.gnu.org/cgi/bugreport.cgi?bug=18479

GbTS> If you require further information, please followup to 
18...@debbugs.gnu.org.

GbTS> debbugs.gnu.org maintainers
GbTS> (administrator, GNU bugs database)

bug#14971: acknowledged by developer (Re: bug#14971: split man page table mushed)

[積丹尼 Dan Jacobson]

Say, can we get the final information just from this email next time,
just like in Debian. Where one doesn't need to click on the link to see
how the bug was solved.


> "GbTS" == GNU bug Tracking System  writes:
GbTS> This is an automatic notification regarding your bug report
GbTS> #14971: split man page table mushed,
GbTS> which was filed against the coreutils package.

GbTS> Thank you for your report, which has now been closed.
GbTS> You can view the full report at
GbTS> http://debbugs.gnu.org/cgi/bugreport.cgi?bug=14971

GbTS> If you require further information, please followup to 
14...@debbugs.gnu.org.

GbTS> debbugs.gnu.org maintainers
GbTS> (administrator, GNU bugs database)

bug#18328: can't say date -d '8pm -0500' though other combos work

[積丹尼 Dan Jacobson]

AG> I hope to get to this bug soon.

Good.

bug#33025: Add examples of why one would want to "sort" something "randomly"

[積丹尼 Dan Jacobson]

On (info "(coreutils) sort invocation")

‘-R’
‘--random-sort’
‘--sort=random’
 Sort by hashing the input keys and then sorting the hash values.
 Choose the hash function at random, ensuring that it is free of
 collisions so that differing keys have differing hash values.  This
 is like a random permutation of the inputs (*note shuf
 invocation::), except that keys with the same value sort
 together...

OK, but you need to mention some examples of why someone would want to
"sort" something "randomly".

OK, I have one:

You have a list of URLs.

You know there are probably duplicates in there, that you want to get
rid of.

But you also don't want to make it look like you have "machine sorted
them." You want them to still look "hand assembled."

So you use sort --random-sort --unique on them!

bug#31055: Document ls -Ur -fr

[積丹尼 Dan Jacobson]

(info "(coreutils) Sorting the output") says

‘-r’
‘--reverse’
 Reverse whatever the sorting method is—e.g., list files in reverse
 alphabetical order, youngest first, smallest first, or whatever.

OK but mention 'whatever' doesn't mean -U, -f, because they are sorted
in "unsorted" order. In fact perhaps trigger an error.

Actually directory order is still an order, so in fact it is odd that -r
is "broken" here.

bug#31038: mv copies in ls -r order

[積丹尼 Dan Jacobson]

OK. Please on (info "(coreutils) cp invocation") at
‘-v’
‘--verbose’
 Print the name of each file before copying it.
add:

"(Note this reveals internal order of operations, often in ls -U order,
thus occasionally appearing to be in ls, ls -t, ls -r, ls -rt etc. order.)"

(I mean on the same page you do go into such details:

‘-a’
‘--archive’
 Preserve as much as possible of the structure and attributes of the
 original files in the copy (but do not attempt to preserve internal
 directory structure; i.e., ‘ls -U’ may list the entries in a copied
 directory in a different order).  Try to preserve SELinux security
 context and extended attributes (xattr), but ignore any failure to
 do that and print no corresponding diagnostic.  Equivalent to ‘-dR

)