bug#50691: pwd: options with "--" (multiple dashes) return bad option

[L A Walsh]

Try 'command pwd --version'

On 2021/09/19 16:09, william wrote:

coreutils version 8.32

The commands

pwd --version

and

pwd --help

return

pwd: bad option: -v
pwd: bad option: -h

bug#49994: upgrade: have "-s" of 'ls' display alloc'd sizes for specified "--block-size"

[L A Walsh]

On 2021/08/20 11:31, Paul Eggert wrote:

On 8/20/21 10:40 AM, L A Walsh wrote:

 I wanted it just to work


So use 'stat -c "%s %n"'. That works just fine. 'stat' is a good tool 
for this job, and there's no need for yet another 'ls' option for this 
rare use case.


stat doesn't come close.
I wanted the automatic-multi column output of 'ls' like "ls -s" gives, 
but instead of the disk-space-allocated number as 'du' would be

sufficient for, I wanted 'byte' output -- like the default output of 'ls'
gives.

By default, ls gives you names, or with -l gives you bytes.  If you want
a short form that gives you bytes+name, the obvious attempt would be
use of -s with a flag that would say to display bytes.

This rare use case? Having a file-list command that 
displays filename+size in a compact form seems one of the

top use use-cases.  Yet that seems to be missing.

The default of ls -s should be to display size, not allocated blocks, since
if you want that, 'du' is what first comes to mind to find the
diskspace-used.

bug#49994: upgrade: have "-s" of 'ls' display alloc'd sizes for specified "--block-size"

[L A Walsh]

On 2021/08/20 08:08, Paul Eggert wrote:

On 8/20/21 12:02 AM, L A Walsh wrote:


When I use "-b" in du (equivalent to '--apparent-size --block-size=1)


Previously in this thread you asked for "allocated space for a file on a 
device", which is why I was talking about that number.

---
	No, I wanted space that "would" be allocated on a device if the 
device allocated size in bytes -- which is what 'du' does.


I even said I wanted the output of ls's block-size output to be
enhanced to pay attention to what users specify via that parameter.
I wanted a simple multi-column output like 'ls' provides.  


I wanted it just to work -- not require a program or figuring it out
but just have it be user-friendly -- something the tools designed by gnu
definitely are not.

bug#49994: upgrade: have "-s" of 'ls' display alloc'd sizes for specified "--block-size"

[L A Walsh]

On 2021/08/18 08:39, Paul Eggert wrote:
Perhaps your request would be more clear if you gave a specific example 
of what you want and why --block-size doesn't do what you want.



I wanted to use ls to list the size of files in bytes, and use
Binary prefixes K=1024, M=1024**2, G=1024**3 to display
the the numeric portion with a maximum 3 digits or
use a floating point format with up to 1 digit to the right
of the decimal point: similar and as rounded by use of "%.1f"
as in printf.

Using a list of 577 files in file "files.txt", the existing 'ls'
using:

cat files.txt|xargs /usr/bin/ls --block-size=1 -1dhsS

Instead of displaying the file sizes in bytes, it showed them
rounded to the nearest 4K, so sorting by size and displaying
only the 1st of a given size, I only ended up with 13 unique 
file-sizes in the list:


312K lib/perl5db.pl
200K lib/Unicode/Collate/Locale/ja.pl
100K lib/Unicode/Collate/Locale/zh_pin.pl
96K ext/XS-APItest/t/utf8_warn_base.pl
36K regen/opcode.pl
32K ext/DynaLoader/DynaLoader_pm.PL
28K regen/feature.pl
24K ext/XS-APItest/t/handy_base.pl
20K Porting/checkURL.pl
16K Porting/corelist.pl
12K t/lib/dbmt_common.pl
8.0K dist/lib/lib_pm.PL
4.0K cpan/Pod-Simple/t/ascii_order.pl


I expected closer to 100 or more files displayed with size under
1000 bytes.

If 'ls' used the user-specified 'block-size' of 1 byte, the number
of files displayed is actually 279, or over 20 times the number
of files with some names elided for sake of brevity.

310K  lib/perl5db.pl
197K  cpan/Unicode-Collate/Collate/Locale/ja.pl
138K  regen/mk_invlists.pl
126K  Porting/bisect-runner.pl
...
53.3K win32/bin/search.pl
52.1K cpan/IO-Compress/t/compress/generic.pl
49.9K t/test.pl
46.4K utils/perlbug.PL
...
17.4K Porting/pod_lib.pl
17.1K Porting/add-package.pl

6.7K  dist/Devel-PPPort/Makefile.PL
6.6K  cpan/Sys-Syslog/Makefile.PL
6.5K  cpan/podlators/Makefile.PL
5.5K  cpan/Unicode-Collate/Collate/Locale/da.pl
5.4K  symbian/makesis.pl
...
1.2K  ext/Hash-Util/Makefile.PL
1.1K  win32/bin/perlglob.pl
1.0K  ext/File-Glob/Makefile.PL
997  cpan/Unicode-Collate/Makefile.PL
983  cpan/Unicode-Collate/Collate/Locale/mk.pl
...
125  dist/Time-HiRes/hints/sco.pl
110  ext/VMS-DCLsym/Makefile.PL
104  dist/Time-HiRes/hints/dynixptx.pl
101  cpan/DB_File/hints/dynixptx.pl
97  ext/POSIX/hints/mint.pl
94  dist/IO/hints/sco.pl

11  symbian/uid.pl
 6  t/op/svleak.pl
 3  t/run/dtrace.pl
 2  cpan/Module-Load-Conditional/t/to_load/LoadMe.pl

-

Instead 'ls' displays 4.0K for a file that is only 2 bytes.

Clearly it isn't using the block-size specified by the user
in the same way 'du' does:
cd /tmp
echo "1" >out.pl
du -b out.pl
2 out.pl
Ishtar:/tmp> /bin/ls --block-size=1 -1dhsS  /tmp/out.pl
4.0K /tmp/out.pl
---

When I use "-b" in du (equivalent to '--apparent-size --block-size=1),
I get a size of '2' which one would expect for a file with 2 chars in it.
however, ls displays 4.0K.  Clearly it isn't using the
--block-size=1 that 'du'  is using.

bug#49994: upgrade: have "-s" of 'ls' display alloc'd sizes for specified "--block-size"

[L A Walsh]

On 2021/08/17 16:00, Paul Eggert wrote:
That's different from displaying the size that would have been allocated 
on a device with a block size of 1 byte. 'du' can't do what you 
requested, any more than 'ls' can.



However you want to phrase it, with:

   --block-size=SIZE

I want to have 'ls'

   'scale sizes by SIZE before printing them'

bug#49994: upgrade: have "-s" of 'ls' display alloc'd sizes for specified "--block-size"

[L A Walsh]

On 2021/08/15 21:36, Paul Eggert wrote:

On 8/15/21 9:26 PM, L A Walsh wrote:

I don't want to display the allocated size on the current device,
but the size that would be allocated on a device with block-size=1-byte.


There's no practical way for 'ls' to calculate that, as the kernel 
doesn't reveal that information.


'du' can display sizes using and arbitrary block size with
no need for kernel support, but it doesn't have the format options
that ls has.

For determining the size with an arbitrary block size, the code
could just be dupped from 'du'.

bug#49994: upgrade: have "-s" of 'ls' display alloc'd sizes for specified "--block-size"

[L A Walsh]

On 2021/08/15 21:00, Paul Eggert wrote:

On 8/15/21 4:13 PM, L A Walsh wrote:

Hmm...  for libc.so, ls -l shows 253 bytes
for -s, it shows '4' and w/block-size=1, it shows
4096...


Right. That is, those numbers look right.


But I'm specifying a block size of 1 byte, to determine
what size it would take up on a device that allocates in 'bytes'.
I don't want to display the allocated size on the current device,
but the size that would be allocated on a device with block-size=1-byte.

bug#49994: upgrade: have "-s" of 'ls' display alloc'd sizes for specified "--block-size"

[L A Walsh]

(reposting w/list+bugdb)

Hmm...  for libc.so, ls -l shows 253 bytes
for -s, it shows '4' 
and w/block-size=1, it shows

4096...

My LS_OPTIONS is
LS_OPTIONS=-N --color=tty -T 0

-N for quoting and -T for no tabs

my version: rpm -qf /usr/bin/ls
coreutils-8.23-2.3.2.x86_64

may not be as current as yours, but it would be odd if it changed and
you didn't know...


Ishtar:/usr/lib64> command ls -lgG libc.so
-rw-r--r-- 1 253 Mar 11 11:22 libc.so
Ishtar:/usr/lib64> command ls -s libc.so
4 libc.so
Ishtar:/usr/lib64> command ls --block-size=1 -s libc.so
4096 libc.so


On 2021/08/11 00:40, Paul Eggert wrote:

On 8/10/21 11:56 PM, L A Walsh wrote:

Perhaps the '-s' option in ls could pay attention to
the user-specified block-size?


Doesn't it already do that?

$ ls -s libc.so
12192 libc.so
$ ls -s --block-size=1 libc.so
12484608 libc.so



On 2021/08/11 00:40, Paul Eggert wrote:

On 8/10/21 11:56 PM, L A Walsh wrote:

Perhaps the '-s' option in ls could pay attention to
the user-specified block-size?


Doesn't it already do that?

$ ls -s libc.so
12192 libc.so
$ ls -s --block-size=1 libc.so
12484608 libc.so

bug#49994: upgrade: have "-s" of 'ls' display alloc'd sizes for specified "--block-size"

[L A Walsh]

How can I find all perl source files under the
perl source tree sorted by size + displayed 
w/binary-metric prefixes.  I wanted to look for

a good sample for _some_ specific size (not sure
of the size until I'd looked through a few).

I got close using:
find -iname \*.pl |sed 's!./!!' |xargs /usr/bin/ls --block-size=1 -1dhsS

That gave 577 lines of output, but only displaying the 1st entry
of same-size, consecutive entries that only has 15 unique sizes:

312K lib/perl5db.pl
200K lib/Unicode/Collate/Locale/ja.pl
100K lib/Unicode/Collate/Locale/zh_pin.pl
96K ext/XS-APItest/t/utf8_warn_base.pl
36K regen/opcode.pl
32K ext/DynaLoader/DynaLoader_pm.PL
28K regen/feature.pl
24K ext/XS-APItest/t/handy_base.pl
20K Porting/checkURL.pl
16K Porting/corelist.pl
12K t/lib/dbmt_common.pl
8.0K dist/lib/lib_pm.PL
4.0K cpan/Pod-Simple/t/ascii_order.pl
4.0K t/run/dtrace.pl

Unfortunately, the "-s" param on 'ls' drops 99.98% of 
the size info.  If the -s parameter displayed allocated
space for a file on a device with the block-size 
as specified on the command line (useful for determining

how much space the files will take on some device
with a finer block-size).

Using the block size as specified by the user gives
279 uniquely-sized entries losing no information (0%)
on the sizes of the files, with only my elision
of names for the sake of less verbosity


310K  lib/perl5db.pl
197K  cpan/Unicode-Collate/Collate/Locale/ja.pl
138K  regen/mk_invlists.pl
126K  Porting/bisect-runner.pl
...
53.3K win32/bin/search.pl
52.1K cpan/IO-Compress/t/compress/generic.pl
49.9K t/test.pl
46.4K utils/perlbug.PL
...
17.4K Porting/pod_lib.pl
17.1K Porting/add-package.pl

6.7K  dist/Devel-PPPort/Makefile.PL
6.6K  cpan/Sys-Syslog/Makefile.PL
6.5K  cpan/podlators/Makefile.PL
5.5K  cpan/Unicode-Collate/Collate/Locale/da.pl
5.4K  symbian/makesis.pl
...
1.2K  ext/Hash-Util/Makefile.PL
1.1K  win32/bin/perlglob.pl
1.0K  ext/File-Glob/Makefile.PL
997  cpan/Unicode-Collate/Makefile.PL
983  cpan/Unicode-Collate/Collate/Locale/mk.pl
...
125  dist/Time-HiRes/hints/sco.pl
110  ext/VMS-DCLsym/Makefile.PL
104  dist/Time-HiRes/hints/dynixptx.pl
101  cpan/DB_File/hints/dynixptx.pl
 97  ext/POSIX/hints/mint.pl
 94  dist/IO/hints/sco.pl

 11  symbian/uid.pl
  6  t/op/svleak.pl
  3  t/run/dtrace.pl
  2  cpan/Module-Load-Conditional/t/to_load/LoadMe.pl

--


Perhaps the '-s' option in ls could pay attention to
the user-specified block-size?

bug#49428: RFE: for --time have option to only include contents, not dir itself.

[L A Walsh]

First stab at a script is really slow...

find dirs, then find all files in the dir:

There's gotta be a faster way...ug!

lastt=1
shopt -s lastpipe

find "$1" -depth -type d |
 while read dr;do
   t=$(find "$dr" -xdev -maxdepth 1 -mindepth 1 ! -name . -a ! -name .. 
-printf "%T@\n" |

   cut -d. -f1|sort -rn|head -1)
   if [[ ! $t ]]; then
 t=$lastt
   fi
   if [[ ! $t ]]; then
 echo "dir=$dr"; exit 1; fi
   #echo "touch -d \"@$t\" \"$dr\""
   touch -d "@$t" "$dr"
   lastt=$t
 done

bug#49428: RFE: for --time have option to only include contents, not dir itself.

[L A Walsh]

I did a re-install-in-place on windows that reset the
dirtimes on all the dirs to the date I did the re-inst.

As a partial recovery, I want to be able to reset the date
to the time of the last modified file in the dir.

I thought to use:

  du -s --time DIR

but it's not just showing (from manpage):

  --time show time of the last modification of any file in the 
directory,

 or any of its subdirectories

instead it is showing the above & the time on the dir itself.
Some people may want to include the dir time, but that's usually
obvious by the time on the directory.

Nevertheless, perhaps a "--contents" flag to not include
the size of the directory-inode itself might be useful?

Sadly --separate-dirs doesn't really separate out all
the dir-sizes either, but only subdirs.

*sigh*
tnx!

bug#49298: [PATCH] df: do not print duplicated entires with NFS and bind mounts

[L A Walsh]

On 2021/06/30 08:53, Kamil Dudka wrote:

The proposed patch makes sure that the devlist entry seen the last time
is used for comparison when eliminating duplicated mount entries.

---
   I'm a bit surprised that the devlists exported for NFS are the same
as for smb.  How is that guaranteed?  But more important, does it work with
other network file systems?  Mostly I'm thinking about mounts of
NTFS from a win server.  I've gotten different results over time, 
specifically,

in regards to whether or not inode numbers are unique.

   Would it be possible for the network file systems to return
different amounts for free+used space depending on the net-interface
being used (I don't know -- I'd hope it wasn't likely, but )

   Another way of solving this issue, other than by special casing
SMB+NFS, a switch that prohibits crossing over to another networked
file system, and a different setting that prohibits crossing over to
another device.  I think there is a need for both as well as how initial
args are treated -- as is done with 'find' in all its diversity! ;-)

Patches to reintroduce behaviors that might result in non-deterministic
behaviors are, at least, "worrisome".

bug#48960: stat v8.30 - device number in decimal shown as 16bit number instead of to converted 8bit

[L A Walsh]

On 2021/06/11 00:37, Wolfgang Rohm wrote:

Hello.

Stat prints the device number, major and minor, in hex and decimal. 
They are both 8bit numbers clamped together. While the hex number is 
perfectly fine, the decimal doesn't respect how this number has come 
to existence. There is no meaning in the decimal value, if the the hex 
value is taken as one 16bit number and then converted.


For example "fd00h" is converted to "64768d". There is no major device 
with 647 and no minor device with 768. Its just completely wrong.

---
   Aside from complete bogus output on my system for either
hex or decimal and the "seemingly" undocumented appearance of 'd'
to convert a 16-bit decimal value back to 2 8-bit values
divide the number by 256 or shift the value right by 8 bits
for the high number and either mod the number with 256 or
'and' (&) the value with 0xff:

decimal_devno=64768   #(dropping the 'd' on the end)
high=$(($decimal_devno/256))
low=$(($decimal_devno%256))
printf "%s:%s\n" "$high" "$low"

 (output:)
253:0

 or via shifts+masks

decimal_devno=64768
high=$((decimal_devno>>8))
low=$((decimal_devno & 0xff))
printf "%s:%s\n" "$high" "$low"

 (output:)
253:0

bug#47703: Same category as "ln " (was: bug#47703: Mention if ln -s needs -r, or ln -r needs -s)

[L A Walsh]

On 2021/04/11 07:21, Pádraig Brady wrote:

On 09/04/2021 12:46, 積丹尼 Dan Jacobson wrote:

man ln says:
-r, --relative
   create symbolic links relative to link location
-s, --symbolic
   make symbolic links instead of hard links
Hard to tell from the man page.

---
   Seems like another related example ignoring what the user wants and
issuing an error for an inexact usage.

   If you used "-r" by itself, or if you try linking a directory,
either without "-s", you get an error message, when it would be more
helpful to assume "-s" and give a diagnostic if "interactive" (assumption
being, that if it was in a script, it was obviously intended that way,
as any other way generates an error).


Fair point.
thanks, Pádraig

bug#48002: Gnu design flaw fixes hindered by Gnu (sexism?) biases

[L A Walsh]

On 2021/04/21 19:11, Paul Eggert wrote:

On 4/18/21 10:46 AM, Peter van Dijk wrote:
While the manual (but not the manpage) mentions the data loss, I 
think it would be great if sort did not have this problem at all, and 
I think the OpenGroup text also says it should not have this problem.

 I looked around, and a lot of software does get this right (by opening a 
randomly-named temp file to write to, and only moving it into place when it is 
written successfuly) - GNU sed -i, OpenBSD sort, and surely there are more. As 
a bonus, doing this would also make the `-o someinputfile -m` case safe.



I don't know of any 'sort' implementation that does not have the 
problem at all. ...

Nevertheless, it is the same problem as reported _1.5_months_
ago where no one had time to look at the same design flaw
in gnu-coreutils implementation of 'cp' (bug#47059).

That bug, still untriaged, had the same suggested solution:

  "When creating a link to a local file, I
   first create the link to a temporary name to ensure
   I have appropriate access (or that its not
   cross-linked in this case)."

At that time the bug was only reported against 'cp', but it
seems that not testing for final location writeability is
a gnu-bug stemming from mono-culture development where
outside ideas and bug reports tend to be ignored.

The previous, similar bug in 'cp' I reported was ignored for
1.5-2 YEARS, before a large enough corporation lost enough
data for GNU to pay attention.  Though in this case, did
the report against 'sort' get noticed because the reporter
wasn't female?  Perhaps others within GNU have inculcated
the biases of RMS and my feelings of tolerance were naive
(wouldn't be the first time).


That bug was left untriaged
that was left untriaged with bug#47059.  And it is the same
solution -- opening a randomly-named temp file to write to
and only performing final actions when writeability of
the destination is confirmed.


Also, I don't see where the Open Group spec says what you're saying. 
On the contrary, the spec merely says that '-o output' should cause 
output to be sent to the output file. If there are multiple hard links 
to the output file, this suggests 'sort' should update the output 
file's contents without breaking any hard links. Admittedly the Open 
Group spec is a bit vague in this area, but I certainly don't see 
anything implying that GNU 'sort' does not conform to POSIX in this area.


FreeBSD 'sort' has a problem, in that 'sort -o A B' preserves all hard 
links to A's file, but 'sort -o A A' does not because it breaks the 
link from A. That's confusing.


Traditional Unix 'sort -o A' behaves the way GNU 'sort' does; it 
preserves all hard links to A's file. So there is a compatibility 
argument for doing things the way GNU 'sort' does them, even if that 
might lead to more data loss in rare cases.

bug#47324: Missing information in documentation

[L A Walsh]

On 2021/03/25 08:36, Glenn Golden wrote:

Perl's perldoc(1) is more or less analogous in spirit to GNU's
approach based on info(1). The man pages contain quite a bit of
useful info, but do not purport to be exhaustive. 
  

=

On 2021/03/25 08:05, Paul Eggert wrote:

Most free-software projects treat manpages the way the Gnu 
project does, or don't even bother with manpages.
  


Re: perldoc analogous to info:

  Perl, by default, installs all of its perldocs as manpages.  Distro
supplied modules follow the same practice.  CPAN modules usually
have their information installed as manpages.

  Individual packages that don't follow existing standards may
not be converted. So yeah, that's analogous to .info: Gnu who does
their own thing doesn't supply full docs in manpages -- doesn't
really try.

---

Re: "most"[sic] fs projs...

Most or all of perl's base language information is installed as
manpages. As for 'most free-sw', if it is GUI based or
windows based, *nix manpages don't exist in their world.

If a project is run via the command line on *nix, the manpages are
the primary documentation -- for MOST free-sw targeting the *nix
cmdline.  Gnu is one of the worst offenders in *nix-cmdline-sw for
not following that standard.


Arguing the point w/Gnu-SW-devs who refuse to consider outside
viewpoints isn't very useful.

Cheers!

bug#47324: Missing information in documentation

[L A Walsh]

On 2021/03/22 15:21, Bernhard Voelker wrote:


According to the GNU guidelines and to avoid double work, the man page of
the coreutils is essentially not much more than the output of --help.
  

---
   It sure would be nice if GNU would join the *nix family and
put full documentation in the manpage (as well as or in place of
putting it in 'info').

   If languages such as python and perl can document their usage
in manpages, certainly gnu could be as helpful.


-l

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

[L A Walsh]

On 2021/03/23 16:43, Dan Jacobson wrote:

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

---
Perhaps a scheme, similar, or duplicating that in logrotate would
be useful where older versions can be limited by count and/or age?

bug#47085: du: why does 'usage' show prefixes 'Z' or 'Y' if they are disallowed?

[L A Walsh]

I thought to display 0 (or 0) for 1st arg by doing:

du -BY, as -B says I can list a unit for scaling, but for
-BY and -BZ I get:
du: -B argument 'Y' too large.

It doesn't even look to see how much space is used, it
immediately returns Y & Z are "too large".

Why are those suffixes listed as valid under the program 'usage'
and manpage, when they are automatically disallowed?

Also something I didn't see as being clear:
 I don't see where it says it will always round up to next higher
 unit (it may say it somewhere, I just don't see it and was
 surprised to see 'du -BT /tmp|hsort -s' show all objects as
 being 1.0T and for hsort to show a summary of ~148T
 (hsort sorts by human prefixes and has an optional '-s'
 switch that shows an additive sum of the sizes).

bug#47059: (bug in cp removing destination file when it can't be replaced due to cross-volume linking)

[L A Walsh]

Did anyone see this?  Usually someone says something like
confirming it or asking for more info.

Is this a known bug and/or has it been seen before?

(slightly cleaned up report below)

Thanks!

On 2021/03/10 13:41, L A Walsh wrote:
Was trying to save disk space by linking duplicate files, in a dir. 
FWIW, my 'cp', is aliased to 'cp --preserve=all'



 for f in Roboto*.ttf;do > cp -l /usr/share/fonts/TTF/$f .; done
cp: cannot create hard link './Roboto-Bold.ttf' to 
'/usr/share/fonts/TTF/Roboto-Bold.ttf': Invalid cross-device link

…
cp: cannot create hard link './RobotoSlab-Thin.ttf' to 
'/usr/share/fonts/TTF/RobotoSlab-Thin.ttf': Invalid cross-device link


Well that didn't work, guess I'll copy over the affected files.

Repeating command w/o "-l":

Ishtar:…/3.1.16055.164_0> for f in Roboto*.ttf; do 
cp /usr/share/fonts/TTF/$f . ; done

cp: cannot access '/usr/share/fonts/TTF/Roboto*.ttf': No such file or directory
---
Huh?...all of the files were deleted!

That's not good.  When creating a link to a local file, I
first create the link to a temporary name in the same directory
to ensure I have appropriate access (or that its not cross-linked
as in this case).  Apparently 'cp' doesn't exercise the same caution.
It seems 'cp' deletes the target first (as it was linked to some
other file), but then can't perform the requested copy-link, so
leaves the target location with no file at all.

Is this fixed in a newer core utils version?
coreutils-8.23-2.3.2.x86_64

bug#47023: df utilility displays G instead of GM as unit size for Gigabytes in power of 1000

[L A Walsh]

On 2021/03/10 15:21, Paul Eggert wrote:
Although his email did reencode those names into ISO 8859-1 which is 
more likely to cause problems than cure them these days, it still 
displays well on my MUA (Thunderbird) because its header said 
"Content-Type: text/plain; charset=iso-8859-1". His email is also 
displaying properly in the archive 
, as the 
archiving software reencodes those names back into UTF-8 and the web 
page uses "Content-Type: text/html; charset=utf-8" for all the emails.


Possibly your email client is programmed to ignore encodings in incoming 
"Content-Type" lines; that would explain the glitches you saw.


I also have Tbird, and for content I can adapt it but usually
have it set to ignore non-UTF-8 these days, as occasionally, 
someone has an old mailer that sends out 8-bit encoding and Tbird would
seamlessly adapt and send the email back out in the same format.  


I didn't want to pass on bad encodings when I replied to such
items to a list, so I changed that default.

However, what Tbird doesn't handle well is local encodings
used in the 'To' or subject lines since there is no encoding line
for those.  In a text archive it can convert and display both in 
UTF-8 format, but even if I set Tbird to respond in the same encoding,

it won't fix the encodings in the header as the content-type: text/plain
doesn't apply to the headers.

So while archives and the email text can be fixed, the text in
the headers often can't.  The only thing to do is bring it to their attention
and hope they have the technical skills to set their mailer to use
UTF-8.

bug#47023: df utilility displays G instead of GM as unit size for Gigabytes in power of 1000

[L A Walsh]

On 2021/03/10 14:09, Glenn Golden wrote:



Second, minor, side rant:
   Would be nice if more attention was paid to fixing mailers encoding
   "Pádraig" and "Bénézech" as "P�draig" and "B�n�zech"



If you see substitute encodings like that, it strongly suggests the problem
is your MUA, not mine. 


It's yours.

You are using a local 8-bit encoding, whereas everyone else was
using UTF-8.  Your mailer re-encoded their messages into one
of the 8-bit western encodings, whereas most people use UTF-8
these days, so while their original messages with accents came
through just fine in UTF-8, your re-encoding into Western didn't
display properly.

bug#47059: bug in cp removing destination file when it can't be replaced due to cross-volume linking

[L A Walsh]

Was trying to save disk space by linking duplicate
files, in a dir. 
FWIW, my 'cp', is aliased to 'cp --preserve=all'



 for f in Roboto*.ttf;do

cp -l /usr/share/fonts/TTF/$f .

 done
cp: cannot create hard link './Roboto-Bold.ttf' to 
'/usr/share/fonts/TTF/Roboto-Bold.ttf': Invalid cross-device link
cp: cannot create hard link './Roboto-Italic.ttf' to 
'/usr/share/fonts/TTF/Roboto-Italic.ttf': Invalid cross-device link
cp: cannot create hard link './Roboto-Light.ttf' to 
'/usr/share/fonts/TTF/Roboto-Light.ttf': Invalid cross-device link
cp: cannot create hard link './Roboto-Medium.ttf' to 
'/usr/share/fonts/TTF/Roboto-Medium.ttf': Invalid cross-device link
cp: cannot create hard link './Roboto-Regular.ttf' to 
'/usr/share/fonts/TTF/Roboto-Regular.ttf': Invalid cross-device link
cp: cannot create hard link './RobotoCondensed-Bold.ttf' to 
'/usr/share/fonts/TTF/RobotoCondensed-Bold.ttf': Invalid cross-device link
cp: cannot create hard link './RobotoCondensed-Light.ttf' to 
'/usr/share/fonts/TTF/RobotoCondensed-Light.ttf': Invalid cross-device link
cp: cannot create hard link './RobotoCondensed-Regular.ttf' to 
'/usr/share/fonts/TTF/RobotoCondensed-Regular.ttf': Invalid cross-device 
link
cp: cannot create hard link './RobotoSlab-Bold.ttf' to 
'/usr/share/fonts/TTF/RobotoSlab-Bold.ttf': Invalid cross-device link
cp: cannot create hard link './RobotoSlab-Light.ttf' to 
'/usr/share/fonts/TTF/RobotoSlab-Light.ttf': Invalid cross-device link
cp: cannot create hard link './RobotoSlab-Regular.ttf' to 
'/usr/share/fonts/TTF/RobotoSlab-Regular.ttf': Invalid cross-device link
cp: cannot create hard link './RobotoSlab-Thin.ttf' to 
'/usr/share/fonts/TTF/RobotoSlab-Thin.ttf': Invalid cross-device link


   Well that didn't work, guess I'll copy over the affected files.

   Repeating command w/o "-l":

Ishtar:…/3.1.16055.164_0> for f in Roboto*.ttf
do
cp -l /usr/share/fonts/TTF/$f .
done
Ishtar:…/3.1.16055.164_0> ll Roboto*
ls: cannot access 'Roboto*': No such file or directory
---
Huh?...all of the files were deleted!

That's not good.  When creating a link to a local file, I
first create the link to a temporary name to ensure I have
appropriate access (or that its not cross-linked in this
case).  Apparently 'cp' doesn't exercise the same caution.
It seems 'cp' deletes the target first (as
it was linked to some other file), but then can't
perform the requested copy-link, so leaves the
target location with no file at all.

Um...not good.
Is this fixed in a newer core utils version?
coreutils-8.23-2.3.2.x86_64

bug#47023: df utilility displays G instead of GM as unit size for Gigabytes in power of 1000

[L A Walsh]

On 2021/03/10 06:50, Glenn Golden wrote:

Pádraig, Philippe, Paul -

Pádraig Brady [Tue, 9 Mar 2021 19:51:45 +]:
  

On 09/03/2021 12:58, Philippe Bénézech via GNU coreutils Bug Reports wrote:
Dear maintener,

I found a reproducible bug in df utility, installed in debian stable

$ df --version |head -1
df (GNU coreutils) 8.30
$ cat /etc/debian_version
10.8

df displays G instead of GM as unit size for Gigabytes in power of 1000
(but the value is correct)
  


The documentation says:

  -h, --human-readable
  print sizes in powers of 1024 (e.g., 1023M)

  -H, --si
  print sizes in powers of 1000 (e.g., 1.1G)

How is this a bug?

If the idea is to print a scaling factor and use the  minimum
space necessary (1 byte for the prefix), it seem to be doing
exactly what it is documented to do.

Side rant:
 Using decimal prefixes with a binary unit (1B=2**3 bits)
 defeats the purpose of using a common multiplier for metric.
 Since computers use base-2, similar prefixes should be used.
 Just because the disk-industry bought and paid for the
 ruling to use base-10 doesn't mean that memory comes in
 units of 1-million, 1-billion or 1-trillion bytes or
 that disk space is organized in decimal units.

 I find it amazing that it is the French who most
 often vocalize support for the capitalistic-backed
 decision. 


*sigh*


Second, minor, side rant:
   Would be nice if more attention was paid to fixing
mailers encoding "Pádraig" and "Bénézech" as "P�draig"
and "B�n�zech"
*double sigh*
:-)

bug#47014: Design flaw: incompatible touch '-f' gnu-option causes loss of (meta)data by default

[L A Walsh]

On 2021/03/08 19:58, Paul Eggert wrote:

On 3/8/21 6:29 PM, L A Walsh wrote:

Warning, '-f' assuming '-r' was intended


I don't think that'd be helpful, given that -f now has a well-defined 
and common meaning that doesn't agree with what you remember, and that 
in 4.2BSD (circa 1983) -f meant something quite different from -r and 
the common current interpretation of -f (which is to ignore it) is 
extremely compatible with 4.2BSD's interpretation. See:


https://www.tuhs.org/cgi-bin/utree.pl?file=4.2BSD/usr/man/man1/touch.1


Indeed!  I wondered about a '-f' ala force...well given that, sigh.
I'm probably thinking of a -f meaning some file to use from some other
util...

Thanks for the update and appreciate your diligence...

bug#47014: Design flaw: incompatible touch '-f' gnu-option causes loss of (meta)data by default

[L A Walsh]

On 2021/03/08 18:04, Paul Eggert wrote:

I don't know which version of touch I remember it from as I've
use a few versions of unix, as in (scratching memory):
some form of SCO Unix on Intel chips (early 80's, pre IBM-PC), HPUX, Sun 
Unix(a BSD variant), SunOS (a SysV variant), IRIX(sgi),

among others whose names I don't remember.


It'd be helpful to nail that down.

---
	Un, given the usage of those spans 4 decades, 
early 80's for Intel, mid-80's for HPUX, late80's/early90's-sun,

mid90's-early 2000's sgi, after that mostly linux flavors, that
asking a bit much.  My email archive only goes back to mid-late 90's.

bug#47014: Design flaw: incompatible touch '-f' gnu-option causes loss of (meta)data by default

[L A Walsh]

On 2021/03/08 18:04, Paul Eggert wrote:

On 3/8/21 5:50 PM, L A Walsh wrote:


Data loss shown in original bug submission.  As mentioned/documented
it was use of:
'touch -f  '


Sure, but what was the context of that command? Was it part of a shell 
script? What was the script for? Can we see a copy? That sort of thing.


wasn't in a shell script.
Was interactive and thought '-f' was flag to take d+t from
the specified file.  Instead, it lost the d+t on the file.

I probably could have restored from backup, but it was more annoying
than anything else, and didn't want to bother.  Though I would have
preferred to have it work and not just silently consume the '-f' 
switch and stomp over the 'from' file's d+t.


If it was in a script, it probably would have been debugged by now.

Didn't say it was "script-unfriendly".


On FreeBSD, touch's -f option is also a no-op, and I observe similar 
behavior on Solaris 10 (where I lack the source code). So there are good 
compatibility arguments for leaving things the way they are.

---
On any modern version of any of the unices that I've been
on that still exist, there is a fair chance that they would have 
switched to '-r', though if unix versions you mention silently accept and

throw away a '-f' -- you can't necessarily know what their usage was, but
should have a record of why it was added in the gnu utils.

It seems odd to consume a switch where the meaning is not known for 
specifically cases like this.  I doubt it could be like 'date's 
-f for a from file, as it seems like that would produce a date for

each line in the specified file, which would make no sense for touch.

All I know is I've been caught more than once by this, though I
usually remember there is something off about the touch command's options
and reread the man page before using it.  But haven't always and not
sure I always remember either, which is why I would think that simply
ignoring it and not consuming a following arg or generating a warning:

Warning, '-f' assuming '-r' was intended 
(if -f is followed by an existing filename)
if not, could just ignore it, but still might be ideal to 
assume it was '-r', since if it is a non-existent filename, 
it would warn of the command failing, like:



touch -f foo bar

/usr/bin/touch: Warning, '-f' assuming '-r' was intended
/usr/bin/touch: failed to get attributes of 'foo': No such file or directory

bug#47014: Design flaw: incompatible touch '-f' gnu-option causes loss of (meta)data by default

[L A Walsh]

On 2021/03/08 16:07, Paul Eggert wrote:

On 3/8/21 3:27 PM, L A Walsh wrote:

gnu accepts but ignores the previously active '-f'(from) switch


GNU "touch -f" has always been a no-op and has never meant "from" as far 
as I know - though I admit I looked back only to 1992. Perhaps you're 
thinking of some other "touch" program? If so, which one and which version?


Is the data loss you mentioned something that you actually observed? If 
so, what was the context?

---

Data loss shown in original bug submission.  As mentioned/documented
it was use of:
'touch -f  '

which overwrites the meta-data information on "from filename" 
with the current date+time.


I don't know which version of touch I remember it from as I've
use a few versions of unix, as in (scratching memory):
some form of SCO Unix on Intel chips (early 80's, pre IBM-PC), 
HPUX, Sun Unix(a BSD variant), SunOS (a SysV variant), IRIX(sgi),

among others whose names I don't remember.

bug#47014: Design flaw: incompatible touch '-f' gnu-option causes loss of (meta)data by default

[L A Walsh]

gnu accepts but ignores the previously active '-f'(from) switch
and replaced it with '-r' to be compatible with posix, likely,
but created a meta-data loss case in that if someone
uses it:


 ll foo bar

-rw-rw-r-- 1 0 Mar  8 14:33 bar
-rw-rw-r-- 1 0 Dec 10  2012 foo

Want to transfer D/T from foo(^) to bar(^)


 /usr/bin/touch -f bar foo  #no warning or error
 ll foo bar

-rw-rw-r-- 1 0 Dec 10  2012 bar
-rw-rw-r-- 1 0 Dec 10  2012 foo

instead the original information time/date
metadata is lost. 


Proposal: make '-f' equivalent to '-r' to
implement safe and user-friendly behavior.

User-annoying behavior: issue warning with
use of '-f' but accept as equivalent to '-r'

User-unfriendly behavior: issue error and
do nothing (even if '-r' is given).

User-hostile behavior: do nothing: let user
damage the metadata on their files.

bug#45924: RFE: rmdir -r: recursively remove [empty] directories under the target.

[L A Walsh]

On 2021/01/18 08:08, Bernhard Voelker wrote:


find(1) can also ... [various examples of find's usefulness elided]
Have a nice day,
Berny

===
As I stated in the original message:

On 2021/01/16 16:29, L A Walsh wrote:

Yes, you could do it some other way, like by using 'find',
but since it is about removing directories, having the option
under rmdir would seem a natural place to put it.


Thank you Bernhard, but numerous ways to do it with find don't 
really have the simplicity, of using "remove dir" for its

"raison d'être":

 rmdir -r DIR

 vs. find:

 find DIR -depth -type d -exec rmdir {} +


One could also use find to implement recursive file removal instead of
using 'rm', but that's hardly simple or straightforward as "rm -r"
either.

bug#45924: RFE: rmdir -r: recursively remove [empty] directories under the target.

[L A Walsh]

Except that 'find DIR -depth -type d -exec rmdir {} +'
is anything but simple and not something anyone outside of
a minority of *nix users would have a clue about how to 
create, whereas 'rmdir -r DIR' is both direct and simple and

more easily understandable by those who know how to remove
a directory and recursively remove files. Applying the -r
option of 'rm' and 'rd's focus on dirs seems a natural 
combination.



Gnu authors seem to pride themselves on their technical and
programming expertise (and not necessarily, w/o reason); but like
many high-level engineers, seem to lose touch with the concept of
'user-friendly' and often, it seems, tend toward the idea that the
users can and should adapt to the program(s) for the sake of
the programs (and engineers).  This is in contrast to the idea
of computers (and programs) being designed as tools to aid, assist,
simplify and empower those who use such tools.



On 2021/01/17 14:18, Paul Eggert wrote:

On 1/16/21 4:29 PM, L A Walsh wrote:

Yes, you could do it some other way, like by using 'find'


That's what I'd do, yes. 'find DIR -depth -type d -exec rmdir {} +'. I 
doubt whether it's worth hacking on this at the C level (complicating 
the documentation too) when there's such a simple and portable way to do 
this unusual task already.

bug#45924: RFE: rmdir -r: recursively remove [empty] directories under the target.

[L A Walsh]

Every once in a while, I want to remove what I believe to be
an empty directory tree, safely.

I wondered, why not have rmdir have a recursive option
that would remove all directories under a given directory,
presuming they were empty.  That way I can try to remove
the tree, removing what it can, and only failing if it
ran into a file that prevented the removal.

I'd _at least_, have it do a depth-first removal and halt
with a ENOTEMPTY status if an rmdir failed to remove a
directory due to it not being empty.

So for dirs one,two,three + file dir 'two' next to three:

one-+two-+three
|-file

rmdir -r one  would first remove
one/two/three,
then fail removing one/two because 'two wasn't empty'.

--- probably, I think adding a mode like "--failearly"
should also be available to have rmdir fail on the recursive
descent if it encountered non-dir while descending.

Yes, you could do it some other way, like by using 'find',
but since it is about removing directories, having the option
under rmdir would seem a natural place to put it.

Useful?

bug#44444: RFE for 'env'?

[L A Walsh]

Ah...so what I asked for has already been added in a newer version.

I seem to have > env --version
env (GNU coreutils) 8.26.18-5e871

What version of env should I try and test?


Thanks!


On 2020/11/04 08:09, Erik Auerswald wrote:

Please see
https://www.gnu.org/software/coreutils/manual/html_node/env-invocation.html#g_t_002dS_002f_002d_002dsplit_002dstring-usage-in-scripts
for an explanation.

HTH,
Erik

bug#44444: RFE for 'env'?

[L A Walsh]

Rewriting this bug as the other one, apparently, was too unclear
to be understood.

This gives an example, two in fact.


On 2020/11/03 14:48, Bernhard Voelker wrote:

On 11/3/20 6:29 PM, L A Walsh wrote:

I tried to use 'env' to find perl in my path and wanted to pass
the -T option to perl.

cat >/tmp/taint+print

#!/usr/bin/env perl -T
printf "Hello World\n";

I am unable to get this to run and print out:

"Hello World" \

Instead of expected output, I get:
/usr/bin/env: ‘perl -T’: No such file or directory


So I tried turning off env's arg parsing as we know the linux kernel
does handle this.

#!/usr/bin/env -- perl -T
/usr/bin/env: unrecognized option '-- perl -T'
Try '/usr/bin/env --help' for more information.

I am not able find a syntax that will generate what I want.

1) '--'  isn't handled as being the end of 'env' arguments
2) It isn't splitting white-space to to generate separate arguments
  but seems to concatenate together as 1 argument. 
3) This overrides normal linux kernel behavior.  This is a kernel policy

that is overridden  by a user-level program.

*>>* If these behaviors were under user control, I don't think it would be a
problem.  While some utils/progs like "find" tend to ignore symlinks
unless they are on the command line.  Others, like bash, by default,
try to give a logical view by following the symlinks and restoring when
backing out.  Both options can have utility.  find even has suboptions for
ignoring their use on the cmdline, but expanding them in subtrees. 

Bernhard V. Thanks, so it seems 'env' works as expected and 
supports the way you need it to run.

---
Hopefully you understand you had it backwards -- in that it doesn't
work as expected (doesn't break arguments in same places as kernel). and does
not support the way I need it to run.

Do to your misunderstanding you closed the original bug -- Hopefully it is
clear explained enough so this note won't also get deleted.



Have a nice day,
Berny


Trying -- at least elections are over.

bug#44412: RFE for 'env'?

[L A Walsh]

On 2020/11/03 04:29, Bernhard Voelker wrote:


As you didn't give an example, it's hard for me to imagine what you
want to achieve, or better why current 'env' would "dislike it".

---
I tried to use 'env' to find perl in my path and wanted to pass
the -T option to perl.

/usr/bin/env perl -T

print "Hello World\n";

Couldn't figure out anyway to have env look up my program in my path and
to pass an option to that program.

bug#44412: RFE for 'env'?

[L A Walsh]

I wanted to pass a switch to an interp line, but 'env' seems to dislike it.

I also noticed that env ignores '--' to indicate end of switches that it 
should

process.

How difficult would this be to do? Specifically,
allow double-dash ("--") to indicate the end of 'env' switches such
that any following arguments would be passed to program to be run?

I was surprised when I found out it didn't do this.

Thanks!

bug#42358: mv w/mkdir -p of destination

[L A Walsh]

Yeah, I'd thought about asking for this as well, like as maybe a "rmdir -r"
or rmdir -rp
where either the want of recursion implied going up to ancestors (since
decending along a chain
of directories would be a bit indeterminent, or requiring a redundant '-p',
as well, as it would tell the program to delete parents (since going down
wouldnt' make much since) from the dir specified back up to the current
directory.  If the current directory wasn't 'above' the specified dir, then
it would die
as it isn't clear what is wanted.  Obviously it can only follow a chain
'up' as long as nothing else is
in the parent besides the directory-parent (i.e. no other files or dirs).

But I've found asking for features usually doesn't work and sometimes
results in work to preclude future
implementation of the feature.  Reporting bugs also, often gets ignored
until some large company reports
the same problem or until it causes a serious enough security incident.

On Sun, May 10, 2020 at 8:17 PM Vito Caputo  wrote:

>
> Does this already exist?
>
> Was just moving a .tgz into a deep path and realized I hadn't created
> it on that host, and lamented not knowing what convenient flag I could
> toss on the end of the typed command to make `mv` do the mkdir -p
> first for me.
>
> I was surprised to not see it in mv --help or mv(1) when I checked for
> next time...
>
> Regards,
> Vito Caputo
>
>

bug#42034: option to truncate at end or should that be default?

[L A Walsh]

I think that would work in my specific use case.
I can think of other use cases that it probably wouldn't, but I'm not going
to worry
about those right now.  :-)

Thanks!
-l




On Wed, Jun 24, 2020 at 1:07 PM Andreas Schwab 
wrote:

> On Jun 24 2020, L A Walsh wrote:
>
> > A second option would be to truncate the file to the last position
> > written.
>
> $ truncate -r $src $dest
>
> Andreas.
>
> --
> Andreas Schwab, sch...@linux-m68k.org
> GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
> "And now for something completely different."
>

bug#42034: option to truncate at end or should that be default?

[L A Walsh]

I allocated a large file of contiguous space (~3.6T), the size of a disk
image I was going to copy into it with 'dd'.  I have the disk image
'overwrite' the existing file, in place using "conv=nocreat,notrunc" (among
other switches) and that works with the final file still using max-sized
8GB extents.

I realize that I _do_ want it to truncate the file to the actual size when
done.

The 'notrunc' switch doesn't work for this purpose as its meaning is
overloaded (it really specifies multiple behaviors) both the non-truncation
effect, as well as a directive to preserve any blocks not written during
that specific invocation of 'dd'.  A possible 3rd behavior arises from a
vague definition of a block.  Do they mean to preserve the data in the
block, or do they mean to preserve the position of the block on disk?  It
seems they mean to preserve data, but whether or not that also preserves a
place on disk isn't specified.

There really needs to be something to specify that writes occur "in-place"
such that no "_RE_-allocation" of blocks occurs (except to extend the file,
if needed)  A second option would be to truncate the file to the last
position written.


Maybe a oflag=overwrite, and a 'ftrunc' for 'final trunc' to the position
of the final byte written?

bug#39827: [PATCH] dircolors: add *direct* to TERM matching

[L A Walsh]

xterm-TrueColor
and xterm-24bit
I've heard of, but direct?  Isn't that a direct serial line
connection?

But suffice it to say, I haven't seen any _concensus_ on a name
or terminal-name for that feature.

Certainly TrueColor or 24-bit (or maybe 32) would be more descriptive
that something used for a direct connetion?


On 2020/02/28 01:07, nl6720 wrote:

* src/dircolors.hin: Add *direct* to match terminals that
support direct colors (24-bit color / TrueColor).
  

---
   Direct colors isn't an industry term that I've ever heard of. 
Besides, it takes about 13 bits per color to represent full color, so 
16-bits seems likely as an upper bound using 64-bits total (upper 16 for 
alpha?).




---
 src/dircolors.hin | 1 +
 1 file changed, 1 insertion(+)

diff --git a/src/dircolors.hin b/src/dircolors.hin
index 8f795bc99..b22643dbb 100644
--- a/src/dircolors.hin
+++ b/src/dircolors.hin
@@ -17,6 +17,7 @@ TERM con[0-9]*x[0-9]*
 TERM cons25
 TERM console
 TERM cygwin
+TERM *direct*
 TERM dtterm
 TERM gnome
 TERM hurd
  

bug#37686: Feature request: flag to not remove any files if any argument doesn't exist or is a directory

[L A Walsh]

On 2019/10/09 14:01, Mark Friedenbach wrote:
> I have a persistent problem that has caused me serious trouble in the
> past: I mixup 'rm' and 'mv'. I suspect this is because on my keyboard
> they are typed with the same fingers and muscle memory kicks in,
> especially if I just typed the other command recently.
>   
rm () {
  if [[ -t 0 ]]; then echo >&2 Disallowed;return 1; fi
  command "$FUNCNAME" "$@"
}
mv () {
  if [[ -t 0 ]]; then echo >&2 Disallowed;return 1; fi
  command "$FUNCNAME" "$@"
}
alias move='

bug#37702: Suggestion for 'df' utility

[L A Walsh]

On 2019/10/11 12:56, Paul Eggert wrote:
> On 10/11/19 11:20 AM, Pádraig Brady wrote:
>   
>> if you want to exclude nested file systems like that,
>> you could try:
>>alias df='df -x squashfs'
>> 
> On my Fedora 30 workstation that option doesn't make any difference. 
>   
--
I'd suggest adjusting the exclusion list to the file systems you want to
exclude.

I.e.
alias df='df -x tmpfs -x devtmpfs -x loop'

That works on my system as well as:
alias df='df -t xfs'

Certainly prompting the user for wanted defaults and adding them to
their .shellrc could be part of an initial run of *some* utilities
that wouldn't cause hard-coded side-effects.

bug#37241: large performance gap when start+inc specified with 'seq'

[L A Walsh]

On 2019/09/03 18:51, Pádraig Brady wrote:
> Yes we could be better here.
> Attached is a fairly simple improvement:
> 
> $ time seq.new 1 1 1e8 >/dev/null
> real  0m1.516s
> 
> $ time seq.new 1 2 1e8 >/dev/null
> real  0m0.834s
> 
> $ time seq.orig 1 2 1e8 >/dev/null
> real  0m40.435s
> 
> It might be improved further with BCD addition of the step string,
> but this should be good for now.
---
Thanks, um, do you know what the time would have been
on your machine of the original, non-explicit case, i.e.:

time seq.new 1e8 >/dev/null

I'm wondering if it is about the same, now, as
the "1 1 1e8" case, as the original question I had was
why the case doing half as many iterations with
"1 2 1e8" took almost 33x as long as the "1e8" case (or,
perhaps logically equivalent) why
"1 1 1e8" wouldn't be the same as "1e8" by itself.

I had a bit of a problem following the logic of the original source
and as to how it determined to use the simpler algorithm over
the more general.

Logically, I thought "1 1 1e8" and "1e8" should have take about the
same amount of time as the first fit the defaults of the 2nd (1e8)
case.  
If that was the same, then the case of
"1 2 1e8", logically, should take half as long (because it was
half as many iterations).  In cases, where all values could be 
determined to be simple integers in the range 1<=X<=1e8 
with integer start and step sizes and where the limit was
'<=' than the native int size of the machine could be
done with a native, non-complex library call.

Other than not being able to use 'INC ' (native inc on a register),
but needing to do an add-immediate 'ADD ,CONS' the algorithms would
be the same.

So, logically, I'd think for all items within the native add/sub 
word size, the timing would be close to the same, wouldn't it?

I'll admit to the work being of questionable use, but not so much
less useful than using/needed 'seq' in the first place.  I.e. if 
coreutils was going to include a special binary to produce sequences
in the first place, it should probably be very efficient so a
user would never feel a need for a specialized version for native
integers.

The reason for that would be so if the work done in making the sequence
was significant enough, it could be split by 'N' physical cores
in a machine, one could see about a {90..100}*N Speed-boost over
the original.

Example of such: 
"Some version" of the 'factor-parallel.sh' test
in the coreutils 'tests/misc' dir, which I thought might actually
do something like that...
:-)

bug#37241: large performance gap when start+inc specified with 'seq'

[L A Walsh]

Was looking at some large sequences and the time they took
and found that while end-point only was fast:

declare -x TIMEFORMAT="%2Rsec %2Uusr %2Ssys (%P%% cpu)"

> time seq 1e8 >/dev/null
0.75sec 0.74usr 0.01sys (99.77% cpu)

Trying just to generate only odd numbers:
> time seq 1 2 1e8 >/dev/null
24.70sec 24.64usr 0.01sys (99.82% cpu)

took way longer.

Shouldn't the 2nd case take about half as long as
the first?  They are both adding integers though in
2nd case, its skipping the "even"s on output.

If it was some floating point calculation needed, I might not
have blinked, but both an integer sequence with the 2nd
being half as long?  Should half the numbers take almost 33x
longer?

bug#36901: Enhance directory and file moves where target already exists

[L A Walsh]

On 2019/08/02 23:10, Assaf Gordon wrote:

 So when I look at the system call on linux for rename:
 oldpath can specify a directory.  In this case, newpath must
 either not
 exist, or it must specify an empty directory.
  (complying with POSIX_C_SOURCE >= 200809L)


 So mv is violating POSIX - it didn't do the rename, but moved
 A under B and neither dir had to be empty.

 Saying it has to follow POSIX when it doesn't appear to, seems
 a bit contradictory?
> 
> I previously quoted one small part of the entire "mv" POSIX specification
> (item #3, regarding using the 'rename(2)' function).
> 
> It would be wise to read the entire specification before making claims
> about violating POSIX.

One doesn't need to read all federal and state laws before 
making claims of law violation.


> Specifically, at the top of the page:
> https://pubs.opengroup.org/onlinepubs/9699919799/utilities/mv.html
>SYNOPSIS
>   mv [-if] source_file target_file
>   mv [-if] source_file... target_dir
>DESCRIPTION
>   [...]
>   In the second synopsis form, mv shall move each file named by a
>   source_file operand to a destination file in the existing directory
>   named by the target_dir operand [...] This second form is assumed
>   when the final operand names an existing directory
> 
> In this regard GNU 'mv' is compliant with POSIX.

But it isn't.  Note to mention -- which posix?  Different posix versions
are not the same.

It isn't 1 spec consistent spec, but changes overtime.  You quoted
a section saying it had to follow the behavior of rename, but it doesn't
do that:


And it doesn't follow the POSIX section quoted on the manpage.

 oldpath can specify a directory.  In this case, newpath must
 either not
 exist, or it must specify an empty directory.
  (complying with POSIX_C_SOURCE >= 200809L)

mkdir A B
touch A/foo B/fee
mv A B

It B exists and is not empty.  Ergo, it is not following the 
requirement that the directory must be empty or not exist.

bug#36901: Enhance directory and file moves where target already exists

[L A Walsh]

It's not a wish list that 'mv' doesn't work as documented.


On 2019/08/02 22:45, Assaf Gordon wrote:
> severity 36901 wishlist
> retitle 36901 mv: merge directories where target already exists
> stop
> 
> Hello,
> 
> (for context: this is a new topic, diverged at https://bugs.gnu.org/36831#38 )
> 
> For completeness, quoting your second message ( from 
> https://bugs.gnu.org/36831#50 ):
> 
> On 2019-08-02 9:56 p.m., L A Walsh wrote:
>> On 2019/08/02 19:47, Assaf Gordon wrote:
>>> Can new merging features be added to 'mv'? yes.
>>> But it seems to me these would be better suited for 'higher level'
>>> programs (e.g. a GUI file manager).
>> ---
>>  But neither the person who posted the original bug on this
>> nor I are using a GUI, we are running 'mv' GUI, we use the cmd line on
>> linux, so that wouldn't
>> be of any use.
>>
>> If the command was named 'ren', then I'd expect it to be dummer,
>> but 'mv'/move seem like it should be able to move files from
>> one dir into another.
>>
>> But you say posix wants it to perform as a rename?
>> I know, create a 're' command (or 'rn') for rename, and have
>> it do what 'mv' would do.  Maybe posix would realize it would
>> be better to have re/rn behave like rename, and 'mv' to
>> behave it was moving something.
>>
>> So if I have:
>> mkdir A B
>> touch A/foo B/fee
>>
>> So when I look at the system call on linux for rename:
>> oldpath can specify a directory.  In this case, newpath must
>> either not
>> exist, or it must specify an empty directory.
>>  (complying with POSIX_C_SOURCE >= 200809L)
>>
>> So move should give an error: Nope:
>>
>> mv A B
>>> tree B
>> B
>> ├── A
>> │   └── foo
>> └── fee
>>
>> 1 directory, 2 files
>>
>> So mv is violating POSIX - it didn't do the rename, but moved
>> A under B and neither dir had to be empty.
>>
>> Saying it has to follow POSIX when it doesn't appear to, seems
>> a bit contradictory?
>>
> 
> 

bug#36831: Enhance directory move. (was Re: bug#36831: enhance 'directory not empty' message)

[L A Walsh]

On 2019/08/02 19:47, Assaf Gordon wrote:
> Can new merging features be added to 'mv'? yes.
> But it seems to me these would be better suited for 'higher level'
> programs (e.g. a GUI file manager).
---
But neither the person who posted the original bug on this
nor I are using a GUI, we are running 'mv' GUI, we use the cmd line on linux, 
so that wouldn't
be of any use.

If the command was named 'ren', then I'd expect it to be dummer,
but 'mv'/move seem like it should be able to move files from
one dir into another.

But you say posix wants it to perform as a rename?
I know, create a 're' command (or 'rn') for rename, and have
it do what 'mv' would do.  Maybe posix would realize it would
be better to have re/rn behave like rename, and 'mv' to
behave it was moving something.

So if I have:
mkdir A B
touch A/foo B/fee

So when I look at the system call on linux for rename:
   oldpath can specify a directory.  In this case, newpath must either not
   exist, or it must specify an empty directory.
(complying with POSIX_C_SOURCE >= 200809L)

So move should give an error: Nope:

mv A B
> tree B
B
├── A
│   └── foo
└── fee

1 directory, 2 files

So mv is violating POSIX - it didn't do the rename, but moved
A under B and neither dir had to be empty.

Saying it has to follow POSIX when it doesn't appear to, seems
a bit contradictory?

bug#36901: Enhance directory and file moves where target already exists

[L A Walsh]

Reposting this, since I realize that fixing the target-exists cases
with a helpful algorithm could change or eliminate many cases
where where now the user gets an error instead.



On 2019/07/28 23:28, Assaf Gordon wrote:

>
>
> $ mkdir A B B/A
> $ touch A/bar B/A/foo
> $ mv A B
> mv: cannot move 'A' to 'B/A': Directory not empty
>
> And the reason (as you've found out) is that the target directory 'B/A'
> is not empty (has the 'foo' file in it).
> Had this been allowed, moving 'A' to 'B/A' would result in the 'foo'
> file disappearing.
>   
---
Why must foo disappear?

Microsoft Windows handles this situation by telling the user that
the target directory already exists and giving the option to *MERGE*
the directories.

If you attempt to move a file into a directory that already contains
a file by the same name, it pops up another notice asking if you want
to replace the old with the new, keep it as it is (file won't be moved and
in this case, old directory would still exist with the unmoved files left
in it), or keep both with the new file getting a name variant (like
foo.exe -> foo_1.exe, keeping the extension the same so as to not mess
up the identity of the contents.

But in all the cases, a file with a non-conflicting name wouldn't
disappear from the target.

bug#36887: coreutils-8.31: printf chokes on \u0041

[L A Walsh]

On 2019/08/01 16:37, Paul Eggert wrote:
> Ulrich Mueller wrote:
>   
>> Except for the surrogates
>> U+D800...U+DFFF, it looks like an arbitrary restriction
>> 
>
> It's not entirely arbitrary. Because of the restriction, coreutils printf 
> doesn't have to worry about what this command should do:
>
>printf '\u0025d\n' 1 2
>
> Does this print a single line "%d", or two lines "1" and "2"? There are good 
> arguments either way, and one can easily construct even-stranger examples.
>   
There are no format characters in the initial line, so only the 1st
argument is interpreted.  You can't do multiple interpretations since if
you do there's no stopping point, (i.e. a hex-encode of a hex-encode of
'%d\n')

bug#36831: Enhance directory move. (was Re: bug#36831: enhance 'directory not empty' message)

[L A Walsh]

On 2019/07/28 23:28, Assaf Gordon wrote:
>
>
> $ mkdir A B B/A
> $ touch A/bar B/A/foo
> $ mv A B
> mv: cannot move 'A' to 'B/A': Directory not empty
>
> And the reason (as you've found out) is that the target directory 'B/A'
> is not empty (has the 'foo' file in it).
> Had this been allowed, moving 'A' to 'B/A' would result in the 'foo'
> file disappearing.
>   
---
Why must foo disappear?

Microsoft Windows handles this situation by telling the user that
the target directory already exists and giving the option to *MERGE*
the directories.

If you attempt to move a file into a directory that already contains
a file by the same name, it pops up another notice asking if you want
to replace the old with the new, keep it as it is (file won't be moved and
in this case, old directory would still exist with the unmoved files left
in it), or keep both with the new file getting a name variant (like
foo.exe -> foo_1.exe, keeping the extension the same so as to not mess
up the identity of the contents.

But in all the cases, a file with a non-conflicting name wouldn't
disappear from the target.

bug#36688: uname no longer accessing hw-platform nor cpu (not updated to use primary info source)

[L A Walsh]

This is a bit weird, as the hw-platform, apparently is i386 or i686, not
sure,
but the cpu is definitely accessible in /proc/cpuinfo.

The following text is from the sysctl call in the
kernel help text for the option:

  CONFIG_SYSCTL_SYSCALL:

  sys_sysctl uses binary paths that have been found challenging
  to properly maintain and use. The interface in /proc/sys
  using paths with ascii names is now the primary path to this
  information.

Apparently my copy of uname is still using the sysctl call(or trying to),
as it comes up with 'unknown' for
   -p, --processor
  print the processor type or "unknown"

   -i, --hardware-platform
  print the hardware platform or "unknown"

This appears to come from:
uname (GNU coreutils) 8.26.18-5e871

Is this fixed in a newer version?

Thanks.

bug#36666: Minor bug/inconsistency in ls command

[L A Walsh]

On 2019/07/15 00:01, hoffelm...@gmail.com wrote:
> Hi,
>
> I am using ls from the cureutils 8.31 on arch linux (5.2.0 x86_64) and
> think it has a bug/inconsistant in printing an file type indicator (-F) 
> while using the long listing format (-l).
>
>
> If I use `ls -F ~` I get the following output:
> ---
> Desktop/Downloads/Nextcloud/  Pictures/  Templates/  Workspace/
> Documents/  Music@OneDrive/   Public/Videos/
>
>
> As the Music directory in ~ is a symbolic link to another folder an @
> is appended.
>
>
> But when using `ls -Fl ~` the output is
> ---
> lrwxrwxrwx  1 rxo users   15  8. Jul 08:07 Music -> OneDrive/Music//
>   

In this case, ls -Fl is showing you the result of the link expansion and
the focus is on the 'target', i.e., the OneDrive/Music.  The classifier
character is being shown only for the target -- not the source of the
symlink.

In a different way, in the top listing the '@' in the 1st ls is telling
you that
Music is a symlink, in the 2nd listing, the '->' tells you that the same
thing,
that Music was(is) a symlink, so the '@' would be superfluous.  Instead,
it puts
a classifier on the target so you know what type it is.

One could think of it as inconsistent -- but only if remembering that
inconsistent options (different options) were given as well.


 

bug#36416: realpath doesn't preserve '..' consistently as per POSIX, nor '/.'

[L A Walsh]

On 2019/06/28 12:02, Eric Blake wrote:
> If your application layer is on top of Linux, then yes, the underlying
> OS guarantees that your application processing a path beginning with
> "//" is correct whether it preserves or shortens that path to "/".

Linux doesn't forever guarantee that it will or won't
use '//'.


> If you port the source code of an application originally built on Linux
> to then operate on some other operating system, then the source code is
> buggy if it shortens the path to "/". But you have to actually check the
> source code to see if it has that bug - just because 'realpath' in
> coreutils shortens '//' to '/' on Linux does NOT mean that it is buggy,
> because the code for realpath has an explicit check (run at
> configure-time) for whether "//" is distinct from "/" - and on platforms
> where that check is answered differently than on Linux, the code behaves
> differently.  That is, the coreutils code is self-adapting to the
> implementation definition of the implementation it is compiled on.
---
As long as realpath guarantees that the generated binary 
won't work on any other version of linux, that would be true.  However
the run-time binary isn't recompiled with each version of linux.


> 
> 
>> It would useful if bugs were not closed before asking for more
>> information. 
> 
> They can always be reopened if you provide enough relevant information
> to show it was closed prematurely.  But so far in this case, you have
> not done so, but merely confirmed my suspicions - you noticed a
> difference in behavior between Linux and Cygwin, but both behaviors were
> POSIX-compliant when factoring in the implementation-defined nature of
> the underlying implementation.

And you confirm that there there is a design flaw in realpath.

Realpath is not part of the OS and is not regenerated as part
of the kernel build process. If a patch is applied to specifically 
to enable or assign meaning to '//' separately that to '/', 'realpath'
will continue to run as it was configured to run on the earlier version.

Realpath can't assume either that it was configured properly
for the current linux binary -- neither that the user knows which is
correct, nor that some behavior that was true at compile time is
still true at run time.


Realpath also trims '.' off of "[dir]/." when these do not have
identical meaning within the linux or cygwin ecospheres.  If I process
source and destination paths through realpath before passing them
to another user app, like 'cp', realpath will alter the behavior.  

If you look at the historic behavior of cp w/relation to 
to *nix, it behaves differently if the source comes from '' than
if it comes from '/.'.

Similarly if you look at the historic behavior of *nix, you
can't claim '//' and '/' are identical.  Realpath fixes it's
path-modifying behaviors at compile time but doesn't disallow its 
binary being run on differently compiled copies of linux.

FWIW, for device paths in /etc/fstab, the notation for CIFS remote
mounts is '//', as in:
 
mount -t cifs //Win_Desktop/C/ /Athenae -o rw,cifsacl,nocase,serverino,vers=2.1

It seems useful for '//' to made available on linux as an automounter path, 
though with nothing mounted, refering to the local system.

I could see concatenating paths '//' & '/usr' being reduced to '/usr',
but concatenating '//' & svrname reducing to '//svrname'.


Other realpath problem:
-  ---

But for a real case now where processing path-args with realpath resulting
in different and unwanted behavior:

using a function for shorthand:

rp() { declare p=(); for e in "$@"; do p+=($(realpath -m "$e")); done ; set 
"${p[@]}"; printf "%s\n" "$@"; }; export rp

  # && sample files && cd to /tmp: 

mkdir /tmp/{a,b}; touch /tmp/a{1,2}; cd /tmp;

cp -a $(rp a/.) $(rp b/.)
  #versus
cp -a a/. b/.

produce very different results.  I would assert that reducing
'dir/.' to simply 'dir/'

is also incorrect.

bug#36416: realpath doesn't preserve '..' consistently as per POSIX, nor '/.'

[L A Walsh]

I don't recall reading anything about posix allowing the elimination
of such paths.

If I have an application layer on top of linux that processes those
double slashes, it may or may not work depending on the underlying OS?

That wouldn't be very portable w/r/t a Portable OS Information eXchange
standard.

I also specified the elimination of the single dots after a slash
which in reality don't have the same meaning as the slash.

It would useful if bugs were not closed before asking for more
information.  I've seen many bugs over the years that were closed
when they were real bugs that came back and bit the project hard,
including bugs that were closed out because I hadn't sent them through
cygwin's list first when I knew they were not bugs in cygwin.



On 2019/06/28 08:38, Eric Blake wrote:
> tag ### notabug
> thanks
> 
> On 6/28/19 6:11 AM, L A Walsh wrote:
>> realpath -m //sysname/rootdir/.
>> returns "/sysname/rootdir"  This is incorrect, according to POSIX.
> 
> No, it is implementation-defined if it is correct.  You failed to say
> what platform you are on.  If you are on Cygwin, where // is distinct
> from /, then it is incorrect - but that's not the behavior of realpath
> on Cygwin.  If you are Linux, where // is an alias for /, then the
> behavior is correct.
> 
> Unless you can provide more details about which system you saw this
> behavior on, and which version of realpath you tested, I'm marking this
> as not a bug.
> 

bug#36416: realpath doesn't preserve '//' in -m mode

[L A Walsh]

realpath -m //sysname/rootdir/.
returns "/sysname/rootdir"  This is incorrect, according to POSIX.

and #3-4 have specific meanings in various applications that  in usage.

1) leading double slashes are to be preserved
   My Notes:  in combining paths like pathcat(//, sys, /a) =>
should get //sys/a
  in combining paths like pathcat(//, /sys, /a) => /sys sys
specifies it wants to be directory, not a system., so at root, '//' refer to
no system, and we just get: '/sys/a'

2) final slash indicates end node is a directory

3) a final . in a source specifies something under the directory name.

~4?)  I don't think /.. at end of a pathname can be safely deleted
and have same meaning as without it, but brain is too tired to detail
right now.

bug#35531: problem with ls in coreutils

[L A Walsh]

On 5/1/2019 3:03 PM, Viktors Berstis wrote:
> When running "ls" or "ls -U" on a windows directory containing 5 
> files, ls takes forever.  Something seems to be highly inefficient in there.
>   
---
it sounds like you are running ls with no options
(nothing in environment and no switches on the command line).

Is this the case?  If is, I'm stumped unless whoever
compiled that had it set to do some things by default.

Basically on Windows, anything that you might get away with on
linux with a stat call, takes an 'open' call on windows.   That gets
costly.  Anything that appends a classifyer to the end of the file
(like ls -F, --classify or --file-type) or that would display any
of the data or size information (ls -l would be right out!).  The
only thing 'ls' could display without such a penalty is the file
name.  However that only apply to stock ls, and since we don't know
what options might have been enabled for that 'ls' (including any
default usage of switches such as those mentioned above), it's
hard to say exactly what the problem is.

A suggestion -- try installing a minimal snapshot of 'Cygwin'
('cygwin.org') and try env -i /bin/ls on cygwin's command line
in that directory and see how fast that is.  If it is slow,  then
something excessively weird is going on that is the wonder of a closed
source Windows.  However, my hunch would have it be 'fast', but since
I don't know the cause, can't say if that would help or not.

One further possibility that I'd think unlikely: the directory could
be very fragmented and take a long time to (5minutes?! really unlikely,
almost has to be the missing stat call) read...though the figures
you are stating sound out of bounds for a fragmented directory.
Still, if you grab the 'contig' tool from the sysinternals site (a
windows subsite), it can show you the number of fragments a file
is split into -- and can be used on directories:
/prog/Sysinternals/cmd> contig -a -v .

Contig v1.6 - Makes files contiguous
Copyright (C) 1998-2010 Mark Russinovich
Sysinternals - www.sysinternals.com

Processing C:\prog\Sysinternals\cmd:
Scanning file...
Cluster: Length
0: 3
File size: 12288 bytes
C:\prog\Sysinternals\cmd is in 1 fragment

Summary:
 Number of files processed   : 1
 Average fragmentation   : 1 frags/file



Other than those options, not sure what else to suggest to narrow
it down, but thought i'd at least mention a few possibilities.

Good luck!

bug#35488: Feature du --files-only request

[L A Walsh]

On 4/29/2019 4:36 AM, David Ellenberger wrote:
> Dear maintainers
>
> I understand that admins have become accustomed to see 4096 in directories
> as it's consistent with the ls command and the technicality behind it.
>   
---
Except that it isn't 4096 on all file systems.  For empty
directories, I usually see 0 bytes allocated.  And for very large
directories, it may be megabytes of space in the directory.
The directory takes real space on linux/unix and different depending
on what filesystem you use.  On windows in NTFS, directories, I think
can be virtual since the meta info and names are in a file control
block.  In that single case, the directories may really take zero
space in the file system, but that's a quirk of how NTFS works in
windows.  If the real intent is to measure used disk space, including
directories seems advisable as they can take real space on most
file systems that is counted against a user quota if it exists.

Confusingly, depending on the file-allocation block size on the
source and target (they are often 4k, but don't have to be) and on
the amount of ***fragmentation*** in the free space, of the source
and target.  If free space is heavily fragmented, a directory may
need to be spread out into several areas, making it larger than
necessary if free space wasn't so fragmented.  That's why you often
hear people say you should keep about 15-25% of your disk space
free -- thats so large contiguous areas won't entirely disappear and
storage will be more efficient.

Anyway, just my opinion, but not sure if du should exclude
directories entirely, but I wouldn't be against separate subtotal
lines for directories and files -- that would make it even more helpful!

bug#35343: sort: printing characters: define

[L A Walsh]

On 4/20/2019 6:54 AM, 積丹尼 Dan Jacobson wrote:
> (info "(coreutils) sort invocation") says
>
> ‘-i’
> ‘--ignore-nonprinting’
>  Ignore nonprinting characters.  The ‘LC_CTYPE’ locale determines
>  character types...
>   

@ location:
 
https://pubs.opengroup.org/onlinepubs/9699919799.2018edition/basedefs/V1_chap07.html#tag_07_03_01

LC CTYPE is defined by POSIX for the 'POSIX' or 'C' locale.  It is
relative (defined) as specified by the current locale.
> Well this leaves the user high and dry trying to figure out what you
> mean by printing characters.
>   
If the user is wet and water is introduced into the printing medium,
ink smearing or other malfunctions may occur that might hinder
performance, recognition and validation w/r/t any specification.
(str8 face)
> Is SPC a printing character he wonders. It makes the printer head
> advance one unit, whereas ESC doesn't.
>   
SPACE is a printing character, ESC is a control-character.  All
control characters are *excluded* from the the class 'PRINT'.

> 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.
>   
In that regard, if each program has its own definition, then different
programs would find it hard to talk with each other.  In order for
programs to inter-operate with each other, it would be best if all
programs being used would use the same specification for details like
"printing character".  Having each program document shared and basic
definitions would tend to be redundant.  Instead the reader should be
aware of standards (such as character definitions and classifications)
for their platform. 

Accordingly, it would be redundant to include extra information about
needed standards with each program.  No?  :-)

bug#35212: problem docs vs. implementation

[L A Walsh]

My console becomes 121 characters wide when I turn on
unicode, but stty says it is 132 characters.

Looking at the stty manpage, I see:
Special settings:
...
   * cols N
  tell the kernel that the terminal has N columns

   * columns N
  same as cols N
---
I thought 'cool', I'll tell the kernel its only 121 characters.

I end up with :
> echo $TTY
> /dev/tty1
> stty cols 121
stty: 'standard input': Invalid argument

So .. why can't I tell the kernel how many columns my tty is?

bug#35109: date 'tomorrow' bug

[L A Walsh]

On 4/2/2019 6:23 AM, Maximilian Gleißner wrote:
> Hi,
>
> I have encountered a possible bug with the date function using both SuSE 
> LEAP 15.0 and SuSE 10.2.
> This bug occurs when asking date for 'tomorrow' when there is a daylight 
> saving timechange.
>
> Note: The machine is located in the GMT+1 timezone, and daylight savings 
> time changed on 31.03.2019 02:00 jumping to 03:00
>
> To replicate the bug:
> date -s "2019-03-30 23:XX"  #where XX is any valid 
> minute, e.g. 23:35
> date -d 'tomorrow'  #expected output: 
> 2019-03-31 23:XX
> actual output: 2019-04-01 00:X
I suppose it would depend on your definition of tomorrow.  I don't
know if it has a locale specific definition.

Is "24 hours from now", or is it the whole day from midnight->midnight,
or is it the same time "X" hours past midnight.

You are using a "same time tomorrow" which, by definition would
be the same time with date+1, but if you use 24 hours ahead, or same #
hours past midnight, or the entire period from day-start to day-end,
you wouldn't get the answer you expected.

I don't know if 'tomorrow' is supposed have meaning of same-time, but
more 1 day ahead of now, which would tend toward 24 hours.

I'm not saying I agree or disagree, just that in my mind, the word
tomorrow seems a bit vaguely defined, but turning to google
and asking for define tomorrow, I get
1) on the day after today, or
   the day after today.

In both cases it refers to 'the day' not a particular number of hours
in the future.

The fact that you can type in tomorrow at all is a bit surprising
given the common definition which never refers to a specific time,
but the entirety.  Even so, the answer you show, intuitively seems
off -- but I don't know that our intuition knows about Daylight savings
time.

I'd be more likely to suggest that tomorrow shouldn't return a time
at all, but only a date, which would be the current data incremented
by one.  Somewhere along the line it looks like someone thought to
"compute" tomorrow as if it was some exact quantity 24 hours in the
future -- which doesn't fit any of the most frequently used definitions
I see.

I.e. expected output:
2019-04-01
(no time).

It's always the case that people need to specify a time when referring
to yesterday, today or tomorrow.  Tomorrow wouldn't be 24 hours ahead
of now anymore than today means 'now'.

Just my 2 cents.

There's probably some inane definition of tomorrow defined by
POSIX, but of course, you'd need to specify which POSIX version you
are referring to as there is more than one definition of the
since they do change over time.


> I am aware you recommend not using local timezones and daylight savings 
> time, but I still think this should/could be implemented better.
>   

Who is 'you' in this context, Gnu, POSIX, SuSE or ???
Seems odd to tell people not to use something that most computers
likely do automatically these days.

bug#34700: rm refuses to remove files owned by the user, even in force mode

[L A Walsh]

On 3/3/2019 4:43 AM, Erik Auerswald wrote:
> Hi,
>
> On 3/3/19 09:40, L A Walsh wrote:
>   
>> On 3/2/2019 11:31 AM, Bob Proulx wrote:
>> 
>>> But regardless of that it does not change the fact that the entire
>>> purpose of read-only directories is to prevent removing and renaming
>>> of files within them.
>>>
>>>   
>> 
>>  But not by the user owning them.
>> 
>
> The rationale given by the Go developers is to prevent downloaded test
> code to remove or alter files in the modules directory, not to prevent
> the user from doing that.
>   

I'm not familiar w/go, or why the user wants to purge something
that sounded equivalent to a web-cache, vs. the local extension-source
storage.

> The Go developers implemented "go clean -modcache" for that purpose.
> https://github.com/golang/go/issues/27161#issuecomment-415213240
> https://tip.golang.org/cmd/go/#hdr-Remove_object_files_and_cached_files
>   

If there is a utilities for what the user needs, why are they wanting
'rm' to do it?  Is it just that they don't know about the util, or
maybe  the
util has constraints on its use to delete the source if the cached version
is deleted?  I don't know.  I do know that Google isn't known for following
common sense standards and like to force its own way on people, so I don't
know why the util isn't "working" for the original poster. 
> I concur to let software handle repetitive tasks.

That's one of the reasons I got into computer SW development to
begin with.  I wanted to be able to program the computer to automatically
do the things I'd normally have to do manually.


> If cleaning the cache occurs all the time, using "go cache -modcache"
> (or whatever program is appropriate for the specific cache) should be
> the routine used. If there is no specialized program provided yet, a
> script could be developed for that purpose.
>   

Well, that's might be the rub -- the current cache-cleaning program may
not be doing things "when" and "how" the user wants (I don't know).  Even
if there is a specialized program that provides one way to clean a cache,
that doesn't mean it works for the original user.  Another possibility is
that they might want to delete only files meeting some specific criteria. If
the provided tool doesn't do what they want or does "too much", they may
want to have their own way of cleaning things up.

I've had more than one process that existed and worked well for me
before
google got involved.  My over-active imagination can easily come up with
situations and possibilities where the user might prefer their own controls
in place.

Cheers,
Linda

bug#34700: rm refuses to remove files owned by the user, even in force mode

[L A Walsh]

On 3/2/2019 11:31 AM, Bob Proulx wrote:
> But regardless of that it does not change the fact that the entire
> purpose of read-only directories is to prevent removing and renaming
> of files within them.
>   

But not by the user owning them.  I don't remember the last time I used
chmod -w to prevent myself from deleting all the files in a directory. 
I use
it to prevent other people from removing/renaming.  If I want to
give myself "pause", I'll set them to immutable (on linux) and chmod
read-only or system on windows -- both of those give some pause to the
standard flow.  

But read-only and owned by me, takes about an extra 1-2 seconds as
I tack sudo on the front and run right over user perms.

>   
>> I would suggest people with specific directories that inhibit deletion of
>> files inside although they should not (e.g. a "cache") to deliberatly change
>> the permissions of said directories prior to deleting files inside. Using a
>> script like the above, even without the basic mistakes in the script, is
>> quite dangerous.
>> 
Yeah...I wouldn't do it, I'd write a script that invokes the app and
clears out the cache dir when the app exits if it bothered me enough.

Much better to let the computer do the repetitive deletions.  If I do it
manually, it increases the chances of me creating a problem the more often
I do it. 

Really -- scripts are much better at handling redundant/routine matters that
turn parts of my brain off.  OTOH, some people are better at redundant
detail
and don't suffer the same problems I would.  People are different.
>   

bug#12400: rmdir runs "amok", users "curse" GNU...(as rmdir has no option to stay on 1 file system)...

[L A Walsh]

On 2/26/2019 12:10 PM, Bob Proulx wrote:
>> rm -fr --one-filesystem foo/. or 
>> cd foo && rm -fr --one-filesystem .
> 
>   rm: refusing to remove '.' or '..' directory: skipping '.'
> 
> I agree with your complaint about "rm -rf ." not working.  That is an
> annoying nanny-state restriction.  It should fail removing '.' after
> having removed all it can remove.  And it only took 16 messages in
> order to get to this root cause!  It would have been so much easier if
> you had started there.
> 
> But this report is about rmdir so let's get back to rmdir.  Any
> reports about rm should be in a separate ticket.  Mixing multiple bugs
> in any one bug ticket is confusing and bad.
---
I think your example is where things started.

The issue with rmdir is a follow-on problem for not having
a "-x" option (don't delete from more than 1 file system),
and I recognized that from the fact that rm -fr no longer has
the ability to stay on 1 file system.

The only way you can delete files from under "." with 'rm',
and I have been told this NUMEROUS TIMES, is to use
the shell's expansion.  While I would agree one should 
remove the shell's expansion from the effects of a tool when
writing a bug report, the oft-quoted solution to 
rm -fr . not following the original design, was to use
rm -fr *.  With rm -fr *, rm no longer can delete files just
on 1-filesystem, let alone the 1 file system that the 
top of the tree "." is on.  If all subdirs underneath
"." (arbitrary directory as used in "rm -fr ."), are on 
different file systems, as all are different mount points,
then there is no fixed limit as to how many file systems it 
will affect.

Then people will say to use the find command -- which instantly
makes 'rm' worthless for the job for which it was intended.

If people want nanny behavior, like rm -i or even rm -I, let them
alias it that way.  My main issue is one can't delete all
files under a directory with 'rm' anymore.  

I've asked for it to only refuse to do so if POSIX_CORRECTLY
is set, or to add the converse IGNORE_POSIX_DOT_RESRICTIONS
(keeping the one for '/' -- as there is no reason to ever delete
'/' -- it's inefficient -- just remake the file system).
But as 'rm' was first designed, it did a depth first removal
and didn't preprocess the path looking for reasons to stop.

And I HAVE submitted multiple attemps to get rm-fr. to work
again.  They are continuously shot down such that I often
have my own version of 'rm' that also removes empty 
directories (behaving like 'rmdir').  It can't remove
'.' because it is in the dir and doesn't know the name to
remove from the parent, so that's still not affected.

If people have issues with rm having these changes, then 
I have no problem adding 'r' as a new util that does --that
would not be bound by restrictions on 'rm', it would

1) allow "rm -fr .", deleting all but the current directory and
   issue no error message due to the "-f".
and
2) delete empty directories without '-r' -- but only if it
   knows their name -- i.e. it wouldn't delete '.'.

As it stands, the only reason this bug was filed was because
it's behavior is inconsistent with what is implemented in rm
in that it has no option to stay on 1 file system (which no
longer works in 'rm' due to previously cited reasons).

Creating such a utility would be trivial -- modify 'rm' to
allow processing the dirtree below "." and allow it to process
an empty directory.

So where would you suggest going from here to get to 'there'?

Linda

bug#12400: rmdir runs "amok", users "curse" GNU...(as rmdir has no option to stay on 1 file system)...

[L A Walsh]

On 2/10/2019 1:52 PM, Bob Proulx wrote:
> L A Walsh wrote:
>>>> If you want a recursive option why not use 'rm -rf'?
>> rmdir already provides a recursive delete that can cross
>> file system boundaries
> 
> Please provide an example.  Something small.  Something concrete.
> Please include the version of rmdir.

As near as I can tell the rmdir case derives from
the similar case (assuming -x as shorthand for --onefilesystem),
under 'rm -frx foo/*' or 'cd foo && rm -frx *'
that was suggested as a replacement for the
desired rm -frx foo/.  or 'cd foo && rm -frx .'

The first two forms of rm using '*' have no limit on the number
of file systems that can be affected.
Only the form 'foo/.' or '.' when used with --one-filesystem
will be actually limited to one-file-system.

If rmdir ever had a related but (now can have more so with -p),
it could also affect multiple dirs with 'rmdir foo/*'

Now you can't claim '*' is a somehow disallowed as it was
suggested as a workaround for disallowing rm -frx foo/.

But any form with 'rm' or rmdir can unsafely affect multiple
file systems on multiple systems, as users are told to use
shell-wildcards to make up for being unable to specify the
top level inside dir for deletion.

The reason things proably got so chaotic is that when it as
suggested that '*' be used with rm -frx *, one-filesystem was
no longer just 1 file system.  

1) pray tell, why would it be called one file system when its
not?  Now it's one-filesystem / root arg?  Uh huh.  That
sounds more than a bit specious to me.

2) if 'rm' really limited its deletes to 1 file system (ensuring
all it's cmd line args were on the same file system, Then the
same feature can be applied to rmdir to prevent it going from
touching different file systems in 1 command.  Of couse with -p
as it back tracks, each back track and imply a change of
file system.

I can't find the original posts, but early comments applied to
'rm'.  Some people seem to change titles of bugs without really
understanding what the root bug was about, so the fact that
something has rmdir in the title now doesn't really mean the 
original was about rmdir.

Might want to examine that policy so things won't get as confusing --
adding on to a title in a separate field (gnu-summary), seems
like it might be less consusing that changing the original title.

That's my best guess at what this is about, but trying to recall
details where my original didn't seem to get posted back to me
(I thought it did, maybe things have chnaged in 6 years?).

-l


Since to delete all files under a directory with something
like (assuming '-x' for '--one-filesystem')
rm -frx * or rmdir * can all delete things on multiple 
file systems.

Note, multiple responders, in discussing rm -frx
> 
> Something like:
> 
>   mkdir testdir testdir/dir1 testdir/dir2 testdir/dir2/dir3
>   rmdir --recursive testdir/dir2
>   rmdir --version
> 
> Include all input and output verbatim.  For clarity do not use shell
> file glob wildcards because that is a dependence upon a specific
> command line shell and the shell's configuration.
> 
>> dir1->dir2->dir3
>>
>> dir1 is on 1 file system, dir 2 is on another and dir 3 can be on another.
> 
> GNU Coreutils rmdir does not provide a recursive delete option.
> Therefore one can only assume that the rmdir you are referring to is a
> different rmdir from a different project.
> 
> I specifically asked if you were using the rmdir --parents option but
> my message was the only mention of --parents in this entire ticket and
> in subsequent responses your messages also did not mention it.
> Therefore I can only assume that there is no --parents option being
> used here.
> 
>>>> There is always 'find' with the -delete option.  But regardless there
>>>> has been the find -exec option.
>> true -- so why should 'rm' protect against crossing boundaries
>> deleting '/' or everything under '.' when there is find?
>>
>> find is the obvious solution you are saying, so all that checking in
>> rm should be removed, as it is inconsistent with rmdir that can
>> cross boundaries.
> 
> My mention of 'find' was really a simple statement about alternatives
> when programmatic needs are desired.  Because 'find' is the swiss army
> chainsaw for directory traversal.  I didn't mean to derail the
> discussion there.  But if it is to be derailed then 'find' is the best
> choice when needing a specific set of programmatic requirements for
> directory traversal.  The other utilities that have simpler
> capabilities are the distractions.  But in theory this bug ticket was
> about 'rmdir'.
> 
>> As for closing something not addressed for 6 years while the problem
>> has grown worse -- (rmdir didnt' used to have a recursive delete), d

bug#12400: rmdir runs "amok", users "curse" GNU...(as rmdir has no option to stay on 1 file system)...

[L A Walsh]

On 2/10/2019 1:52 PM, Bob Proulx wrote:
> L A Walsh wrote:
>>>> If you want a recursive option why not use 'rm -rf'?
>> rmdir already provides a recursive delete that can cross
>> file system boundaries
> 
> Please provide an example.  Something small.  Something concrete.
> Please include the version of rmdir.

The original bug stems from having to use wild cards to delete
all files in a directory instead of '.', as in being told to use:

rm -fr --one-filesystem foo/*

instead of 

rm -fr --one-filesystem foo/. or 
cd foo && rm -fr --one-filesystem .


The recommended solution to use foo/* won't stay on 1 file
system, while an alternative using '.' would.

if I use rm --one-filesystem  a b c, I could be deleting
files off of 3 file systems.  Why would the argument be named
'one-filesystem' if there as no way to ensure that all files
were only on 1 file system?

bug#34345: coreutils v.8.30 – Two fractional digits accuracy. Appropriate notation regarding time elapsed.

[L A Walsh]

On 2/6/2019 1:36 AM, Ricky Tigg wrote:
> Enhancements request
> Hi. Command executed:
>
>
>- Could values reported at '(8.0 GB, 7.5 GiB)' be displayed using a two
>fractional digits accuracy (model 1.23 GiB).
>   

Nah

Implies more accuracy than there is.

Use 2-3 digits for reporting.  That way it can be displayed as
2-3 digits, if choice.  If value is between 2 endpoings, choose the
one that keeps the most bits, like 23.5->23, 34.5->35, basically round
to odd.

> entical values may be
> interpreted as a programming issue. Regards.
>   

bug#12400: rmdir runs "amok", users "curse" GNU...(as rmdir has no option to stay on 1 file system)...

[L A Walsh]

On 1/18/2019 12:32 AM, Assaf Gordon wrote:
> retitle 12400 rmdir: add --one-file-system option
> severity 12400 wishlist
> tags 12400 wontfix
> stop
>   
>> If you want a recursive option why not use 'rm -rf'?
>> 
-
rmdir already provides a recursive delete that can cross
file system boundaries


dir1->dir2->dir3

dir1 is on 1 file system, dir 2 is on another and dir 3 can be on another.


>> There is always 'find' with the -delete option.  But regardless there
>> has been the find -exec option.
>> 

true -- so why should 'rm' protect against crossing boundaries
deleting '/' or everything under '.' when there is find?

find is the obvious solution you are saying, so all that checking in
rm should be removed, as it is inconsistent with rmdir that can
cross boundaries.

As for closing something not addressed for 6 years while the problem
has grown worse -- (rmdir didnt' used to have a recursive delete), doesn't
seem a great way to judge whether or not a bug is valid or not .

bug#34340: cp -a doesn't copy acls

[L A Walsh]

and it is not on the manpage, but tar copies
acls and has them on the manpage.

It guess it is an oversite that cp copies over 'xattrs'
but not acls?

bug#15328: Bug or dubious feature?

[L A Walsh]

On 1/11/2019 1:20 AM, Assaf Gordon wrote:
> tags 15328 notabug
> close 15328
> stop
> 
> Hello,
> 
> On 2013-09-10 3:01 p.m., Linda Walsh wrote:
>> Whatever the problem is, it's not in 'mv'...
> 
> Given the above, and no further comments in 5 years,
> I'm closing this item.

There were further comments but, some
Erik/eric, the cygwin person supporting core utils 
at the time refused to 
allow me to process the bugs through core utils 
before being "ok'd" / triaged by the cygwin interface
person(him).

This was a very serious bug that appeared in several
other areas where "update" conflicted with read-only
settings on sources that caused deletion of data off of
sources that were marked as 'read-only'.

Of course even after telling him how he could reproduce
the bug on linux using the "ignore case" feature on XFS, he
couldn't be bothered.

I also got ignored when mentioning this was related to the
"file changed as we read it" bug that kept resurfacing on
some filesystem that never became stable enough on linux for
a first release.

bug#33787: Policy Change: Use of /etc/gnu.conf files to configure default system behavior

[L A Walsh]

On 12/31/2018 4:23 AM, Assaf Gordon wrote:

Hello,

On 2018-12-31 4:36 a.m., L A Walsh wrote:


On 12/20/2018 5:21 PM, Assaf Gordon wrote:

If there was an "rm --depth-first" feature,

---
 If you would ensure that this is possible, you would have
my gratitude.


There seem to be some confusion: this item was "#2" in my previous
email, and as I wrote (quoted below), I think find(1) is better


You miss the point.  The point is not to increase the length of the command
lines.  The original users of the unix command line used short abbreviated
commands because they were efficient.


They didn't have one command for listing files, and then require another one
to list properties (stat), and then another to line things up and then another 
to
put things out in a different format.

Basic formatting was included in the basic, most used commands. 


But most of all, short commands led to fewer errors.  Having to type
in 2 or more commands to do what could be done in 8 characters would be
an anathema to early unix designers.  The need to call some other utility
to do something that could be more easily done in 1 creates a whole
can of worms

The suggestions I've made involve making things simpler for users.
It's not about how well you can string different commands
together it's about making this short and concise.

More than one source on computer languages talk about brevity in
a language being inversely proportional to power in a language. 


pain.

It ignore that basic fact is insensitive and masochistic.  I certainly don't
need longer repetitive lines to do the same tying I could do in 3...

The point is how can I do what I mean as concisely as possible.



suited for these things.
I have no intention of implementing this functionality.

---
You said it could be better done in an alias.
I say -- no, it cannot.  I'm not talking about righting extra
code for find nor something lone.  Inherently, aliases are
short.  You imply it it easy by claiming it can be done in an
alias.  If it was easy, it would be easier for you to through
out a one- liner than respond to the last note.


As for #3 - The "expand" program already does tab-expansion.
It can be easily combined with existing programs using
a simple shell function.


The need to call another program to generate
basic consistent output is a sign of dysfunction.




With the unix philosophy of "each program should do one thing, and do it
well",


That's not the unix philosophy by itself.  If it was, ls would only
list filenames, and would call stat, expand and table commands to format things.


once one learns how to use "expand" (or fmt, numfmt, awk and

similar text formatting programs) - they can use them to format output
from any program - saving lots of time in re-implementing the same 
functionality in different programs.

---
   You can also put those in libs with the main program calling those libs
based on args using dynamic run-time loading.



these are all tangents.
The topic of this thread is adding support for a global configuration
file.   That request is not likely to be implemented.


	One of the main points here was that some of those other 
features were discarded because there was no easy way of providing

a default configuration for how users wanted these things.

That argument clearly goes in circles.  The hazard of using
it as a reason for not supplying various features is that it becomes necessary
to provide that feature as it is a noted requirement for a score of 
other features.





To continue discussing other topics or feature requests (e.g.
  tab-expansion) - please start a new dedicated thread.


Dedicated to what?
Each problem that need a configuration file?  Or a configuration 
facility to provide a ready backdrop to allow for tool extensibility?

It seems they are interrelated.

I seem to remember this statement by you:

"Discussion can continue by replying to this thread."

bug#33787: Policy Change: Use of /etc/gnu.conf files to configure default system behavior

[L A Walsh]

On 12/20/2018 5:21 PM, Assaf Gordon wrote:

For example,
If there was an "rm --depth-first" feature,
you could enable it easily with "alias" - right?

---
If you would ensure that this is possible, you would have
my gratitude.  However, it is not the case.  The algorithm USED to
be depth first, as described in old unix books describing the utility.

However, someone added processing before descending depth first --
specifically, if current name = '.', then abort any processing of that
tree.  Dunno if it was a local distro patch or use of some different
version of 'rm' (thinking this might have been the case, as I seem to remember
it support an 'x' option to not cross into other file systems), but 
but it used to be the case in some past version that rm would 
delete the files under / in that directory without deleting the 
directory.  It was more concise and safer than anything than

any workaround that has been suggested since.

So if there was an alias to restore that simple behavior, please
share it.




3. Adding "--expand-tabs" option to multiple programs.


	This was asked for and denied.  
type.  Compare:

df output   vs. ls output

8.0K  /usr/adm  0 adm
0 /usr/arpwatch 0 arpwatch
76K /usr/bandwidthd 0 bandwidthd
1.5G  /usr/bin   288K bin
1.6G  /usr/bin1  300K bin1
0 /usr/com  0 com
0 /usr/db   0 db
304K  /usr/etc   4.0K etc
0 /usr/games0 games
294M  /usr/include60K include
0 /usr/java 0 java
2.5G  /usr/lib32K lib
4.8G  /usr/lib64 264K lib64
780K  /usr/libexec   4.0K libexec
284K  /usr/libreadline.so.6  284K libreadline.so.6
467M  /usr/local 284K libreadline.so.6.2
0 /usr/lock 0 local
0 /usr/man  0 lock
0 /usr/opt  0 man
16K /usr/run0 opt
1.8M  /usr/samba0 run
128M  /usr/sbin  4.0K samba
16G /usr/share60K sbin
0 /usr/src44K share
6.7M  /usr/swat 0 src
0 /usr/tmp  0 swat
0 /usr/var  0 tmp
20K /usr/virtualbox 0 var
0 /usr/x86_64-suse-linux 8.0K virtualbox
total 1.6M  0 x86_64-suse-linux

by default ls has options to expand to screen tabs and line things up.
'du' does not.



As for #1 - this idea is the topic of the current thread,
and was previously decided to not be accepted.

As for #2 - not sure if this was discussed before,
but I have a hunch that once more sophisticated control
over file-traversal is needed, find(1) is likely better
solution (e.g. "find -depth").

As for #3 - The "expand" program already does tab-expansion.
It can be easily combined with existing programs using
a simple shell function.


So can calling a library where the output is expanded
automatically according to user choice in a config file.

I shouldn't have to figure out the syntax of a separate program to get
a 1-time usage of lined up output.

bug#33787: Policy Change: Use of /etc/gnu.conf files to configure default system behavior

[L A Walsh]

On 12/23/2018 5:46 PM, Paul Eggert wrote:

Similarly with 'find'


"find" is not part of coreutils, and discussion of it should be moved to
a separate bug report, which you can create by emailing bug-findut...@gnu.org.


 If you were discussing whether or  not each each county or province in
the state should have a place where the laws and regulations of that state 
and county were on display for reference or consultation, AND you had a 
case where whether or not Santa Clara County in California should include
in its display, Bay Area regulations as well, should such discussion 
or cases be opened and entertained in Santa Clara County at the same
time one is discussing the statewide or national cases?  


 Wouldn't it be proper to discuss the Bay Area's inclusion after the wider
jurisdiction cases have been discussed?  It might be wiser to discuss
other areas for inclusion after until sometime _after_ the larger case
is settled.
... configuration files 
(system-wide? user-specific? directory-specific? it's not clear).

---
  As far as the proposal went, I think it was:

   "Now I suspect that people will want these options to be
   configurable by user and not just at a system level -- so
   ideally, there would be a '~/.gnurc' file for user overrides."

applications and kernels are 
different animals, and the existence of a configuration method for the kernel 
does not necessarily imply that the same configuration method is a good idea for 
applications.

---
 Different animals, yes, but similar eco systems (arch, hw, source
lang(s), users, etc...).  Also, a need to configure both for their
environments.  Both need different methods for building on x86 than on
MIPS, likely different building for a US-based distro vs.
a China-based distro.  Like different need for home environment vs
that of a National-Security-Agency, or a bank.  Even a vastly
different needs based on filesystem type (How many times did we see
a message from the tail program about an unknown file system?).

 Of course in some ways, the kernel stores part of the user's choices
in the hardware config.   If they wanted a graphics pen, they probably
bought one, and windows will turn on pen-input, though on linux it's
probably "each app for themself", however the variability in how the
kernel can be configured not only varies by hardware but by your
desired software behavior.  Turning on FLASK or SMAC security will
result in the utilities behaving differently.

 In all of the above, we see lots of configuration for different
items, but almost non of those items touch on "*user-requirements".
Huh?  user requirements?  Nearly every bit of new work has
a requirements or prereq. list; why not users?

 In new features or improvements in the past year or two -- how many
of them came with some study or poll of users who asked for it?  How
many voted for the feature vs. against?  How many were discussed on
coreutils before they were introduced?  How much weight is given to
user requests?  


 At one point in time there were vendor versions of many of these
tools, but people often sought the gnu version because it had some
extra behavior or feature.  Additionally, I would bet that
many gnu features and utils wooed users by being responsive to
new feature and enhancement requests.  Unfortunately, these days
there usually isn't an alternative.  Gnu has gone from responsive
to the place of "holding the line" against user wanted changes.

 Out of a list of new features or in the past few years, how many
came from user requests?  I wonder if number of requests has dropped
off as fewer people are drawn-to or have the ability to do software
development (hard to think about doing much in the way of development
on an iPad or Android device). 


I encountered a first, recently: a third-party company that was hired
to support end-users adapting their computers to the program -- but
that did no actual support of the program.  If you wanted a new
feature or bug -- you were directed to a community discussion
list that you are told "is often a place where developers (in
a different country speaking a different language) get new
ideas.  Right   


 The disconnect seems to almost be complete.  No longer are programs
created to attract users or solve their problems, but users and their
HW are now being adapted to run the programs.

 Maybe this is the first step in computers & hardware laying down
requirements for users.

 So I can see why providing a /etc/gnu.conf file to allow programs
to support diffent user behaviors would seem like a a step backward.
But is it really?

bug#33787: Policy Change: Use of /etc/gnu.conf files to configure default system behavior

[L A Walsh]

On 12/20/2018 5:21 PM, Assaf Gordon wrote:


If you are requesting such features (or others)
It's best to start a new thread for each topic.



They've already been discussed and ignored because there was no
way to add the feature for a default behavior other than
ENV vars or a config, both of which have been rallied against
to maintain the behavior monopoly with the existing devs.

bug#33787: Policy Change: Use of /etc/gnu.conf files to configure default system behavior

[L A Walsh]

Features where their non inclusion was unable to be met due to
pre-existing usage and where using or allowing behavior change based
on ENV vars was disallowed due to new gnu policies to minimize usage
of ENV vars.  At the time config files were mentioned as a possible
solution but at the time I was told there would be no more config files.

Now I'm seeing references to /etc/xattr.conf regarding which attributes
should be copied and which not when utils like 'cp' or 'tar' preserve
or restore xattrs.  If you don't allow a config, how will you skip
attributes that shouldn't be copied on a given system vs. those that 
should?


As for random features being added, paul, who was it that added a random
range feature incompatible with what was original suggested and going off
in a different direction.  You created an incompatible feature to the 
one that was originally proposed... so this is to allow a workaround for

for malicious features rushed to build to disallow alternate sets. It's
not about a new random one, but one that you specifically found an
alternate and incompatible algorithm for.  It certainly is no more of
a random feature than the collection of new features that has gone
into random coreutils programs in the past year or two -- many of which,
like with 'ls' were strongly complained about -- and ignored.

Those people who don't like the new, unwelcomed 'features' forced 
upon them would have a choice.


Similarly with 'find' -- supposing to use the user provided prefix
prepended on targets, when this doesn't:

"find -type f" doesn't emit plain filenames, but "./" appended to each.

But if you want "./" appended, you already have
"find . -type f".  There are several little nitnats that came down to 
the dev's choice overriding things users suggested or wanted.

This would allow users to have a choice -- so of course the dictator
devs wouldn't like or want this.  Users are to be trodden upon and forced
to conform to what devs think they should do.  So much for user-friendly
and programs being to help users vs. oppressed by them.


On 12/20/2018 4:48 PM, Paul Eggert wrote:
If the behaviors you want cannot be done now via command-line options, 
that's not an argument against configuring via PATH; it's merely an 
argument that you would like some random features that the programs 
don't provide now.

bug#33787: Policy Change: Use of /etc/gnu.conf files to configure default system behavior

[L A Walsh]

The below methods cannot alter or fix  the problems that require
a configuration file.

Example: have 'rm -fr .' do a depth first removal and not 
pre-inspect any argument before its children.


Whether or not to expand tabs in output so that output to
a terminal that doesn't have tabstops every 8 characters will 
line up.


I could go on, but those cannot be handled with a simple alias.





The common and recommended way to add default command-line arguments
is to use aliases (e.g. "alias rm='rm -i'").

If used in $HOME/.profile - it will affect your interactive use.
If used in /etc/profile (or similar) - it will affect all users in your
system.

That method already works in almost every Unix system - without adding
additional code and complexities of a global configuration file.



Given the above, I'm closing this as "wontfix".
Discussion can continue by replying to this thread.

bug#33787: Policy Change: Use of /etc/gnu.conf files to configure default system behavior

[L A Walsh]

But coreutils already does act differenty based on what
local libraries it pulls in at runtime.  If you want to
ensure they have the same behavior then they'd be statically
linked.

Second, coreutils behaves differently depending on the contents
of xattr.conf -- any util that deals with files will need to have
a look at that.

Third, coreutils behaves differently based on what is installed
with alternate versions of various programs, including coreutils
being configured for use on a system-by-system basis.

On more than one coreutils-including system, I see coreutil 
programs replaced with alternate versions like from BSD

because the bsd version was more user friendly.

Coreutils should service the owner of the system.
They should not be like a virus or malware that can change
behavior at the behest of the util-maintainer against what 
users want.  This has been what is happening.  


I'm suggesting a way for coreutils to better serve the users
of these programs.  Note -- there is facility for separating 
behaviors desired for scripts vs. those desired for interactive

use.  It has been my intent that behaviors for scripts could
advise users to accept defaults to provide for script 
portability between systems.


But for interactive use, I can make the statement that coreutils 
should not go against what users want and have 
non-optional/non-configurable changes made to defaults against

their will.  That's the behavior of malware.

Foremost, software should be user friendly -- something 
many if not most software developers have forgotten.  It's

there to service the users. Not to control them and force them
to do things in a way they are not comfortable with or that
causes them unnecessary grief.

Those things said, coreutils apparently is already using xattr.conf
and my proposal is to fold that into a gnu.conf where other
utils can store config ops, or go ahead and provide gnu.conf 
even if xattr.conf doesn't want to fold in to allow more 
flexibiltiy


At this point, all I'm trying to do is to gather xattr.conf into
one place, 'gnu.conf', so that users can know to pay attention to
it.  Notice I'm naming it 'gnu.conf' and not coreutils.conf -- I'm
not intending this to be limited to coreutils.



On 12/20/2018 1:59 PM, Paul Eggert wrote:

On 12/17/18 11:12 PM, L A Walsh wrote:

I find that /etc/xattr.conf is being used to
regulate behavior in gnu tools.


Sure, just as lots of other system configuration files do, e.g., 
/etc/passwd. But these files are intended to act globally throughout the 
operating system; they're not an exception to the rule that coreutils 
itself is supposed to portable.


Coreutils should not behave differently on different hosts merely 
because the coreutils installer on one platform prefers behavior A 
whereas the installer on another platform prefers behavior B.

bug#33786: Bug: undocumented feature (algorithm) for version-sort (include on manpage)

[L A Walsh]

I wouldn't consider debian to be a standards organization.

Perhaps they should get their version sort adopted by POSIX?

But having algorithms that read:

use ascii sort for this field if after a character in this list [].
but use numeric sort for this field if after this list [].
but use an indeterminant sort if the field has unicode characters...

would hardly seem likely if it was a publish standard.

In the test cases I used, subsequent fields' sort methods
were determined by previous fields with a non-obvious
behavior. 

That it is well documented on the net 'somewhere', is 
part of the problem -- on a console, there was no

web browser nor internet access.

bug#33786: Bug: undocumented feature (algorithm) for version-sort (include on manpage)

[L A Walsh]

So undocumented features are considered wishlist items
in Gnu?   


On 12/18/2018 12:04 AM, Assaf Gordon wrote:

tags  33786 notabug
severity 33786 wishlist
retitle 33786 doc: sort: document Debian's version-sort algorithm
stop

Hello,

On 2018-12-18 12:11 a.m., L A Walsh wrote:

meaning that if one is going to put a Debian sort into a
general purpose tool like "sort", then the algorithm really
needs to be documented.


It is well documented in many places online, e.g.:
https://www.debian.org/doc/debian-policy/ch-controlfields.html#version
https://readme.phys.ethz.ch/documentation/debian_version_numbers/

With a shorter summary available in the coreutils manual here:
https://www.gnu.org/software/coreutils/manual/html_node/Details-about-version-sort.html#Details-about-version-sort


This means there is no way to verify consistent behavior
from as the utility matures 


The sort-version.sh test ensure the behavior is consistent from
one release to the next:
https://opengrok.housegordon.com/source/xref/coreutils/tests/misc/sort-version.sh

It also ensures the behavior is compatible with Debian's definition.


and no way to write an
independent, auditable test case to assure that the sort algorithm, 
operates with consistency from release to release

as well as w/r/t other included sort algorithms.


This message contains example of how to compare results between
coreutils' sort and debian's utilities:
https://lists.gnu.org/archive/html/bug-coreutils/2018-11/msg00017.html

Here's a post about doing the same using python:
https://stackoverflow.com/a/4957741

And in NodeJS:
https://www.npmjs.com/package/deb-version-compare

I'm sure there are many other implementations that
allow easy comparison of one against the other to quickly find
any discrepancies.


As for auditable code, the actual code is here (part of gnulib):
https://opengrok.housegordon.com/source/xref/gnulib/lib/filevercmp.c

And gnulib also includes a unit-test:
https://opengrok.housegordon.com/source/xref/gnulib/tests/test-filevercmp.c

There's no better audit-ability than the source code itself.



The request here is for the algorithm used by 'version-sort'
be included in sort's manpage.  This should document
sort's features for reference and use by users who are using
the utility in its native, cmd-line environment.


If a coreutils' program implements a known standard,
it's not necessarily beneficial to include implementation details of
the standard, as this is available elsewhere.

For example, the manual for the "base64" program does not include
an explanation of what base64 is. Instead, it links to RFC4648:
https://www.gnu.org/software/coreutils/manual/html_node/base64-
invocation.html#base64-invocation

As your request is for a change in documentation, I'm marking this
as a wish-list item.
As always, concrete patches are welcomed and they go a long way towards
expediting any desired changes - if you have suggestions please do send
a patch.


Also of importance: that the documentation should be include with the
source and installable with the program executable.

When someone downloads coreutils' source, they automatically get
the manual (in texinfo format, easily convertible to HTML/PDF).

When they install coreutils (e.g. "make install"), the manual
is also installed (as an "info" file).


regards,
  - assaf

bug#33787: Policy Change: Use of /etc/gnu.conf files to configure default system behavior

[L A Walsh]

Over the past few years I have has for the ability to set
defaults for my system regarding various behaviors in
coreutil programs.  Some of the these behaviors have been
regulated via ENV vars in the past, but I was told that this
was not desirable as gnu was trying to get away from using
ENV vars to regulate a person's util behavior in their
environment.  I suggested using a config file in /etc
as an alternative and was told "no way". 


However, now I find that /etc/xattr.conf is being used to
regulate behavior in gnu tools.

Given the acceptance of such config files I would like
see a single file /etc/gnu.conf hold configs for any gnu
tool.

In it should be options for configuration by function
and tool, with tool-specific options overriding
function-specific options.  An additional selector
should be if the behavior is configured for "interactive"
use vs. "script" use.

Now I suspect that people will want these options to be
configurable by user and not just at a system level -- so
ideally, there would be a '~/.gnurc' file for user overrides.

Examples of configurable items:

Default quoting and sorting
Default TAB expansion (both tab column and expansion to space)
Default aliases for existing long options.
Default algorithm usage (if using depth-first processing,
   no pre-processing of names in non-depth-first order).
Default addition of optional path elements ("find" processing)
Default per-unit prefixes and their values.

The above should not be taken as a comprehensive list, but
as possible examples of included items.

Maybe I can go back and resubmit several bugs that would benefit
from this new policy?

L Walsh

bug#33786: Bug: undocumented feature (algorithm) for version-sort (include on manpage)

[L A Walsh]

Recently there was some discussion on inconsistencies in
how version sort worked and some people *basically*, said:

  "it's not our fault, it's Debian's algorithm, you wanna
  change it, convince them."

Um...fine.  Except that it is a Gnu tool, not a Debian tool,
meaning that if one is going to put a Debian sort into a
general purpose tool like "sort", then the algorithm really
needs to be documented.

This means there is no way to verify consistent behavior
from as the utility matures and no way to write an
independent, auditable test case to assure that the sort 
algorithm, operates with consistency from release to release

as well as w/r/t other included sort algorithms.

The request here is for the algorithm used by 'version-sort'
be included in sort's manpage.  This should document
sort's features for reference and use by users who are using
the utility in its native, cmd-line environment.  


Also of importance: that the documentation should be include
with the source and installable with the program executable.

thanks,
linda

bug#33303: prob no. thirty-three thousand, three-hundred & three: hex id for file system is incorrect

[L A Walsh]

The reason I was confused about the output -- is that
it really is messed up. (3-3-3-0-3)

On 11/8/2018 6:19 AM, Bernhard Voelker wrote:

On 11/8/18 11:53 AM, L A Walsh wrote:

Both should be %i for the file system ID in hex.
How is it that the fs ID is the same as the device
number of the file system?

i.e.
8:34 =  8:21 in hex
8:33 =  8:22 in hex


dunno - I assume this is the secret of the implementation of the file system.
Did you verify with strace?  I'm quite sure 'stat' only forwards the
values from the system call.



Nope.  It's just wrong: someone added a define, above, 
around #116:


#  define f_fsid dev

So instead of a fsid, it's the device number in hex
with an extra 8 0's tacked on the end.

Does your source control allow finding out when that was added
and by whom?

tnx...

bug#18168: Bug in "sort -V" ?

[L A Walsh]

On 11/6/2018 10:48 AM, Assaf Gordon wrote:

On 2014-08-01 3:38 a.m., Schleusener, Jens wrote:
  
I am not sure if it's a bug or not but for my application cases the 
"sort" command with use of the very helpful option "-V" (natural sort of 
(version) numbers within text) not always delivers the by me expected 
output.



Note that "-V/--version" is specifically sorting by Debian's *version*
sorting rules. It might seem like it's the same as "natural sort", but
it is not.
The exact rules are here:
https://www.debian.org/doc/debian-policy/ch-controlfields.html#version
https://readme.phys.ethz.ch/documentation/debian_version_numbers/
  

Example input file (with four test cases):
1.0.5_src.tar.gz
1.0_src.tar.gz
2.0.5src.tar.gz
2.0src.tar.gz
3.0.5/
3.0/
4.0.5beta/
4.0beta/

Sorted ("sort -V") output file (with errors?):
1.0.5_src.tar.gz
1.0_src.tar.gz
2.0src.tar.gz
2.0.5src.tar.gz
3.0.5/
3.0/
4.0beta/
4.0.5beta/

By me expected output file:
1.0_src.tar.gz
1.0.5_src.tar.gz
2.0src.tar.gz
2.0.5src.tar.gz
3.0/
3.0.5/
4.0beta/
4.0.5beta/



The disagreement is about "1.0_src.tar.gz" vs "1.0.5_src.tar.gz"
and "3.0/" vs "3.0.5/" .

Note that these characters are not strictly valid characters in debian
version strings.
  

---
   I too would disagree with the above ordering.

   This bug had me go and look at 2 places where I compared version
strings (I compared 2 algorithms) using the above as input, but removing
the '/' which really shouldn't be part of the version string as it looks 
like
output from ls (though I probably should add that case in my torture 
testing).
My 2nd algorithm looks like I looked at sources from rpm probably 
derived from

some debian order.

   My first algorithm I could justify as right or wrong gives the original
posters expected order, but the 2nd(likely deb) gives the deb order -- 
almost.
The addition of the '/' chars changes the sort order.  Even that points 
to the

assertion that "it shouldn't".

I.e. in the
3.0 v. 3.0.5, the latter comes out 'greater' in deb rules rules (and mine)

**BUT**

3.0/ v. 3.0.5/ and
3.0_ v. 3.0.5_  don't sort as might be expected, though these:

3.0- v. 3.0.5-
3.0() v 3.0.5()
3.0a v. 3.0.5a

show the 2nd expr as greater.  I am thinking such inconsistencies are a bit
odd in a Version-sort, especially for a determinant tool?



Let's try to compare them using Debian's own tools:

First, define a tiny shell function to help compare strings:

 compver() {
dpkg --compare-versions "$1" lt "$2" \
 && printf "%s\n" "$1" "$2" \
 || printf "%s\n" "$2" "$1"
 }

Then, compare the values:

   $ compver 1.0.5_src.tar.gz 1.0_src.tar.gz
   dpkg: warning: version '1.0.5_src.tar.gz' has bad syntax: invalid 
character in version number
   dpkg: warning: version '1.0_src.tar.gz' has bad syntax: invalid 
character in version number

   1.0.5_src.tar.gz
   1.0_src.tar.gz

   $ compver 3.0/ 3.0.5/
   dpkg: warning: version '3.0/' has bad syntax: invalid character in 
version number
   dpkg: warning: version '3.0.5/' has bad syntax: invalid character in 
version number

   3.0.5/
   3.0/

So sort's order agrees with Debian's ordering rules.
  

---
   One might consider an error, to mean "indeterminant".

   Especially -- it should be the case that the tool sort documents how it
sort(s) work within its manpages. -- hyperlinks to outside sources 
doesn't usually cut it for this type of program (console based -- _most_ 
consoles

don't support hyperlinks).

bug#33371: RFC: option for numeric sort: ignore-non-numeric characters

[L A Walsh]

On 11/14/2018 12:27 AM, Erik Auerswald wrote:

Hi,

On Tue, Nov 13, 2018 at 06:32:55PM -0800, L A Walsh wrote:

I have a bunch of files numbered from 1-over 2000 without leading zeros
(think rfc's)...
They have names with a non-numeric prefix & suffix around the number.


Are prefix and suffix constant? RFC files are usually named rfc${NR}.txt.


It would be nice if sort had the option to ignore non-numeric
data and only sort on the numeric data in the 'lines'/'files'.


Perhaps --version-sort could work for you?

$ for r in rfc{1..100}.txt; do echo "$r"; done | sort | sort -V

(The first sort un-sorts the sorted input data, the seconds sorts it
again.)

-
Tried this... had initial "turn-off" with using a for loop to
list files when '/bin/ls -1 *.txt' was so much shorter.  However, just
the 'sort -V' works by itself, works.

I'm not sure exactly why, but that wasn't initially clear to
me, though, maybe should have been, having written version-sort
more than once before. 


Minor gotchas, using single numbers, the for loop produced:
rfc1.txt
rfc2.txt
rfc3.txt
rfc4.txt
rfc5.txt
rfc6.txt
rfc7.txt
rfc8.txt
rfc9.txt

while the '/bin/ls -1 rfc?.txt|sort -V' algorithm produced:
rfc1.txt
rfc2.txt
rfc3.txt
rfc4.txt
rfc5.txt
rfc6.txt

(7-9 didn't exist in the directory)


[...]
Or is there an options for this already, and my manpage out of date?


AFAIK not exactly.

Thanks,
Erik


"-V" seems like it might be sufficient, but I doubt most
non-computer types would know that -V would sort multiple numeric fields
separated by invariant non-numeric characters in a numeric fashion
(or would even know how a version sort is the other sorts).

Given how well read docs are these days, almost need a literal definition
of 'version sort' besides just calling it a 'version sort' (which we
must admit, is 'jargon'). Along the lines of:

   --version-sort |  -V 
  Sees inputs as a mix of numeric and alphabetic (or "identifier")

  fields, where the numeric fields are sorted naturally, and alpha
  fields sorted alphabetically.  Fields may have separators like
  '.', '_', or '-',  sometimes constrained by a specific computer
  language, or may have no separator at all between numeric and
  alpha fields.  This is type of sort is often called a 
  "version sort" in the computer field.


???  I listed 'version sort' at the end, as the equivalence so those who tend
to skip and read initial parts of lines/paragraphs would not just see 
"version sort" and gloss over the rest, inserting their own equivalence

for the definition -- especially likely w/"version-sort" being the long form
of the switch.

bug#33371: RFC: option for numeric sort: ignore-non-numeric characters

[L A Walsh]

On 11/13/2018 6:44 PM, Eric Blake wrote:

On 11/13/18 8:32 PM, L A Walsh wrote:

I have a bunch of files numbered from 1-over 2000 without leading zeros
(think rfc's)...
They have names with a non-numeric prefix & suffix around the number.

It would be nice if sort had the option to ignore non-numeric
data and only sort on the numeric data in the 'lines'/'files'.

Yeah, I can renumber and rename them all, but I just wanted
an instant command that could sort numeric values even if embedded
in a line, where the "field" was determined by the start/stop of
numeric characters.

Or is there an options for this already, and my manpage out of date?


Without ACTUAL data to experiment with, it's much harder for anyone else 
to propose a solution that will work with your specific data.


	...think rfcs...um have you ever looked at the directory 
with a bunch (all or most) rfc in it?





But one quick approach comes to mind: decorate-sort-undecorate:

sed 's/^\([^0-9]*\)\([0-9]*\)/\2 \1\2/' < myinput \
   | sort -k1,1n | sed 's/^[0-9]* //' > myoutput



That does work, but still seems a bit odd on a numeric
sort not to have it, even by default, ignore non-numeric data in front or after.

I may be imagining this, but I though I'd seen some version of sort
that did this -- simply skipping the non numeric characters and sorting on the
numbers.

Instead this sort reverted to alpha sort.  Thinking about
it...if I ask for numeric sort, shouldn't it at least try to look for
numbers in each line to sort them?

That seems like it might be a user-friendly and even consistent
thing to do, considering there are options to
1) ignore leading blanks
2) ignore case
3) ignore nonprinting... ( this most close parallels the request, since when 
	when doing an alpha sort, one might hope it could ignore what isn't 
	visible).

4) "human sort" --- actually this option sorta makes it look like a
bug, since this sort ignores things that don't look like a number+suffix).
So why wouldn't numeric sort do the same?

I'd even sorta hoped the -h sort might work for this... since
if you were showing sizes, and only had values in 'bytes', you wouldn't see
the suffixes.  So I'd hoped that it would order 
rfc98.txt before rfc979.txt, but such is not the case.


I.e. in the case of 'ls', it ignores junk before and after the 
numbers+optional unit).  So one might wonder why it doesn't properly 
sort the numbers with 'rfc' before them and '.txt' after them.  

I.e. should 4 have worked maybe?  Might be a bit perverse, but 
can't see why not.

bug#33371: RFC: option for numeric sort: ignore-non-numeric characters

[L A Walsh]

I have a bunch of files numbered from 1-over 2000 without leading zeros
(think rfc's)...
They have names with a non-numeric prefix & suffix around the number.

It would be nice if sort had the option to ignore non-numeric
data and only sort on the numeric data in the 'lines'/'files'.

Yeah, I can renumber and rename them all, but I just wanted
an instant command that could sort numeric values even if embedded
in a line, where the "field" was determined by the start/stop of
numeric characters.

Or is there an options for this already, and my manpage out of date?

Thx
-l

bug#33303: hex id for file system is incorrect or non-standard using uil 'id'

[L A Walsh]

On 11/7/2018 11:22 AM, Bernhard Voelker wrote:

On 11/7/18 5:07 PM, L A Walsh wrote:

Was looking to see when the underlying filesystem
changed in a path.

I used:

 stat -f -c%f /

821
stat -f -c%i /var
822


sorry, I overlooked the %i example:

---
Both should be %i for the file system ID in hex.
How is it that the fs ID is the same as the device
number of the file system?

i.e.
8:34 =  8:21 in hex
8:33 =  8:22 in hex

bug#33303: hex id for file system is incorrect or non-standard using uil 'id'

[L A Walsh]

Was looking to see when the underlying filesystem
changed in a path.

I used:

 stat -f -c%f /

821
stat -f -c%i /var
822

There are way too many zeros, not to mention being left justfied
with zeros.

What I might expect to see is more like this:
821
or
822

mountpoint -d shows the maj:min for the given path (in decimal):

 mountpoint -d /

8:33

 mountpoint -d /tmp

8:34

bug#33155: rfe? cp from symlink -> to symlink? cp symlink meta-info(target) with "-a"? (vs. no diagnostic)

[L A Walsh]

Created following test dir (as seen by tree) in /tmp

 tree mybin

Ishtar:/tmp> tree mybin
mybin
├── iptool -> alt-tool #broken link
├── iptool-restore -> iptool   #broken link
├── iptool-save -> iptool  #broken link
└── usr
   └── mybin
   ├── alt-tool
   ├── iptool -> alt-tool
   ├── iptool-restore -> iptool
   ├── iptool-save -> iptool
   ├── junka
   ├── junkb
   └── junkc

3 directories, 9 files

So first I try copying iptool-save from mybin/usr/mybin to /tmp/mybin

Ishtar:/tmp/mybin/usr/mybin> cp --preserve=all iptool-save /tmp/mybin/
cp: not writing through dangling symlink '/tmp/mybin/iptool-save'

  then try:
Ishtar:/tmp/mybin/usr/mybin> /bin/cp -r --preserve=all -iptool-save 
/tmp/mybin/

(and get no error message)

It seems to have _re_copied the link (time is updated on that link)
but it didn't recursively follow the link and copy the destination.
(nor with -a).  Why did it act as though I said "force" and recopy the
link (unexpected), but didn't recursively follow the link to its target?
(not entirely expected, but wanted).

Especially if I use '-a', shouldn't copying a symlink also copy the
material pointed to -- i.e. duplicated the symlink structure at the target?

One *could* consider the target file "metadata" of the symlink, so at least,
"-a" could cover that case.

It seems odd to silence the diagnostic with "-r" and "-a", but not
recursively follow the link...(I know traditionally -r has referred to
directory structure, but in this case it would be more important & useful
to copy the symlink structure -- ESPECIALLY, since the target symlink
does not exist.  Maybe only overwrite symlink target with "-af"?

bug#32272: [PATCH] iscntrl: behavior for chars >= 0x80

[L A Walsh]

Pádraig Brady wrote:

+This function does not support arguments outside of the range of the
+unsigned char type in locales with large character sets, on some platforms.
+OS X 10.5 will return non zero for characters >= 0x80 in UTF-8 locales.
  

---
   According to Unicode, characters 0x80-0x9F are control
characters, but characters >=0xA0 are not (and have different
classifications (at least in Unicode).

   The patch doesn't say if OS X 10.5 is classifying them correctly
or not.  For example,  0xA0 is a type of Space, some are symbols, some are
letters, some are a type of punctuation, etc...

   Perhaps OS X is using their Unicode definition for characters defined
to be in a Unicode compatible encoding?



  

bug#32127: RFE -- in the way "cp -rl" -- enable 'ln' to do likewise?

[L A Walsh]

Michael Stone wrote:



Or, they expect the traditional behavior, which is that requesting a
link which can't be created will result in failure. You seem to 
completely disregard the possibility that any script written in 40 years 
might use that behavior in its logic, while I find it extremely unlikely 
that scripts would be written in the hope that someday the behavior 
might change and things work differently because they make more sense 
that way.

---
Like I saidputting change into the kernel to do the same --
seems to fly by with little or no comment...  Putting it in an app
where it is visible...and everyone complains.  Interesting.

Apps that rely on getting errors?  You don't regard that as a bit
of an unreliable design?  But easily solved -- go the way of 'ls'
and only create the symlinks if the process is interactive.

Problem solved

bug#32127: RFE -- in the way "cp -rl" -- enable 'ln' to do likewise?

[L A Walsh]

Mike Hodson wrote:

I wager that some people *aren't* aware that you cannot hardlink a directory 


If they don't know why, they probably don't know the difference
between hard and soft links to files -- and will *then* be annoyed that
linking doesn't work.  *THEN*, they will your "hundreds of NEW 
bug reports 'linking broken' 'why can't I link a directory' -- all because
ln creates no link nor gives an explanation.  

My suggestion does both -- create a link that they obviously wanted, 
of the only type that works (as no link type was specified(**) ), AND warn

that "A symlink was created, as hard-linking to a directory is
not supported".

(**) - if they go so far as to use '-P'/'--physical', then I would suggest
NOT creating the symlink. 


That addresses the issue of people filing 100's of new bug reports
as it tells them why -- it's not supported.

The message "hard link not allowed for directory" is also inaccurate.
It says hard linking is not "allowed" (permitted), suggesting it could
be.  Saying 'not supported' says nothing about permissions.


Look at the YEARS of new users being introduced, as their distributions 
finally 'stabilize' newer coreutils, to the new "Quoted Filenames" in 
'ls' . So many people have been totally confused, angry, and rather 
taken aback that such an old utility did something different.

---
Because someone chose to *add* quotes by default when there
was already an option to add them.  They changed the default on a
personal whim.  It's not the case that without quotes nothing will
work.  It was an *arbitrary* choice for change among several choices
that were already present.



Even when it could be argued(and I said exactly this when I saw the new 
feature)  "Hey, thats pretty cool, i can cut and paste with a mouse now 
and it won't require manual editing later"

---

Sigh...untrue.  Maybe someone new who hadn't developed a workflow
to handle such input would like it.  Anyone who had been around "a while"
would have developed a workaround, *if* it bothered them.  That workflow
broke with the new change:


/bin/ls -1

  # that I Copy+Paste as such:
readarray -t files

^D
## now my filenames w/spaces in them or whatever, are in 'files'
# now try to use the files like 'ls "${x[@]}"'

ls "${x[@]}"

ls: cannot access "'Anime/D. Gray-man'": No such file or directory
ls: cannot access ' Anime/DGreyMan-「ディー・グレイマン」オリジナル・サウンドトラック　２': No such file 
or directory
ls: cannot access "'Anime/Daphne In The Brilliant Blue'": No such file or 
directory
ls: cannot access "'Anime/Darling in the FranXX'": No such file or directory
ls: cannot access "'Anime/Devil Survivor 2 - The Animation OST'": No such file 
or directory
ls: cannot access "'Anime/Dragonaut - The Resonance OST'": No such file or 
directory



Total SNAFU.


many other people have made the argument of "if its not 
in an interactive terminal, NOTHING CHANGED" because so many thought 
that "well crap I can't rely on any scripts to work anymore" \

---
If I never ran interactively, I wouldn't have noticed (nor
would I already have a workaround).  

	So it was 1) arbitrary, 2) already had an option to do 
it (could have been done w/aliases) and 
3) it broke existing workflows ==>>  Bad Change.


The proposed change, however fixes an error condition
as well as provides the workaround, automatically (with an
optional explanation).  The two cases are VERY different.

-l

bug#32127: RFE -- in the way "cp -rl" -- enable 'ln' to do likewise?

[L A Walsh]

Michael Stone wrote:

On Tue, Jul 17, 2018 at 02:15:14PM -0700, L A Walsh wrote:

  I can't think of a similar failure mode that I'd want a hard link
created


Yes, you've made that clear

---
I think you are making it clear that you didn't
understand what I said and why I said it.

	I said that I could not think of a similar situation 
that would involve creating a hard link by default, as I would

not be less than 50% certain it was what was wanted.

That is directly the opposite of my initial proposal
to handle directories differently and default to the only
option that works rather than assuming they got it wrong
and issuing an error message and not doing anything useful
for them.

You seem to think my positions on the two types of links
would be the same when they are not.  In almost any
circumstance where you could create a hardlink, you could also
create a symlink -- I.e. if you *wanted* to try to do what the
user wanted, there is no way to know -- since there are two
possibilities.

In the case of creating a link to a directory there is
no choice in creating a "working solution".  If you want a link 
there, it HAS to be a symlink.  That the user would bother to

use the 'ln' (link) command in the first place is a sufficiently
convincing "argument" that they really DID want a link there.
That they didn't explicitly specify the type should additionally
be taken that they didn't care enough to specify the type -- only
that the link be created.

I hope that clarifies that I'm not attempting to always
find some "automatic action", but saw that in this case, it
wouldn't be hard to figure out what was wanted and that doing
so wouldn't be hard to undo if it was not.

bug#32127: RFE -- in the way "cp -rl" -- enable 'ln' to do likewise?

[L A Walsh]

Michael Stone wrote:

On Tue, Jul 17, 2018 at 01:25:59AM -0700, L A Walsh wrote:
  

I am not suggesting handing out alternates when you have a
choice.  I'm suggesting doing something useful in a case where there are
no alternates and no downsides.  If you can come up with a case where
a symlink to a directory would do more harm than a hardlink, I might agree,
but in this case, hardlinks are not supported.  So there can be no
"dramatic consequences".  I.e. that sounds more like FUD for the sake
of argument than a sound engineering analysis.



You want to change the semantics of a command that's been around for 40 
years, which can be used as an atomic primitive, which has the very 
simple semantics of "make this hard link or fail", and your idea of a 
"sound engineering analysis" is "I don't see how this could cause a 
problem"?
  


   I can't think of a similar failure mode that I'd want a hard link
created, so I can't say I'd be in favor of that or not.

   In this case, we aren't talking about atomic primitives -- or hard
links.  If you can make a hard link to a directory, I'll stand corrected,
but this is using 'ln' to create a sym link to a directory -- something
that can't fail in standard linux.

I don't see how this could cause a problem = I see no way for this to cause
a problem =>  I assert it can't in normal usage.  If you create an OS where
symlinking a directory removes it, then that is not what we are talking
about here.

OTOH, Just as redhat et al changed the semantics of both symlinks and
hardlinks via a setting in the kernel, I suppose a solution could be
implemented there: if the kernel detects an attempted hardlink to a
directory, it creates a symlink instead.

Do you really see modifying the linux kernel and how it handles links as
being safer than adding the proposed behavior to 'ln'?  I would be 
surprised if many linux users knew where to disable the new behaviors 
(which are enabled

by default in many distros) that change default semantics.  I suspect
most users weren't even aware of the change, though I hit the change on
the first new kernel with the features.  The features were based on 2 linux
security firms -- one being gr_security -- the company that tried to silence
a security researcher pointing out their poor security practices.

A review of the stated reasons for making these kernel changes points to
their them being necessary to get around other poor security decisions
that most unix old-hands knew ages ago -- reasons for having tmp files on
separate partitions from user, tmp, and system files, and reasons why adding
new security features that don't apply to root can cause problems.
(most users can rely on not accidently overwriting someone elses files in
/tmp.  Since root can override such restrictions, they can more easily
be exposed to disintegrous files.

Anyway, since only values 0/1 were used for symlink control, it would be
easy to say, value==2, would auto create a symlink to a dir when any
type of link is attempted. 


Of course, I was just suggesting an ease-of-use change for the 'ln' program
to create the only viable type of link one can make when trying to make
one pointing to a directory.  But if you think that's too risky despite
not being able to come up with any solid examples, then the same feature 
could

be built into the kernel and probably with less FUD.

Note that the the change to ln was to follow along in the path of 'cp 
-rl', where even though hard-linking is specified, "creates" directories 
-- which

would seem to violate your "atomic primitive" behavior, no?









  

bug#32127: RFE -- in the way "cp -rl" -- enable 'ln' to do likewise?

[L A Walsh]

Bernhard Voelker wrote:



I disagree here: some people are not that familiar with the differences
between symlinks and hardlinks, okay, but the consequences for using either
type may be quite dramatic later on.


I am not suggesting handing out alternates when you have a
choice.  I'm suggesting doing something useful in a case where there are
no alternates and no downsides.  If you can come up with a case where
a symlink to a directory would do more harm than a hardlink, I might agree,
but in this case, hardlinks are not supported.  So there can be no
"dramatic consequences".  I.e. that sounds more like FUD for the sake
of argument than a sound engineering analysis.


Therefore I think it's better to give
a helping error instead of second-guessing what the user *may* have wanted.


I said doing both would be fine -- i.e. creating the symlink
and issuing a warning that a symlink was used.


The point is: also an experienced user may sometimes forget to specify
the -s option, and I'm sure they *want* a proper error message.


I think I'd fall into the category of experienced user -- more
so than most.  I really don't care about a proper error message nor do I
prefer to type in '-s'.  I just wanted the link of the right type for
linking to a directory.  Your example of what an experience user would want
is conjecture, and in this case, incorrect.  Additionally, your initial
argument refers to cases that cannot occur or happen w/modern linux (or 
unix) systems.  I repeat -- what dramatic consequence could happen here

where the user got a symbolic link, but somehow expected expected a hard
link -- what worse behavior would a symbolic link enable that wouldn't have
happened with a hard or physical link?

	If you can come up with a realistic case where such code 
creates dramatic effects/consequences, then lets have a discussion on real

problems -- not on things that don't exist.

bug#32127: RFE -- in the way "cp -rl" -- enable 'ln' to do likewise?

[L A Walsh]

Paul Eggert wrote:

On 07/12/2018 02:16 AM, L A Walsh wrote:

I'm asking why does 'ln' bother to tell the user that they are
wrong and do nothing useful?  Why not just go ahead and create a symlink


The user didn't ask for a symlink,

User didn't ask for a physical or hardlink (-P) either.  Just asked
for a link, kind unspecified.


and it sounds unwise for ln to be
second-guessing that.

---
 True - should **probably** have given them *SOME* link.  Since
they didn't specify Physical or Symlink...either would be fine.



Sometimes, reporting an error and exiting is a
better thing to do.

---
Unless they claim to want one or the other (-P or -l), unless
it is an "undo-able" operation (like one that deletes data), why would
you guarantee ln doing the wrong thing, rather than having a better than
50% chance of doing the right thing?

bug#32127: RFE -- in the way "cp -rl" -- enable 'ln' to do likewise?

[L A Walsh]

Paul Eggert wrote:

On 07/12/2018 02:16 AM, L A Walsh wrote:

I'm asking why does 'ln' bother to tell the user that they are
wrong and do nothing useful?  Why not just go ahead and create a symlink


The user didn't ask for a symlink, and it sounds unwise for ln to be
second-guessing that. Sometimes, reporting an error and exiting is a
better thing to do.


Often in deciding whether it is good or not good to make a reasonable
attempt at completion factors are evaluated --  such as consequences
for trying or not trying and whether or not the user is running
interactively or not, and the likelihood of the possible solution being
what they wanted.

In this case, it seems they wanted some type of link created or they would not have used the link command.  If they link was created as a symlink because hardlinks are not available, then they have solved their problem.  If the link isn't created because hardlinks are not supported (even though they did not specify the link type (-P|-s) then ln would fail and they would need to redo the command.  

If they didn't want the link created, it would be unlikely they'd be using the 'ln' (link) command.  


Only in the case that they wanted a link -- but only a hard link, would they 
need to remove it -- 'ln' would have failed to do the right thing.


I posit that they wouldn't need to create a hard link in a workable
solution -- they will need to find some other way to create a solution ( 
perhaps mounting the file).  However if they are not root, they won't be able 
to use that solution.  I would suggest that it would be unlikely that they 
would need a hard link there and they might change their mind and decide that a 
symlink is fine.


In all of the cases, given the probabilities, it would be most helpful and most 
useful to create *some link*, as that is what they asked for by using the 'ln' 
command.  Non of the outcomes require any more correction than undoing the 
incorrect action, but it is likely they would agree that a symbolic link was 
the right choice given that physical links are not
available.

You said "The user didn't ask for a symlink".  Neither did they hask
for a hardlink by using "-P'.  They wanted a link.  Creating the only
possible link would seem to be the best option available.

Indeed -- my focus was on creating a link -- that it had to be a symlink
was a bit of minutia that I didn't care much about.  If I had stated that
I wanted a physical link by specifying "-P" -- then I would not suggest
auto-creating the link -- only in the case where a link was asked for
without specification of type.

Frequently is is more user friendly to do something than do nothing (assuming 
doing something doesn't cause damage -- which is the case here.

-L.

bug#32127: RFE -- in the way "cp -rl" -- enable 'ln' to do likewise?

[L A Walsh]

 Original Message 
Subject: 	bug#32127: RFE -- in the way "cp -rl" -- enable 'ln' to do 
likewise?

Resent-Date:Thu, 12 Jul 2018 07:17:02 +
Resent-From:    L A Walsh 
Resent-CC:  bug-coreutils@gnu.org
Date:   Thu, 12 Jul 2018 00:16:50 -0700
From:   L A Walsh 
To: Paul Eggert 
CC: 32...@debbugs.gnu.org
References: 	<5b465a80.8030...@tlinx.org> 





Paul Eggert wrote:

L A Walsh wrote:

Like I'll want an "RCS" dir to point to 1 RCS tree -- so I try to use
ln  .  ln, of course seems to think I
want the impossible -- and says you can't have hard-linked directories.


You can use "ln -s" instead of plain "ln". If that's not what you want, then I'm 
afraid I don't understand what you want, exactly.

---
Yes, I can retype the command after getting an error telling
me that regular links to directories are invalid.

I'm asking why does 'ln' bother to tell the user that they are wrong 
and do nothing useful?  Why not just go ahead and create a symlink -- since it 
is likely that is what is wanted and is the only type of link that works?

If needed, it could even tell the user that hard links don't
work so it created a symlink instead.  That way, in the mostly likely case 
(user wanted a symlink and left off the '-l'), they user would have the symlink 
created and would not have to re-enter the command.

bug#32127: RFE -- in the way "cp -rl" -- enable 'ln' to do likewise?

[L A Walsh]

Paul Eggert wrote:

L A Walsh wrote:

Like I'll want an "RCS" dir to point to 1 RCS tree -- so I try to use
ln  .  ln, of course seems to think I
want the impossible -- and says you can't have hard-linked directories.


You can use "ln -s" instead of plain "ln". If that's not what you want, then I'm 
afraid I don't understand what you want, exactly.

---
Yes, I can retype the command after getting an error telling
me that regular links to directories are invalid.

I'm asking why does 'ln' bother to tell the user that they are wrong 
and do nothing useful?  Why not just go ahead and create a symlink -- since it 
is likely that is what is wanted and is the only type of link that works?

If needed, it could even tell the user that hard links don't
work so it created a symlink instead.  That way, in the mostly likely case 
(user wanted a symlink and left off the '-l'), they user would have the symlink 
created and would not have to re-enter the command.

bug#32127: RFE -- in the way "cp -rl" -- enable 'ln' to do likewise?

[L A Walsh]

If one does a 'cp -rl' -- one gets a coyp of the tree...sorta,
with file hardlinked, and with directories getting their own set
of inodes because:
can't be hardlinked -- so no hardlinking (even if worked, wouldn't make
a separate copy) &&
can't have softlinked dirs, as to softlink something, you need something
to softlink things *to*.  If dirs were softlinked, again, the files
inside would be referenced by the same name-entry in the same real 
directory.


Instead it tries to do a useful think in creating a separate tree with
a fresh set of name entries that point to the same inode-data.

In the same way, I'm often wanting to work on some set of source
files from a different starting location in the source tree.

Like I'll want an "RCS" dir to point to 1 RCS tree -- so I try to use
ln  .  ln, of course seems to think I
want the impossible -- and says you can't have hard-linked directories.

Instead, just as cp-rl only hard links files while creating new dirs
for directories in the other tree, instead of treating dirs+files the
same, and giving an error message that wouldn't be helpful.


I was wondering if ln dir1 target/ could differentiate and "do what
I meant", and create a softlink rather than giving an error and
requiring me to re enter the command with -l.

I wouldn't be against the idea of it saying that it created a softlink,
but the point it to favor it doing something useful rather than issuing an
error that isn't.

Would that be possible? 
Thanks,  Linda

bug#30928: no error val returned by 'nice' failure?

[L A Walsh]

Paul Eggert wrote:

L A Walsh wrote:

how do you tell if the resetting of the
priority worked or failed?


I guess you're supposed to look at stderr, which is what you did.

This is the way 'nice' has behaved for quite some time, and it's what POSIX 
specifies. We'd need a real good reason to change it, given that changing it 
would no doubt break stuff.

---
How about a flag, like -e for 'fail on failure to change priority' and
(maybe less important or useful) '-w' to only return nice's return 
value, with the posix error message returned for called app (if error).


So, 
 nice -e --19 sleep 99

would return immediately if not root with exit status for EPERM (and
no text); sleep would not be executed.

and for -w case:

 nice -w --19 ls noexist
would return status for EPERM, and message:
ls: cannot access 'noexist': No such file or directory

Seems those would cover most possibly wants, though
the first would be enough to determine if nice is going to work.

Not an earth-shattering change, but at least it would allow
some way to check if nice is going to work or not so
one could not use it where it would fail (and not
generate an error message).

Thanks,..