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", it
could emulate the effect.
I just spotted a mistake I made. My patch affected the -P option, tho I think
you saw it before me.
Now with my new patch, the -P output looks as follows:-
$ unalias df
$ /bin/df -P | head -3 # system df from debian
Filesystem 1024-blocks Used Available Capacity Mounted on
/dev/ide/host0/bus0/target0/lun0/part5 19686804 7107944 11578816 39% /
/dev/ide/host0/bus0/target0/lun0/part6 85610300 63209432 21531112 75%
/mnt/store
$ ./df -P | head -3 # my new df with patch (same as ^)
Filesystem 1024-blocks Used Available Capacity Mounted on
/dev/ide/host0/bus0/target0/lun0/part5 19686804 7107944 11578816 39% /
/dev/ide/host0/bus0/target0/lun0/part6 85610300 63209436 21531108 75%
/mnt/store
$ ./df -P -w | head -3 # my new df with patch (same as ^)
Filesystem 1024-blocks Used Available Capacity Mounted on
/dev/ide/host0/bus0/target0/lun0/part5 19686804 7107944 11578816 39% /
/dev/ide/host0/bus0/target0/lun0/part6 85610300 63209436 21531108 75%
/mnt/store
$ ./df -w | head -3 # my new df with patch (showing just -w)
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/ide/host0/bus0/target0/lun0/part519686804 7107952 11578808 39% /
/dev/ide/host0/bus0/target0/lun0/part685610300 63209432 21531112 75% /mnt/store
Again, use fixed width font to actually see differences, but in short the
patch does not effect -P. If -w and -P are both used then the output
looks like -P.
As a side note, -w has no effect if the -T is used to print the fs type.
> `-P'
> `--portability'
> Use the POSIX output format. This is like the default format
> except for the following:
>
>1. The information about each filesystem is always printed on
> exactly one line; a mount device is never put on a line by
> itself. This means that if the mount device name is more
> than 20 characters long (e.g., for some network mounts), the
> columns are misaligned.
-w is like this, one filesystem to one line, but it aligns all the
columns and headings.
Here is the new patch:-
--- coreutils-5.2.0/src/df.c.orig 2004-02-22 02:29:02.0 +
+++ coreutils-5.2.0/src/df.c2004-02-22 23:09:03.0 +
@@ -111,6 +111,9 @@
/* If nonzero, print filesystem type as well. */
static int print_type;
+/* Print in wide mode, usefull for long device entries, eg devfs or udev */
+static int wide;
+
/* For long options that have no equivalent short option, use a
non-character as a pseudo short option, starting with CHAR_MAX + 1. */
enum
@@ -135,6 +138,7 @@
{"no-sync", no_argument, NULL, NO_SYNC_OPTION},
{"type", required_argument, NULL, 't'},
{"exclude-type", required_argument, NULL, 'x'},
+ {"wide", no_argument, NULL, 'w'},
{GETOPT_HELP_OPTION_DECL},
{GETOPT_VERSION_OPTION_DECL},
{NULL, 0, NULL, 0}
@@ -145,11 +149,13 @@
{
char buf[MAX (LONGEST_HUMAN_READABLE + 1, INT_BUFSIZE_BOUND (uintmax_t))];
- if (print_type)
+ if (print_type) {
fputs (_("FilesystemType"), stdout);
- else
+ } else {
fputs (_("Filesystem"), stdout);
-
+if (wide && !posix_format)
+ fputs (_(""), stdout);
+ }
if (inode_format)
printf (_("Inodes IUsed IFree IUse%%"));
else if (human_output_opts & human_autoscale)
@@ -325,8 +331,10 @@
}
else
{
- if ((int) strlen (disk) > 20 && !posix_format)
+ if ((int) strlen (disk) > 20 && !posix_format && !wide)
printf ("%s\n%20s", disk, "");
+ else if (wide && !posix_format)
+ printf ("%-40s", disk);
else
printf ("%-20s", disk);
}
@@ -752,6 +760,7 @@
-T, --print-type print filesystem type\n\
-x, --exclude-type=TYPE limit listing to filesystems not of type TYPE\n\
-v(ignored)\n\
+ -w, --wideprint in wide format, for long device entries\n\
"), stdout);
fputs (HELP_OPTION_DESCRIPTION, stdout);
fputs (VERSION_OPTION_DESCRIPTION, stdout);
@@ -784,6 +793,7 @@
inode_format = 0;
show_all_fs = 0;
show_listed_fs = 0;
+ wide = false;
human_output_opts = human_options (getenv ("DF_BLOCK_SIZE"), false,
&output_block_size);
@@ -792,7 +802,7 @@
posix_format = 0;
exit_status = 0;
- while ((c = getopt_long (argc, argv, "aB:iF:hHklmPTt:vx:", long_options, NULL))
+ while ((c = getopt_long (argc, argv, "aB:iF:hHklmPTt:vx:w", long_options, NULL))
!= -1)
{
switch (c)
@@ -852,6 +862,9 @@
case 'x':
add_exclu
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 getbsize, >and which contexts they use it in? >Here's why I'd like to know the details. OpenBSD 3.2 'ls' treats >BLOCKSIZE differently than coreutils-5.2.0 'ls' treats BLOCK_SIZE. >The latter affects the st_size column, but the former doesn't. (See >below.) So, even if we make BLOCK_SIZE default to BLOCKSIZE, the >emulation won't be quite right for "ls". I'm worried that there are >other problems in other programs. Hmm. Lemme see what I can do. $ cd /usr/src $ find . -name "*.c" -print | xargs grep -l getbsize ./bin/df/df.c ./bin/ls/ls.c ./lib/libc/gen/getbsize.c ./sbin/swapctl/swaplist.c ./usr.bin/du/du.c ./usr.bin/systat/swap.c ./usr.sbin/quot/quot.c Looks like they all do the same thing. -s ___ Bug-coreutils mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-coreutils
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. >> It seems to me like it would be reasonable to use $BLOCKSIZE if >> $BLOCK_SIZE isn't set, simply because it's widely used elsewhere. >Something like that sounds reasonable, except what is BLOCKSIZE >supposed to mean when it's widely used elsewhere? Do you have a >specification somewhere? I couldn't find one. The only spec I've found is in the environ(7) manpage on NetBSD, but all of the BSDs seem to agree on it; they have a standard getbsize(3) which does the dirty work. BLOCKSIZEThe size of the block units used by several commands, most notably df(1), du(1) and ls(1). BLOCKSIZE may be specified in units of a byte by specifying a number, in units of a kilobyte by specifying a number followed by ``K'' or ``k'', in units of a megabyte by specifying a number followed by ``M'' or ``m'' and in units of a gigabyte by specifying a number followed by ``G'' or ``g''. Sizes less than 512 bytes or greater than a gigabyte are ignored. Note that weird values such as "100" work fine; this is arguably a feature for hard drive vendors, I guess. >It seems to me that "ls" etc. should ignore ridiculous settings like >that, instead of having them be equivalent to BLOCK_SIZE=1024. Does >that sound right to you? If so, I can prepare a patch. (But this >might be related to the issue of what BLOCKSIZE actually means on >those other platforms.) Well, the documented behavior for BLOCKSIZE on NetBSD is "if it's incoherent, assume it's 512". For GNU utilities, I wouldn't be surprised if the answer were "if it's incoherent, use 512 if POSIXLY_CORRECT, and 1024 otherwise". -s ___ Bug-coreutils mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-coreutils
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
+++ src/cut.c 2004-02-08 16:19:54.673963000 -0800
@@ -1207,8 +1207,8 @@
mbdelim[0] = '\t';
mbdelim[1] = '\0';
delimlen = 1;
-}
#endif
+}
if (output_delimiter_string == NULL)
{
--- src/join.c.ORG 2004-02-08 16:25:54.958277000
-0800
+++ src/join.c 2004-02-08 16:22:04.945347000 -0800
@@ -1069,8 +1069,8 @@
tablen = 1;
}
else
- {
#endif
+ {
tablen = 1;
}
break;
### PATCH BEGIN
__
Do you Yahoo!?
Yahoo! Mail SpamGuard - Read only the mail you want.
http://antispam.yahoo.com/tools
___
Bug-coreutils mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-coreutils
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/ChangeLog 2004-02-22 13:36:13.163611440 +
@@ -1,3 +1,11 @@
+2004-02-22 Ed Avis <[EMAIL PROTECTED]>
+
+ * src/ls.c: ordinary files are written with no ANSI escape
+ sequences, even with --color. The escape sequence to reset the
+ terminal is not output if no filenames were printed with color.
+ In particular this means nothing printed on stdout for 'ls --color
+ nonexistent-file'.
+
2004-02-17 Jim Meyering <[EMAIL PROTECTED]>
* Version 5.2.0.
diff -ru coreutils-5.2.0/NEWS coreutils-5.2.0-new/NEWS
--- coreutils-5.2.0/NEWS2004-02-19 18:04:27.0 +
+++ coreutils-5.2.0-new/NEWS2004-02-22 13:42:28.437561128 +
@@ -1,4 +1,11 @@
GNU coreutils NEWS-*- outline -*-
+* Major changes since 5.2.0
+
+ ls --color now leaves ordinary files uncolored, unless you have
+ explicitly chosen a color for them in the LS_COLORS environment
+ variable. And if it did not print any color escape sequences, it
+ will not print the escape sequence to reset the terminal afterwards.
+
* Major changes in release 5.2.0 (2004-02-19) [stable]
** Bug fixes
diff -ru coreutils-5.2.0/src/ls.c coreutils-5.2.0-new/src/ls.c
--- coreutils-5.2.0/src/ls.c2004-02-01 19:31:00.0 +
+++ coreutils-5.2.0-new/src/ls.c2004-02-22 13:34:13.349825904 +
@@ -227,7 +227,7 @@
static int file_interesting (const struct dirent *next);
static uintmax_t gobble_file (const char *name, enum filetype type,
int explicit_arg, const char *dirname);
-static void print_color_indicator (const char *name, mode_t mode, int linkok);
+static bool print_color_indicator (const char *name, mode_t mode, int linkok);
static void put_indicator (const struct bin_str *ind);
static int put_indicator_direct (const struct bin_str *ind);
static void add_ignore_pattern (const char *pattern);
@@ -483,6 +483,13 @@
static int print_with_color;
+/* Whether we used any colors in the output so far. If so, we will
+ need to restore the default color later. If not, we will need to
+ print some stuff (prep_non_filename_text ()) before using color for
+ the first time. */
+
+static bool used_color = false;
+
enum color_type
{
color_never, /* 0: default or --color=never */
@@ -501,13 +508,13 @@
enum indicator_no
{
-C_LEFT, C_RIGHT, C_END, C_NORM, C_FILE, C_DIR, C_LINK, C_FIFO, C_SOCK,
+C_LEFT, C_RIGHT, C_END, C_RESET, C_NORM, C_FILE, C_DIR, C_LINK, C_FIFO, C_SOCK,
C_BLK, C_CHR, C_MISSING, C_ORPHAN, C_EXEC, C_DOOR
};
static const char *const indicator_name[]=
{
-"lc", "rc", "ec", "no", "fi", "di", "ln", "pi", "so",
+"lc", "rc", "ec", "rs", "no", "fi", "di", "ln", "pi", "so",
"bd", "cd", "mi", "or", "ex", "do", NULL
};
@@ -523,8 +530,9 @@
{ LEN_STR_PAIR ("\033[") },/* lc: Left of color sequence */
{ LEN_STR_PAIR ("m") },/* rc: Right of color sequence */
{ 0, NULL }, /* ec: End color (replaces lc+no+rc) */
-{ LEN_STR_PAIR ("0") },/* no: Normal */
-{ LEN_STR_PAIR ("0") },/* fi: File: default */
+{ LEN_STR_PAIR ("0") },/* rs: Reset to ordinary colors */
+{ 0, NULL }, /* no: Normal */
+{ 0, NULL }, /* fi: File: default */
{ LEN_STR_PAIR ("01;34") },/* di: Directory: bright blue */
{ LEN_STR_PAIR ("01;36") },/* ln: Symlink: bright cyan */
{ LEN_STR_PAIR ("33") }, /* pi: Pipe: yellow/brown */
@@ -977,7 +985,8 @@
signal (sig, SIG_IGN);
#endif
- restore_default_color ();
+ if (used_color)
+restore_default_color ();
/* SIGTSTP is special, since the application can receive that signal more
than once. In this case, don't set the signal handler to the default.
@@ -1035,7 +1044,6 @@
may have just reset it -- e.g., if LS_COLORS is invalid. */
if (print_with_color)
{
- prep_non_filename_text ();
/* Avoid following symbolic links when possible. */
if (color_indicator[C_ORPHAN].string != NULL
|| (color_indicator[C_MISSING].string != NULL
@@ -1192,7 +1200,7 @@
}
/* Restore default color before exiting */
- if (print_with_color)
+ if (used_color)
{
put_indicator (&color_indicator[C_LEFT]);
put_indicator (&color_indicator[C_RIGHT]);
@@ -3408,8 +3416,8 @@
print_name_with_quoting (const char *p, mode_t mode, int linkok,
struct obstack *stack)
{
- if (print_with_color)
-print_color_indicator (p, mode, linkok);
+ const bool used_
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. Could your sources include modifications from some vendor like RedHat, SuSE, or Mandrake? Sunil <[EMAIL PROTECTED]> wrote: > 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 > +++ src/cut.c 2004-02-08 16:19:54.673963000 -0800 > @@ -1207,8 +1207,8 @@ >mbdelim[0] = '\t'; >mbdelim[1] = '\0'; >delimlen = 1; > -} > #endif > +} ... ___ Bug-coreutils mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-coreutils
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 of making this new rejection behaviour dependent on POSIXLY_CORRECT (i.e. having the old behaviour remain the default in its absence), rather than only providing the old behaviour with _POSIX2_VERSION=199209? Tim. */ pgp0.pgp Description: PGP signature ___ Bug-coreutils mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-coreutils
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 '.' may be used > in addition. Let's hope the LSB is flexible on this, if they haven't already corrected things for the next version. > Is there any chance of making this new rejection behaviour dependent > on POSIXLY_CORRECT (i.e. having the old behaviour remain the default > in its absence), rather than only providing the old behaviour with > _POSIX2_VERSION=199209? It wouldn't make sense to tie chown's accepting `.' in place of `:' to POSIXLY_CORRECT, since it would make chown interpret a.b as username `a' and group `b' while POSIX requires that it be interpreted as username `a.b'. So I guess it'd be more like POSIXLY_INCORRECT :) ___ Bug-coreutils mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-coreutils
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 list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-coreutils
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 off-chance
that it can be removed altogether I filed this bug report:
http://bugs.linuxbase.org/show_bug.cgi?id=98
> > Is there any chance of making this new rejection behaviour dependent
> > on POSIXLY_CORRECT (i.e. having the old behaviour remain the default
> > in its absence), rather than only providing the old behaviour with
> > _POSIX2_VERSION=199209?
>
> It wouldn't make sense to tie chown's accepting `.' in place of `:'
> to POSIXLY_CORRECT, since it would make chown interpret a.b as username
> `a' and group `b' while POSIX requires that it be interpreted
> as username `a.b'.
>
> 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_options2004-02-23 16:51:00.0
+
+++ coreutils-5.2.0/lib/userspec.c 2004-02-23 17:04:41.0 +
@@ -171,7 +171,8 @@
separator = strchr (spec, ':');
/* 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")))
{
dot = strchr (spec, '.');
/* If there's no colon but there is a `.', then first look up the
Tim.
*/
___
Bug-coreutils mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-coreutils
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 option. It would evolve:- - Finding the width of the terminal df is running on, the "COLUMNS" environment variable could override this. - Then calculate if all the df columns would fit. Then based on this, print on one line or split the line in two. And arrange the column widths accordingly. 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. Regards -- Tom PGP Fingerprint [DCCD 7DCB A74A 3E3B 60D5 DF4C FC1D 1ECA 68A7 0C48] PGP Publickey [http://www.stewarts.org.uk/public-key.asc] PGP ID [0x68A70C48] ___ Bug-coreutils mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-coreutils
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/userspec.c2004-02-23 17:04:41.0 +
> @@ -171,7 +171,8 @@
>separator = strchr (spec, ':');
>
>/* 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 consider using a different environment variable.
Setting POSIXLY_CORRECT should not make an otherwise-POSIX-conforming
program like GNU chown *non*conforming.
___
Bug-coreutils mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-coreutils
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 consider using a different environment variable.
> Setting POSIXLY_CORRECT should not make an otherwise-POSIX-conforming
> program like GNU chown *non*conforming.
Setting the variable would mean that "." *wouldn't* be recognized,
AFAICT. If it's *not* set, then "." is considered as a separator.
paul
___
Bug-coreutils mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-coreutils
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 == NULL && (posix2_version () < 200112 ||
>> >> + !getenv ("POSIXLY_CORRECT")))
>> >
>> > Please consider using a different environment variable.
>> > Setting POSIXLY_CORRECT should not make an otherwise-POSIX-conforming
>> > program like GNU chown *non*conforming.
>>
>> Setting the variable would mean that "." *wouldn't* be recognized,
>> AFAICT. If it's *not* set, then "." is considered as a separator.
>
> Precisely -- this is what I tried to say in words, and then with the
> code. :-)
Oh. I see now.
If you do that, you should also adjust `chown --help' output
and coreutils.texi to describe the new default behavior.
You should also change the descriptions of the
--from=CURRENT_OWNER:CURRENT_GROUP
option, since it too relies on the parse_user_spec function
that you're proposing to change.
___
Bug-coreutils mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-coreutils
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 single line of output. 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).
The only way I might be wrong is if the file can be interpreted as a UTF-8
file with two non-identical lines, but I don't think it can.
I attach the relevant file, and display it below (the \200 is a literal
top-bit-set byte, value octal 0200). The file ends with a linefeed, in
case you're wondering!
ushort f(char,double,char,double):('a',0.2,'\200',0.4)->65506
ushort f(char,double,char,double):('a',0.2,'\200',0.4)->65506
--
http://www.mupsych.org/~rrt/ | The only person worth beating is yourselfushort f(char,double,char,double):('a',0.2,'',0.4)->65506
ushort f(char,double,char,double):('a',0.2,'',0.4)->65506
___
Bug-coreutils mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-coreutils
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 ||
> >> + !getenv ("POSIXLY_CORRECT")))
> >
> > Please consider using a different environment variable.
> > Setting POSIXLY_CORRECT should not make an otherwise-POSIX-conforming
> > program like GNU chown *non*conforming.
>
> Setting the variable would mean that "." *wouldn't* be recognized,
> AFAICT. If it's *not* set, then "." is considered as a separator.
Precisely -- this is what I tried to say in words, and then with the
code. :-)
The intent is to make 'POSIXLY_CORRECT=1 chown ...' behave as in
unpatched coreutils-5.2.0.
Tim.
*/
pgp0.pgp
Description: PGP signature
___
Bug-coreutils mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-coreutils
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. ftp://ftp.gnu.org/gnu/coreutils/coreutils-5.2.0.tar.gz If coreutils-5.2.0 is also broken for you, can you please use GDB to place a breakpoint on the xmemcoll function and see why it is not printing an error message for you? It is possible that you're seeing a bug in your C library's implementation of strcoll. If strcoll is returning a nonzero value for identical strings, and is not setting errno to indicate an encoding error exists in the strings, that would explain your symptoms. That's why I'm asking for the GDB debugging, if you still observe the bug in 5.2.0. ___ Bug-coreutils mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-coreutils
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" and
"tail --help" don't.
As I caused this problem originally (sorry!), I looked into the POSIX
spec with tweezers and a fine-toothed comb, and I spotted an escape
hatch. Here is a simpler (and what I hope is a better) proposal: have
chown support the old syntax regardless of POSIX version of
POSIXLY_CORRECT. This conforms, is because POSIX allows the "chown
user.group file" behavior as an upward-compatible extension, so long
as it comes into play only where a vanilla chown would report an error
(which is what the code already does).
Here is a proposed patch.
2004-02-23 Paul Eggert <[EMAIL PROTECTED]>
* NEWS: Document the following.
* doc/coreutils.texi (chown invocation): Likewise.
* lib/userspec.c: Don't include "posixver.h".
(parse_user_spec): Fall back on USER.GROUP parsing regardless
of POSIX version, as POSIX 1003.1-2001 allows that behavior as a
compatible extension. Simplify code by removing a boolean int
that was always nonzero if a string was nonnull.
Index: NEWS
===
RCS file: /home/meyering/coreutils/cu/NEWS,v
retrieving revision 1.178
diff -p -u -r1.178 NEWS
--- NEWS21 Feb 2004 09:26:56 - 1.178
+++ NEWS23 Feb 2004 23:02:56 -
@@ -14,6 +14,12 @@ GNU coreutils NEWS
The `|' and `&' operators now use short-circuit evaluation, e.g.,
`expr 1 \| 1 / 0' no longer reports a division by zero.
+** New features
+
+ `chown user.group file' now has its traditional meaning even when
+ conforming to POSIX 1003.1-2001, so long as no user has a name
+ containing `.' that happens to equal `user.group'.
+
* Major changes in release 5.2.0 (2004-02-19) [stable]
Index: doc/coreutils.texi
===
RCS file: /home/meyering/coreutils/cu/doc/coreutils.texi,v
retrieving revision 1.161
diff -p -u -r1.161 coreutils.texi
--- doc/coreutils.texi 22 Feb 2004 15:44:32 - 1.161
+++ doc/coreutils.texi 23 Feb 2004 23:05:15 -
@@ -7712,11 +7712,13 @@ is omitted, only the group of the files
@end table
Some older scripts may still use @samp{.} in place of the @samp{:} separator.
[EMAIL PROTECTED] 1003.1-2001 (@pxref{Standards conformance}) does not allow that,
-but you may be able to work around the compatibility problems by setting
[EMAIL PROTECTED] in your environment.
-New scripts should avoid the use of @samp{.} because @sc{gnu} @command{chown}
-may fail if @var{owner} contains @samp{.} characters.
[EMAIL PROTECTED] 1003.1-2001 (@pxref{Standards conformance}) does not
+require support for that, but for backward compatibility @acronym{GNU}
[EMAIL PROTECTED] supports @samp{.} so long as no ambiguity results.
+New scripts should avoid the use of @samp{.} because it is not
+portable, and because it has undesirable results if the entire
[EMAIL PROTECTED]@samp{.}group} happens to identify a user whose name
+contains @samp{.}.
Warning: The @command{chown} command may clear the set-user-ID or
set-group-ID bits on some systems. The @command{chown} command is
Index: lib/userspec.c
===
RCS file: /home/meyering/coreutils/cu/lib/userspec.c,v
retrieving revision 1.39
diff -p -u -r1.39 userspec.c
--- lib/userspec.c 3 Nov 2003 14:57:41 - 1.39
+++ lib/userspec.c 23 Feb 2004 21:34:10 -
@@ -42,7 +42,6 @@
#endif
#include "userspec.h"
-#include "posixver.h"
#include "xalloc.h"
#include "xstrtol.h"
@@ -158,7 +157,6 @@ parse_user_spec (const char *spec_arg, u
struct group *grp;
char *g, *u, *separator;
char *groupname;
- int maybe_retry = 0;
char *dot = NULL;
error_msg = NULL;
@@ -171,17 +169,14 @@ parse_user_spec (const char *spec_arg, u
separator = strchr (spec, ':');
/* If there is no colon, then see if there's a `.'. */
- if (separator == NULL && posix2_version () < 200112)
+ if (separator == NULL)
{
dot = strchr (spec, '.');
/* If there's no colon but there is a `.', then first look up the
whole spec, in case it's an OWNER name that includes a dot.
If that fails, then we'll try again, but interpreting the `.'
-as a separator. */
- /* FIXME: accepting `.' as the separator is contrary to POSIX.
-someday we should drop support for this. */
- if (dot)
- maybe_retry = 1;
+as a separator. This is a compatible extension to POSIX, since
+the POSIX-required behavior is always tried first. */
}
retry:
@@ -311,10 +306,10 @@ parse_user_spec (const char *spec_arg, u
