bug#73928: Bug#1080330: coreutils: who no longer works

On Mon, Feb 17, 2025 at 12:28:03AM +0100, Vincent Lefevre wrote: No data for xterm. Other terminals are affected too, such as GNOME Terminal. Yes, much of the data from the old utmp is simply not there. A sane transition would deprecate utmp in one release while adding a replacement, then rem

bug#73928: Bug#1080330: coreutils: who no longer works

On Sun, Feb 16, 2025 at 07:05:13PM +0100, Vincent Lefevre wrote: No, w(1) is broken (at least in sid). See the difference between "who" and "w" with systemd 256.7-1, i.e. before the upgrade of systemd that removed utmp support: That's because someone decided to suddenly remove an interface whic

bug#69873: Acknowledgement (df(1) does not display all UFS mountpoints as valid on FreeBSD)

I have now reported this upstream since I consider this to be a bug in the FreeBSD Linux compat layer: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277804

bug#69873: Acknowledgement (df(1) does not display all UFS mountpoints as valid on FreeBSD)

I did some more investigation with stat(2). Running native on FreeBSD with Python os package 'st_dev': $ df -t ufs | cut -f 6 -w | sed 1d | xargs -I% python ~/stat.py % /: 108 /tmp: 110 /var: 111 /var/tmp: 112 /usr: 113 /usr/local: 161 /usr/ports: 142 /usr/obj: 141 /usr/local/pgsql: 140 /var/ne

bug#69873: df(1) does not display all UFS mountpoints as valid on FreeBSD

oes fail here to properly identify the filesystem? Any idea why this happens, where to start digging or what to try? Michael

bug#62572: Bug#1058752: bug#62572: cp --no-clobber behavior has changed

On Mon, Jan 29, 2024 at 04:11:05PM +, Pádraig Brady wrote: You've introduced a silent incompatibility and I'm trying to find some way to make that clear. If upstream would provide a better solution I would certainly use it. I have despaired of there being such since your attitude thus far see

bug#62572: Bug#1058752: bug#62572: cp --no-clobber behavior has changed

On Sun, Jan 28, 2024 at 11:14:14PM -0800, Paul Eggert wrote: I'm not sure reverting would be best. It would introduce more confusion, and would make coreutils incompatible with FreeBSD again. Reverting makes more sense than the current situation. I do not understand why you seem to value FreeB

bug#62572: cp --no-clobber behavior has changed

On Sun, Dec 17, 2023 at 12:34:11AM -0800, Paul Eggert wrote: On 2023-12-16 13:46, Bernhard Voelker wrote: Whether the implementation is race-prone or not is an internal thing. I wasn't referring to the internal implementation. I was referring to cp users. With the newer Coreutils (FreeBSD) be

bug#62572: cp --no-clobber behavior has changed

On Fri, Dec 15, 2023 at 11:21:06AM -0800, Paul Eggert wrote: Stlll, Pádraig gave a reasonable summary of why the change was made, despite its incompatibility with previous behavior. (One thing I'd add is that the FreeBSD behavior is inherently less race-prone.) It seemed like a good idea at the

bug#62572: cp --no-clobber behavior has changed

that's because it has not yet been widely deployed, which makes now the time to fix it. Michael Stone

bug#62572: cp --no-clobber behavior has changed

the old behavior. I am reluctant to do so as that will likely lead to divergent behavior between distributions, but breaking scripts without a compelling reason is also not good. I would encourage coreutils to reconsider the change and finding a non-breaking way forward. Michael Stone

bug#65423: README-install contains invalid/outdated information about 32 bit time_t compared to NEWS in 9.3

On 2023-08-21 21:25, Paul Eggert wrote: On 8/21/23 05:51, Osipov, Michael (IN IT IN) via GNU coreutils Bug Reports wrote: in 9.3 year 2038 support with 64 bit time_t was made required [1], here on HP-UX this is a bit problematic, but that's not the actual problem. The diff between 9.2 an

bug#65423: README-install contains invalid/outdated information about 32 bit time_t compared to NEWS in 9.3

e has written our old applications with portability in mind. It needs to remain 32 bit for now. Michael [1] https://github.com/coreutils/coreutils/commit/ffd62ab92c259d513a419b4078a45f1c658dc774 [2] https://github.com/coreutils/coreutils/compare/v9.2...v9.3#diff-2646d31b27172b7564edd6b4e21

bug#61720: BUG: omission of crucial detail in 'chown --reference' man page (vs info)

GNU build itself is generating this man page, as opposed to it having been created by RHEL. I understand that the man pages are secondary and brief, but they shouldn't be actively misleading, IMO. Thanks, Mike Michael Coleman Computational Scientist Research Advanced Computing Services (HPC) University of Oregon

bug#50070: chmod reads uninitialized variables when fts_info is an error and -v is set, leading to random error messages

false and old_mode/new_mode won't be set. However, old_mode and new_mode are still accessed for the invocation of describe_change if verbosity is set to high, leading to incorrect error messages. I think a better behavior could be to not print the "from mode to mode" part of the error message if the file could not be accessed, since it is meaningless anyways. Have a nice day, Michael

bug#49925: cat -E interprets sentinel newline at the end of buffer as an actual newline after a \r

ts a "^M" for a trailing "\r", but I think that's wrong. - When the file is too big to fit into one buffer. If you try to "cat -E" a big file (mutliple megabytes) that consists of only "\r", cat will print a few "^M" whenever it hits the end of a buffer in the middle of the file and at the end. Michael

bug#49239: Unexpected results with sort -V

Am 28.06.21 um 18:41 schrieb Kamil Dudka: On Sunday, June 27, 2021 12:04:53 AM CEST Michael wrote: Hi, I found some unexpected results with sort -V. I hope this is the correct place to send a bug report to [1]. They are caused by a bug in filevercmp inside gnulib, specifically in the function

bug#49239: Unexpected results with sort -V

mentioned above :) I'll attach a rather simple patch to fix 1) and 2) (including test), I hope that's right. Have a nice day, Michael [1]: https://www.gnu.org/software/coreutils/manual/html_node/Reporting-bugs-or-incorrect-results.html#Reporting-bugs-or-incorrect-results diff --git a

bug#41657: md5sum: odd escaping for input filename \

--Original Message----- From: Bob Proulx Sent: Wednesday, June 24, 2020 02:34 PM To: Michael Coleman Cc: 41...@debbugs.gnu.org Subject: Re: bug#41657: md5sum: odd escaping for input filename \ close 41657 thanks No one else has commented therefore I am closing the bug ticket. But the discussi

bug#41657: md5sum: odd escaping for input filename \

e were even one example. If so, perhaps it could be changed without trouble. In any case, thanks very much for your explanation. Regards, Mike -Original Message- From: Bob Proulx Sent: Monday, June 1, 2020 08:53 PM To: Michael Coleman Cc: 41...@debbugs.gnu.org Subject: Re: bug#416

bug#41657: md5sum: odd escaping for input filename \

And in any case, the "\d" has no obvious interpretation. Really, I can't imagine ever escaping the checksum. (Yes, my users are a clever people.) Cheers, Mike Michael Coleman (mcole...@uoregon.edu<mailto:mcole...@uoregon.edu>) Computational Scientist Research Advanced Compu

bug#39951: tail -n +NUM is not working properly

you want the `head` of the file sans the last few lines, rather than the `tail` of the file sans the first few. from the man page for tail > -n, --lines=[+]NUM > output the last NUM lines, instead of the last 10; or use -n +NUM to output starting with line NUM > use -n +NUM to

bug#38908: Bug on comm or sort

I am trying to use the comm utility to compare two list of IP addresses, sorted with regular sort (not -n), and the result is erroneous. I could not find the answer in Google. list1= 208.78.161.18 208.78.161.19 208.78.161.20 208.78.161.206 208.78.161.207 208.78.161.21 208.78.161.22 208.78.161.224

bug#37864: bug: env exec bomb (no hash bang arg)

One of my users unwittingly stumbled upon the most delightful 'env' bug. It seems to be present in a couple of pretty recent distributions. Try this: #!/usr/bin/env whatever This results in an endless 'execve' recursion (if that's the w

bug#35650: [PATCH] Improving HP-UX support

Am 2019-05-17 um 17:00 schrieb Paul Eggert: On 5/16/19 1:42 AM, Osipov, Michael wrote: + /opt/aCC/bin/aCC -AC99 -I. -I./lib -DHASH_ALGO_BLAKE2=1 -DHAVE_CONFIG_H -Ilib -I./lib -Isrc -I./src -I/opt/ports/coreutils/include -D_INCLUDE_STDC__SOURCE_199901 -g -c -o src/blake2/b2sum-blake2b-ref.o

bug#35650: [PATCH] Improving HP-UX support

Am 2019-05-17 um 00:31 schrieb Paul Eggert: On 5/16/19 1:09 AM, Osipov, Michael wrote: stdbuf is still compiled and linked: If it works, great; if not then I suppose we have more work to do. I don't know how to test stdbuf to figure out whether it works as intended. Michael

bug#35650: [PATCH] Improving HP-UX support

Am 2019-05-15 um 22:02 schrieb Paul Eggert: On 5/15/19 2:30 AM, Osipov, Michael wrote: I don't know how to solve this differently for now, but to disable include_next in configure.ac if the compiler is aCC. Better yet, let's stop using the -include option as it's not portabl

bug#35650: [PATCH] Improving HP-UX support

Am 2019-05-15 um 19:59 schrieb Paul Eggert: On 5/14/19 2:15 PM, Osipov, Michael wrote: configure:68559: checking whether this system supports stdbuf configure:68586: /opt/aCC/bin/aCC -AC99 -o conftest +z -g -I/opt/ports/coreutils/include -D_INCLUDE_STDC__SOURCE_199901 -b -L/opt/ports

bug#35650: [PATCH] Improving HP-UX support

sys/bitypes.h: Am 2019-05-14 um 18:26 schrieb Paul Eggert: On 5/14/19 6:52 AM, Osipov, Michael wrote: aCC does not exit with non-zero, it just prints a warning. OK, I installed the attached patch to try to fix this problem with 'configure'. Please give it a try. We may need

bug#35650: [PATCH] Improving HP-UX support

getacl, aclsort: Am 2019-05-14 um 18:26 schrieb Paul Eggert: On 5/14/19 6:52 AM, Osipov, Michael wrote: aCC does not exit with non-zero, it just prints a warning. OK, I installed the attached patch to try to fix this problem with 'configure'. Please give it a try. We may need

bug#35650: [PATCH] Improving HP-UX support

let's examine #include_next first: Am 2019-05-14 um 18:26 schrieb Paul Eggert: On 5/14/19 6:52 AM, Osipov, Michael wrote: aCC does not exit with non-zero, it just prints a warning. OK, I installed the attached patch to try to fix this problem with 'configure'. Please give i

bug#35650: [PATCH] Improving HP-UX support

Am 2019-05-14 um 18:26 schrieb Paul Eggert: On 5/14/19 6:52 AM, Osipov, Michael wrote: aCC does not exit with non-zero, it just prints a warning. OK, I installed the attached patch to try to fix this problem with 'configure'. Please give it a try. We may need some more patches

bug#35650: [PATCH] Improving HP-UX support

library is for HP-UX now. At best autotools would determine that with some default m4 file. Plain './configure; make' should work and if it doesn't work we should fix it. Normally it does not build shared libraries or try to use PIC; although you can arrange for it to do so that is lower priority for us. See above. Michael

bug#35650: [PATCH] Improving HP-UX support

Am 2019-05-10 um 11:49 schrieb Pádraig Brady: On 09/05/19 03:50, Osipov, Michael wrote: diff -ur src/system.h src/system.h --- src/system.h2019-01-05 11:36:22 + +++ src/system.h2019-05-08 15:19:29 + @@ -422,6 +422,10 @@ # endif #endif +#ifndef __GNUC__ +#define

bug#35650: [PATCH] Improving HP-UX support

ools would determine that with some default m4 file. Note: I am not subscribed to this list. Regards, Michael diff -ur src/basenc.c src/basenc.c --- src/basenc.c2019-02-11 02:51:47 + +++ src/basenc.c2019-05-08 15:08:50 + @@ -247,7 +247,7 @@ struct ba

bug#33775: fold: counting multi-byte utf-8 sequences as separate columns

Hello, I've just discovered an odd behavior of `fold' while trying to wrap a piece of text containing phonetic characters. Take the following line, for example: Tcl (pronounced "tickle" or tee cee ell /ˈtiː siː ɛl/) is a high-level, It is 71 characters long. Still, running echo "Tcl (pronounce

bug#18479: acknowledged by developer ()

nowledged by developer"), that's all. I wouldn't call it "damaged". Best regards, Michael.

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

messages like this. However, this won't happen next days; first we need to set up the new debbugs.gnu.org machine. Best regards, Michael.

bug#32603: Thank you for the quick response and answer!

While the behavior of ignoring parts of the data is unexpected and confusing, the explanation is clear and useful, and the LC_ALL=C setting does result in the expected results. Thank you to all respondents. The explanation of LC_ALL use in the "sort --help" output could perhaps be clearer however

bug#32603: sort bug?

My version of sort seems to have unpredictable behavior, based on the data being sorted: $ sort http://gnu.org/licenses/gpl.html >. This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Written by Mike Haertel and Paul Eggert. --

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

On Wed, Jul 18, 2018 at 03:23:59AM -0700, L A Walsh wrote: In the case of creating a link to a directory there is no choice in creating a "working solution". If you want a link there, it HAS to be a symlink. That the user would bother to use the 'ln' (link) command in the first place

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

On Tue, Jul 17, 2018 at 01:25:59AM -0700, L A Walsh wrote: I am not suggesting handing out alternates when you have a choice. I'm suggesting doing something useful in a case where there are no alternates and no downsides. If you can come up with a case where a symlink to a directory wou

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

On 1/3/2018 5:16 AM, Paul Eggert wrote: OK, attached is a proposed patch to coreutils. Michael, can you give it a try? Looks good! After patch: root@x072:[/home/prj/gnu/coreutils-8.29]lslpp -L | grep coreutils   aixtools.gnu.coreutils.man.en_US     8.29.0.0    C F

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

On 02/01/2018 20:40, Paul Eggert wrote: Pádraig Brady wrote: This is non standard. So I suggest lslpp hardcodes /usr/bin/tr or better again uses LC_ALL, LC_COLLATE=C etc. to enforce working in ASCII mode. I am just a messenger. lslpp is AIX-specific, so it can assume AIX-specific extensions

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

1). AIX 5.3 (/usr/bin/tr) as an argument (-A) that was not used by the command 'lslpp', so the message does not occur: root@x064:[/home/prj/gnu/coreutils-8.29]/usr/bin/tr -A tr: 0653-712 The combination of options and String parameters is not legal. Usage: tr [ -[c|C] | -[c|C]ds | -[c|C]s | -ds

bug#29788: chown: recursive operation with "-H" flag does not work as documented

On 12/20/2017 04:52 PM, Paul Eggert wrote: > On 12/20/2017 12:58 PM, Bernhard Voelker wrote: >> Thus, I think this not a bug in chmod or the documentation, but in the >> your expectations. > > I think his expectations are what POSIX requires. For chown -H -R, POSIX > says that... This is where I

bug#29788: chown: recursive operation with "-H" flag does not work as documented

On 12/20/2017 03:58 PM, Bernhard Voelker wrote: > > I think there is something else going on you didn't consider: > >--dereference affect the referent of each symbolic link (this is > the default), rather than the symbolic link itself > > ... > > Thus, I t

bug#29788: chown: recursive operation with "-H" flag does not work as documented

The documentation for the "-H" flag to chown says, The following options modify how a hierarchy is traversed when the -R option is also specified. If more than one is specified, only the final one takes effect. -H if a command line argument is a symbolic link to a directory,

bug#29396: Comm bug verified

Dear Maintainers I guess the names are Richard M. Stallman and David MacKenzie. I found a vierifiable bug in the utilitu comm. This is very important because hundreds maybe thousands of application rely on this app to make crucial decisions, in power plants, banks, etc. We nedd to trust it. I hav

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

On Sat, 19 Aug, 2017 at 14:09:00 -0700, Paul Eggert wrote: > I'm afraid the problems would be more than minor, as other programs parse > the output (there's an option in GNU 'sort' to do that, for example). You're right, I was way too optimistic about this. But still, it could be way worse imho.

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

n.wikipedia.org/wiki/Unit_prefix#Binary_prefixes - https://en.wikipedia.org/wiki/Data_rate_units - http://man7.org/linux/man-pages/man7/units.7.html - http://man7.org/linux/man-pages/man1/numfmt.1.html - https://debbugs.gnu.org/cgi/bugreport.cgi?bug=7176 - https://debbugs.gnu.org/cgi/bugreport.cgi?

bug#26279: sort bug

This isn't a bug in sort. The ">" redirection operator in your shell opens and truncates the file to ready it for output before your shell invokes sort. After sort starts running and opens and reads the foo.txt file, it finds that empty file and outputs nothing, as you would expect if you had purpo

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

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 |

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

estion gets accepted I'm happy to flesh it out more and write the man-page entry and tests. Cheers, Michael diff --git a/src/md5sum.c b/src/md5sum.c index e58a68e..17cbde0 100644 --- a/src/md5sum.c +++ b/src/md5sum.c @@ -154,6 +154,9 @@ static bool quiet = false; improperly formatted. */

bug#24926: ls output has been made ugly

Can anyone point me to the mailing list discussion where this originally was decided? There are legion of coreutils users out there who are dumbfounded and who detest this change; I see that Debian has reverted it. However, I (and Debian) could be wrong. I'd like to see the original discussion whi

bug#24926: ls output has been made ugly

On Fri, Nov 11, 2016 at 2:00 PM, Eric Blake wrote: > ...Having two > different quoting modes, where you can choose between the options, may > be the way to go - but then you STILL have the problem of what to pick > as the default of those two modes when neither one was explicitly > requested. >

bug#24926: ls output has been made ugly

"...we don't mean to dictate, only to improve things" -Pádraig Brady Feb 15 at 20:46 Somebody went and

bug#23737: wrong rm -i prompt

With coreutils 8.25 on Cygwin I get this; P01104393> rm -i a\b rm: remove regular empty file 'a'$'\t''b'? What is this? The filename is 'a b' and not the nonsense rm outputs. There is a tab character between a and b. P01104393> rm --version rm (GNU coreutils) 8.25 Packaged by Cygwin

bug#23422: stat -c %N returns strange results for file names including

quot;shell" style. > It probably makes sense to have this configurable. > I'll do that for the next release. Thanks! In general I don't care whether you implement it via environment variable or command parameter. The environment variable has the advantage, that the call of stat would be backwards compatible. > thanks, > Pádraig. Best regards, Michael.

bug#23422: stat -c %N returns strange results for file names including

too late for the upcoming Emacs 25.1). Btw, neither in the stat man page nor in the NEWS file of coreutils I found a hint about the changed behaviour. It would be nice to announce such incompatible changes, somehow. > thanks, > Pádraig Best regards, Michael.

bug#23422: stat -c %N returns strange results for file names including

vironment variable. Thanks for the hint with QUOTING_STYLE. However, it doesn't work for me: # env QUOTING_STYLE=escape /usr/bin/stat -c %N /tmp/foo* '/tmp/foo'$'\t''bar' Best regards, Michael.

bug#23422: stat -c %N returns strange results for file names including

coreutils) 6.12" on a very old machine I have access too, used to return `foo\tbar' . Best regards, Michael.

bug#22233: bug: unrecognized file system type 0x794c7630

running elk using docker 1.9.1 and docker-compose 1.5.2 I receive the following directives: *elk_1 | tail: unrecognized file system type 0x794c7630 for '/var/log/elasticsearch/elasticsearch.log'. please report this to bug-coreutils@gnu.org . reverting to polling* *elk_1 | tail: unrecognized file

bug#22057: Sort missing feature proposed

acing for the next 100 years, until it gets done, why don't we just go ahead and do it? On Mon, Nov 30, 2015 at 9:54 AM, Pádraig Brady wrote: > On 29/11/15 22:44, Assaf Gordon wrote: > > tag 22057 notabug > > close 22057 > > stop > > > > Hello Federico, >

bug#22057: Sort missing feature proposed

Dear GNU I suggest that we add a new flag to Sort, to skip certain number of lines from the sorting and copy them verbatim to the output, for example cat temp 10 8 1 2 3 4 5 > sort -z2 temp 10 8 5 4 3 2 1 In this example, the parameter "z" tell the app to ignore first two lines and copy them as

bug#21186: date core with bad string

hese are the GNU core utilities. This package is the combination of : the old GNU fileutils, sh-utils, and textutils packages. moffatt@centos :~$ uname -a Linux X 3.13.0-54-generic #91-Ubuntu SMP Tue May 26 19:15:08 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux ---

bug#20884: copying NFS4 ACLs portably

On Tue, Jun 23, 2015 at 08:22:44PM +0200, Andreas Grünbacher wrote: Somewhat. The "system.nfs4_acl" attribute is nfs specific though: its format isn't well suited for other file systems. Adding support to gnulib would only make copying permissions on nfs work, not across different file system typ

bug#20884: copying NFS4 ACLs portably

On Tue, Jun 23, 2015 at 05:39:14PM +0100, Pádraig Brady wrote: There have been recent changes in this area, so we need to know the version to help determine if this is a regression or was always an issue. 8.23, 8.13 On Tue, Jun 23, 2015 at 07:05:43PM +0200, Andreas Grünbacher wrote: I assume

bug#20884: copying NFS4 ACLs portably

I'm looking for some information before I run too far down this rathole. Currently cp --preserve=all will attempt to preserve both the unix modes and any ACL on a file. This seems to be working entirely as expected with a linux NFS4 client & server. If I attempt the same using a solaris server,

bug#20733: coreutils build problem

I can certainly install a test partition and give someone access to work through this. Just contact me privately and we can get it in motion. Takes a bit less than 10 minutes to do a fresh install (compiler is in the backup image being restored). On Sun, Jun 7, 2015 at 12:10 AM, Paul Eggert wrote

bug#20733: coreutils build problem

l just build in phases.) Many thanks again. On Sat, Jun 6, 2015 at 6:32 PM, Michael Felt wrote: > I downloaded, unpacked, ran configure and then "make -i". The only thing > notable is still the problem with the man page for 'test' aka '[' > (right_bracket) &

bug#20733: coreutils build problem

I downloaded, unpacked, ran configure and then "make -i". The only thing notable is still the problem with the man page for 'test' aka '[' (right_bracket) GEN man/test.1 help2man: can't get `--help' info from man/test.td/[ Try `--no-discard-stderr' if option outputs to stderr make: 1254-004

bug#20733: coreutils build problem

I had only applied the last patch, not both - so I shall backup to the coreutils-8.23.211-b1d1a.tar.xz and apply only the second patch. This is what I thought had been done - but at least then I will not be working from one where configure has already been run. michael@x071:[/data/prj/gnu

bug#20733: coreutils build problem

+ test 1 -eq 127 + exit 1 On Fri, Jun 5, 2015 at 11:34 PM, Pádraig Brady wrote: > On 05/06/15 20:27, Eric Blake wrote: > > On 06/05/2015 11:53 AM, Pádraig Brady wrote: > >> On 05/06/15 17:02, Michael Felt wrote: > >>>> Attribute "constructor" is n

bug#20733: coreutils build problem

e path name does not exist. ld: 0706-012 The -h flag is not recognized. ld: 0706-012 The -a flag is not recognized. make: 1254-004 The error code from the last command is 255. On Fri, Jun 5, 2015 at 5:29 PM, Paul Eggert wrote: > Michael Felt wrote: > >> "lib/get-permissions.c&

bug#20733: coreutils build problem

I did not run config.status - this dog missed that part of the trick! On Fri, Jun 5, 2015 at 4:30 PM, Eric Blake wrote: > On 06/05/2015 08:09 AM, Michael Felt wrote: > > root@x065:[/data/prj/gnu/coreutils/coreutils-8.23]make V=1 > > rm -f src/coreutils.h > >

bug#20733: coreutils build problem

uot; is not allowed. make: 1254-004 The error code from the last command is 1. Stop. make: 1254-004 The error code from the last command is 1. Stop. make: 1254-004 The error code from the last command is 2. Stop. On Fri, Jun 5, 2015 at 4:24 PM, Paul Eggert wrote: > Michael Felt wrote: &

bug#20733: coreutils build problem

quot;, $main)"; done | sort > src/coreutils.ht /bin/sh: 0403-057 Syntax error at line 1 : `;' is not expected. make: 1254-004 The error code from the last command is 2. Stop. root@x065:[/data/prj/gnu/coreutils/coreutils-8.23] On Fri, Jun 5, 2015 at 4:07 PM, Paul Eggert wr

bug#20733: coreutils build problem

This is reassuring. Thank you for the reply. On Fri, Jun 5, 2015 at 3:05 PM, Eric Blake wrote: > On 06/05/2015 04:45 AM, Michael Felt wrote: > > [we tend to avoid top-posting on technical lists, as it makes it harder > to follow the flow of the message] > > > My "

bug#20733: coreutils build problem

ncerned - I had automake 1.15 installed. I removed it and installed automake-1.14.1 and the 'complaint' went away when I ran automake. On Fri, Jun 5, 2015 at 3:08 PM, Eric Blake wrote: > On 06/05/2015 05:13 AM, Michael Felt wrote: > > I think I still have automake 1.14 lying around,

bug#20733: coreutils build problem

As I said before - I do not really know the ins and outs of autoconf and automake - so I shall only summarize my steps: On my "download" server... (/data/prj is an NFS mount shared by all servers) michael@x071:[/data/prj/gnu/coreutils]xz -dc *23*xz | tar xf - michael@x071:[/da

bug#20733: coreutils build problem

, unpack, patch, automake, and see where/how things go). Michael On Fri, Jun 5, 2015 at 1:16 PM, Michael Felt wrote: > After rerunning ./configure --prefix=/opt I still stop at: > > GEN src/coreutils.h > /bin/sh: 0403-057 Syntax error at line 1 : `;' is not expected. > make

bug#20733: coreutils build problem

After rerunning ./configure --prefix=/opt I still stop at: GEN src/coreutils.h /bin/sh: 0403-057 Syntax error at line 1 : `;' is not expected. make: 1254-004 The error code from the last command is 2. On Fri, Jun 5, 2015 at 1:13 PM, Michael Felt wrote: > I think I still have

bug#20733: coreutils build problem

error code from the last command is 2. Shall rerun ./configure and see if the ./src directory problem is solved as well (after automake) p.s. I do this packaging as root - so I always need to # export FORCE_UNSAFE_CONFIGURE=1 Would be "more friendly" if this check could be reported ea

bug#20733: coreutils build problem

different executable (different inode) michael@x071:[/usr/bin]ls -li *ksh* 986 -r-xr-xr-x 5 bin bin 292316 Jun 30 2014 ksh 932 -r-xr-xr-x 2 bin bin 902655 Jul 11 2014 ksh93 986 -r-xr-xr-x 5 bin bin 292316 Jun 30 2014 rksh 932 -r-xr-xr-x 2 bin bin 902655 Jul 11 2014 rksh93 On Fri, Jun 5, 2015 a

bug#20733: coreutils build problem

ing!! On Thu, Jun 4, 2015 at 9:34 PM, Eric Blake wrote: > [adding autoconf] > > On 06/04/2015 01:17 PM, Paul Eggert wrote: > > > > On 06/04/2015 09:41 AM, Michael Felt wrote: > >> GEN src/coreutils.h > >> /bin/sh: 0403-057 Syntax error at line 1 : `;

bug#19218: Inconsistent spacing of output of "ls --full-time [file argument]"

To wrap up: I reported inconsistent output format from ls as a bug; others have made informative comments, to the effect that the output format of ls is not specified in detail so there is no program error; it is user error. I think the essential points are, going from the general to the partic

bug#19218: Inconsistent spacing of output of "ls --full-time [file argument]"

rth fixing though? I repeat, ls --full-time on the SAME file on the SAME directory at the SAME time on the SAME platform with the SAME ls version produces significantly differently-spaced output formats (the actual non-space content is identical, as expected) Best wishes, Michael Salem

bug#19218: Inconsistent spacing of output of "ls --full-time [file argument]"

s are due to viewer and transmission issues.) MS Windows -- ls 5.3.0 ls --full-time (with no argument; same for ls --full-time *.exe) ... -rw-rw-rw- 1 Michael 0 0 2014-11-29 12:28:00.0 + .txt -rwxrwxrwx 1 Michael 0 17920 2003-06-20 16:57:42.0 +0100 cut.ex

bug#18893: Bug with Gnu sort program in coreutils 8.4

Hi, There might be a bug in the “sort” program in GNU coreutils 8.4, present at least in CentOS 6 x86_64. It’s not immediately obvious to me whether or not this bug has been reported before. Given the following: CC = gcc CC = aCC CCFLAGS = CC = cc sort (GNU coreutils) 8.4 yields:

bug#18428: Bug#760861: bug#18428: Bug#760861: bug#18428: coreutils binary breaks coreutils documentation

On Tue, Sep 09, 2014 at 03:31:35PM +0100, Pádraig Brady wrote: It's useful to many, but I agree most don't bother with it due to the awkward non intuitive default info reader _interface_ (though pinfo is a bit better in that regard). Right. I've heard the argument for 15 years that info docs ar

bug#18428: Bug#760861: bug#18428: coreutils binary breaks coreutils documentation

On Mon, Sep 08, 2014 at 06:10:35PM -0600, Bob Proulx wrote: But I think in recent years the install-info problems have been fixed. Perhaps we don't need to do any of this anymore? Or perhaps finally getting to the canonical (FILENAME)NODE-WITHIN-FILE form we have finally arrived at the end and s

bug#17773: AIX build errors with coreutils-8.22

Thanks for the update. On Thu, Jun 19, 2014 at 12:25 AM, Paul Eggert wrote: > Michael Felt wrote: > >> Curious why you are calling this a compiler bug. >> > > Because it is a compiler bug. Try to compile (but not link) the attached > file. Here's what I get

bug#17773: AIX build errors with coreutils-8.22

;, adju sted_width, buf); pad_remaining = next_pad; } } Aren't macros fun! Anyway, if this is the "workings" of the bug, then maybe I can get it submitted for a bugfix. So, before I do any try and submit a bugreport to IBM - please verify that the above is "the bug" -

bug#17773: AIX build errors with coreutils-8.22

ntifer has worked well for ftoast.c for many years. The simple "include" of ftoastr.h to src/od.c and src/getlimits.c seems to be making assumptions that ftoastr.c has not. So, maybe there is another more elegant solution? On Wed, Jun 18, 2014 at 8:59 PM, Michael Felt wrote: > Curi

bug#17773: AIX build errors with coreutils-8.22

ncy on something not found by default when using the xlc compilers. But I may be wrong :p@me On Fri, Jun 13, 2014 at 5:37 PM, Pádraig Brady wrote: > On 06/13/2014 02:38 PM, Michael Felt wrote: > > > make[2]: Entering directory `/data/prj/gnu/coreutils/coreutils-8.22' > > CC

bug#17774: AIX and lbracket ([) program - will not install on AIX using installp

include either in an AIX INSTALL or README? On Wed, Jun 18, 2014 at 8:23 AM, Michael Felt wrote: > Well, you guys are the experts. I was trying to be "smart" - thinking that > lbracket 'required' the closing right bracket to keep the shell syntax > checkers happy. Maybe

bug#17774: AIX and lbracket ([) program - will not install on AIX using installp

ther designed - so I shall make some specialized 'buildaix' components to get around the filenameing problem. Will keep you posted. On Tue, Jun 17, 2014 at 11:16 PM, Eric Blake wrote: > On 06/17/2014 02:50 PM, Michael Felt wrote: > > FYI: the program runs fine, and even from the

bug#17774: AIX and lbracket ([) program - will not install on AIX using installp

name ? -ls 859258194 drwxrwxr-x 7 michael 1954 4096 Dec 16 2013 . 85988590 126 -rwxr-xr-x 1 root system 128624 Jun 13 13:52 ./coreutils-8.20/src/[ 85986625 130 -rwxrwxr-- 1 michael 1954 132118 Nov 3 2012 ./coreutils-8.17/src/[ 85932793 111 -rwxrwxr-- 1 mich

bug#17774: AIX and lbracket ([) program - will not install on AIX using installp

then if nobody has cared up til now I doubt I will have much chance of making a difference on that. thx for the correction. I will mention it, but will not be holding my breath. Michael On Jun 14, 2014 7:28 PM, "Paul Eggert" wrote: > Michael Felt wrote: > >> this is a

  1   2   3   >