Re: Device names too long for df

On Sunday 22 February 2004 20:44, Bob Proulx wrote: > I don't have a system to test this on but I am curious what the -P > output looks like in your case. Just a thought, if you "mkdir -p /dev/ide/host0/bus0/target0/lun0/part1", and "mount --bind /dev/ide/host0/bus0/target0/lun0/part1 /mnt/point",

Re: df & du should honor $BLOCKSIZE

In message <[EMAIL PROTECTED]>, Paul Eggert writes: >[EMAIL PROTECTED] (Peter Seebach) writes: >> BLOCKSIZEThe size of the block units used by several commands, >> most notably df(1), du(1) and ls(1). >Can you find a complete list of BSD programs that use getbsi

Re: df & du should honor $BLOCKSIZE

In message <[EMAIL PROTECTED]>, Paul Eggert writes: >As the 1998 change caused the environment variable to have the same >interpretation as the "--block-size" long option, I thought it more >consistent at the time to spell the environment variable "BLOCK_SIZE" >rather than "BLOCKSIZE". Makes sense

Bug due to multi-byte to wchar macro - PATCH

Hi, coreutils compile failed on solaris 2.6 because MBRTOWC is not defined. Its just about parenthesis in wrong place and because on GNU systems MBRTOWC is defined, th e code compiles. ### PATCH BEGIN --- src/cut.c.ORG 2004-02-08 16:25:32.888099000 -0800 +++ sr

Re: ls --color feature request: ordinary files uncoloured

Here is an updated patch against coreutils-5.2.0, including changelog and news entries. All the 'make check' tests pass, at least for me. diff -ru coreutils-5.2.0/ChangeLog coreutils-5.2.0-new/ChangeLog --- coreutils-5.2.0/ChangeLog 2004-02-17 16:05:39.0 + +++ coreutils-5.2.0-new/Ch

Re: Bug due to multi-byte to wchar macro - PATCH

Thank you for reporting that. Unfortunately, the code in question is not part of the GNU coreutils package. ftp://ftp.gnu.org/gnu/coreutils/coreutils-5.2.0.tar.gz ftp://ftp.gnu.org/gnu/coreutils/coreutils-5.2.0.tar.bz2 Please provide more information on the version/origin of your sources. Co

chown xxx.yyy, POSIX, and LSB

Hi, In coreutils-5.2.0 I see that the dotted user.group form of chown(1) is now rejected unless an environment variable is set, and I understand that POSIX specifies that ':' is the separator. Unfortunately, the Linux Standard Base specifies that '.' may be used in addition. Is there any chance

Re: chown xxx.yyy, POSIX, and LSB

Hi Tim, Tim Waugh <[EMAIL PROTECTED]> wrote: > In coreutils-5.2.0 I see that the dotted user.group form of chown(1) > is now rejected unless an environment variable is set, and I > understand that POSIX specifies that ':' is the separator. > > Unfortunately, the Linux Standard Base specifies that

Re: Device names too long for df

Thomas Stewart <[EMAIL PROTECTED]> writes: > It is far nicer, but how do you find out the running terminals width, without > curses? I did a quick look round, but found nothing. 'ls' does it, so I'd just do what 'ls' does. ___ Bug-coreutils mailing l

Re: chown xxx.yyy, POSIX, and LSB

On Mon, Feb 23, 2004 at 06:49:55PM +0100, Jim Meyering wrote: > Let's hope the LSB is flexible on this, if they haven't > already corrected things for the next version. Version 1.3 says that '.' is supported, while the current 2.0 draft says that it is deprecated (but still supported). On the of

Re: Device names too long for df

On Monday 23 February 2004 06:14, Paul Eggert wrote: > How about having df automatically calculate the column widths based on > their data, much as coreutils 5.2.0's "ls" already does? That way, we > wouldn't have to add a new option to "df". Ye that would be nice, guess I just did the the easy o

Re: chown xxx.yyy, POSIX, and LSB

>> So I guess it'd be more like POSIXLY_INCORRECT :) > > Just to be clear about what I mean, here is the patch I intend to > apply for the Fedora Core coreutils package: > > --- coreutils-5.2.0/lib/userspec.c.allow_old_options 2004-02-23 16:51:00.0 > + > +++ coreutils-5.2.0/lib/usersp

Re: chown xxx.yyy, POSIX, and LSB

Jim Meyering <[EMAIL PROTECTED]> wrote: >>/* If there is no colon, then see if there's a `.'. */ >> - if (separator == NULL && posix2_version () < 200112) >> + if (separator == NULL && (posix2_version () < 200112 || >> +!getenv ("POSIXLY_CORRECT"))) > > Please conside

Re: chown xxx.yyy, POSIX, and LSB

Tim Waugh <[EMAIL PROTECTED]> wrote: > On Mon, Feb 23, 2004 at 02:42:58PM -0500, Paul Jarc wrote: > >> Jim Meyering <[EMAIL PROTECTED]> wrote: >> >>/* If there is no colon, then see if there's a `.'. */ >> >> - if (separator == NULL && posix2_version () < 200112) >> >> + if (separator == NUL

uniq prints invalid unique lines multiple times

When I run uniq from coreutils 5.0 with LANG=en_GB.UTF-8 on a glibc 2.3.2 system on a file which (I think) is not valid UTF-8, I get a confusing result: the two lines in the file are identical, but uniq prints them both, and returns an exit code of 0. If I run LANG=C uniq I get the expected sing

Re: chown xxx.yyy, POSIX, and LSB

On Mon, Feb 23, 2004 at 02:42:58PM -0500, Paul Jarc wrote: > Jim Meyering <[EMAIL PROTECTED]> wrote: > >>/* If there is no colon, then see if there's a `.'. */ > >> - if (separator == NULL && posix2_version () < 200112) > >> + if (separator == NULL && (posix2_version () < 200112 || > >> +

Re: uniq prints invalid unique lines multiple times

Reuben Thomas <[EMAIL PROTECTED]> writes: > What I expect when I run with LANG=en_GB.UTF-8 is either for uniq to > return an error (because the file is not valid text), or to print > one single line (if it's being lenient). Can you please try coreutils-5.2.0? It has some patches in this area. f

Re: chown xxx.yyy, POSIX, and LSB

Jim Meyering <[EMAIL PROTECTED]> writes: > If you do that, you should also adjust `chown --help' output > and coreutils.texi to describe the new default behavior. But the practice elsewhere is to not document the old-fashioned POSIX 1003.2-1992 behavior in help strings; for example, "sort --help"