head -1 fails with _POSIX2_VERSION=200112

dixsept:~ _POSIX2_VERSION=200111 head -1 /dev/null dixsept:~ _POSIX2_VERSION=200112 head -1 /dev/null head: `-1' option is obsolete; use `-n 1' Try `head --help' for more information. zsh: exit 1 _POSIX2_VERSION=200112 head -1 /dev/null I do not think this is a good idea to fail on the old

tail -c fails (coreutils 5.92)

Under Mac OS X, with tail 5.92 installed by DarwinPorts: prunille:~ echo abcd blah prunille:~ /opt/local/bin/gtail -c 2 blah /opt/local/bin/gtail: cannot open `2' for reading: No such file or directory == blah == abcd zsh: exit 1 /opt/local/bin/gtail -c 2 blah prunille:~[1]

Re: tail -c fails (coreutils 5.92)

On 2005-10-31 23:25:10 -0700, Bob Proulx wrote: What is the output of grep on getopt from the config.log file? $ grep getopt config.log configure:27962: checking getopt.h usability configure:28007: checking getopt.h presence configure:28078: checking for getopt.h configure:28108: checking for

Re: tail -c fails (coreutils 5.92)

On 2005-10-31 23:25:10 -0700, Bob Proulx wrote: Thanks for the report. This works for me on my GNU/Linux machine. I am guessing that configure is somehow not configuring the getopt routine properly. It may be deducing that getopt_long is available and functional when it is not. No, this is

Re: tail -c fails (coreutils 5.92)

On 2005-11-01 15:15:43 -0800, Paul Eggert wrote: With coreutils 5.92, you don't need _POSIX2_VERSION=199209 in your environment to use head -5. head -5 now has the traditional meaning regardless of _POSIX2_VERSION's value. This change came about becase of clarifications to the standard

Alignment bug in ls with UTF-8 filenames under Mac OS X

Hi, Under Mac OS X 10.4.8 with ls (GNU coreutils) 5.97 (installed via MacPorts), in a 80-column terminal (uxterm), I get: $ ls É y123456789012345678901234567890 x123456789012345678901234567890 z123456789012345678901234567890 instead of: $ ls É

Re: Alignment bug in ls with UTF-8 filenames under Mac OS X

On 2007-01-15 20:13:02 -0700, Eric Blake wrote: According to Vincent Lefevre on 1/15/2007 8:05 PM: Under Mac OS X 10.4.8 with ls (GNU coreutils) 5.97 (installed via MacPorts), in a 80-column terminal (uxterm), I get: $ ls É y123456789012345678901234567890

Re: Alignment bug in ls with UTF-8 filenames under Mac OS X

On 2007-01-15 22:29:41 -0800, Paul Eggert wrote: Most likely this has something to do with how mbrtowc and/or wcwidth behaves on MacOS X. Perhaps you can debug the quote_name function of 'ls' on the affected file name, and see why it's computing the width that it's computing? First, do you

Re: Alignment bug in ls with UTF-8 filenames under Mac OS X

On 2007-01-18 03:14:37 +0100, Bruno Haible wrote: Conclusion: What you see is not an ls bug, but an Apple Terminal bug with tabs. I don't use the Apple Terminal (and never use it). As I said in my bug report, I'm using uxterm here. More precisely: prunille:~ uxterm -version XFree86

Re: Alignment bug in ls with UTF-8 filenames under Mac OS X

On 2007-01-18 17:39:40 +0100, Bruno Haible wrote: The --color option also has the effect of turning tabs into spaces; yet this is undocumented. Actually the doc states `ls' uses tabs where possible in the output, for efficiency. If COLS is zero, do not use tabs at all. and the

Re: Alignment bug in ls with UTF-8 filenames under Mac OS X

On 2007-01-19 01:23:44 +0100, Bruno Haible wrote: Apple Terminal version 1.4.6, part of MacOS X 10.3.9, is affected. I forgot to say. This is still not fixed in Terminal 1.5 (133) from Mac OS X 10.4.8. -- Vincent Lefèvre [EMAIL PROTECTED] - Web: http://www.vinc17.org/ 100% accessible validated

Re: Alignment bug in ls with UTF-8 filenames under Mac OS X

On 2007-01-19 03:43:02 +0100, Vincent Lefevre wrote: On 2007-01-18 17:39:40 +0100, Bruno Haible wrote: Vincent, do you have time to report that to the Apple people? No need to mention 'ls' - a simple printf 'E\xcc\x81\t2nd column\nFoo\t2nd column\n' should be all you need

stty discard undef fails under Mac OS X

Hi, Under Mac OS X: prunille:~ /usr/local/bin/stty --version stty (GNU coreutils) 6.7 [...] prunille:~ /usr/local/bin/stty discard undef /usr/local/bin/stty: invalid argument `discard' Try `/usr/local/bin/stty --help' for more information. zsh: exit 1 /usr/local/bin/stty discard undef But

rm -r sometimes produces errors under NFS

Hi, I sometimes get the following error: courge:~/software \rm -r zsh-4.3.2 rm: cannot remove `zsh-4.3.2/Src/Modules/zutil..o': No such file or directory rm: cannot remove `zsh-4.3.2/Src/Modules/zutil.export': No such file or directory rm: cannot remove `zsh-4.3.2/Src/Modules/zutil.so': No

Re: rm -r sometimes produces errors under NFS

On 2007-03-05 16:45:46 +0100, Jim Meyering wrote: Thanks for the report. What version of coreutils are you using? rm (GNU coreutils) 5.97 This is the version from Debian/testing. From the output, I'll bet it is not new. Can you reproduce the problem using the latest snapshot?

Re: rm -r sometimes produces errors under NFS

On 2007-03-05 17:36:08 +0100, Jim Meyering wrote: Vincent Lefevre [EMAIL PROTECTED] wrote: On 2007-03-05 16:45:46 +0100, Jim Meyering wrote: Can you reproduce the problem using the latest snapshot? http://meyering.net/cu/coreutils-6.8+.tar.gz Tried, and this is even worse: I got

Re: rm -r sometimes produces errors under NFS

On 2007-03-05 21:59:37 +0100, Jim Meyering wrote: Vincent Lefevre [EMAIL PROTECTED] wrote: But IMHO, rm should remember that is has already done an unlink and there shouldn't be a diagnostic in this case. Unfortunately it's not that easy. If I were to make such a change, it is quite

Re: rm -r sometimes produces errors under NFS

On 2007-03-05 16:02:54 -0800, Paul Eggert wrote: Read the directory, removing files as we go. getdents64(4, /* 15 entries */, 8192) = 472 lstat(/proc/self/fd/4/config.h.in, {st_mode=S_IFREG|0644, st_size=27828, ...}) = 0 access(test/config.h.in, W_OK)= 0

Re: rm -r sometimes produces errors under NFS

On 2007-03-06 09:03:46 +0100, Jim Meyering wrote: Would you please try changing this definition (from src/remove.c) to e.g., 200 or 2000, CONSECUTIVE_READDIR_UNLINK_THRESHOLD = 10 and see if it lets you use rm -r ... with no errors? I've tried 2000, and no longer get the problem with

Re: rm -r sometimes produces errors under NFS

On 2007-03-06 15:17:07 +0100, Jim Meyering wrote: Such remembering would be prohibitively expensive, in general. I don't see why. In fact, it isn't necessarily useful to remember anything. When rm attempts to remove a file in a recurse phase, no errors should be reported if the file doesn't

Re: rm -r sometimes produces errors under NFS

On 2007-03-06 20:45:24 +0100, Jim Meyering wrote: Vincent Lefevre [EMAIL PROTECTED] wrote: On 2007-03-06 15:17:07 +0100, Jim Meyering wrote: Such remembering would be prohibitively expensive, in general. I don't see why. Remembering means storing names, potentially many of them

Re: rm -r sometimes produces errors under NFS

On 2007-03-06 23:41:30 +0100, Jim Meyering wrote: Vincent Lefevre [EMAIL PROTECTED] wrote: No need to store names: if it's the second pass, all the files have already been unlinked. Not necessarily. Have you looked at the code? New files may have been added since the original opendir

Re: rm -r sometimes produces errors under NFS

On 2007-03-07 01:13:11 +0100, Jim Meyering wrote: You want to ignore only certain ENOENT errors. With the current implementation, knowing which to ignore would require recording which names have been successfully unlinked. In fact I want to ignore all ENOENT errors, but you disagreed.

Re: stty discard undef fails under Mac OS X

Hi, Any news? On 2007-02-14 19:43:09 +0100, Jim Meyering wrote: Vincent Lefevre [EMAIL PROTECTED] wrote: Under Mac OS X: prunille:~ /usr/local/bin/stty --version stty (GNU coreutils) 6.7 [...] prunille:~ /usr/local/bin/stty discard undef /usr/local/bin/stty: invalid argument

Re: rm -r sometimes produces errors under NFS

On 2007-03-08 00:14:06 +0100, Jim Meyering wrote: If you want to discuss further whether rm -r should ignore ENOENT unconditionally, I suggest that you raise the issue with the people who work on the POSIX standard (use the austin-group-l mailing list; subscribe at

Re: rm -r sometimes produces errors under NFS

On 2007-03-08 00:13:48 -0800, Paul Eggert wrote: Here's a more-diabolical example. You invoke 'rm a/b/c', and a/b/c is read-only. Some other process temporarily renames a/b to a/B between the time that 'rm' stats a/b/c and the time 'rm' invokes euidaccess(a/b/c, W_OK); the other process then

Re: rm -r sometimes produces errors under NFS

On 2007-03-09 00:44:55 +0100, Jim Meyering wrote: Realize that for most people (everyone except you, afaik), rm works just fine. Yes, for most people, rm works fine. But the problem exists (I had it on 3 different NFS servers in the past few years). And for your information, other users have

Re: rm -r sometimes produces errors under NFS

On 2007-03-10 12:41:27 +0100, Jim Meyering wrote: Vincent Lefevre [EMAIL PROTECTED] wrote: On 2007-03-09 00:44:55 +0100, Jim Meyering wrote: Realize that for most people (everyone except you, afaik), rm works just fine. Yes, for most people, rm works fine. But the problem exists (I had

Re: rm -r sometimes produces errors under NFS

On 2007-03-15 16:26:52 -0700, Linda Walsh wrote: [...] I agree rm should report a failed unlink, but if the access returns ESTALE, shouldn't that be taken as a hint that the filename we are trying to access has been updated and that an unlink should not be attempted (because the filename

Re: configure fails on Maemo/OS2008 (sed: no previous regexp)

On 2008-03-25 21:30:58 -0600, Eric Blake wrote: Thanks for this portability analysis. I agree that it is a violation of POSIX; perhaps someone should report this to the busybox maintainers. I can't reproduce the problem with BusyBox v1.9.2 (now in Debian). But I don't know when BusyBox will be

logname documentation should say that it relies on getlogin()

The logname documentation is silent concerning its implementation. It appears to rely on getlogin(), which is known to have limitations (or bugs)[*]. Even though such limitations may be documented in the getlogin documentation, the user isn't necessarily aware that they affect logname. [*]

bug#6124: basename/dirname are not POSIX compliant on arg starting with a dash

Hi, I've reported the following bug in the Debian BTS: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=580492 With the basename and dirname utilities from GNU Coreutils, one has: ypig% POSIXLY_CORRECT=1 basename -- basename: missing operand Try `basename --help' for more information. ypig%

bug#6124: basename/dirname are not POSIX compliant on arg starting with a dash

On 2010-05-06 13:50:27 +0100, Pádraig Brady wrote: The above busybox behavior implies that if you write a robust script like this for coreutils, that it is not portable to busybox: base=$(basename -- $path) If one follows POSIX, the correct way to do it is: base=$(basename $path) and

bug#6124: basename/dirname are not POSIX compliant on arg starting with a dash

On 2010-05-06 07:41:59 -0600, Eric Blake wrote: No, you're missing one other key point of POSIX: http://www.opengroup.org/onlinepubs/9699919799/utilities/V3_chap01.html Section 1.4, OPTIONS: Default Behavior: When this section is listed as None., it means that the implementation need

bug#6123: basename/dirname are not POSIX compliant on arg starting with a dash

A practical example of a failure could be when one uses dirname $0 in a rc file and the shell happens to be a login shell. -- Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/ 100% accessible validated (X)HTML - Blog: http://www.vinc17.net/blog/ Work: CR INRIA - computer

bug#6124: basename/dirname are not POSIX compliant on arg starting with a dash

On 2010-05-06 08:02:04 -0600, Eric Blake wrote: On 05/06/2010 07:23 AM, Vincent Lefevre wrote: According to grep 'basename --' /usr/bin/* grep 'basename \$' /usr/bin/* on my Debian machine, almost all scripts use basename without --. The only exceptions are autoconf (but I'm

bug#9346: wc does not conform to POSIX (additional spaces)

http://pubs.opengroup.org/onlinepubs/9699919799/utilities/wc.html says: STDOUT By default, the standard output shall contain an entry for each input file of the form: %d %d %d %s\n, newlines, words, bytes, file But wc from GNU coreutils 8.12 adds spaces: $ echo | wc 1

bug#17578: cp(1) man page: behavior of cp -R dir target on symbolic links is unclear

The cp(1) man page does not describe the behavior on symbolic links when copying recursively. It appears that in such a case, cp does not dereference the links (this is also what the info file says: When copying from a symbolic link, `cp' normally follows the link only when not copying

bug#17578: cp(1) man page: behavior of cp -R dir target on symbolic links is unclear

On 2014-05-24 10:28:30 -0700, Paul Eggert wrote: Vincent Lefevre wrote: this is also what the info file says: When copying from a symbolic link, `cp' normally follows the link only when not copying recursively. Must be an old version; The man page says: GNU coreutils 8.21

bug#18428: coreutils binary breaks coreutils documentation

On 2014-09-08 18:10:35 -0600, Bob Proulx wrote: Note that IIRC originally the pointer was: info touch But that failed due to shortcomings in variously implemented install-info commands that I don't remember now. There were actually several (Debian-specific?) problems with this form.

bug#18449: cat x x error even when x is empty

With coreutils 8.23 under Debian/unstable: ypig% : x ypig% cat x x cat: x: input file is output file ypig% POSIXLY_CORRECT=1 cat x x cat: x: input file is output file while there's no reason to return an error in this case: the file should just remain empty. Using the same file for input and

bug#18449: cat x x error even when x is empty

On 2014-09-11 14:20:06 +0100, Pádraig Brady wrote: On 09/11/2014 02:00 PM, Vincent Lefevre wrote: This may not seem really useful here, but this can potentially break scripts with things like: cat $foo $bar where $foo may be the same file as $bar only if it is empty. I'm

bug#22491: Incorrect date(1) man page about --iso-8601 example for GNU coreutils 8.25

Hi, In the date(1) man page, the --iso-8601 example is: 2006-08-14T02:34:56-0600 This should be: 2006-08-14T02:34:56-06:00 -- Vincent Lefèvre - Web: 100% accessible validated (X)HTML - Blog: Work: CR INRIA -

bug#28989: stat(1) man page should reference statfs(2) in addition to stat(2)

According to strace, statfs() is used when the --file-system is used. The stat(1) man page has: SEE ALSO stat(2) It should have: SEE ALSO stat(2), statfs(2) -- Vincent Lefèvre - Web: 100% accessible validated (X)HTML - Blog:

bug#26101: Counterproductive calculation order in date

On 2017-03-15 13:23:48 +0100, Ulf Zibis wrote: > A more simple example without touch: > $ date +%F > 2017-03-15 > $ date -d "-20 day" +%F > 2017-02-23 > $ date -d "-20 day -2 month" +%F > 2016-12-26 > $ date -d "-2 month -20 day" +%F > 2016-12-26 > > In the 2nd example I would expect: >

bug#33113: incorrect and inconsistent quoting in ls output

On 2018-10-22 01:21:40 -0700, Paul Eggert wrote: > Vincent Lefevre wrote: > > I get the following with ls (GNU coreutils) 8.30. > > > > zira% touch a=b a=b\ > > zira% ls a=b* > > 'a=b' 'a=b' > > zira% ls -b a=b* > > a=b a=b > > zira% ls -F a

bug#33113: incorrect and inconsistent quoting in ls output

I get the following with ls (GNU coreutils) 8.30. zira% touch a=b a=b\ zira% ls a=b* 'a=b' 'a=b' zira% ls -b a=b* a=b a=b zira% ls -F a=b* 'a=b' 'a=b' zira% ls -bF a=b* a\=b a\=b AFAIK, the = character is not a shell metacharacter (except with zsh but only in the first position), thus does

bug#33113: incorrect and inconsistent quoting in ls output

On 2018-10-27 07:28:26 -0700, Pádraig Brady wrote: > On 23/10/18 17:54, Paul Eggert wrote: > > On 10/22/18 1:44 AM, Vincent Lefevre wrote: > >> On the behavior, there's still the issue concerning = and &. > > > > Yes, you're right, there's no need to quote = wit

bug#33915: ls / dircolors should support more than 8 colors

ls / dircolors should support more than 8 colors. First, "dircolors -p" says: # Below are the color init strings for the basic file types. A color init # string consists of one or more of the following numeric codes: # Attribute codes: # 00=none 01=bold 04=underscore 05=blink 07=reverse

bug#33915: ls / dircolors should support more than 8 colors

On 2018-12-30 02:21:15 +0100, Vincent Lefevre wrote: > But one can get bright colors without bold by using 90, 91, etc. > This is useful with gnome-terminal. > > I think that this should be documented. > > Support for more than 16 colors could be nice... Actually t

bug#33914: In man pages, the URL's should not be split on two lines

In the dircolors(1) man page (and other ones for long command names) of GNU coreutils 8.30, as output in a 80-column terminal, one has REPORTING BUGS GNU coreutils online help: Report dircolors translation bugs to

bug#35939: version sort is incorrect with hyphen-minus

On 2019-06-26 12:25:26 -0600, Assaf Gordon wrote: > "ls -v" and "sort -V" (coreutils' version sort) behaves differently than > other implementations in regards to minus character: > > $ printf "%s\n" abb ab-cd | sort -V > abb > ab-cd > > $ v1="abb" > $ v2="ab-cd" > $ dpkg

bug#35939: version sort is incorrect with hyphen-minus

On 2019-06-26 18:40:50 -0700, Paul Eggert wrote: > Perhaps the coreutils manual could be improved to make this all clearer, and > perhaps it should refer to the Debian manual if it doesn't already. In this case, there should be a new ordering option to provide true numeric sort with strings

bug#54785: for floating point, printf should use double like in C instead of long double

On 2022-04-11 14:52:50 -0400, Chet Ramey wrote: > It sounds like there are three cases. > > 1. If the `L' modifier is supplied, as an extension (POSIX doesn't allow >length modifiers for the printf utility), use long double. This would >work in both default and posix modes. > > 2. In

bug#54785: for floating point, printf should use double like in C instead of long double

The printf command assumes that floating-point arguments are long double values, which can yield surprising results, while most of the time the double type is assumed by applications (for instance, this is the case of XPath). For instance: $ zsh -fc '/usr/bin/printf "%a\n" $((43./2**22))'

bug#54785: for floating point, printf should use double like in C instead of long double

On 2022-04-29 16:16:28 -0700, Paul Eggert wrote: > On 4/29/22 13:04, Chet Ramey wrote: > > I think I'm going to stick with the behavior I proposed, fixing the POSIX > > conformance issue and preserving backwards compatibility, until I hear more > > about whether backwards compatibility is an issue

bug#58476: buggy version sort

A regression in version sort (used as the natural sort for "ls") has been introduced from coreutils 8.32 to 9.1: With coreutils 8.32 (Debian 11): $ printf "%s\n" a a0 a1 a.b a0.b a1.b | sort -V a a.b a0 a0.b a1 a1.b With coreutils 9.1 (Debian/unstable): $ printf "%s\n" a a0 a1 a.b a0.b a1.b |

bug#58476: buggy version sort

On 2022-10-13 10:31:38 +0100, Pádraig Brady wrote: > This looks to be the same point as discussed in https://bugs.gnu.org/58153 > where a trailing '0' is essentially ignored when sorting, > as per the debian version sorting spec. > > This is surprising, and perhaps we should diverge from the spec

bug#69939: test utility bug: "test -a -a -a" and "test -o -o -o" fail

With GNU Coreutils 9.4, both "test -a -a -a" and "test -o -o -o" fail: $ export POSIXLY_CORRECT=1 $ /usr/bin/test -a -a -a ; echo $? /usr/bin/test: ‘-a’: unary operator expected 2 $ /usr/bin/test -o -o -o ; echo $? /usr/bin/test: ‘-o’: unary operator expected 2 According to POSIX, they should