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

On 2025-02-17 10:39:09 +0100, Thorsten Kukuk wrote: > "who -d" shows which login processes exit without removing the utmp > entry and where the init process cleaned up the utmp entry instead. > Since no terminal is controlled by an init process, you should never > see any terminal listed. So I have

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

On 2025-02-17 08:03:23 +0100, Thorsten Kukuk wrote: > Some terminal applications (e.g. xterm, konsole, ...) create fake utmp > entries for historic reasons: so that broadcast messages are shown in > every single terminal. Which for people, who only work with graphical > applications, but not termin

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

On 2025-02-16 23:56:43 +0100, Chris Hofstaedtler wrote: > * Michael Stone [250216 22:45]: > > 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"

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

On 2025-02-16 19:05:13 +0100, Vincent Lefevre wrote: > On 2025-02-16 18:55:54 +0100, Chris Hofstaedtler wrote: > > Control: retitle -1 coreutils: "who" needs to ask seat manager > > > > On Fri, Sep 20, 2024 at 05:24:11PM +0200, Vincent Lefevre wrote: > >

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

On 2025-02-16 18:55:54 +0100, Chris Hofstaedtler wrote: > Control: retitle -1 coreutils: "who" needs to ask seat manager > > On Fri, Sep 20, 2024 at 05:24:11PM +0200, Vincent Lefevre wrote: > > Control: retitle -1 coreutils: "who" should support wtmpdb (y2038)

bug#73928: "who" should support wtmpdb

The "who" utility should support wtmpdb. It no longer works when utmp support is disabled by systemd (the /var/run/utmp file no longer exists). -- Vincent Lefèvre - Web: 100% accessible validated (X)HTML - Blog: Work: CR INRIA - computer

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 ret

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

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

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))' 0xa.c00

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 mixing

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

On 2019-06-26 12:57:14 -0700, Paul Eggert wrote: > GNU sort uses the same algorithm as glibc strverscmp, and this algorithm has > changed only once since strverscmp was added to glibc in 1997. The change > was made in 2009, to fix this bug: > > https://sourceware.org/bugzilla/show_bug.cgi?id=9913

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

With GNU coreutils 8.30 under Debian/unstable, I get: $ LC_ALL=C ls ab-cd abb abe $ LC_ALL=C ls -v abb abe ab-cd The hyphen-minus character should still be regarded as being less than the letters (there are no digits, so both are expected to be equivalent). The GNU coreutils manual says: 10.

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 this

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 08=concea

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

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\&c > > zira% ls a=b* > > 'a=b' 'a=b&c' > > zira% ls -b a=b* > >

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\&c zira% ls a=b* 'a=b' 'a=b&c' zira% ls -b a=b* a=b a=b&c zira% ls -F a=b* 'a=b' 'a=b&c' zira% ls -bF a=b* a\=b a\=b&c AFAIK, the = character is not a shell metacharacter (except with zsh but only in the first position), th

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: > 2016-12-23

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#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 - computer arithmetic / A

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

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

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

On 2014-09-09 12:58:14 -0400, Assaf Gordon wrote: > BTW, > "http://gnu.org/s/"; redirects to "http://www.gnu.org/software/"; , > so > http://gnu.org/s/coreutils/ls > > also works. But isn't it better to avoid a redirection (if possible)? -- Vincent Lefèvre - Web: 1

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#17578: cp(1) man page: behavior of "cp -R dir target" on symbolic links is unclear

On 2014-05-26 09:59:04 +0100, Pádraig Brady wrote: > Yes we shouldn't assume users would know that -H and -L would override -P. > Also --link is recently wound up in this. Hence it's not easy to describe. It could be described like in the info file. > We could accurately describe using something

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 versio

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 recursively

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", , , , But wc from GNU coreutils 8.12 adds spaces: $ echo | wc 1 0 1 Setting

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 scr

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 - Web: 100% accessible validated (X)HTML - Blog: Work: CR INRIA - computer arithmetic / Aréna

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 implementati

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")

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% P

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. [*] http://

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 b

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

orts usage like > '/\(re\)/{s//\1/;...}', and POSIX appears to requires this, > busybox's sed does not support it. So duplicate the regexp: > '/\(re\)/{s/\(re\)/\1/;...}'. Reported by Vincent Lefevre: > <http://thread.gmane.org/gmane.

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

When configuring coreutils 6.10 on my Nokia N810 (Linux Maemo/OS2008, using BusyBox v1.6.1), I get: [...] checking for getspnam... yes checking for library containing crypt... -lcrypt sed: no previous regexp configure: error: internal error: g'l_INCLUDE_EXCLUDE_PROG's 2nd arg, ,

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 th

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

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 r

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

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 http://www.opengroup.org/

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/l

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

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

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 ex

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 proble

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

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

Re: rm -r sometimes produces errors under NFS

On 2007-03-05 19:07:31 +0100, Jim Meyering wrote: > Your log shows that rm succeeds in removing each file (all unlink syscalls > succeed), yet the directory is not empty, so it rewinds it and goes > through again -- and all names are still there. The _second_ unlink > attempt fails with ENOENT, be

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/coreut

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

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 suc

"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

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

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: 100% accessible valid

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. > > an

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 4.3.99.90

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 yo

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

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: 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 standar

Re: tail -c fails (coreutils 5.92)

On 2005-11-01 15:15:43 -0800, Paul Eggert wrote: > > Also, the following code (considering a boolean as an integer value) > > is at least dirty if not buggy: > > It's not a bug. This sounds like a mere style issue. C has > well-defined behavior here, and that code operates correctly as far as >

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

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 ge

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]> /opt/local/b

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 f