bug#31332: touch unnecessarily calls dup2

[Paul Eggert]

John Steele Scott wrote:

Prior tohttp://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=commitdiff;h=e373bb19  
fd_reopen() initially did "close(desired_fd); fd = open(...)" which would 
always do the right thing


No, as the old code did the wrong thing for "touch /dev/stdin", whereas the 
current code works.

bug#7073: threadlib vs. pthread modules

[Assaf Gordon]

(triaging old bugs)

Hello,

This thread ( https://bugs.gnu.org/7073 )
starts with build error on Mac OS X due to pthread related issues.

It then deals with this (already commited) gnulib change:
=
2010-09-22  Bruno Haible  
   threadlib: Allow the package to change the default to 'no'.
   * m4/threadlib.m4 (gl_THREADLIB_EARLY_BODY): When
   gl_THREADLIB_DEFAULT_NO is defined, change the default to 'no'.
=

And finally:

On 2010-09-22 11:48 a.m., Paul Eggert wrote:

On 09/22/10 08:18, Bruno Haible wrote:


Would you (in coreutils, sort) be willing to use such an API that is
slightly different from POSIX, but much closer to POSIX than
'lock', 'tls', 'cond', 'thread', 'yield' are now?


Yes, that sounds like a better option, thanks!  Two further thoughts.



Can this bug be closed?
(at least - I believe newer coreutils builds fine on newer Mac OS X)

thanks!
 - assaf

bug#7057: Use of JOIN with tab as delimiter

[Assaf Gordon]

tags 7057 moreinfo
close 7057
stop

(triaging old bugs)

On 2010-09-17 2:06 p.m., Eric Blake wrote:

On 09/17/2010 12:22 PM, Magerman, Tom wrote:
I would like to use JOIN on tab delimited files in a Windows console 
window (with GNUwin32 CoreUtils), but I'm not able to specify tab as 
delimiter (-t switch).


With the default settings, all tabs are replaced by spaces in my 
output file.


Any solution for this problem?


What have you tried (that is, show us the command line you typed)?  Are 
you sure you are quoting tab correctly for the shell you are using? 


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

-assaf

bug#6816: df bug on 64-bit Solaris (need to use getextmntent)

[Assaf Gordon]

Hello Bruno,

On 2018-10-12 10:17 a.m., Bruno Haible wrote:

David Wood wrote:

At this point, me->me_dev contains a wrongly packed (32-bit) device
number, which forces the find_mount_point() code path (causing other
unpleasantries).  The following patch against coreutils v8.5 fixes the
problem:


This problem description was to the point, but I needed a bit of time to
understand the issue entirely.

[...]

So, really, we need to avoid the wrongly encoded dev_t values, and
this means to follow the advice from the mnttab.4 man page.


2018-10-12  Bruno Haible  

mountlist: Improve support for Solaris in 64-bit mode.
Reported by David Wood  in
.
* m4/ls-mntd-fs.m4 (gl_LIST_MOUNTED_FILE_SYSTEMS): On Solaris 8 or
newer, define MOUNTED_GETEXTMNTENT instead of MOUNTED_GETMNTENT2.
* lib/mountlist.c: Add code for MOUNTED_GETEXTMNTENT case.


Did this solve the issue (any reports from Solaris users)?
can this bug be closed?

-assaf

bug#6661: test "install/install-C" fails on Mac OS X 10.6.4

[Assaf Gordon]

close 6661
stop

(triaging old bugs)

On 2010-07-16 9:33 p.m., Richard Godbee wrote:

When I build coreutils 8.5 on Mac OS X 10.6.4, test "install/install-C" fails.



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

Both coreutils 8,.5 and Mac OS X 10.6.4 are very old,
and we've had successful compilation reports with newer versions of both.

As such, I'm closing this bug (despite not being resolved).

If you still experience issues with building coreutils on mac,
please do reply to this thread.

-assaf

bug#6288: gnuwin32 du fails at "C:\Program Files"

[Assaf Gordon]

tags 6288 moreinfo
close 6288
stop

(triaging old bugs)

On 2010-05-28 6:42 a.m., Eric Blake wrote:

On 05/27/2010 06:54 PM, pklam...@hidglobal.com wrote:

On XP SP3, 12GB drive, du quits at (i.e., just before) my directory
"C:\Program Files\".


In general, questions about tools ported to windows are better directed
to the place where you got the tools, rather than upstream, since
windows includes its own set of porting pitfalls.



C:\Program Files\gnu\gnuwin32>du --v
du (GNU coreutils) 5.3.0


That's quite old.  Perhaps you would be interested in trying cygwin,
where coreutils 8.5 has been ported.  I have not had any problems using
the cygwin port of coreutils in running things like du.



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

-assaf

bug#5783: bug5783: ls.c missing HAVE_NL_LANGINFO check

[Assaf Gordon]

tags 5783 fixed
close 5783
stop

triaging very old bug: https://debbugs.gnu.org/5783
and https://savannah.gnu.org/bugs/?29349 .

In 2016, Paul committed the following:

ls: fix %%b format and precompute more
https://git.savannah.gnu.org/cgit/coreutils.git/commit/?id=1db94ee969b984bbd00b97c6abbe2f69db8e

Which I believe fixes the ls/month issue
(compare the commit with the suggested patch from 2010:
https://savannah.gnu.org/bugs/download.php?file_id=20037 ).

As such, I'm closing this bug (if that's wrong, re-open it).
Discussion can continue by replying to this thread.

-assaf

bug#31332: touch unnecessarily calls dup2

[John Steele Scott]

Hi Assif,

Thanks for your reply.

On 30/10/18 1:47 pm, Assaf Gordon wrote:
> tags 31332 notabug
> close 31332
> stop
>
> On 2018-05-01 4:38 a.m., John Steele Scott wrote:
>>  From 
>> https://stackoverflow.com/questions/40446555/why-does-touch-call-the-dup2-syscall
>>
>> jscott@citra:/tmp$ touch --version | head -1
>> touch (GNU coreutils) 8.25
>> jscott@citra:/tmp$ strace -ttt touch foo 2>&1 | tail -9
>> 1525170579.952032 open("foo", O_WRONLY|O_CREAT|O_NOCTTY|O_NONBLOCK, 0666) = 3
>> 1525170579.952080 dup2(3, 0)    = 0
>> 1525170579.952119 close(3)  = 0
>> 1525170579.952156 utimensat(0, NULL, NULL, 0) = 0
>> 1525170579.952209 close(0)  = 0
>> 1525170579.952257 close(1)  = 0
>> 1525170579.952294 close(2)  = 0
>> 1525170579.952333 exit_group(0) = ?
>> 1525170579.952450 +++ exited with 0 +++
>>
>> My analysis from that discussion:
>>
>>  It's a historical artifact.
>>
>>  The open()+dup2() pattern comes from the fd_reopen() function, which is 
>> used
>>  by several of the programs in the coreutils code base.
>>
>
> Not exactly an "artifact" - but an indented operation.
>
I called it a historical artefact because the call to dup2() did not occur when 
touch started calling fd_reopen(). Prior to 
http://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=commitdiff;h=e373bb19 
fd_reopen() initially did "close(desired_fd); fd = open(...)" which would 
always do the right thing if stdin was the desired fd. No call to dup2().


> The goal of "fd_reopen" is not just to open a file,
> but to ensure the returned file descriptor (an "int") has a specific
> value.
>
> For example, standard input (STDIN) is typically file descriptor value 0. 
> calling fd_reopen first opens the file (the kernel returns file descriptor 
> 3), then it ensures file descriptor 0 is associated with the same file (and 
> then, calling "close(3)" gets rid of the other file descriptor).
>
> Checking how fd_reopen is used in coreutils, it is almost always used
> to ensure STDIN/STDOUT point to the desired file(s):
> 
> $ git grep fd_reopen
> src/csplit.c:  if (! STREQ (name, "-") && fd_reopen (STDIN_FILENO, name, 
> O_RDONLY, 0) < 0)
> src/dd.c:/* Restart on EINTR from fd_reopen().  */
> src/dd.c:ifd_reopen (int desired_fd, char const *file, int flag, mode_t mode)
> src/dd.c:  ret = fd_reopen (desired_fd, file, flag, mode);
> src/dd.c:  if (ifd_reopen (STDIN_FILENO, input_file, O_RDONLY | 
> input_flags, 0) < 0)
> src/dd.c:   || ifd_reopen (STDOUT_FILENO, output_file, O_RDWR | opts, 
> perms) < 0)
> src/dd.c:  && (ifd_reopen (STDOUT_FILENO, output_file, O_WRONLY | 
> opts, perms)
> src/nohup.c:  if (fd_reopen (STDIN_FILENO, "/dev/null", O_WRONLY, 0) < 0)
> src/nohup.c:    ? fd_reopen (STDOUT_FILENO, file, flags, mode)
> src/nohup.c:    ? fd_reopen (STDOUT_FILENO, in_home, 
> flags, mode)
> src/split.c:  && fd_reopen (STDIN_FILENO, infile, O_RDONLY, 0) < 0)
> src/stty.c:  if (fd_reopen (STDIN_FILENO, device_name, O_RDONLY | 
> O_NONBLOCK, 0) < 0)
> src/touch.c:  fd = fd_reopen (STDIN_FILENO, file,
> ===
>
> This means the rest of the program can just operate on STDIN (or STDOUT). 

I haven't looked at all those cases, but my point was that the call to dup2() 
adds an extra 40us to each invocation of touch. In the case of touch, it really 
only cares about the fd being STDOUT_FILENO or !STDOUT_FILENO; it doesn't need 
to be STDIN_FILENO exactly. With a small amount of work touch could use open() 
instead of fd_reopen(). The code would be somewhat simpler and it would save 
40us of execution time.

Or maybe it wouldn't, since there's an extra fd open when the program 
terminates and we need to wait for the kernel to clean that up anyway? I don't 
know.

Cheers,

John

bug#23222: test: incorrect operator-precedence

[Assaf Gordon]

tags 23222 fixed
close 23222
stop

On 2016-04-05 9:09 a.m., Eric Blake wrote:

tag 23222 confirmed
thanks

On 04/05/2016 05:57 AM, Mattias Andrée wrote:

Failing test-case #1:

./test -n -a -n

fails and outputs

   ./test: extra argument ‘-n’

Expected behaviour is silent success, as seen in
Bash's implementation.


Thanks for the report.  POSIX indeed says that -a is a binary primary,
and also says that




With this recent commit:
  test: remove support for the ambigous -a unary operator

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

test(1) no longer accepts unary "-a".

Closing this item as "fixed".

-assaf

bug#33125: /bin/del

[Assaf Gordon]

severity 33125 wishlist
retitle 33125 rm: add --backup option, similar to cp/mv/ln
stop

On 2018-10-28 3:12 p.m., Paul Eggert wrote:
It'd be nice to add a --backup flag to 'rm', which would behave like 
--backup does with cp, mv, and ln. This would have the effect of the 
'del' command you're suggesting.


The topic of the thread changed, I'm marking this as a "wishlist" item.

-assaf

bug#32796: please consider using renameat2 from glibc if available

[Assaf Gordon]

tags 32796 fixed
close 32796
stop

On 2018-10-08 12:27 a.m., Paul Eggert wrote:
Thanks for checking. I installed the attached into Gnulib master. The 
"(tiny change)" is because the patch is small enough that we don't need 
to worry about copyright papers.


Pushed here:
https://git.savannah.gnu.org/cgit/gnulib.git/commit/?id=c50cf67bd7ff70525f3cb4074f0d9cc1f5c6cf9c

Closing as "fixed".

-assaf

bug#32774: Filenames with spaces in ls

[Assaf Gordon]

tags 32774 notabug
close 32774
stop

On 2018-09-19 1:46 p.m., Paul Eggert wrote:

Ivan Perez wrote:
the presence of the extra quote and the misalignment that that causes 
draws one's attention to the quote.


That's part of the intent. The quotes draw the reader's attention to the 
oddball file name, which is a good thing since these file names can 
cause trouble when they are cut and pasted from 'ls' output.




Given the above, I'm closing this bug.

-assaf

bug#32472: sort doesn't sort and uniq loses data for many non-Latin scripts on UTF-8 locales

[Assaf Gordon]

tags 32472 notabug
close 32472
stop


On 2018-08-18 11:34 a.m., Paul Eggert wrote:

Vaayda Yaasra wrote:

Here’s an example in Syriac:

ܡܠܬܐ
ܒܝܬܐ
ܒܪܢܫܐ
ܡܠܬܐ

Sort produces the following:

ܡܠܬܐ
ܒܝܬܐ
ܡܠܬܐ
ܒܪܢܫܐ


This is a property of your locale, so I suggest sending a bug report to 
whoever maintains your locale. You should be able to reproduce the 
problem by bypassing GNU 'sort' entirely and using the C strcoll function.


For what it's worth, I observe the problem on Ubuntu 18.04 but not on 
Fedora 28. As Fedora tends to be more up-to-date, perhaps the problem is 
fixed already in glibc.


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

-assaf

bug#32308: join doesn't ignore trailing whitespace

[Assaf Gordon]

severity 32308 wishlist
retitle 32308 doc: join: mention whitespace is significant
stop

Hello,

On 2018-07-29 9:11 p.m., Dima Kogan wrote:

It appears that join doesn't ignore trailing whitespace, resulting
in surprising results. 

[...]
 > I guess the manpage isn't explicit about what happens in this case, but

as a user, I find this to be extremely surprising, and this thus feels
like a bug.


I've marked this as a wishlist item - to be improved in the future.

-assaf

bug#31493: please add null-terminated line output for sha256sum, sha1sum, etc

[Assaf Gordon]

tags 31493 fixed
close 31493
stop

Pushed here:

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

So closing as "fixed".

-assaf

bug#31472: tsort reporting false loop in input. unix2dos fixes the problem.

[Assaf Gordon]

tags 31472 notabug
close 31472
stop

Hello,

On 2018-05-16 10:16 a.m., Bernhard Voelker wrote:

This replaces "\n" by "\r\n", and of course changes the way tsort
works. If your suspicion was that the file has Windows-style
line-endings, then you would have had to use 'dos2unix'.


On 2018-05-17 2:54 a.m., Ivan Ivanov wrote:

Beyond the CRLF problem, I found that the result, returned by tsort on
the file with dos line endings had duplicates. So it is totally
incorrect.


The conclusion of the thread is that dos/windows/mac line endings
will affect "tsort" (as expected - since tsort treats them as normal 
characters which change the sorted string).


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

-assaf

bug#31332: touch unnecessarily calls dup2

[Assaf Gordon]

tags 31332 notabug
close 31332
stop

On 2018-05-01 4:38 a.m., John Steele Scott wrote:

 From 
https://stackoverflow.com/questions/40446555/why-does-touch-call-the-dup2-syscall

jscott@citra:/tmp$ touch --version | head -1
touch (GNU coreutils) 8.25
jscott@citra:/tmp$ strace -ttt touch foo 2>&1 | tail -9
1525170579.952032 open("foo", O_WRONLY|O_CREAT|O_NOCTTY|O_NONBLOCK, 0666) = 3
1525170579.952080 dup2(3, 0)    = 0
1525170579.952119 close(3)  = 0
1525170579.952156 utimensat(0, NULL, NULL, 0) = 0
1525170579.952209 close(0)  = 0
1525170579.952257 close(1)  = 0
1525170579.952294 close(2)  = 0
1525170579.952333 exit_group(0) = ?
1525170579.952450 +++ exited with 0 +++

My analysis from that discussion:

     It's a historical artifact.

     The open()+dup2() pattern comes from the fd_reopen() function, which is 
used
     by several of the programs in the coreutils code base.



Not exactly an "artifact" - but an indented operation.

The goal of "fd_reopen" is not just to open a file,
but to ensure the returned file descriptor (an "int") has a specific
value.

For example, standard input (STDIN) is typically file descriptor value 
0. calling fd_reopen first opens the file (the kernel returns file 
descriptor 3), then it ensures file descriptor 0 is associated with the 
same file (and then, calling "close(3)" gets rid of the other file 
descriptor).


Checking how fd_reopen is used in coreutils, it is almost always used
to ensure STDIN/STDOUT point to the desired file(s):

$ git grep fd_reopen
src/csplit.c:  if (! STREQ (name, "-") && fd_reopen (STDIN_FILENO, name, 
O_RDONLY, 0) < 0)

src/dd.c:/* Restart on EINTR from fd_reopen().  */
src/dd.c:ifd_reopen (int desired_fd, char const *file, int flag, mode_t 
mode)

src/dd.c:  ret = fd_reopen (desired_fd, file, flag, mode);
src/dd.c:  if (ifd_reopen (STDIN_FILENO, input_file, O_RDONLY | 
input_flags, 0) < 0)
src/dd.c:   || ifd_reopen (STDOUT_FILENO, output_file, O_RDWR | 
opts, perms) < 0)
src/dd.c:  && (ifd_reopen (STDOUT_FILENO, output_file, O_WRONLY 
| opts, perms)
src/nohup.c:  if (fd_reopen (STDIN_FILENO, "/dev/null", O_WRONLY, 0) 
< 0)

src/nohup.c:? fd_reopen (STDOUT_FILENO, file, flags, mode)
src/nohup.c:? fd_reopen (STDOUT_FILENO, in_home, 
flags, mode)

src/split.c:  && fd_reopen (STDIN_FILENO, infile, O_RDONLY, 0) < 0)
src/stty.c:  if (fd_reopen (STDIN_FILENO, device_name, O_RDONLY | 
O_NONBLOCK, 0) < 0)

src/touch.c:  fd = fd_reopen (STDIN_FILENO, file,
===

This means the rest of the program can just operate on STDIN (or STDOUT).


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

-assaf

bug#31184: tail -f on Network FS not refreshing as soon as the file is changed.

[Assaf Gordon]

close 31184
stop

On 2018-06-12 9:10 a.m., Jewsco Pius Jacquez wrote:

Padraig, thanks a lot for your help on this.

We found a workaround combined with cache=none mount option and it works for 
our customer. You can close this case.

tail --follow=name --max-unchanged-stats=1 --sleep-interval=.01 



Given the above, I'm closing this bug.

-assaf

bug#30907: mv return value.

[Assaf Gordon]

tags 30907 fixed
close 30907
stop

(triaging old bugs)

On 2018-03-23 7:45 a.m., Kamil Dudka wrote:

On Friday, March 23, 2018 2:00:01 PM CET Eric Blake wrote:

I don't know if mv exposes RENAME_NOREPLACE semantics yet, but it should
be taught to do so, where such semantics are available.


mv was recently patched to use renameat2(..., RENAME_NOREPLACE):

http://git.savannah.gnu.org/cgit/coreutils.git/commit/?id=v8.29-9-g29baf25aa


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

-assaf

bug#30504: bug tail -2 FILE1 FILE1 - tail: option used in invalid context -- 2

[Assaf Gordon]

close 30504
stop

(triaging old bugs)

On 2018-02-17 3:37 p.m., Paul Eggert wrote:
There is a backward-compatibility problem with supporting "tail -2" with 
any number of extra arguments, since (for example) "tail -2c 20" has a 
different meaning in traditional "tail" than you might think. To avoid 
confusion, "tail -2" is not encouraged when using non-traditional 
features (in your case, two or more FILE arguments). Since "tail -n2 
FILE1 FILE2 ..." suffices, it's not clear that it'd be worth the 
aggravation to rethink this.




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

-assaf

bug#30430: [column] accounting for ansi color codes

[Assaf Gordon]

tags 30430 notabug
close 30430
stop

(triaging old bugs)

On 2018-02-17 2:33 p.m., Pádraig Brady wrote:

On 11/02/18 22:07, Boruch Baum wrote:

The `column -t' command doesn't align input properly when that input
includes ansi color codes.



Note column(1) is part of the util-linux project.
We've similar considerations though with wc -L
which we've at least mentioned at:
http://www.pixelbeat.org/docs/coreutils-gotchas.html#wc



Given the above, I'm closing this bug.

-assaf

bug#30453: Bug in BC calculator version 1.07.1

[Assaf Gordon]

tags 30453 notabug
close 30453
stop

(triaging old bugs)

On 2018-02-14 3:33 p.m., Martin Møller Skarbiniks Pedersen wrote:

This is not a bug.
 From the man-page:

$ man bc | fgrep -A5 "expr * expr"
expr * expr
   The result of the expression is the product of the two
expressions.

expr / expr
   The  result  of  the  expression  is  the quotient of
the two expressions.  The scale of the result is the value of the
variable
   scale.


as bc(1) is not part of GNU coreutils,
I'm closing this bug.

-assaf

bug#29946: no -A argument for 'tr' generates an error message whenever the AIX command "lslpp -L" is used (AIX 6.1 and later).

[Assaf Gordon]

tags 29946 fixed
close 29946
stop

(triaging old bugs)

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

so closing as "fixed".

-assaf

bug#29939: 回复: Re: bug#29939: HELP:enter a "ls"command, then the os connection will closed

[Assaf Gordon]

tags 29939 moreinfo
close 29939
stop

(triaging old bugs)

On 2018-01-08 8:22 a.m., Bernhard Voelker wrote:

On 01/04/2018 01:58 AM, lil...@chinaunicom.cn wrote:

$ type ls
ls is aliased to `ls $LS_OPTIONS'


It was a bit hard to find a an old SLES-11.1 ...
Hmm, is your LS_OPTIONS set to something strange?
What if you remove the alias?



With no further comments in 10 months,
I'm closing this bug.
If this is still an issue, please reply with more details.

-assaf

bug#29807: Probably ignore this bug report ;-)

[Assaf Gordon]

tags 29807 notabug
close 29807
stop

(triaging old bugs)

On 2017-12-21 9:45 p.m., Martin Schwenke wrote:

After reading the documentation again, I realise that it is actually
complete (i.e. no arguments implies --tmpdir).


Given the above, I'm closing this bug.


[...] A separate discussion of TMPDIR would be more helpful.


Patches and wording suggestions are always welcomed.

regards,
 - assaf

bug#29802: "uniq -c" doesn't like counting lines with nulls

[Assaf Gordon]

tags 29802 moreinfo
close 29802
stop

(triaging old bugs)

On 2017-12-21 9:33 a.m., Pádraig Brady wrote:

On 21/12/17 08:40, PD wrote:

# printf "\n\x00\n\x00\n" | uniq -c | cat -e
   1 $
   1 ^@$
   1 ^@$


Not reproducible on recent versions.
Might this have been specific to the i18n patch?
I.E. can you reproduce with LC_ALL=C set in the env?



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

-assaf

bug#29604: man cut should mention no way to do ls -l|cut ...

[Assaf Gordon]

severity 29604 wishlist
retitle 29604 wontfix
close 29604
stop

(triaging old bugs)

On 2017-12-07 8:53 a.m., 積丹尼 Dan Jacobson wrote:

"EB" == Eric Blake  writes:


EB> Let's step back a bit. We recommend that you NEVER parse ls output, as

No problem.  [...]


Closing this bug.

-assaf

bug#29589: date %k adds extra space for single digits hours

[Assaf Gordon]

tags 29589 notabug
close 29589
stop

(triaging old bugs)

From: Bishop Bettini [mailto:bishop.bett...@gmail.com]

On Wed, Dec 6, 2017 at 4:17 AM, Noam Arad  wrote:
When using date command with the format %k if the hour is single digits there 
is an extra space added.
E.g.: date -u +"%Y/%m/%d %k:%M:%S" when run at "2017/12/06 9:16:26" will give the output 
"2017/12/06  9:16:26"
NOTE: there are two spaces between "06" and "9".

This seems expected. Per the documentation as of GNU coreutils 8.22:

%k hour, space padded ( 0..23); same as %_H



On 2017-12-06 11:55 a.m., Noam Arad wrote:

Thanks for the quick reply. Will use your suggestions.

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

-assaf

bug#29475: filesystem (apparently cagefs) does not allow ln to create bad symbolic link

[Assaf Gordon]

tags 29475 notabug
close 29475
stop

(triaging old bugs)

On 2017-11-30 6:07 p.m., Paul Eggert wrote:

On 11/30/2017 04:59 PM, bug-coreut...@trodman.com wrote:
 From my trial and error, this file system does not let you create bad 
sym links.


Hmm, yes, apparently that filesystem can be configured to disallow 
creation of dangling symlinks or links to files they don't own. See:


https://www.cloudlinux.com/getting-started-with-cloudlinux-os/41-security-features/933-activating-securelink 

Using this feature will break a lot of programs (not just ln), but 
evidently they're not concerned about that.




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

-assaf

bug#29285: Error building coreutils 8.28.32-a4eed under Archlinux from AUR

[Assaf Gordon]

tags 29285 moreinfo
stop

(triaging old bugs)

Hello,

On 2017-11-13 7:43 a.m., timofonic timofonic wrote:


As the coreutils build system reported, I'm sending the following
building error from using the coreutils-git Arch User Repository
package ( https://aur.archlinux.org/packages/coreutils-git/)



Based on the attached logs, it's a gnulib test failure;

===
FAIL: test-getlogin
===

test-getlogin.h:79: assertion 'pwd->pw_uid == stat_buf.st_uid' failed
FAIL test-getlogin (exit status: 134)



It's been a while since your report (sorry about that).
Do you still get similar failure with more recent coreutils versions?


-assaf

bug#29259: tail does not seek to the end of block device

[Assaf Gordon]

tags 29259 fixed
close 29259
stop

(triaging old bugs)

Pushed here:

tail: seek to the end of block devices
https://git.savannah.gnu.org/cgit/coreutils.git/commit/?id=31dd7a0de272affa1120ba1fbc7db3445c548aa5

so closing as "fixed".

-assaf

bug#29228: Broken link

[Assaf Gordon]

tags 29228 fixed
close 29228
sto

(triaging old bugs).

On 2017-11-09 8:18 a.m., Chris Koehnke wrote:


On http://www.gnu.org/software/coreutils/coreutils.html the "plain text" link to 
http://stagecraft.theprices.net/nomime.html goes to "Page not found".



Thanks for the report.
Sorry there was no reply for a long time.

The link was fixed (changed to point to the wayback machine's archived
copy of the page) - so I'm closing this bug.


regards,
 -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

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#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#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#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#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#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#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