bug#7731: Bug in coreutils version 8.7 sort on i386 (Leopard) macintosh system

[Assaf Gordon]

close 7731
stop

(triaging old bugs)

On 25/12/10 07:11 PM, Paul Eggert wrote:

On 12/24/2010 12:21 PM, Allen Delaney wrote:


sort -u -s --key=1,1 sort_8.7_i386_bug_testdata > xxx


That looks like bug 7489 ,
which is fixed in coreutils 8.8.  Can you please give 8.8 a try?


Both coreutils 8.8 and Mac OS Leopard on i386 are very old,
and with no follow-ups in 8 years - I'm closing this bug.

-assaf

bug#7960: [PATCH] fmt: fix formatting multibyte text (bug #7372)

[Assaf Gordon]

retitle 7960 multibyte: fmt: fix formatting multibyte text (bug #7372)
close 7960
stop

(triaging old bugs)

On 17/04/11 03:32 AM, Jim Meyering wrote:


Eric Blake wrote:

[readding the list]

On 02/02/2011 02:11 PM, Kostya Stopani wrote:

On Wed, Feb 02, 2011 at 10:15:53AM -0700, Eric Blake wrote:


Thanks for the patch.  However, it's not trivial, so it would need
copyright assignment.


Oh boy... Anyway I don't mind signing papers, if you (or whoever)
don't mind bothering with it.


OK, I'll send you those details off-list.


Marked as "moreinfo" since now we're waiting for
copyright assignment paperwork.


With no further follow-ups in 7 years
(and the original author's name not in the copyright.list file),
I'm closing this bug.

If there are new developments, we can always re-open it.

regards,
 -assaf

bug#9513: improvement remark for "cp"

[Assaf Gordon]

close 9513
stop

(triaging old bugs)

On 13/11/11 04:48 AM, Jim Meyering wrote:

Paul Eggert wrote:

On 09/15/11 05:23, Charles ELSAESSER WebmailOrange wrote:

cp -p file1 file2

does not preserve timestamp.


That looks like a bug.

Can you please try it with coreutils 8.13?  That has some
fixes in this area; the version you're using (8.4) is a bit old.


Hello Charles,
The latest release is now coreutils-8.14.
Would you please try to reproduce the problem using that version
and send us the information that Paul requested?




With no follow-ups in 7 years, I'm closing this bug.

-assaf

bug#9715: Error while compiling coreutils-8.12

[Assaf Gordon]

close 9715
stop

(triaging old bugs)

On 10/10/11 11:44 AM, Paul Eggert wrote:

Thanks for the bug report.

 From the 'configure' file you sent, it appears that you're
using a modified version of coreutils, along with some other
files (e.g., ) that aren't part of the coreutils
distribution.


[...]

One other thing: it's better to use the latest version of
coreutils (currently this is 8.13).  Sometimes this fixes
your problem without any further effort on your part; and
even when it doesn't, any patches are easier to merge in.



With no further follow-ups in 7 years, I'm closing this bug.

-assaf

bug#9823: request for more correct error reporting of mv

[Assaf Gordon]

close 9823
stop

(triaging old bugs)

On 25/10/11 12:39 AM, Voelker, Bernhard wrote:

Eric Blake wrote:

Like I said earlier, POSIX allows either ENOTEMPTY or EEXIST, and Linux
happened to choose ENOTEMPTY.  Maybe special-casing that error and
converting to EEXIST would produce better output.  But someone would
have to submit a patch.


I think mv is right to say "Directory not empty". Let's look at
the opposite example, i.e. where the destination _is_ empty:


Given the above, and no further comments in 7 years,
I'm closing this bug.

-assaf

bug#10423: problem with "make check" coreutils-8.14 after build

[Assaf Gordon]

close 10423
stop

(triaging old bugs)

On 03/11/12 10:26 AM, Pádraig Brady wrote:

On 11/03/2012 03:31 PM, Michael Felt wrote:


Lots of +++ at the end (might be something left over from debugging), but
ends with:

Testsuite summary for GNU coreutils 8.15

Will test with 8.17 in a few days (8.20 does not compile, 8.17 just
succeeded).


Please send the compile fail messages.
We'd much rather work from 8.20 at this stage.



There are newer bug reports dealing with newer coreutils versions
and newer AIX versions. That, and with no follows-up in 6 years,
I'm closing this (specific) bug.

-assaf

bug#10456: bug in "du"

[Assaf Gordon]

tags 10456 moreinfo
close 10456
stop

(triaging old bugs)

On 08/01/12 11:43 PM, Alan Curry wrote:

Lubomir Mateev writes:


root@thor:/# fdisk -l

Disk /dev/hda: 15.0 GB, 15000330240 bytes

<...>

9.5T/usr/lib


I'm going to guess filesystem corruption causing a file in /usr/lib (not a
subdirectory) to have the wrong block count. Do ls -Ssr /usr/lib and see if
you get a big surprise at the end. unmount and fsck it to fix if I'm right.



With no further comments in 6 years, I'm closing this bug.

-assaf

bug#11316: coreutils 8.16: du

[Assaf Gordon]

close 11316
stop

(triaging old bugs)

On 24/04/12 11:12 PM, Paul Eggert wrote:

Sorry, it looks like this will have to be debugged
by someone who has debugging tools on HP-UX; I'm
afraid that I can't do this long distance.



With no further follow-ups in 6 years, I'm closing this bug.

-assaf

bug#7858: coreutils-8.9 test failed on rh5 amd

[Assaf Gordon]

close 7858
stop

(triaging old bugs)
Hello,

With no further follow-ups in 7 years,
I'm closing this bug (despite not reaching
a resolution).

If this is still an issue, please reply to this thread.

-assaf

bug#12020: ls should show when extended system attributes are set

[Assaf Gordon]

tags 12020 notabug
close 12020
stop

(triaging old bugs)

On 21/07/12 04:50 PM, Luk Claes wrote:

[...]
Though I guess it's close enough, only a pitty it's not in the manpage.
So feel free to close this or retarget it.



Closing.

-assaf

bug#12551: ls -l

[Assaf Gordon]

close 12551
stop

(triaging old bugs)

On 01/10/12 10:49 AM, Bob Proulx wrote:


Chen,Wei wrote:

When I typed 'ls -l *chr4*' in linux, it gave me this:

bash-4.1$  ls -l *chr4*
ls: invalid option -- '4'
Try `ls --help' for more information.

It used to work for me, why?


You are expanding a file glob "*chr4*" in the current directory.  This
will be expanded to match any files in the current directory.  If any
of those files start with a dash character '-' then the string will be
interpreted as an option.



With no further comments to Bob's explanation,
I'm closing this bug.

-assaf

bug#12783: info for sort has an illogical example

[Assaf Gordon]

close 12783
stop

(triaging old bugs)

On 06/11/12 07:59 PM, Kevin O'Gorman wrote:

On Tue, Nov 6, 2012 at 6:44 AM, Pádraig Brady  wrote:

[]

... it may be significant when specifying (multibyte) characters
to skip etc. and thus impacts the sort order in that way.
This is either with common downstream i18n patches or future
multibyte handling in upstream sort.

Unfortunately LC_CTYPE is would up with LC_MESSAGES too (since
glibc-2.3.3):
http://www.gnu.org/software/**libc/manual/html_node/Charset-**
conversion-in-gettext.html

thanks,
Pádraig.



What I wrote is only a suggestion.  As I'm far from expert in these
matters, I'll leave the final form to you all.  Thanks for your work on
coreutils, and your attention to this matter.  I think my work is done here.


With no further comments in 6 years, I'm closing this bug.

-assaf

bug#12642: bug#12645: 24.2.50; hang in redisplay

[Assaf Gordon]

close 12642
stop

(triaging old bugs)

On 25/10/12 09:08 AM, Eric Blake wrote:

On 10/25/2012 07:13 AM, Michael Welsh Duggan wrote:

This particular problem is bugging me quite a bit.  It makes inferior
python mode useless to me.  The behavior for me is this:


Based on the subject line, it looks like you meant to send this to bug
12645 (an emacs bug), but instead ended up attaching unrelated
information to bug 12642 (a coreutils bug).  It would help if you tried
sending this information again to the correct address.



Given the above, closing this bug.

-assaf

bug#12650: Bug in date command

[Assaf Gordon]

close 12650
stop

(triaging old bugs)

On 14/10/12 05:28 PM, Bob Proulx wrote:


Thiago Picharski wrote:

I'm trying run this command "date -d 12-10-21", but occur the follow
error, date: invalid date "12-10-21"
and finalize with error code 1.


[...]
The basic problem is that when you specify 12-10-21 it means 
hours.  That is often when DST changes.  Better to specify noon
instead which is far from when DST changes.


[...]

Very likely those dates are valid.  Since you didn't say what timezone
you are working in I can't look to see what was happening there.



With no further comments to Bob's explanation in 6 years,
I'm closing this bug.

-assaf

bug#12631: GNU coreutils 8.19: Failed Self-Tests

[Assaf Gordon]

close 12631
stop

(triaging old bugs)

On 12/10/12 03:06 PM, Eric Blake wrote:


On 10/12/2012 01:59 PM, David McInnis wrote:

My System is Arch Linux;  I was trying to build coreutils from the abs tree.

I got an error asking me to report this.


I fail to see what you think is an error.  Skipped tests are normal, and
none of your tests failed.  What in particular in this log are you
worried about?



With no further comments in 6 years, I'm closing this bug.

-assaf

bug#12421: Issue of the cp on Ubuntu 10.10

[Assaf Gordon]

close 12421
stop

(triaging old bugs)

On 15/09/12 12:25 AM, Jim Meyering wrote:

Alan Curry wrote:

owen.z...@alitech.com writes:


A strange issue happens when I use the cp tool on two directory.


[snip - summary: after recursive cp, some file has the wrong size]

[...]
If it's reproducible, run strace -o cptrace cp ... and publish the cptrace
for others to look at. (If the files being copied are private, the names and
contents will be in the trace so you will have to inspect it yourself.)


Thanks for replying, Alan.
I've marked this as needing more info.


With no further information in 6 years, I'm closing this bug.

-assaf

bug#12224: Several testsuite failures on OpenIndiana

[Assaf Gordon]

close 12224
stop

(triaging old bugs)

On 18/08/12 01:44 PM, Stefano Lattarini wrote:
...]

  Since this might be a misconfiguation issue, I say this
is not a release blocker, and you should go ahead and release coreutils
8.19 in the expected timeframe.  I'll try to work this issue out with the
system administrator before bothering you again.


With no further follow-ups in 6 years, I'm closing this bug.

-assaf

bug#13058: European date format

[Assaf Gordon]

close 13058
stop

(triaging old bugs)

On 02/12/12 02:42 PM, Bob Proulx wrote:

Ohad Basan wrote:


Regarding 'date' command.
the -d parameter doesn't know how to receive a european date format
e.g. DD/MM/


I am assuming by "doesn't know how to receive" you mean it produces a
different result than one you wish?  Because of course it parses it.
It just parses it (receives it) with a different result than you
wish.  Please give an example of the behavior you see and what you
would like to see instead.  Did you mean this:

   $ date -d '12/15/2012 12:00' '+%F %T %z'
   2012-12-15 12:00:00 -0700


With no further comments to Bob's explanation in 6 years,
I'm closing this bug.

-assaf

bug#13938: Bug: date(1) -d "relative-to-skipped-time" problem (also in touch(1) -d)

[Assaf Gordon]

close 13938
stop

(triaging old bugs)

On 12/03/13 11:23 PM, Bob Proulx wrote:

Aleš Kantor wrote:

Set date to Mar 10, 2013  (the day clocks moved fwd)


In which timezone?  Please tell us what timezone you are in because
the tzdata is different for everyone.

Instead of setting the time simply include the date in the timestamp.
But for the purpose of recreating the problem please do include the
timezone too.  The -R,--rfc-2822 option is good to use to avoid the
ambiguous timezone naming used in the traditional legacy output.

   $ env TZ=US/Mountain date -R -d "2013-03-10 12:00"
   Sun, 10 Mar 2013 12:00:00 -0600


This command
 date -d 2:30am
gives "Invalid date," probably reasonable, since that time didn't exist.


Correct.  In US timezones at least that time does not exist.


This one should work, but fails as well:
   date  -d "2:00am yesterday"
date: invalid date `2:00am yesterday'




With no further comments to Bob's explanation in 5 years,
I'm closing this bug.

-assaf

bug#13144: "comm" bug or strange behaviour

[Assaf Gordon]

close 13144
stop

(triaging old bugs)

On 11/12/12 09:53 PM, Bob Proulx wrote:

Matteo Zambelli wrote:

Hi, i was trying to find common lines between the two attached
files(both created with "dpkg --get-selections > filename.txt") with
this command:

comm -12 squeeze-xfce-installed_packages.txt squeeze-xfce-installed_packages.txt 
> result.txt


[...]
Unfortunately I cannot reproduce your result.

   $ comm -12 squeeze-xfce-installed_packages.txt 
squeeze-xfce-installed_packages.txt | grep libcdio10
   libcdio10install

And so there it is in the output??


With no further comments to Bob's explanation in 6 years,
I'm closing this bug.

-assaf

bug#14505: Bug in "cat" command

[Assaf Gordon]

close 14505
stop

(triaging old bugs)

On 29/05/13 11:19 PM, Kakkar, Mayank (NSN - IN/Bangalore) wrote:


Thanks. That was very informative.



With no further comments, I'm closing this bug.

-assaf

bug#14555: Facing Some problem in uniq command

[Assaf Gordon]

close 14555
stop

(triaging old bugs)

On 05/06/13 09:06 AM, Bob Proulx wrote:

Shahid Hussain wrote:

Appreciate your quick reply. What exactly i m doing is there are so many
files in my product which contains some data in "name =  value" format. By
using some pattern i m extracting only "value" field from all files and
redirecting the output to one temporarily file as i do not want any value
to be repeated in any file. And here i m applying uniq command to this
temporary file (by pipe lining sort [sort |uniq -c tempFile]) But i am
unable to get expected result.


It might be better if in your script you set:

   #!/bin/sh
   LC_ALL=C
   export LC_ALL
   ...
   sort | uniq
   ...

That will force a standard sort order everywhere in your script.


But as you have told whitespace also should be identical at every line so
this might be the problem in my case. Because when i displayed content of
file using cat command and manually copied the same data to another file
and then tried uniq with sort command it works fine.


Without knowing enough about your data a quick and dirty hack to clean
up whitespace might be to pass it through awk.

   awk '{print$1}' somefile1 | sort | uniq ...

Since awk splits on whitespace this will only print the first field
and any whitespace or additional anything will be discarded.


So it is fine for me but it would be too better if there could be an option
in uniq command to work fine even if  whitespace is not identical :).


No.  The way is not to use an option.  The way is to prepare the data
without whitespace differences.  You have the option of using tools
like awk to split on whitespace while preparing the data.  Preparing
the data to avoid whitespace differences is the right option to use.



With no further comments in 5 years, I'm closing this bug.

-assaf

bug#14622: gdate

[Assaf Gordon]

close 14622
stop

(triaging old bugs0

On 19/06/13 09:15 AM, Jim Meyering wrote:

Lien, John wrote:

Eric, it looks like "gdate" version is 6.4 and gnudate version is 1.16.


Thanks for the follow-up.
That means Eric was right on the money.
Your 1.16 gnudate is from early 1997
and your gdate is from from October of 2006.
There have been many fixes and improvements since then.



With no further comments in 5 years, I'm closing this bug.

-assaf

bug#15083: MKNOD issue

[Assaf Gordon]

close 15083
stop

(triaging old bugs)

On 13/08/13 02:24 PM, Bob Proulx wrote:


Paul Eggert wrote:

Manish Gupta wrote:

when i try to create in NFS mounted
volume, hitting with error "operation not permitted".


It sounds like your NFS server is not permitting it.
If so, it's not mknod's fault.  You can double-check
by running 'strace mknode' and seeing what system calls
it's using.


As far as I know NFS does not support the making of device nodes.
Remember that NFS is not a POSIX compliant filesystem.  It only
supports a subset of file operations.


[...]

In order to know more you would need to tell us what command you were
running that failed.  And also include what type of system you were
running on and what type of file system you were using.


With no further comments in 5 years, I'm closing this bug.

-assaf

bug#15168: mkdir alway creates a file instead a direktory if it is run trough a sub sub shell

[Assaf Gordon]

close 15168
stop

(triaging old bugs)

On 24/08/13 12:46 PM, Bob Proulx wrote:

horvan dillus wrote:

For a better ovvervie  I'll post the  4 scripts I mentioned above:



[...]

First, those "*" characters, what are they?  Two are on a line by
itself.  You said you marked a line.  I think you confused things
terribly when you did that.  Because "*" is special to the shell.  It
is a file glob.  The shell expands it to match a glob of characters.
This makes it data dependent.  When you have lines with only a "*" in
the script on that line then what happens depends upon what files are
in the current directory.

[...]



There are more scripts of course I hope this will be enough information to
exermain if this is really a bug.


I expect you will find that mkdir is making directories.  If you are
seeing it to be a file then I expect you will find that it was already
a file before the mkdir.  I expect that ls command will show that
there was a file present and then the mkdir fails.



With no further comments in 5 years, I'm closing this bug.

-assaf

bug#15409: commands not working on "Cygwin" window

[Assaf Gordon]

close 15409
stop

(triaging old bugs)

On 05/10/13 11:31 PM, Bob Proulx wrote:

Eric Blake wrote:

Dhaval Desai wrote:

I am trying the commands is not working is as below: -


Thanks for the report; however, it is not clear from what you wrote what
you think is wrong.  A good report describes not only the command names
that you are asking about, but also a transcript of how you used the
commands, the actual results you got, and the results you were
expecting.


Ping?  We are waiting for more information about this bug report.  We
are unable to proceed.



With no further comments in 5 years,
I'm closing this bug.

-assaf

bug#16549: bug

[Assaf Gordon]

close 16549
stop

(triaging old bugs)

On 25/01/14 11:30 AM, Pádraig Brady wrote:

On 01/25/2014 10:33 AM, sn...@eaglet.co.in wrote:

make[6]: *** [test-suite.log] Error 1
make[6]: Leaving directory `/sources/coreutils-8.21/gnulib-tests'
make[5]: *** [check-TESTS] Error 2


We need more info than that.
What platform are you on?
Can you attach the test-suite.log?



With no further comments in 4 years, I'm closing this bug.

-assaf

bug#17242: fmt bug (?)

[Assaf Gordon]

close 17242
stop

(triaging old bugs)

On 11/04/14 01:05 PM, Eric Blake wrote:

On 04/11/2014 12:25 PM, sldev wrote:

I'm trying fmt provided by coreutils but it isn't working as expected.
fmt file >> to_file
on mac is different than the windows port, I still have tabs on the
windows version, wheras on mac it are spaces.


Can you also show 'fmt --version' from both machines, in case it is
something that we can identify as having been fixed between the two
versions, or in case you aren't running GNU fmt like you thought on one
machine?  Can you demonstrate this with a bit more details, such as
attaching 'file' and 'to_file' (trim them to be reasonably small, merely
enough lines to demonstrate what you are seeing)?


With no follow-ups in 4 years, I'm closing this bug.

-assaf

bug#18538: stdbuf: command not found

[Assaf Gordon]

close 18538
stop

(triaging old bugs)

On 23/09/14 12:05 PM, Eric Blake wrote:


On 09/23/2014 07:48 AM, Pollgreen, Rick (AS) wrote:

Hi,
I am trying to figure out why the "stdbuf" command is not working on our 
ubuntu64 system.
Any ideas?


Help us help you.  What version are you (trying) to use? Is this a
pre-built version from your distro (if so, ask the ubuntu folks why they
are shipping a broken build, rather than upstream), or something you are
building yourself?  What error messages are you getting, or other
symptoms that lead you to believe it is not working?



With no further follow-ups in 4 years, I'm closing this bug.

-assaf

bug#18735: Possible bug - df on Ubuntu's LTS 14.04 Trusty

[Assaf Gordon]

close 18735
stop

(triaging old bugs)

On 15/10/14 09:52 AM, Eric Blake wrote:


On 10/15/2014 02:28 AM, Jordi Ribas wrote:


If possible command "df" not running correctly in Ubuntu 14.04 Trusty ?


Thanks for the report.  However, you'll need to provide more details.
What output are you getting that makes you think it is not running
correctly?  We don't know of any reason that it shouldn't work, and
without a testcase or terminal transcript or other proof of something
that you think is out of the ordinary, we cannot pinpoint a bug.


With no further follow-ups in 4 years, I'm closing this bug.

-assaf

bug#19065: dd design bug

[Assaf Gordon]

close 19065
stop

(triaging old bugs)

On 16/11/14 12:05 PM, Bob Proulx wrote:


bt wrote:

The following undocumented behavior of dd is (IMO) a design flaw.


If dd actually did this then that would be quite annoying.  And I
could see anyone becoming very frustrated with it.  But the reason
this is not documented in dd is that dd doesn't do this.


[...]


What is in your partition table?  There are many different ways to
browse the partition table.  I am not the most proficient with parted
but parted is likely the most capable in the face of newer GPT
formats.  I am perhaps not even likely to be able to interpret the
answer but I think this information would be needed and if not me then
perhaps another may be able to interpret it.

   parted /dev/sdb unit s print



With no further follow-ups to Bob's explanation in 4 years,
I'm closing this bug.

-assaf

bug#26002: [patch] md5sum --digest-only

[Assaf Gordon]

severity 26002 wishlist
tags 26002 wontfix
close 26002
stop

(triaging old bugs)

On 07/03/17 01:04 AM, Michael Vogt wrote:

On Mon, Mar 06, 2017 at 08:26:07PM -0800, Pádraig Brady wrote:

On 05/03/17 23:55, Michael Vogt wrote:

[..]

   `md5sum /etc/papersize 2> /dev/null | awk '{print $1}'`
   `md5sum /etc/lsb-release | cut -d" " -f1`
   $(md5sum /etc/networks | sed -e 's/ .*//')

Having a --digest-only option in md5sum would make this a bit more
uniform.


This is one of those marginal ones, previously discussed as indicated at:
https://www.gnu.org/software/coreutils/rejected_requests.html#checksum

[..]
Aha, thanks! I found the discussion about it now and see this was
already discussed. Sorry that I have not found in earlier.


With no further comments in a year and a half,
I'm closing this as "wont fix".

Discussion can continue by replying to this thread.
 - assaf

bug#21094: cp: add option to sort when copying

[Assaf Gordon]

severity 21094 wishlist
tags 21094 wontfix
close 21094
stop

(triaging old bugs)

On 20/07/15 10:20 AM, Andreas Schwab wrote:

Pádraig Brady  writes:


For the progress use case, one can use rsync,
or perhaps an explicit progress option in cp.


rsync also sorts.



Given the above, and no further comments in 3 years,
I'm closing this bug.

-assaf

bug#21265: tail -f: inotify being used on non-regular files

[Assaf Gordon]

tags 21265 wontfix
close 21265
stop

(triaging old bugs)

On 26/08/15 05:19 AM, Stephane Chazelas wrote:

2015-08-26 03:13:59 +0100, Pádraig Brady:
[...]


The same argument applies that the kernel should return
and error when adding a watch on pseudo file systems like /proc?
To work around that, we'd have to get real kludgy and see
were the files on a "dummy" file system or something.

[...]

Though tail -f /proc files in either mode is not that useful,
so probably not worrying about that case.

[...]

All very good points.

Many files in /proc, /sys... can only be read reliably in one read()
operation anyway, and doing tail -f on them would give you
garbage even if it worked.


Given the above, and no further comments in 3 years,
I'm closing this bug.

-assaf

bug#21349: who shows no users nowadays on Debian

[Assaf Gordon]

tags 21349 notabug
close 21349
stop

(triaging old bugs)

On 26/08/15 02:40 PM, Bob Proulx wrote:

[...]
 It appears that very recently it was changed to
not log utmp. 

[...]

I will further take the discussion to the Debian bug log since it
doesn't have anything to do with coreutils.


With no further comments in 3 years,
I'm closing this as "not a bug" (at least not a coreutils bug).

-assaf

bug#21405: df has '/root/.gvfs': permission denied, again

[Assaf Gordon]

tags 21405 moreinfo
close 21405
stop

(triaging old bugs)

On 03/09/15 10:00 AM, Pádraig Brady wrote:

On 03/09/15 16:02, John Bowling wrote:

This is a repeat of the bug around 2009.


Well need more info.
Which version of df are you using?
Do you have a reference to the original discussion?



With no follow-ups in 3 years, I'm closing this bug.
Discussion can continue by replying to this thread.

-assaf

bug#22064: expr: expr string : '.*' returns the number of matched bytes not characters

[Assaf Gordon]

tags 22064 fixed
close 22064
stop


(triaging old bugs)

On 30/11/15 02:09 PM, Stephane Chazelas wrote:


that's another multibyte issue, it may be known already but I
can't see it being referenced on debbugs.gnu.org.



This commit added multibyte support to expr(1):
https://git.savannah.gnu.org/cgit/coreutils.git/commit/?id=a9f2be5bfec2bfe86c0851787312996467a653ee

Available since coreutils 8.28 (released Sep 2017).

Closing as "fixed".

-assaf

bug#22397: Date -- Format arithemtic yields unexpected results

[Assaf Gordon]

tags 22397 notabug
close 22397
stop

(triaging old bugs)

On 18/01/16 07:16 AM, Pádraig Brady wrote:


On 18/01/16 03:53, Adam Danischewski wrote:

$> date
Sun Jan 17 22:49:40 EST 2016
$> date -d"04:00"
Sun Jan 17 04:00:00 EST 2016
$> date -d"04:00 +1 day"
Sun Jan 17 22:00:00 EST 2016

To fix this, a work around for me now is:
$> date -d"$(date -d"04:00") +1 day"
Mon Jan 18 04:00:00 EST 2016


The +1 is taken as a timezone offset.
You'll want:

date -d '04:00 today +1 day'

Note also the relative date discussion at:
http://bugs.gnu.org/18159


date now supports the "--debug" option
to make such troubleshooting easier.

With no further comments in over a year,
I'm closing this bug.

-assaf

bug#22418: Potential Bug with 'df'

[Assaf Gordon]

close 22418
stop

(triaging old bugs)

Hello,

On 20/01/16 05:30 PM, Darrell Kitchen wrote:
I can't get 'df' to report the correct device name, as /dev/???n, 


It seems your message was lost and never replied to. Sorry about that.

df(1) was improved in newer version of 'coreutils'
to report to shortest name of the device.

I'm closing this bug, but if you still experience the same problem,
please reply to this thread.

regards,
 - assaf

bug#21063: coreutils-8.24 - documentation installation targets fail in some sub-directories

[Assaf Gordon]

retitle 21063 solaris: documentation installation targets fail in some 
sub-directories (coreutis 8.24)
stop

(triaging old bugs)

Hello,

On Wed, Jul 15, 2015 at 09:23:41PM +1000, Peter Bray wrote:
> One last quick bug report for the day. Still coreutils-8.24 on Solaris
> 10 and Solaris 11 on X86 VMs.
> 
> The installation of built documentation (dvi,ps,pdf) requires the use
> of the gmake(1) option '-k' to avoid failing in sub-trees not
> supporting these phony make targets.
> 
> Successful Steps:
> 
>   gmake pdf ps dvi
> 
> Unsuccessful Steps:
> 
>   gmake install-pdf install-ps install-dvi
> 
> Workaround Steps:
> 
>   gmake -k install-pdf install-ps install-dvi
> 

Is this still an issue with the latest coreutils on Solaris?

-assaf

bug#22584: cp could be more precise than "Not a directory"

[Assaf Gordon]

severity 22584 wishlist
tags 22584 wontfix
close 22584
stop

(triaging old bugs)

On Tue, Feb 09, 2016 at 08:29:12AM +0100, Bernhard Voelker wrote:
> On 02/08/2016 10:28 PM, 積丹尼 Dan Jacobson wrote:
> > Ah ha, they just should have returned what the system calls said in the
> > first place, and not tinker with the output!
> > 
> > Them tinkering with the output only makes things worse.
> 
> Actually this _is_ an improvement:
> 
> After stat() has detected that the target does not exist, cp simply
> tries to open() it - and while it has a trailing slash, the kernel
> returns EISDIR:
> 
> stat("/tmp/My_DocVments/", 0x7ffdd335eee0) = -1 ENOENT (No such file or 
> directory)
> ...
> open("/tmp/My_DocVments/", O_WRONLY|O_CREAT|O_EXCL, 0644) = -1 EISDIR (Is a 
> directory)
> 
> Taking this over as-is, the error diagnostic would be quite confusing and
> plain wrong:
> 
>   cp: cannot create regular file ‘/tmp/My_DocVments/’: Is a directory
> 
> Therefore, the current mapping to ENOTDIR - introduced in coreutils-v8.8 -
> is the best we can do:
> 
>   $ cp .profile /tmp/My_DocVments/
>   cp: cannot create regular file ‘/tmp/My_DocVments/’: Not a directory
> 
> Your suggestion to say "no such file or directory" (ENOENT) would be 
> misleading,
> because the target is treated by the system as a directory due to the trailing
> slash.
> 

With no further follow-ups to this thread, I'm closing this bug.

-assaf

bug#30477: [PATCH] chmod chown chgrp: added --exclude-files and --exclude-directories

[Assaf Gordon]

tags 30477 wontfix
severity 30477 wishlist
close 30477
stop

(triaging old bugs)

On Sat, Feb 17, 2018 at 01:30:24PM -0800, Pádraig Brady wrote:
> 
> Such functionality has been discussed previously at:
> https://www.gnu.org/software/coreutils/rejected_requests.html#chmod
> 

Given the above, I'm closing this bug report.
Discussion can continue by replying to this thread.

-assaf

bug#22517: dd byte count report does not correlate with df byte count report

[Assaf Gordon]

tags 22517 notabug
close 22517
stop

(triaging old bugs)

On Tue, Feb 02, 2016 at 12:20:36AM +0100, Bernhard Voelker wrote:
> On 02/01/2016 05:53 AM, Bob Gustafson wrote:
> > 
> > Expected results:
> > 
> > I would think that the sizes reported by dd and df would be comparable, but 
> > they are not.
> > 
> a) the MiB numbers are 1024-based, while MB are 1000-based.
> 
> b) df(1) and du(1) show statistics or summaries of the data *inside*
> a file system, while the file system itself may need some space to
> manage the data.  And even df/du report different sizes:
> http://www.gnu.org/software/coreutils/faq/coreutils-faq.html#df-and-du-report-different-information
> Starting with BTRFS, the situation may even be worse (df showing
> lots of free space while BTRFS doesn't allow to create - or even
> delete - another file).
> 
> Thus said: the size of the underlying device is not 100% related to
> the sizes inside the file system on that device.
> You may get the real size using e.g.

With no further comments in 2 years, I'm closing this bug.
Discussion can continue by replying to this thread.

-assaf

bug#22568: "grep ... | tee file" drops the 'n' in its output

[Assaf Gordon]

tags 22568 moreinfo
close 22568
stop

(triaging old bugs)

On Fri, Feb 05, 2016 at 03:05:24PM -0700, Eric Blake wrote:
> On 02/05/2016 02:41 PM, oldefoxx wrote:
> > Odd problem.  Seems to be partly tied to when IFS=\n is used for
> 
> It's not obvious how grep, cat, or tee fit into the picture here.
> Without seeing the full shell script you are running, it is very hard to
> say what exactly went wrong for you, but in all likelihood, it is NOT a
> bug in 'tee' nor in 'grep', but a case of the shell doing exactly what
> you told it to.
> 

With no further comments in 2 years, I'm closing this bug.
Discussion can continue by replying to this thread.

-assaf

bug#22909: [PATCH] test: Document that -a and -o are undesirable

[Assaf Gordon]

tags 22909 fixed
close 22909
stop

(triaging old bugs)

On Fri, Mar 04, 2016 at 11:43:05AM -0700, Eric Blake wrote:
> On 03/04/2016 10:51 AM, Jim Meyering wrote:
> > On Fri, Mar 4, 2016 at 9:50 AM, Jim Meyering  wrote:
> >> On Fri, Mar 4, 2016 at 9:12 AM, Pádraig Brady  wrote:
> >>> On 04/03/16 08:55, Eric Blake wrote:
> >> ...
>  +NOTE: Use of binary -a and -o create inherently ambiguous situations.
> >>
> 
> I like it; I'll push with that wording.
> 

pushed here:
https://git.savannah.gnu.org/cgit/coreutils.git/commit/?id=6475c514550bc1fbdb3410485312211726765798

So closing as "fixed".

-assaf

bug#22803: bash printf and negative precision

[Assaf Gordon]

tags 22803 notabug
close 22803
stop

(triaging old bugs)

On Thu, Feb 25, 2016 at 07:18:24AM +, Billerbeck, Dirk wrote:
> Hello,
> 
> I don't know if it's really a bug, if I'm just mistaken or this is the right 
> address but I just want to give it a try.
> 
> I'm using the following bash-builtin printf command:
> 
> [...] 
> 
> The bash version is "GNU bash, version 3.2.51(1)-release 
> (x86_64-suse-linux-gnu)". I know it's an older version but I can't change it 
> as there are corporate restrictions. The coreutil package is 
> "coreutils-8.12-6.25.32.33.1".
> 

It seems your message was lost and not replied to in 2 years. Sorry about that.

Your question is about bash's "printf", so it should be sent to 
help-b...@gnu.org
(or bug-b...@gnu.org if you suspect a bug).

This mailing list is for GNU coreutils (which also provides a 'printf' program,
but not bash's built-in one).

As such, I'm closing this bug.

-assaf

bug#22624: [bug-coreutils] coreutils-8.25: big success, but problem on GNU/Hurd

[Assaf Gordon]

tags 22624 fixed
close 22624
stop

(triaging old bugs)

With fixes commited in:
https://git.savannah.gnu.org/cgit/coreutils.git/commit/?id=632eda520f7cf49d9d1662835c7c37e17033e128
https://git.savannah.gnu.org/cgit/coreutils.git/commit/?id=62e7af0326786a7dec91d982238948eddab9d6af

And no further comments in over a year,
I'm marking this as "fixed".

-assaf

bug#23024: ls output quoting (when using --dired switch)

[Assaf Gordon]

close 23024
stop

(triaging old bugs)

On Wed, Sep 28, 2016 at 09:23:47PM +0100, Pádraig Brady wrote:
> On 16/03/16 17:07, Pádraig Brady wrote:
> > On 15/03/16 23:35, Daniel Lopez wrote:
> >>
> >> The recent change to the default way that ls renders filenames with
> >> spaces in (now surrounding them in single quotes) is also happening in
> >> the presence of this switch:
> >>
> > Right, we shouldn't mess with quoting in --dired mode.
> 
> On further analysis I see that --dired mode already distinguishes
> the quoting-style in its output.  Also we had already documented
> that --dired should specify a --quoting-style to get consistent output.
> Also this looks to have been fixed already in emacs:
> https://github.com/emacs-mirror/emacs/commit/e4adb6
> 
> Therefore I'm inclined to leave this behavior as is.
> 

With no further comments in 2 years, I'm closing this bug.

-assaf

bug#23110: seq apparent bug

[Assaf Gordon]

tags 23110 fixed
close 23110
stop

(triaging old bugs)

On 2016-04-14 11:19 a.m., Bernhard Voelker wrote:

On 04/14/2016 06:47 PM, Pádraig Brady wrote:

The 2 patches look good.


thanks for the review, pushed.



closing as "fixed".

-assaf

bug#23120: cp with --dereference (-L) and --link (-l) or --symbolic-link (-s)

[Assaf Gordon]

unarchive 15173
merge 23120 15173
tags  23120 fixed
close  23120
stop

(triaging old bugs)

On 2016-03-26 11:26 a.m., Pádraig Brady wrote:


On 26/03/16 10:36, Petr Skočík wrote:


I'm on a system with cp 8.21, and when I do `cp -Ll` or `cp -Ls` on a
symlink, it hardlinks (-Ll) or symlinks (-Ls) the symlink instead of the
target of the symlink.



The -Ll hardlink case was fixed in 8.22 with a bit of
an epic discussion in http://bugs.gnu.org/15173

The -Ls symlink case currently just symlinks the source symlink.


With no further comments in 2 years, I'm closing this bug.

-assaf

bug#23268: sort ant uniq bug report

[Assaf Gordon]

tags 23268 notabug
close 23268

(triaging old bugs)

On 2016-04-11 11:56 a.m., Assaf Gordon wrote:


On 04/11/2016 12:43 PM, 126 wrote:
Every other input is working well,but when my input contain several 
lines of "src/table/checkpoint/checkPointInfo5000.lua". The result of 
(sort -u) contain two lines of 
"src/table/checkpoint/checkPointInfo5000.lua"


Without seeing the exact input, it is hard to diagnose the issue.

Please attach a *small* input file, with the exact command that 
reproduces your situation to help us understand what's going on.


With no further follow-ups in 2 years, I'm closing this bug.

-assaf

bug#23302: mention what are nonprinting characters

[Assaf Gordon]

close 23302
stop

(triaging old bugs)


Le 16/04/2016 21:50, 積丹尼 Dan Jacobson a écrit :

In (info "(coreutils) Concept index") there are several items that talk
about nonprinting characters.

Well on each definition be sure to have a blue word link:: to a passage
about which characters are nonprinting, lest the user think e.g.,
SPC (' ') is nonprinting.



On 2016-04-17 2:16 a.m., f0rhum wrote:

As per https://en.wikipedia.org/wiki/ASCII#ASCII_control_characters


With no further comments in 2 years, I'm closing this bug.

-assaf

bug#23441: mention wc defaults more on man page

[Assaf Gordon]

close 23441
stop

(triaging old bugs)

On 2016-05-03 9:14 p.m., 積丹尼 Dan Jacobson wrote:

On the man page mention if the default if no arguments
are given is
wc --bytes --words --lines


It seems your message was lost and not answered to in 2 years. Sorry 
about that.


The first line of 'man wc' says:
===
   wc - print newline, word, and byte counts for each file
===

And similar wording is used through-out (and in 'wc --help').

As such, I'm closing this bug.
Discussion can continue by replying to this thread (and concrete patches
are very welcomed to improve wording).

-assaf

bug#23449: cp command error report

[Assaf Gordon]

tags 23449 moreinfo
close 23449
stop

(triaging old bugs)

On 2016-05-04 11:47 a.m., Paul Eggert wrote:

On 05/04/2016 02:10 AM, Bruce.Zhang wrote:

When I run the command like this "/bin/cp -rf /root/update/*  /www"  .  I
find some file's permissions  is update but  the file's content not 
update .


I do not known what happened .


Nor does anyone else. :-)  I suggest running your command under strace, 
e.g.,:


strace -o foo.log /bin/cp -rf /root/update/* /www

and then looking at foo.log to see what happened. The idea is that you 
need to create a complete, self-contained test case that will let us 
reproduce the bug.


With no further follow-ups in 2 years, I'm closing this bug.

-assaf

bug#23556: sort(1): misleading description of option -n

[Assaf Gordon]

close 23556
stop

(triaging old bugs)


On 2016-05-16 4:23 p.m., Carsten Hey wrote:

* Assaf Gordon [2016-05-16 15:07 -0400]:


IIUC, you are disputing the accuracy (or clarity) of the term "string
numerical value" on the manual page, and not the actual behavior of
"sort -n" …


Exactly.  It seems like many people have problems to understand mails
that contain code, but are neither a patch nor complain about the
behaviour of a program - maybe my wording was suboptimal too.  I'll
consider this in future when I write similar mails.


[...]



If you have a suggestion for improved wording, I'm sure they can be
considered for inclusion.


If I would not know that "string numeric value" is proper English,
I wouldn't consider it to be correct, hence I'm likely the wrong person
to suggest a concrete wording, …


With no further follow-ups in 2 years, I'm closing this bug.
Discussion can continue by replying to this thread,
and patches are always welcomed.

-assaf

bug#21063: coreutils-8.24 - documentation installation targets fail in some sub-directories

[Assaf Gordon]

tags 21063 fixed
close 21063
stop


On 2018-10-27 8:55 p.m., Peter Bray wrote:

I just downloaded coreutils 8.30, and I’m happy to report this is no longer an 
issue. So the bug can be closed as Fixed in 8.30 (or earlier).


Thanks for following-up.

Closing as "fixed".

-assaf

bug#23645: GNU coreutils 8.25 make check report

[Assaf Gordon]

(triaging old bugs)

Hello,

On 2016-05-29 12:22 a.m., Donald A. MacDonald wrote:

Just build coreutils on a MacBook Pro running OS X 10.11.5 (El Capitan)

I think the results are excellent, only four tests failed and they were dealing 
with changing
group file permissions.  And El Capitan is “locked down” tighter than a “gnats 
ass” when
dealing with permissions.  I needed to turnoff “rootless” and munge the 
permissions on
/usr/local to just get things to compile.  So all in all only failing four 
tests is pretty darn good
out of the box!



Your message seemed to have been lost and not replied to in 2 years,
sorry about that.

The test log shows the following failures:
===
FAIL: tests/chgrp/basic
FAIL: tests/chgrp/posix-H
FAIL: tests/chgrp/recurse
FAIL: tests/cp/existing-perm-race
===

Are you still experiencing these failures (perhaps with more recent
coreutils version, or more recent Mac OS X version) ?

-assaf

bug#23665: spaces in keys: doc, --debug in LC_ALL=C

[Assaf Gordon]

tags 23665 fixed
close 23665
stop

(triaging old bugs)

On 2016-05-31 8:15 p.m., Assaf Gordon wrote:



On May 31, 2016, at 20:54, Pádraig Brady  wrote:

On 01/06/16 01:38, Assaf Gordon wrote:


2. add a bit more verbose progress information to the 'sort-debug-warn.sh' test 
- just so it'll be easier to discuss to the changed messages.

3. removes the 'maybe_space_aligned' and modifies the condition a bit.


2 and 3 are good to push.


Thank you, pushed in:
  
http://git.savannah.gnu.org/cgit/coreutils.git/commit/?id=d548f87595a193e21b170368bc8fc2ded4dadb73
  
http://git.savannah.gnu.org/cgit/coreutils.git/commit/?id=6223bf94bfeac75fb4252095864a80545ba00a0d



With no further follow-ups in 2 years, I'm closing this as fixed.

-assaf

bug#23677: sort --debug not ignoring punctuation when sort does

[Assaf Gordon]

close 23677
stop

(triaging old bugs)

On 2016-06-02 4:09 p.m., Eric Blake wrote:

On 06/02/2016 03:28 PM, Karl Berry wrote:

 They are not ignored, just considered only secondary, if the first
 order characters didn't provide an ordering.

Ok.  One would have no clue of that, either, from the --debug output.

sort obviously knows the exact rules defined by the locale, or it
couldn't do its job.


sort merely calls strcoll(); all the rules are a black box to sort, and
are really something that you have to know how strcoll() uses locale
definitions.


  How about a way to dump the rules in some
human-readable way?  (In sort or another utility or a separate program
or whatever.)  Similar to how James Youngman found a way to write out
regex definitions in Texinfo ... just a wish ... -karl


It might be nicer to request the glibc folks to give human-readable
descriptions of their locale files, and how strcoll() is affected by
those definitions, since it is more than just sort(1) that is impacted.



With no further follow-ups in 2 years,
I'm closing this bug.
Discussion continue by replying to this thread.

-assaf

bug#23825: maint: avoid md5sum.c warning from bleeding-edge gcc's -Wstrict-overflow

[Assaf Gordon]

tags 23825 fixed
close 23825
stop

(triaging old bugs)

The two discussed issues pushed here:

maint: work even if argc == INT_MAX
https://git.savannah.gnu.org/cgit/coreutils.git/commit/?id=818b2f48974298065a43a8a2d5355e4aaa65c09d

yes: handle short writes
https://git.savannah.gnu.org/cgit/coreutils.git/commit/?id=5845664c8c61faf004eb3ef9979e770f794108c1


Closing as "fixed".

-assaf

bug#23853: chmod can unset sticky bits using octet format

[Assaf Gordon]

close 23853
stop

(triaging old bugs)

On 2016-06-27 8:13 a.m., Eric Blake wrote:

On 06/26/2016 06:56 PM, westlake wrote:


contrary to documentation, chmod can otherwise clear sticky bits using
the octet notation but by using a 5th octal

[...]

The behavior of the 5th octal to intentionally specify that the
otherwise leading 0 is intended to clear sticky bits is intentional, so
the only bug here is in the documentation for not making the intended
behavior more obvious.


With no further comments in 2 years,
I'm closing this bug.
Discussion can continue by replying to this thread.

-assaf

bug#23886: testcase issue

[Assaf Gordon]

tags 23886 moreinfo
close 23886
stop

(triaging old bugs)

On 2016-07-03 4:08 a.m., Pádraig Brady wrote:

On 01/07/16 15:01, Rabia Arsalane wrote:


I'm nort able to slplit the lib file


split -b 1000m libs_2016_Jul_1_084343.tgz libs_2016_Jul_1_084343aa

split: extra operand `libs_2016_Jul_1_084343.tgz'


Hi. What version of split is this?
I can't reproduce this.


With no follow-ups in 2 years,
I'm closing this bug.

If this is still an issue, please reply to this thread with more details.

-assaf

bug#24217: dd - root partition security

[Assaf Gordon]

retitle 24217 dd: add root partition checks/confirmation
severity 24217 wishlist
tags 24217 wontfix
close 24217
stop

(triaging old bugs)

On 2016-08-13 8:15 a.m., Pádraig Brady wrote:

On 13/08/16 12:34, David Hedlund wrote:

rm / # do not remove root partition
rm -f / will remove root partition

In my opinion:

dd of=/dev/sda # will destroy sda even if it is a root partition, it
should not
dd -f of=/dev/sda # -f flag do not exists for dd, it should be added so
it can force a write if the previous step is implemented


Since dd is a lower level and much less widely/frequently used tool,
I don't think it's warranted.


With no further comments in 2 years,
I'm closing this bug.
Discussion can continue by replying to this thread.

-assaf

bug#24244: bug: dd deletes file

[Assaf Gordon]

retitle 24244 dd: protect against same file in input,output
severity 24244 wishlist
tags 24244 wontfix
close 24244
stop

(triaging old bugs)

On 2016-08-16 10:03 a.m., Pádraig Brady wrote:

On 16/08/16 16:44, puggy wrote:

by mistakes i used the same input and output file.
dd said it wrote 0 bytes, but what it actually did
is overwrite the file and setting it back to zero.
doing so, dd deleted a 4.3G file in a fraction of
a blink.

[]

please find some solution for it. if it is
intentional, make an option for it. this way
you can also shorten the command. otherwise
if input and output are the same, warn the user!


Well dd is a low level tool so we have to be careful
to not preclude operations which may be valid in some cases.
For example one might definitely want to read/write the same device.


With no further comments in 2 years, I'm closing this bug.
Discussion can continue by replying to this thread.

-assaf

bug#24551: who doesn't read what man page says it does, so doesn't work

[Assaf Gordon]

tags 24551 notabug
close 24551
stop

(triaging old bugs)

It seems your message was lost and not replied to in 2 years.
Sorry about that.

On 2016-09-26 7:40 p.m., L. A. Walsh wrote:

manpage says:
  If  FILE is not specified, use /var/run/utmp.  /var/log/wtmp as FILE is
  common.

[...]

    Behavior says:
access("/var/run/utmpx", F_OK)  = -1 ENOENT (No such file or 
directory)
open("/var/run/utmp", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or 
directory)


This seems like the behavior is exactly as described:
The manual says "/var/run/utmp",
and the open syscall was performed on "/var/run/utmp"

As such, I'm marking this as 'notabug'.
Discussion can continue by replying to this thread.

-assaf

bug#24661: [RFE] Allow running shred on directories

[Assaf Gordon]

retitle 24661 shred: allow running shred on directories
severity 24661 wishlist
tags 24661 wontfix
close 24661
stop

(triaging old bugs)

On 2016-10-10 11:26 a.m., Mohammed Sadiq wrote:

This is a request for enhancement.

It might be nice to allow users to run shred on directories which
would recursively shred the directory and its contents. This may be
limited to happen only when `-u' flag is used.



It seems your message was lost and not replied to in 2 years.
Sorry about that.

Regarding shredding subdirectories,
this suggestion has been previously discussed, and deemed undesired
for shred, as there are other tools that can be used to shred files
recursively (e.g. combined with find/xargs).

For details, see:
https://www.gnu.org/software/coreutils/rejected_requests.html#shred

As such, I'm closing this bug.

regards,
 -assaf

bug#24744: coreutils: dircolors - recognize both st and stterm

[Assaf Gordon]

tags 24744 moreinfo
close 24744
stop

(triaging old bugs)

On 2016-10-20 10:57 a.m., Andreas Schwab wrote:

On Okt 20 2016, Jari Aalto  wrote:


It would be nice if dircolors also recognized terminal with
name "stterm".


Why can't stterm continue to use the "st" terminal?



With no reply in 2 years, I'm closing this bug.
Discussion can continue by replying to this thread.

-assaf

bug#24794: broken tags in coreutils.git

[Assaf Gordon]

tags 24794 fixed
close 24794
stop

(triaging old bugs)

On 2016-10-25 12:07 p.m., Eric Blake wrote:

We've sorted out the details off-list (thanks also to Assaf), and I have
completed the conversion.  The attached file 'broken' is the list of all
the tags that I regenerated.  If you have an existing clone, git will
not replace your local broken tags by default, but you can fix your
local side by:

$ git tag -d $(cat broken)
$ git fetch origin --tags

then, optionally use git prune to remove the now-dangling broken tags.

I'll leave this bug open just a bit longer, until we have undone the
temporary changes that we had to make to bypass normal tag deletion
prevention.



I believe this is OK by now, and so closing.
If someone is still experiencing git/tag issues, please reply to this 
thread.


-assaf

bug#24813: Du Maximum files?

[Assaf Gordon]

tags 24813 moreinfo
close 24813
stop

(triaging old bugs)

On 2016-10-28 1:27 a.m., Erik Auerswald wrote:

On Fri, Oct 28, 2016 at 05:56:07AM +, Benny D. Miller Jr. wrote:

  I am not so sure that this is a bug but a limitation. I am using
"du" for a disk file listing/usage in the command:

du --all --time --human-readable --apparent-size $1;


You did not specify any problems with the above line pertaining to "du".


printf "Total number of files: ";  find $1 -type f | wc -l;


The above line does not relate to "du", but to "find" and "wc".


But it seems to maximum out the file count to 38341

  So I am thinking that this is a limitation to the counter in "wc"?


I don't think so. You can easily check wc's counter by generating known
input, e.g. as follows:

$ yes | head -n8 | wc -l
8
$ yes | head -n2678400 | wc -l
2678400


[]

I do not see the limit you observed.


With no follow-ups in 2 years, I'm closing this bug.
Discussion can continue by replying to this thread.

-assaf

bug#24850: need your help！strange problem.shred sometimes slow sometimes normal.

[Assaf Gordon]

close 24850
stop

(triaging old bugs)

On 2016-11-01 9:55 a.m., Pádraig Brady wrote:

On 01/11/16 06:30, qq wrote:



[shred v8.20 sometimes takes 18min to shred 1G of /dev/sda,
  but usually takes 20seconds, on my ironic minios container]


I'm not sure, but I suspect the issue is outside of shred.
Note shred >= 8.21 enables direct IO which bypasses a
lot of the system VM chicanery, and so may performance better for you.


With no follow-ups in 2 years, I'm closing this bug.

-assaf

bug#24846: error while loading shared libraries: libgmp.so.10: unexpected PLT reloc type 0x40

[Assaf Gordon]

tags 24846 notabug
close 24846
stop

(triaging old bugs)

Pádraig Brady wrote:

On 01/11/16 17:10, Yan Markman wrote:  I think that described failure is 
only a symptom  of more generic

problem. just occasionally failing on coreutils::ls command. So
I would like to understand what exactly this message says. This
message is reported by " ld-2.22.so" but I have no
LIB-source-code. >

You can see this in the glibc source code.

[...]

- Have you got an idea what the code 0x40 (PLT reloc type 0x40) means?


It was expecting reloc type R_ARM_JUMP_SLOT (0x16) or R_ARM_TLS_DESC (0x0D), 
but got R_ARM_LDRS_PC_G0. I don't know how that could happen.


- Should the "coretuls" be resident in RAM or could be swapped out under any condition 
and pumped back upon "ls" command?
- Should the "libgmp.so" be resident in RAM or could be swapped out under any 
condition?


Yes that could happen under mem pressure.



On 2016-11-01 1:33 p.m., Yan Markman wrote:

MANY MANY THANKS

Given the above, and with no further comments in 2 years,
I'm closing this bug.

-assaf

bug#24929: comm enhancement proposal: --print-summary --quiet

[Assaf Gordon]

tags 24929 fixed
close 24929
stop

(triaging old bugs)

Pushed here:

comm: add --total option
https://git.savannah.gnu.org/cgit/coreutils.git/commit/?id=b50a151346c42816034b5c26266eb753b7dbe737


Closing as "fixed".

-assaf

bug#25004: Bug in OD utility

[Assaf Gordon]

close 25004
stop

(triaging old bugs)

On 2016-11-23 9:49 p.m., Jim Meyering wrote:

On Wed, Nov 23, 2016 at 5:16 PM, Marcel Böhme  wrote:



On 24 Nov 2016, at 8:45 AM, Pádraig Brady  wrote:

I can't reproduce the issue here BTW with ASAN and running in a tight
loop for a few minutes.  So perhaps it has been fixed in glibc already?
I have glibc-2.22-10.fc23.x86_64
Depending on how widespread the issue is will determine if it's worth
adding the check to gnulib.


I can reproduce the crash on Ubuntu 14.04 x86_64 with preinstalled od version 
8.21 and the version in trunk.


What libc are you using?


$ /lib/x86_64-linux-gnu/libc.so.6
GNU C Library (Ubuntu EGLIBC 2.19-0ubuntu6.9) stable release version 2.19, by 
Roland McGrath et al.
Copyright (C) 2014 Free Software Foundation, Inc.

...

Compiled by GNU CC version 4.8.4.

...

Both gcc-4.8.4 and EGLIBC 2.19 are showing their age.
I too have failed to reproduce this. I used a Fedora 25 system, which
has glibc-2.24.


Given the above (and other comments in the thread indicating it's
a too-old-glibc issue), I'm closing this bug.
Discussion can continue by replying to this thread.

-assaf

bug#25159: chown bug ? or sys glitch ?

[Assaf Gordon]

tags 25159 moreinfo
stop

(triaging old bugs)

On 2016-12-10 6:51 a.m., ahfc wrote:

Maybe a system glitch or a chown bug so just fyi.

Intention:  change  root:root  to  root:users   on dir struct
command:  sudo chown -R root:users /run/media/user_name/long_disk_number/*

( so mounted through /run/media but an internal disk  i.e. no
external usb, or such )

chown went happily on its way but with a message in between:

chown: changing ownership of ‘/run/media/rest_/of_/path_/filename ':
Operation not permitted

Puzzling, but no time to look into it immediately.
After sys power off ( and later on again ) I did an

"ls -hal"  on that specific file: it had become root:users   after all;
surprisingly !


It seems your message was lost and not replied to in 2 years.
Sorry about that.

If this is still an issue for you, can you provide more details,
in particular what is the file system on /run/media ?

regards,
 - assaf

bug#25455: uniq considers all the full-width punctuation and Japanese kana as the same under zh_CN.UTF-8 locale

[Assaf Gordon]

tags 25455 notabug
close 25455
stop

(triaging old bugs)

On 2017-01-20 8:08 p.m., Mike Frysinger wrote:

On 16 Jan 2017 04:01, Icenowy Zheng wrote:

When dealing lines with only a Chinese full-width punctuation or Japanese kana
and locale is zh_CN.UTF-8, uniq command will consider all the lines are the
same, and wrongly removed different punctuations.


this is a problem with glibc, not coreutils.  you can follow the upstream bug:
https://sourceware.org/bugzilla/show_bug.cgi?id=13063


Given the above, and with no further comments
in more than a year, I'm closing this bug.
Discussion can continue by replying to this thread.

-assaf

bug#25540: notice issue in expand -- doesn't allow for expressing tabsize value in tabstop(s)

[Assaf Gordon]

tags 25540 fixed
close 25540
stop


On 2017-02-28 8:58 a.m., Bernhard Voelker wrote:

On 02/27/2017 12:44 AM, Pádraig Brady wrote:

The attached uses your suggestion of '/' but only allowed in the last position.




Pushed here:

https://git.savannah.gnu.org/cgit/coreutils.git/commit/?id=b1413b6011cd368fb4244f0aa79f4c4ea5ab50c5

Closing as "fixed".

-assaf

bug#25554: date to support iso-8601 week-format (patch included)

[Assaf Gordon]

retitle 25554 date: add iso-8601 week-format option
severity 25554 wishlist
tags 25554 wontfix patch
close 25554
stop

(triaging old bugs)

On 2017-01-27 3:22 p.m., Paul Eggert wrote:
I dunno, there are several ISO 8601 formats that 'date -I' doesn't have 
a special case for now; why add these particular shorthands? If we go 
down this route, shouldn't we also add shorthands for %Y%j, %GW%V, 
%G-W%V-%u, etc., etc.? Where will it stop?


Instead, perhaps we should just suggest to people that they use ordinary 
date formats, as standardized by POSIX. These should be more portable 
anyway. -I is meant as a convenience for interactive use, and I doubt 
whether people would want to use "date -Iweek" interactively much.




Given the above, and no further comments in more than a year,
I'm closing this as "wontfix".
Discussion can continue by replying to this thread.

-assaf

bug#25589: Probably a bug in cp

[Assaf Gordon]

tags 25589 moreinfo
close 25589
stop

(triaging old bugs)

On 2017-01-31 11:53 a.m., Bernhard Voelker wrote:

On 01/31/2017 12:18 PM, Francesco Asnicar wrote:

Dear all,
I'm facing a problem with the cp command when using the -a (or
--preserve=all) parameter.

[...]


You did not provide an example, but I guess that you are running cp(1)
as a regular user.  From the documentation [1]:

   ‘-p’
   ‘--preserve[=attribute_list]’

[...]


Did you fall over this aspect?


With no further follow-ups, I'm closing this bug.
Discussion can continue by replying to this thread.

-assaf

bug#15278: -a vs -e

[Assaf Gordon]

tags 15278 fixed
forcemerge 33097 15278
close 15278
stop

(triaging old bugs)

On 2013-09-05 10:45 a.m., Eric Blake wrote:
[...]

Coreutils therefore should fix its test to favor binary -a over unary
-a, when there are three arguments and the first is !.



Just last week Bernhard committed
  test: remove support for the ambigous -a unary operator

https://git.savannah.gnu.org/cgit/coreutils.git/commit/?id=88c32fa68ee7057744bfb6d41f6e8eb68801306f

So closing this as "fixed".

-assaf

bug#25140: [PATCH] test: implement -N

[Assaf Gordon]

tags 25140 fixed
close 25140
stop

(triaging old bugs)

On 2016-12-08 10:22 a.m., Pádraig Brady wrote:

On 08/12/16 16:56, isabella parakiss wrote:

test currently produces this error message with -N
$ /bin/test -N /
/bin/test: extra argument ‘-N’



Just last week Bernhard committed:
 test: add -N unary operator

https://git.savannah.gnu.org/cgit/coreutils.git/commit/?id=1a674a036bf92739bc79dc54596b9340e8b2ddea

So closing as "fixed".

-assaf

bug#8090: strerror(1) and strsignal(1)?

[Assaf Gordon]

retitle 8090 new programs: strerror(1) and strsignal(1)?
severity 8090 wishlist
tags 8090 wontfix
close 8090
stop

(triaging old bugs)

On 2011-02-20 4:34 p.m., Pádraig Brady wrote:

However this was considered before and discounted as overkill:
http://lists.gnu.org/archive/html/bug-coreutils/2010-01/msg00060.html


Given the above (and similar replies in the thread),
and no more comments in 7 years, I'm closing this bug.

Discussion can continue by replying to this thread.

-assaf

bug#25620: mkdir ignores set-group-id bit in mode argument

[Assaf Gordon]

tags 25620 moreinfo
close 25620
stop

(triaging old bugs)

On 2017-02-04 2:00 p.m., Pádraig Brady wrote:

On 04/02/17 10:34, Alexander Syvak wrote:

[...]

As you can see the set-group-id bit is not set in directory test/test.

umask was 0002.



Is this NFS or if not what file system is it?
usually test/test would auto inherit the g+s bit even if not specified.

What does an strace look like? For me on ext4 it's:


With no further follow-ups in more than a year,
I'm closing this bug.
Discussion can continue by replying to this thread.

-assaf

bug#25930: optimize mv for multiple bind mounts

[Assaf Gordon]

close 25930
stop

(triaging old bugs)

On 2017-03-04 1:01 a.m., Sven Joachim wrote:

On 2017-03-02 13:16 -0800, L A Walsh wrote:


Sven Joachim wrote:

,
|   EXDEV  oldpath and newpath are not on the same mounted filesystem.
|  (Linux  permits  a  filesystem  to  be  mounted at multiple
|  points, but rename() does not work across  different  mount
|  points, even if the same filesystem is mounted on both.)
   


That's unfortunate, as Windows recognizes moves between
the same device and does a rename vs. a copy (i.e. it doesn't
matter if the mounted object from the mount is different, as
long as the rename happens between the same devices).


Linux used to do the same in kernel 2.2, but changed the behavior when
bind mounts were introduced in 2.4.0.  In other words, it's deliberate.



Given the above (kernel limitation), I'm closing this bug.
Discussion can continue by replying to this thread.

-assaf

bug#26324: Tail does not recognize .log file type

[Assaf Gordon]

retitle 26324 tail,stat: add UNIONFS (0xf15f083d)
tags 26324 wontfix
close 26324
stop

(triaging old bugs)

On 2017-04-02 2:56 a.m., Bernhard Voelker wrote:

It seems that this was a UNIONFS filesystem ...

   http://unionfs.filesystems.org/
   http://copilotco.com/mail-archives//linux-kernel.2008/msg45027.html

... which never made it into the linux kernel.
I'm not sure we should support that.  Newer tail(1) >v8.24  wouldn't
output the warning any longer anyway, so silently falling back
to polling seems to be sufficient for UNIONFS.



Given the above, and no further comments,
I'm closing this bug.
Discussion can continue by replying to this thread.

-assaf

bug#26621: hint for translators is missing from POT file, but is opaque anyhow

[Assaf Gordon]

tags 26621 fixed
close 26621
stop

(triaging old bugs)
Pushed here:
https://git.savannah.gnu.org/cgit/coreutils.git/commit/?id=7ea15a57c7a8b876daa3d4d01f1192af3f58f3c7
https://git.savannah.gnu.org/cgit/coreutils.git/commit/?id=d1f5616b2d9b851298f377ae7888b2d718802140

So closing as "fixed".

-assaf

bug#26806: Invalid byte sequence in tr command

[Assaf Gordon]

severity 26806 wishlist
retitle 26806 multibyte: tr: Invalid byte sequence in tr command
stop


(triaging old bugs)

On 2017-05-06 9:07 a.m., maximiliam steffens wrote:

Trying to convert subtitles with characters (accented) possibly changed by
the opensubtitles.

Converting only the lowercase letters is ok

$cat legenda1.srt | tr 'AЯЖЗсржьзнЩКу' 'AÀÊÔãáéíóôúÇç' > teste.srt

With the capital letters of invalid code page
$cat legenda1.srt | tr '├┴┬╔' 'ÃÁÂÉ' > teste2.srt


It seems your message was lost and not answered to in a year.
Sorry about that.

Regarding 'tr': multibyte/utf-8 support is currently lacking,
but is being worked on.

I'll keep this bug open until it is resolved.

-assaf

bug#27358: Timeout command was get failed to kill soffice.bin processes

[Assaf Gordon]

tags 27358 notabug
close 27358
stop

(triaging old bugs)

On 2017-06-14 10:01 a.m., Assaf Gordon wrote:


Without further details I can't tell if this is indeed the culprit
for the behaviour you're experiencing, but this would be one direction
to investigate.



With no further comments in more than a year, I'm closing this bug.
Discussion can continue by replying to this thread.

-assaf

bug#27488: du -tX -t-Y won't exclude or select an interval of SIZE

[Assaf Gordon]

severity 27488 wishlist
tags 27488 wontfix
close 27488
stop

(triaging old bugs)

On 2017-06-26 1:37 a.m., f0rhum wrote:

On 26/06/2017 at 09:00, Pádraig Brady wrote :

On 25/06/17 11:08, f0rhum wrote:

If not, maybe a feature could allow this like du -t3G-5G or -t3G -t-5G
could show dirs from 3 to 5G
and -t-3G5G or -t5G -t-3G would show all others.
Okay, I guess this would be an opened door for guys requesting more than
one intervall ;)



Maybe, though it would complicate things,
and make it incompat with older -t implementations.
I'm not sure there is enough need for this?


[...]

Okay don't worry, I'll have to find how to script this, as I also need
to exclude directories that contain a 0 byte flag file.


With no further comments in more than a year,
I'm closing this bug.

-assaf

bug#27531: Coreutils 8.27 bug report

[Assaf Gordon]

tags 27531 moreinfo
close 27531
stop

(triaging old bugs)

On 2017-07-10 10:51 a.m., Pádraig Brady wrote:

On 29/06/17 06:32, Bernardo Lopes Almeida de Oliveira wrote:


Please find attached the test-suite.log.


The seq failure though is due to your system not behaving like:

   $ src/seq inf inf | head -n2
   inf
   inf

What architecture and c library do you use?



With no further follow-ups in more than a year,
I'm closing this bug.
Discussion can continue by replying to this thread.

-assaf

bug#27640: Bug-report

[Assaf Gordon]

tags 27640 fixed
close 27640
stop

(triaging old bugs)

On 2017-07-10 1:08 p.m., Paul Eggert wrote:
Looking at that test's source code, the test was clearly incorrect for 
Unix-like systems, as it incorrectly assumed a 1-1 mapping between user 
names and user IDs. I fixed that in Gnulib by installing the attached 
patch.


Pushed to gnulib here:

https://git.savannah.gnu.org/cgit/gnulib.git/commit/?id=24605b2f03bfa8367a9149835c687c9073aacc2c

So closing as "fixed".

-assaf

bug#27864: [request] safety to prevent `rm -rf ~`

[Assaf Gordon]

severity 27864 wishlist
tags 27864 wontfix
close 27864
stop

(triaging old bugs)

On 2017-07-29 10:05 a.m., Pádraig Brady wrote:

On 28/07/17 09:28, R0b0t1 wrote:

I recently had a script create a file named "~" when I passed it a
value for an installation directory. Without thinking the next command
I typed was the one in the title. Luckily this was not my main
computer and was a virtual machine.



On 2017-07-28 11:07 a.m., Bernhard Voelker wrote:
>
> rm(1) does not see the tilde "~", but the shell expands it before
> invoking the tool:



This was one of the reasons that upstream ls defaults to quoting
problematic file names like this. With that you can always
copy and paste the name ('~' in this case), for subsequent use.
Even if not copy/pasting '~' would give a visual indication
that the quoting was needed. If your distro disables that feature,
you can enable it in your ls alias using --quoting='shell-escape'



Given the above, and no further comments in a year,
I'm closing this bug.
Discussion can continue by replying to this thread.

-assaf

bug#33113: incorrect and inconsistent quoting in ls output

[Assaf Gordon]

Hello,

On 2018-10-28 2:11 p.m., Paul Eggert wrote:


That's right, we need another way to escape classifier characters with 
-bF, since the current method is clearly wrong.

[...]
This works because in ISO C "b""=" is equivalent to "b=". We should do 
this only with characters at the end, because it's not needed elsewhere 
and the "" is annoying.


Not sure if this is relevant,
but while going over old bugs I noticed this:

  Bug in 'ls -FQ': incorrectly quoted characters
  http://bugs.gnu.org/29832

Which reports incorrect quoting of "@" as "\@"
and also mentions "ls -b", and had a pending patch which was
never committed.

regards,
 -assaf

bug#28152: Human readable units (-h/--human-readable vs --si) - Wrong prefix and missing unit

[Assaf Gordon]

severity 28152 wishlist
tags 28152 wontfix
close 28152
stop

(triaging old bugs)

On 2017-08-21 5:21 p.m., Paul Eggert wrote:

On 08/21/2017 03:56 PM, Michael Weiss wrote:

Do you think it would be possible to add another variable that wouldn't
overwrite the default but use the "human_B" output with -h or --si?


Probably not. We've been heading more in the opposite direction, in that 
we'd rather not have environment variables affect the behavior of 
standard utilities, due to the possibility of confusion and even attacks 
on unwary users. For interactive use you can define your own du command 
or alias that behaves the way you prefer.


On 2017-08-21 5:58 p.m., Assaf Gordon wrote:

You've mentioned numfmt(1), it's worth noting that your request is
exactly what numfmt was designed to do.

With no further comments, I'm closing this bug.
Discussion can continue by replying to this thread.

-assaf

bug#28506: coreutils 8.28 test suite hangs on APFS filesystem

[Assaf Gordon]

tags 28506 fixed
close 28506
stop

(triaging old bugs)

On 2017-09-23 8:47 p.m., Pádraig Brady wrote:

On 22/09/17 20:07, Pádraig Brady wrote:

Is is a wait or a cpu spin?
Could you use the equivalent of strace on your platform to see what's happening?


Offlist Jack sent a profile showing /usr/bin/FILE was waiting on input.
That was the result of a silly typo in the script, which the attached
should fix.  I don't know what that command does, nor why it's specifically
a problem on APFS, but hopefully this fixes things.


Pushed here:
https://git.savannah.gnu.org/cgit/coreutils.git/commit/?id=63d2f05f5283c88f6c60ebe6de7a26ce6b9e4ee8

so closing as "fixed".

-assaf

bug#28440: fts_info is set to FTS_DP for an Unreadable directory instead of FTS_DNR on s390x

[Assaf Gordon]

tags 28440 notabug
close 28440
stop

(triaging old bugs)

Hello,

On 2017-09-12 9:56 p.m., Prajakta Bhatekar wrote:

I have a piece of code that checks for access to a non-root user to perform a 
recursive chown operation on a directory with its child directory having 0 
permissions(all permission bits set to zero)

It uses the` fts_info` flags of FTSENT structure returned by fts_read().For 
s390x architecture(big endian), it is seen that the value of fts_info for the 
unreadable directory is set as 6 (FTS_DP) corresponding to postorder directory 
instead of 6 (FTS_DNR) which is an Unreadable directory . For x86 architecture 
(little endian), expected behaviour is observed as fts_info is FTS_DNR.



It seems your message was lost and not replied to in a year.
Sorry about that.

From your question it appears you are asking a programming question,
but this is the GNU coreutils mailing list - used to report
bugs in GNU coreutils programs (e.g. sort/head/tail/cut/dd).

As such, I'm closing this as "not a bug".

regards,
 - assaf

bug#28528: Split command problems.

[Assaf Gordon]

tags 28528 notabug
close 28528
stop

(triaging old bugs)

On 2017-10-01 6:09 p.m., Nick Farrow wrote:
[...] And from what it looks like the compression was 
the problem. Each server was compressing differently compared to the other.


Given the above, I'm closing this bug.

-assaf

bug#28927: ln -fs dir name doesn't force

[Assaf Gordon]

tags 28927 notabug
close 28927
stop

(triaging old bugs)

On 2017-10-21 12:53 p.m., Andreas Schwab wrote:

On Okt 21 2017, "Sven C. Dack"  wrote:


The link should have been set to "bar" with the "-f" or "--force" option,
shouldn't it?


The file baz/bar has been overwritten.  You need to use -n if you want
to overwrite a link to a directory.



Given the above, and no further comments in a year,
I'm closing this bug.

-assaf

bug#28942: base64 decoding issue

[Assaf Gordon]

tags 28942 notabug
close 28942
stop

(triaging old bugs)

On 2017-10-22 10:13 a.m., Aaron Schneider wrote:
 I try to decode the "thunder://" link to the "magnet://" link using 
base64.  For me, it adds 'AA' at the beginning (0x4141) which shouldn't 
be there.


* Website:
--
thunder://QUFtYWduZXQ6P3h0PXVybjpidGloOmY5YWFkZDYxY2EzM2ZkMWQwYzQ3Mjk2MTQwZTg4ZmFmMWYzZGQyYTJaWg==
--
magnet:?xt=urn:btih:f9aadd61ca33fd1d0c47296140e88faf1f3dd2a2


* My base64 (happens on all versions I've tried):
echo 
QUFtYWduZXQ6P3h0PXVybjpidGloOmY5YWFkZDYxY2EzM2ZkMWQwYzQ3Mjk2MTQwZTg4ZmFmMWYzZGQyYTJaWg==
 | base64 -d
AAmagnet:?xt=urn:btih:f9aadd61ca33fd1d0c47296140e88faf1f3dd2a2ZZ



It seems your message was lost and not replied to in a eyar.
Sorry about that.

If you try to encode the "magnet://" string to base64,
you'll get:

$ echo "magnet:?xt=urn:btih:f9aadd61ca33fd1d0c47296140e88faf1f3dd2a2" \
   | base64 -w0 ; echo
bWFnbmV0Oj94dD11cm46YnRpaDpmOWFhZGQ2MWNhMzNmZDFkMGM0NzI5NjE0MGU4OGZhZjFmM2RkMmEyCg==

Which means your encoded string (the one starting with "QUF") is
not identical to the encoded "magnet://" string.


As such, I'm closing this bug.
If this is still an issue, discussion can continue by replying to this 
thread.


-assaf

bug#29012: od: busy skip on block devices

[Assaf Gordon]

severity 29012 wishlist
retitle 29012 od: add skip option
tags 29012 wontfix
close 29012
stop

(triaging old bugs)

On 2017-10-27 11:59 p.m., Christian Kögler wrote:


Am 27. Oktober 2017 07:25:25 MESZ schrieb "Pádraig Brady" :

On 26/10/17 08:13, Christian Kögler wrote:

If od is used on block devices together with skip, od reads the

skipped bytes instead of seeking it.

Yes it has done that from the initial version.
Note od concatenates multiple files, and skips across
all of them, so consequently restricts itself to
seeking where it knows the file length (regular files).

I suppose we could try to seek if a single argument was specified.

As an alternative you could skip with dd and pipe to od?



I loose the absolute address offset, but in our case a way to go.
Thanks for helping so quickly!


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

-assaf

bug#29205: --force doesn't work

[Assaf Gordon]

tags 29205 notabug
close 29205
stop

(triaging old bugs)

It seems your message was lost and not replied to in a year.
Sorry about that.

On 2017-11-08 2:35 a.m., Konstantin Kharlamov wrote:

Steps to reproduce:

1. $ mkdir -p foo/bar/buzz1
2. $ mkdir -p bar/buzz2
3. $ mv --force bar foo/

Expected result: "bar" is merged into the other "bar"
Actual result: error "mv: cannot move 'bar' to 'foo/bar': Directory not 
empty"


This is the Linux kernel refusing to move (using the rename(2) syscall)
source to a non-empty directory:

Using 'strace' we can see the sys-call failure:

rename("bar", "foo/bar")  = -1 ENOTEMPTY (Directory not empty)

In the kernel's rename(2) syscall manual page, the error is explained:
  ENOTEMPTY or EEXIST
newpath is a nonempty directory, that is, contains entries
other than "." and "..".
http://man7.org/linux/man-pages/man2/rename.2.html#ERRORS

mv(1) simply forwards the kernel error to the user.

So I'm removing this dir, and trying to continue `mv`ing, and here we 
coming to the bug I'm reporting.


Of course I could just copy, but `mv`ing is α) much faster, and β) 
leaves dates of file creation in places, so I don't need to rebuild the 
whole thing over again, only the files I gonna change.


"cp" will copy all files from inside "bar" to "foo/bar".
"mv" tries to replace "foo/bar" with "bar",
and because "foo/bar" is not empty, the kernel refuses to replace it.

If you care about preserving the fiels inside "bar/", but not the "bar"
directory itself, you can use:

mv bar/* foo/bar/

Or you can just delete the "foo/bar" directory
(using -f ensures it will not complain if the directory doesn't exist):

   rm -rf ./foo/bar ; mv bar foo

As such, I'm closing this bug.
Discussion can continue by replying to this thread.

-assaf