[bug #28492] pr header lacks spaces around long file names
URL:
http://savannah.gnu.org/bugs/?28492
Summary: pr header lacks spaces around long file names
Project: GNU Core Utilities
Submitted by: None
Submitted on: Wed 06 Jan 2010 12:53:34 AM UTC
Category: None
Severity: 3 - Normal
Item Group: None
Status: None
Privacy: Public
Assigned to: None
Open/Closed: Open
Discussion Lock: Any
___
Details:
Printing a file whose path or name is longer than 48 chars
leaves the file name adjoining the date and/or page
elements of the header.
Names shorter than 48 chars are centered between spaces in
the available width.
Names longer than 48 chars lack padding spaces.
Names longer than 50 chars appear without spaces in a wider format header.
Repeat by:
base='123456789_123456789_123456789_123456789_1234567'
longs=$( echo ${base}{8,89,89_,89_1} )
for f in ${longs} ; do echo $f; done
pr ${longs} | cat -s
produces (modulo date formats and 'Page' translation):
2010-01-05 16:48 123456789_123456789_123456789_123456789_12345678 Page 1
2010-01-05 16:48123456789_123456789_123456789_123456789_123456789 Page 1
2010-01-05 16:48123456789_123456789_123456789_123456789_123456789_Page 1
2010-01-05 16:48123456789_123456789_123456789_123456789_123456789_1Page 1
POSIX appears to specify a printf format for pr headers equivalent to:
\n\n%s %s Page %d\n\n\n,
output of date, file, page number
which shows explicit spaces around the file name field.
I added statements to pr.c to coerce the spacing to be greater than 0,
but there may certainly be a more elegant approach that considers
the issues of headers for multiple columns.
--- pr.c2010-01-05 16:27:54.0 -0800
+++ pr.orig.c 2010-01-05 15:10:50.0 -0800
@@ -2403,9 +2403,6 @@
lhs_spaces = available_width 1;
rhs_spaces = available_width - lhs_spaces;
- lhs_spaces = lhs_spaces 0 ? lhs_spaces : 1;
- rhs_spaces = rhs_spaces 0 ? rhs_spaces : 1;
-
printf (\n\n%*.*s%s%*.*s%s%*.*s%s\n\n\n,
chars_per_margin, chars_per_margin, ,
date_text, lhs_spaces, lhs_spaces, ,
file_text, rhs_spaces, rhs_spaces, , page_text);
--
I am entitled to copyright of this bug report and patch, but
disclaim any such interest, and place them in the public domain,
with the intent that GNU/FSF may use them as they please.
best wishes,
Denis McKeon
___
Reply to this item at:
http://savannah.gnu.org/bugs/?28492
___
Message sent via/by Savannah
http://savannah.gnu.org/
[bug #28141] REQ: df and du, use -g to specify a 1gig block size
URL: http://savannah.gnu.org/bugs/?28141 Summary: REQ: df and du, use -g to specify a 1gig block size Project: GNU Core Utilities Submitted by: None Submitted on: Tue 01 Dec 2009 05:27:07 AM UTC Category: None Severity: 3 - Normal Item Group: None Status: None Privacy: Public Assigned to: None Open/Closed: Open Discussion Lock: Any ___ Details: The initial legwork has been done, from the mailing list of Fri, 5 Dec 2008. Other implementations use -g for 2's based 1GB block size, but coreutils apparently hasn't yet. ___ Reply to this item at: http://savannah.gnu.org/bugs/?28141 ___ Message sent via/by Savannah http://savannah.gnu.org/
[bug #27373] sort -h performs incorrectly if in utf8 locale.
URL: http://savannah.gnu.org/bugs/?27373 Summary: sort -h performs incorrectly if in utf8 locale. Project: GNU Core Utilities Submitted by: None Submitted on: Wed 02 Sep 2009 19:12:06 UTC Category: None Severity: 3 - Normal Item Group: None Status: None Privacy: Public Assigned to: None Open/Closed: Open Discussion Lock: Any ___ Details: Sample shell session: % echo $LC_ALL % echo $LC_COLLATE C % echo $LANG en_GB.utf8 % printf 1Mi\n1M | sort -h 1M 1Mi % export LANG=en_GB % printf 1Mi\n1M | sort -h sort: both SI and IEC prefixes present on units The relevant lines in my locale.gen are: en_GB.UTF-8 UTF-8 en_GB ISO-8859-1 However, this appears to occurs for any utf8 locale. Coreutils 7.5. Other tests fail in a similar manner, eg: % export LANG=en_GB.utf8 % printf K\nE\nM\nZ\n | ./sort -h E K M Z % export LANG=en_GB % printf K\nE\nM\nZ\n | ./sort -h K M E Z ___ Reply to this item at: http://savannah.gnu.org/bugs/?27373 ___ Message sent via/by Savannah http://savannah.gnu.org/
[bug #27146] cp --no-preserve=mode is counter-intuitive
URL: http://savannah.gnu.org/bugs/?27146 Summary: cp --no-preserve=mode is counter-intuitive Project: GNU Core Utilities Submitted by: None Submitted on: Чтв 30 Июл 2009 23:57:13 Category: None Severity: 3 - Normal Item Group: None Status: None Privacy: Public Assigned to: None Open/Closed: Open Discussion Lock: Any ___ Details: Currently cp option --no-preserve=mode behavior is counter-intuitive. What one would expect is that --no-preserve=mode should set mode to (0666 ~umask). See below for a shell transcript (coreutils 7.4). $ umask 0002 $ mkdir 1 $ cd 1 $ touch file1 $ ls -l total 0 -rw-rw-r-- 1 grib grib 0 Jul 19 21:48 file1 $ touch ../file2 $ chmod 0644 ../file2 $ ls -l ../file2 -rw-r--r-- 1 grib grib 0 Jul 19 21:48 ../file2 $ cp ../file2 . $ cp --no-preserve=all ../file2 ./file2-no-preserve-all $ ls -l total 0 -rw-rw-r-- 1 grib grib 0 Jul 19 21:48 file1 -rw-r--r-- 1 grib grib 0 Jul 19 21:50 file2 -rw-r--r-- 1 grib grib 0 Jul 19 21:50 file2-no-preserve-all There is a usecase for behavior I'm requesting (but I can't think of a usecase for current behavior). For example, a shared directory on a multiuser computer could set-group-id and owned by group users. If appropriate umask value (0002) is used, then all new files created in the shared directory would be owned by group users and group-writable. All new directories would be set-group-id. But files copied (with cp) to the shared directory won't get such treatment. It would be great if cp --no-preserve=mode set new file's mode like for plain new files (e. g. created with touch). Then cp --no-preserve=mode could be used to copy files to the shared directory. There is a couple of discussions on this topic, so I'm not alone in thinking that current behavior makes little sense. [1] http://lists.gnu.org/archive/html/bug-coreutils/2003-02/msg00033.html [2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=488024 [3] https://bugs.launchpad.net/ubuntu/+source/coreutils/+bug/144024 [4] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=402332 [5] http://karapuz.habrahabr.ru/blog/64868/ Excuse me for linking [5], it is in Russian, but it describes the options to create a shared directory on a Linux computer. Because cp doesn't support behavior I'm requesting, the author had to conclude that the only working solution is fam (monitoring new files and changing their permissions). ___ Reply to this item at: http://savannah.gnu.org/bugs/?27146 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
[bug #26512] ls: it's no longer possible to change the default (NORMAL) text color
URL: http://savannah.gnu.org/bugs/?26512 Summary: ls: it's no longer possible to change the default (NORMAL) text color Project: GNU Core Utilities Submitted by: None Submitted on: Sat 09 May 2009 04:38:02 PM UTC Category: None Severity: 3 - Normal Item Group: None Status: None Privacy: Public Assigned to: None Open/Closed: Open Discussion Lock: Any ___ Details: I prefer to have the -l output (rights, size, date etc) in an unintrusive bold black, which is no longer possible since commit 483297d5ddaea930d61da1da9c3f052cbd3c3810. - C_NORM was replaced by C_RESET. C_RESET doesn't sound like it should be used to change the default color, but to reset to the default terminal colors ([0m) - If I try to use C_RESET to change the default color, the first line of output is uncolored. ls tries not to output unnecessary escape sequences, so the color is not reset until the second line of output. A call to prep_non_filename_text() was removed in main(). If i re-add it everything looks fine again. ___ Reply to this item at: http://savannah.gnu.org/bugs/?26512 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
[bug #24934] confusing description of -c option
URL: http://savannah.gnu.org/bugs/?24934 Summary: confusing description of -c option Project: GNU Core Utilities Submitted by: None Submitted on: Tue 25 Nov 2008 11:38:19 PM UTC Category: None Severity: 3 - Normal Item Group: None Status: None Privacy: Public Assigned to: None Open/Closed: Open Discussion Lock: Any ___ Details: -c option's info documentation states: `-c BYTES' `--bytes=BYTES' Output the last BYTES bytes, instead of final lines. However, if N starts with a `+', start printing with the Nth byte from the start of each file, instead of from the end. Appending `b' multiplies BYTES by 512, `kB' by 1000, `K' by 1024, `MB' by 1000*1000, `M' by 1024*1024, `GB' by 1000*1000*1000, `GB' by 1024*1024*1024, and so on for `T', `P', `E', `Z', and `Y'. - it is not clear in here what N stands for? Maybe the author wanted to write BYTES instead of N? this is in file [coreutils.git] / doc / coreutils.texi ___ Reply to this item at: http://savannah.gnu.org/bugs/?24934 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
[bug #24935] incorrect information regardin size suffixes in -c option
URL: http://savannah.gnu.org/bugs/?24935 Summary: incorrect information regardin size suffixes in -c option Project: GNU Core Utilities Submitted by: None Submitted on: Tue 25 Nov 2008 11:46:55 PM UTC Category: None Severity: 3 - Normal Item Group: None Status: None Privacy: Public Assigned to: None Open/Closed: Open Discussion Lock: Any ___ Details: When describing -c option for tail command it says: `-c BYTES' `--bytes=BYTES' Output the last BYTES bytes, instead of final lines. However, if N starts with a `+', start printing with the Nth byte from the start of each file, instead of from the end. Appending `b' multiplies BYTES by 512, `kB' by 1000, `K' by 1024, `MB' by 1000*1000, `M' by 1024*1024, `GB' by 1000*1000*1000, `GB' by 1024*1024*1024, and so on for `T', `P', `E', `Z', and `Y'. in here 'GB' is equivalent to 1000*1000*1000 and 1024*1024*1024 which is impossible. this is in file [coreutils.git] / doc / coreutils.texi for tail documentation. ___ Reply to this item at: http://savannah.gnu.org/bugs/?24935 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
[bug #22505] id command fails to retrieve group info when nss_ldap is used
URL: http://savannah.gnu.org/bugs/?22505 Summary: id command fails to retrieve group info when nss_ldap is used Project: GNU Core Utilities Submitted by: None Submitted on: Thursday 03/06/08 at 18:39 UTC Category: None Severity: 3 - Normal Item Group: None Status: None Privacy: Public Assigned to: None Open/Closed: Open Discussion Lock: Any ___ Details: coreutils-6.10 By just installing nss_ldap and adding it to passwd, group and shadow in /etc/nsswitch.conf, the below happens: [EMAIL PROTECTED] ~]# id miura uid=501(miura) gid=502(miura)id: failed to get groups for user `miura': No such file or directory but: [EMAIL PROTECTED] ~]# getent passwd miura miura:x:501:502::/home/miura:/bin/bash [EMAIL PROTECTED] ~]# getent group miura miura:x:502: Notice that it is not even required to have an ldap server around, nor to configure /etc/ldap.conf. Downgrading to coreutils-6.9 makes the problem go away. I tracked it to a change in getugroups() and came up with the attached patch. ___ File Attachments: --- Date: Thursday 03/06/08 at 18:39 UTC Name: coreutils-6.10-groupfix.patch Size: 463B By: None http://savannah.gnu.org/bugs/download.php?file_id=15198 ___ Reply to this item at: http://savannah.gnu.org/bugs/?22505 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
[bug #22102] gcp fails to set default ACL on FreeBSD
URL: http://savannah.gnu.org/bugs/?22102 Summary: gcp fails to set default ACL on FreeBSD Project: GNU Core Utilities Submitted by: None Submitted on: Четверг 24.01.2008 at 06:53 UTC Category: None Severity: 3 - Normal Item Group: None Status: None Privacy: Public Assigned to: None Open/Closed: Open Discussion Lock: Any ___ Details: see http://www.freebsd.org/cgi/query-pr.cgi?pr=107229 for details. ___ Reply to this item at: http://savannah.gnu.org/bugs/?22102 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
[bug #22065] add uniq options: --check-fields and --separator
URL: http://savannah.gnu.org/bugs/?22065 Summary: add uniq options: --check-fields and --separator Project: GNU Core Utilities Submitted by: None Submitted on: Sunday 01/20/2008 at 19:53 UTC Category: None Severity: 3 - Normal Item Group: None Status: None Privacy: Public Assigned to: None Open/Closed: Open Discussion Lock: Any ___ Details: there was systems supporting --check-fields and --separator options of the uniq command, these options are very useful A patch adding the options is at: http://www.mail-archive.com/[EMAIL PROTECTED]/msg00128.html ___ Reply to this item at: http://savannah.gnu.org/bugs/?22065 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
[bug #22017] zic can generate files which crash the linux kernel
URL: http://savannah.gnu.org/bugs/?22017 Summary: zic can generate files which crash the linux kernel Project: GNU Core Utilities Submitted by: None Submitted on: Monday 14/01/08 at 09:18 UTC Category: None Severity: 3 - Normal Item Group: None Status: None Privacy: Public Assigned to: None Open/Closed: Open Discussion Lock: Any ___ Details: Hi there, Don't know if you'll want to fix, but we just had an issue where zic is generating files which cause a kernel panic in tzfile.c on Linux. Apparently the -01:00 is the offending time offset. cheers, Jamie ([EMAIL PROTECTED]) We compiled the following timezone file with zic and put the result in /etc/localtime. This makes tzfile.c fail with assertion that numtypes==1. # /etc/timezone (auto-generated) # Daylight savings time rules #Name YrStart YrEnd Type Month,Day,At,Offset Letter Rule DAYLIGHT 2000 max - Mar lastSun 02:00 01:00 - Rule DAYLIGHT 2000 max - Oct lastSun 03:00 -01:00 - # Timezone description #NAMEOffsetRule Name(/DaylightName) Zone localtime 00:00 DAYLIGHT GMT/BST ___ Reply to this item at: http://savannah.gnu.org/bugs/?22017 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
[bug #21999] rm fails completely on systems that don't have dirfd()
URL: http://savannah.gnu.org/bugs/?21999 Summary: rm fails completely on systems that don't have dirfd() Project: GNU Core Utilities Submitted by: None Submitted on: Thursday 01/10/08 at 16:04 UTC Category: None Severity: 3 - Normal Item Group: None Status: None Privacy: Public Assigned to: None Open/Closed: Open Discussion Lock: Any ___ Details: Due to the hard requirements in remove.c, rm completely fails to work on systems that don't implement dirfd(). ___ Reply to this item at: http://savannah.gnu.org/bugs/?21999 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
[bug #21758] yes problem with differents languages
URL: http://savannah.gnu.org/bugs/?21758 Summary: yes problem with differents languages Project: GNU Core Utilities Submitted by: None Submitted on: Sunday 12/09/07 at 06:01 UTC Category: None Severity: 3 - Normal Item Group: None Status: None Privacy: Public Assigned to: None Open/Closed: Open Discussion Lock: Any ___ Details: the utility yes has some troubles to handle differents languages , for example, in a GNU/linux system with locales setted to es_ES this line fails. # yes | mkfs.ext3 more options the line is in one script in this post : http://bbs.archlinux.org/viewtopic.php?t=20385 the problem ocurrs when I call these line, mkfs expects the character S to continue but yes generates the character Y ... ___ Reply to this item at: http://savannah.gnu.org/bugs/?21758 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
[bug #21163] join stops on numeric field if last number before double-digit is missing
URL: http://savannah.gnu.org/bugs/?21163 Summary: join stops on numeric field if last number before double-digit is missing Project: GNU Core Utilities Submitted by: None Submitted on: Wednesday 09/26/2007 at 18:52 UTC Category: None Severity: 3 - Normal Item Group: None Status: None Privacy: Public Assigned to: None Open/Closed: Open Discussion Lock: Any ___ Details: tested with coreutils-5.2.1-31.4 on RHEL4, coreutils-5.97-12.1.el5 on RHEL5 Looks likes join terminates when joining on a numeric field if the last n-digit number before the n+1-digit number is missing, e.g. I have 2 sorted files with numbers 1-2000 (and then some data in other fiels). If in one file the line with 999 some data is missing, the join output will stop at the line before. If instead the 998 some other data line is missing, join's output continues as expected. # cat a (sequence) 7 8 9 10 11 12 # cat b (sequence with 9 missing) 7 8 10 11 12 # cat c (sequence with 8 missing) 7 9 10 11 12 # join a b 7 8 --- where's the rest? # join a c 7 9 10 11 12 ___ Reply to this item at: http://savannah.gnu.org/bugs/?21163 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
[bug #20883] sort -u -n drops more lines than expected
URL: http://savannah.gnu.org/bugs/?20883 Summary: sort -u -n drops more lines than expected Project: GNU Core Utilities Submitted by: None Submitted on: Friday 08/24/2007 at 05:52 UTC Category: None Severity: 3 - Normal Item Group: None Status: None Privacy: Public Assigned to: None Open/Closed: Open Discussion Lock: Any ___ Details: Given the following example input: 1 3 2 1 1 1 3 1 1 2 1 1 sort -u gives the expected output: 1 1 1 2 1 3 2 1 3 1 But sort -n -u drops all lines that match the sort column: 1 3 2 1 3 1 Or compare sort -n -u -k2: 2 1 1 2 1 3 It's not clear from the info page that this is the correct behavior, but I would expect sort -n -u to do the same as sort -n | uniq, or for this omitting equal keys (instead of equal lines) to be more explicit in the documentation. ___ Reply to this item at: http://savannah.gnu.org/bugs/?20883 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
[bug #20784] mv should be able to change filename case on case-insensitive file systems
URL: http://savannah.gnu.org/bugs/?20784 Summary: mv should be able to change filename case on case-insensitive file systems Project: GNU Core Utilities Submitted by: None Submitted on: Tuesday 08/14/2007 at 16:29 UTC Category: None Severity: 3 - Normal Item Group: None Status: None Privacy: Public Assigned to: None Open/Closed: Open Discussion Lock: Any ___ Details: On Cygwin using non-managed mounts (and presumably other operating systems when using a case-insensitive file system), it's not possible to use Coreutils mv to change the case of a filename; mv reports that they are the same file. The underlying Cygwin rename() function does support this functionality. Also see the thread on the Cygwin mailing list starting at http://cygwin.com/ml/cygwin/2007-08/msg00335.html. Example: $ touch foo $ mv foo Foo mv: `foo' and `Foo' are the same file $ mv --version mv (GNU coreutils) 6.9 Copyright (C) 2007 Free Software Foundation, Inc. This is free software. You may redistribute copies of it under the terms of the GNU General Public License http://www.gnu.org/licenses/gpl.html. There is NO WARRANTY, to the extent permitted by law. Written by Mike Parker, David MacKenzie, and Jim Meyering. $ uname -a CYGWIN_NT-5.1 jonathan-lmi 1.5.24(0.156/4/2) 2007-01-31 10:57 i686 Cygwin $ perl -e 'rename foo, Foo or die($!)' $ ls [Ff]oo Foo ___ Reply to this item at: http://savannah.gnu.org/bugs/?20784 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
[bug #19649] chown major behaviour change
URL: http://savannah.gnu.org/bugs/?19649 Summary: chown major behaviour change Project: GNU Core Utilities Submitted by: None Submitted on: Friday 04/20/2007 at 22:35 UTC Category: None Severity: 3 - Normal Item Group: None Status: None Privacy: Public Assigned to: None Open/Closed: Open Discussion Lock: Any ___ Details: I don't see any place to set who this is from so for future reference [EMAIL PROTECTED] In atleast 5.97 chown now works on the target of a symlink rather than a symlink. This has NEVER been the case with any version of chown. This leads to unexpected results on GNU systems as even on GNU systems chown hasn't functioned like this. Bug was discovered in Debian coreutils 5.97-5.3, marked and reported as such by myself. ___ Reply to this item at: http://savannah.gnu.org/bugs/?19649 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
[patch #5662] Add version sorting to sort (like ls -v)
URL: http://savannah.gnu.org/patch/?5662 Summary: Add version sorting to sort (like ls -v) Project: GNU Core Utilities Submitted by: None Submitted on: Sonntag 07.01.2007 um 00:10 UTC Category: None Priority: 5 - Normal Status: None Privacy: Public Assigned to: None Originator Email: [EMAIL PROTECTED] Open/Closed: Open Discussion Lock: Any ___ Details: This patch adds version number sorting (i.e. 1.2.3 1.2.12) to sort. It was taken from an old email from Ian Dall (http://lists.gnu.org/archive/html/bug-coreutils/2005-11/msg00018.html) and adapted to coreutils 6.7. ___ File Attachments: --- Date: Sonntag 07.01.2007 um 00:10 UTC Name: versionsort.patch Size: 4kB By: None http://savannah.gnu.org/patch/download.php?file_id=11688 ___ Reply to this item at: http://savannah.gnu.org/patch/?5662 ___ Nachricht geschickt von/durch Savannah http://savannah.gnu.org/ ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
[bug #17956] sort manual should mention that fields are numbered starting from 1
URL: http://savannah.gnu.org/bugs/?17956 Summary: sort manual should mention that fields are numbered starting from 1 Project: GNU Core Utilities Submitted by: None Submitted on: Monday 10/09/2006 at 18:33 UTC Category: None Severity: 3 - Normal Item Group: None Status: None Privacy: Public Assigned to: None Open/Closed: Open ___ Details: sort (GNU coreutils) 5.97 The manual I'm looking at says POS is F[.C][OPTS], where F is the field number and C the character position in the field. However, it'd be nice if it said the first field in number 1. ___ Reply to this item at: http://savannah.gnu.org/bugs/?17956 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
[patch #5408] test script error
URL: http://savannah.gnu.org/patch/?5408 Summary: test script error Project: GNU Core Utilities Submitted by: None Submitted on: Wednesday 09/20/2006 at 02:08 UTC Category: None Priority: 5 - Normal Status: None Privacy: Public Assigned to: None Originator Email: [EMAIL PROTECTED] Open/Closed: Open ___ Details: test script coreutils-5.97/tests/sort/sort-mb-tests fails indicating the input mb1.I and mb22.I input files are missing when coreutils is built outside the source directory. This patch adds the srcdir variable to the path. ___ Carbon-Copy List: CC Address | Comment +- Available only the item webpage | Originator Email ___ File Attachments: --- Date: Wednesday 09/20/2006 at 02:08 UTC Name: coreutils-5.97-sort-mb-tests-1.patch Size: 1.17KB By: None patch file http://savannah.gnu.org/patch/download.php?file_id=10808 ___ Reply to this item at: http://savannah.gnu.org/patch/?5408 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
[bug #17427] CVE-2005-1039, chmod race in mkdir, mkfifo, mknod
URL: http://savannah.gnu.org/bugs/?func=detailitemitem_id=17427 Summary: CVE-2005-1039, chmod race in mkdir, mkfifo, mknod Project: GNU Core Utilities Submitted by: None Submitted on: Monday 08/14/2006 at 06:29 UTC Category: None Severity: 3 - Normal Item Group: None Status: None Privacy: Public Assigned to: None Open/Closed: Open ___ Details: Hello! Attached is a patch to fix the race in mkdir, mkfifo, and mknod, as seen in CVE-2005-1039 when running with --mode. It is the same as the patch sent to Debian, where other details and discussion can be found: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=304556 (sorry for the anonymous bug, Savanah doesn't appear to be delivering email to me today... Please CC [EMAIL PROTECTED]) Thanks! ___ File Attachments: --- Date: Monday 08/14/2006 at 06:29 UTC Name: coreutils-chmod-race.patch Size: 3.23KB By: None PATCH: solve mkdir/mkfifo/mknod --mode chmod race http://savannah.gnu.org/bugs/download.php?file_id=10533 ___ Reply to this item at: http://savannah.gnu.org/bugs/?func=detailitemitem_id=17427 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
[bug #16913] sleep fails to detect overflow on amd64 / linux 2.6
URL: http://savannah.gnu.org/bugs/?func=detailitemitem_id=16913 Summary: sleep fails to detect overflow on amd64 / linux 2.6 Project: GNU Core Utilities Submitted by: None Submitted on: Thursday 06/22/2006 at 14:54 UTC Category: None Severity: 3 - Normal Item Group: None Status: None Privacy: Public Assigned to: None Open/Closed: Open ___ Details: sleep 100 - returns immediately with exit code 0 sleep 10 - sleeps sleep 1000 - sleeps Not really sane amounts of seconds to sleep but on the other hand there is some code in xnanosleep.c to handle overflow conditions. More details about the underlying bug in nanosleep() in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=374983 ___ Reply to this item at: http://savannah.gnu.org/bugs/?func=detailitemitem_id=16913 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
[patch #4978] hexadecimal support for dd
URL: http://savannah.gnu.org/patch/?func=detailitemitem_id=4978 Summary: hexadecimal support for dd Project: GNU Core Utilities Submitted by: None Submitted on: Fri 03/17/06 at 13:11 Category: None Priority: 5 - Normal Status: None Privacy: Public Assigned to: None Originator Email: [EMAIL PROTECTED] Open/Closed: Open ___ Details: This patch adds support for parsing hexadecimal numbers to dd. So instead of writing: dd if=/dev/zero of=test bs=`perl -e 'printf(%d,0xe);'` count=1 you can just write dd if=/dev/zero of=test bs=0xe count=1 It's a feature I use everyday and I'd be really glad if you could take it into the official release of GNU coreutils. ___ Carbon-Copy List: CC Address | Comment +- stepan --AT-- coresystems --DOT-- de | Originator Email ___ File Attachments: --- Date: Fri 03/17/06 at 13:11 Name: dd.diff Size: 667B By: None Patch to add hexadecimal support to dd, against coreutils CVS from 2006-03-17 http://savannah.gnu.org/patch/download.php?item_id=4978item_file_id=6048 ___ Reply to this item at: http://savannah.gnu.org/patch/?func=detailitemitem_id=4978 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
[patch #4774] Fix when piping and --color=always. This patch calls restore_default_color() after the last file and before the last
URL: http://savannah.gnu.org/patch/?func=detailitemitem_id=4774 Summary: Fix when piping and --color=always. This patch calls restore_default_color() after the last file and before the last Project: GNU Core Utilities Submitted by: None Submitted on: Sun 01/08/06 at 18:08 Category: None Priority: 5 - Normal Status: None Privacy: Public Assigned to: None Originator Email: [EMAIL PROTECTED] Open/Closed: Open ___ Details: ___ Carbon-Copy List: CC Address | Comment +- bjk --AT-- arbornet --DOT-- org | Originator Email ___ Reply to this item at: http://savannah.gnu.org/patch/?func=detailitemitem_id=4774 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
[patch #4775] Fix for --color=always and piping.
URL: http://savannah.gnu.org/patch/?func=detailitemitem_id=4775 Summary: Fix for --color=always and piping. Project: GNU Core Utilities Submitted by: None Submitted on: Sun 01/08/06 at 18:14 Category: None Priority: 5 - Normal Status: None Privacy: Public Assigned to: None Originator Email: [EMAIL PROTECTED] Open/Closed: Open ___ Details: When piping to a pager 'less' with the --color=always switch, an extra line is added. This patch calls restore_default_color() after the last file and before the last newline character. Works for me and I don't think it breaks anything. ___ Carbon-Copy List: CC Address | Comment +- bjk --AT-- arbornet --DOT-- org | Originator Email ___ File Attachments: --- Date: Sun 01/08/06 at 18:14 Name: x Size: 1.66KB By: None Fix for --color=always and piping. http://savannah.gnu.org/patch/download.php?item_id=4775item_file_id=5727 ___ Reply to this item at: http://savannah.gnu.org/patch/?func=detailitemitem_id=4775 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
[patch #4600] Addition of dups file utility to GNU Core Utilities
Follow-up Comment #3, patch #4600 (project coreutils): Sorry, there was a serious problem with the handling of symbolic links when hard linking files together. It might be fixed now, though my test filesystem has been destroyed by this utility when trying to link all duplicates. Also, all appropriate text strings have been localized with _() for use with gettext. ___ Additional Item Attachment: File name: mycmp.cSize:8 KB dups utility with bug fix http://savannah.gnu.org/patch/download.php?item_id=4600item_file_id=5444 ___ Reply to this item at: http://savannah.gnu.org/patch/?func=detailitemitem_id=4600 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
[patch #4600] Addition of dups file utility to GNU Core Utilities
URL: http://savannah.gnu.org/patch/?func=detailitemitem_id=4600 Summary: Addition of dups file utility to GNU Core Utilities Project: GNU Core Utilities Submitted by: None Submitted on: Sat 11/05/05 at 06:04 Category: None Priority: 3 - Low Status: None Privacy: Public Assigned to: None Originator Email: [EMAIL PROTECTED] Open/Closed: Open ___ Details: Attached is a command line file utility for GNU Linux that accurately displays all duplicate files listed on the command line, with an option to hard link them. It was written by me, George Gesslein II, in the spirit of GNU Linux. ___ Carbon-Copy List: CC Address | Comment +- gesslein --AT-- panix --DOT-- com | Originator Email ___ File Attachments: --- Date: Sat 11/05/05 at 06:04 Name: mycmp.c Size: 7.42KB By: None quot;dupsquot; file utilitity C source code http://savannah.gnu.org/patch/download.php?item_id=4600item_file_id=5439 ___ Reply to this item at: http://savannah.gnu.org/patch/?func=detailitemitem_id=4600 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
[patch #4600] Addition of dups file utility to GNU Core Utilities
Follow-up Comment #1, patch #4600 (project coreutils): Just some constructive criticism: - doesn't accept long option names - doesn't accept --help and --version that every GNU util should recognise - no ChangeLog entries included - no texinfo documentation or help2man output - coding style does not match the GNU coding standards - messages should be localized with _() for use with gettext - comparing files one byte at a time with getc() is extremely inefficient - it should read each file at most once and store a hash, otherwise performance is going to be horrendous (O(N^2)) when the number of files and/or the file size is large - if the link() fails (such as two files on different volumes) it leaves things in a bad state because it's already committed to unlinking one of the files. This is a very bad thing since it's now caused permanent data loss. It should at the least check if they are on the same volume first before continuing, and additionally it should rename one until the link() succeeds, so that it rename it back to its original name if the link fails. ___ Reply to this item at: http://savannah.gnu.org/patch/?func=detailitemitem_id=4600 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
[patch #4600] Addition of dups file utility to GNU Core Utilities
Follow-up Comment #2, patch #4600 (project coreutils): Thank you very much for your detailed evalution of the dups utility I submitted. It is obviously not ready for addition to GNU software, but I did fix two things you mentioned. It now has a changelog and the devices are compared before hard linking. Attached, if anyone is interested. ___ Additional Item Attachment: File name: mycmp.cSize:7 KB updated dups utility http://savannah.gnu.org/patch/download.php?item_id=4600item_file_id=5443 ___ Reply to this item at: http://savannah.gnu.org/patch/?func=detailitemitem_id=4600 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
