coreutils-7.5 soon?

[Jim Meyering]

There have been enough interesting changes that
it seems worthwhile to make a release soon.
As I see it, the most notable are the new program, stdbuf,
and tail's addition of inotify support.

Here are the NEWS entries:
-
** Bug fixes

  truncate -s failed to skip all whitespace in the option argument in
  some locales.

  sort now correctly ignores fields whose ending position is specified
  before the start position. Previously in numeric mode the remaining
  part of the line after the start position was used as the sort key.
  [This bug appears to have been present in "the beginning".]

** New programs

  stdbuf: A new program to run a command with modified stdio buffering
  for its standard streams.

** Changes in behavior

  ls --color: files with multiple hard links are no longer colored differently
  by default. That can be enabled by changing the LS_COLORS environment
  variable. You can control that using the MULTIHARDLINK dircolors input
  variable which corresponds to the 'mh' LS_COLORS item. Note these variables
  were renamed from 'HARDLINK' and 'hl' which were available since
  coreutils-7.1 when this feature was introduced.

** New features

  chroot now accepts the options --userspec and --groups.

  sort accepts a new option, --human-numeric-sort (-h): sort numbers
  while honoring human readable suffixes like KiB and MB etc.

  tail uses inotify when possible.
-

If anyone has pending patches or unaddressed issues,
please report them to this list.


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

Re: BUG in tr when lowercase letters 'o', 'p' & 'e' file names in the same directory

[Gaafer Goreish]

Thanks for the clarification. My fault, I totally missed the shell
expansion.

On Fri, Jun 26, 2009 at 1:01 PM, Bob Proulx  wrote:

> Gaafer Goreish wrote:
> > I discovered that if there is a file with the one lowercase letter name
> 'o'
> > or 'p'  or 'e' in the same directory where the tr command is executed it
> > generates an error or unexpected result.
>
> Thank you for your report.  However this is not a bug in tr.  It is
> insufficient quoting of shell arguments.
>
> > Following is the the simple commands used to re-produce this bug
> >
> > r...@mme1-f101-1:# echo hello | tr [:lower:] [:upper:]
>
> That has insufficiently quoted arguments.  The shell will expand
> them.  You must quote them.  Try this:
>
>  echo hello | tr "[:lower:]" "[:upper:]"
>
> Your question is a variation on the theme behind this FAQ:
>
>  http://www.gnu.org/software/coreutils/faq/#expr-2-_002a-3-does-not-work
>
> Bob
>
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

sort +k

[Wayne Power]

Greetings,

Imagine my surprise, piping the output of some command to sort +1 and  
seeing ...


sort: open failed: +1: No such file or directory

WTF?  sort -k?  Is there any good reason you decided to break every  
every shell script I've written in the last 30 years that uses sort?


Is this a special version for Apple to piss off old unix folks, or did  
you break this command for everybody?


--wmp



___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

Re: sort +k

[Eric Blake]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

According to Wayne Power on 6/27/2009 11:52 AM:
> sort: open failed: +1: No such file or directory
> 
> WTF?  sort -k?  Is there any good reason you decided to break every
> every shell script I've written in the last 30 years that uses sort?

Yes, and that reason is POSIX.  Coreutils did not make this change
lightly; the standards committees did and coreutils is downstream from the
standards.

That said, the coreutils documentation mentions this in the NEWS:

|   A few usages still have behavior that depends on which POSIX standard is
|   being conformed to, and portable applications should beware these
|   problematic usages.  These include:
|
| Problematic   Standard-conforming replacement, depending on
|usagewhether you prefer the behavior of:
|   POSIX 1003.2-1992POSIX 1003.1-2001
| sort +4   sort -k 5sort ./+4
| tail +4   tail -n +4   tail ./+4
| tail - f  tail f   [see (*) below]
| tail -c 4 tail -c 10 ./4   tail -c4
| touch 12312359 f  touch -t 12312359 f  touch ./12312359 f
| uniq +4   uniq -s 4uniq ./+4
|
| (*) "tail - f" does not conform to POSIX 1003.1-2001; to read
| standard input and then "f", use the command "tail -- - f".
|
|   These changes are in response to decisions taken in the January 2005
|   Austin Group standardization meeting.  For more details, please see
|   "Utility Syntax Guidelines" in the Minutes of the January 2005
|   Meeting .

You may also find it informative to read: 'info coreutils standards'.

> Is this a special version for Apple to piss off old unix folks, or did
> you break this command for everybody?

Because of POSIX, using 'sort +1' is inherently non-portable for everyone.

- --
Don't work too hard, make some time for fun as well!

Eric Blake e...@byu.net
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkpGXyEACgkQ84KuGfSFAYCzZgCguuOl+LodRRuKWQG/X4Asc98A
W28AnAkgqoLxvBL+Y8ng3Dz7gJbvk2CQ
=pc1x
-END PGP SIGNATURE-


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

feature request: -0 option for tr

[Craig Sanders]

please add a -0 option to tr, which is equivalent to
running:

tr '\n' '\000'

this is a useful command for converting \n-terminated input lines to
null-terminated strings suitable for feeding into 'xargs -0' as many
programs can not generate null-terminated ouput by themselves.


it would also be useful if tr did this automatically if invoked
as 'print0'.

craig

-- 
craig sanders 


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

Savannah report new bug link not obvious

[jidanni]

Logged in to https://savannah.gnu.org/
the user cannot find the link to "report a new bug".


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

document or fix dangers of sort -u + any other option

[jidanni]

Please fix the third command,

$ echo -e 'a1\nb2\nc3\nb2'|sort -n|sort -u
a1
b2
c3
$ echo -e 'a1\nb2\nc3\nb2'|sort -u|sort -n
a1
b2
c3
$ echo -e 'a1\nb2\nc3\nb2'|sort -nu
a1

or warn right there on the man page.

Sure, you say

   -u, --unique
  with -c, check for strict ordering; without -c, output
  only the first of an equal run

but still warn that the above will happen if one tries to combine
anything with -u.


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

Re: Savannah report new bug link not obvious

[Giuseppe Scrivano]

Is https://savannah.gnu.org/bugs/?func=additem&group=coreutils the page
you are looking for?

Giuseppe


jida...@jidanni.org writes:

> Logged in to https://savannah.gnu.org/
> the user cannot find the link to "report a new bug".


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

Re: Savannah report new bug link not obvious

[jidanni]

> "GS" == Giuseppe Scrivano  writes:
GS> jida...@jidanni.org writes:
>> Logged in to https://savannah.gnu.org/
>> the user cannot find the link to "report a new bug".
GS> Is https://savannah.gnu.org/bugs/?func=additem&group=coreutils the page
GS> you are looking for?
Ah, indeed it is.

OK, all I know is when I browse https://bugzilla.wikimedia.org/ (logged
in), there is a link "Enter a new bug" in the side panel.

What you Savannah fellows need to do is add a similar link to your side
panel.

Yes, bugzilla then asks "First, you must pick a product on which to
enter a bug.". So Savannah could do the same.


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

Re: Savannah report new bug link not obvious

[Eric Blake]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

According to jida...@jidanni.org on 6/27/2009 8:42 PM:
> Logged in to https://savannah.gnu.org/
> the user cannot find the link to "report a new bug".

Actually, for coreutils, we are just as happy with email bug reports (as
requested by the --help output of each program).  We tend to get so few
reports via savannah that we haven't really been bothered with trying to
make it easier.

- --
Don't work too hard, make some time for fun as well!

Eric Blake e...@byu.net
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkpG4JwACgkQ84KuGfSFAYD2sQCgg5rUcafoWIs7slTuSWoA7Xj5
AIgAoJ08neBuVAzVSAgo6MJ78AGSYuPv
=guTK
-END PGP SIGNATURE-


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

Re: feature request: -0 option for tr

[Eric Blake]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

According to Craig Sanders on 6/27/2009 7:20 PM:
> please add a -0 option to tr, which is equivalent to
> running:
> 
> tr '\n' '\000'

Why should we burn an option letter, when it is not that much more typing
to get what you wanted anyways?  An option letter makes the most sense
only when there is no other easy way to do the same task.

> this is a useful command for converting \n-terminated input lines to
> null-terminated strings suitable for feeding into 'xargs -0' as many
> programs can not generate null-terminated ouput by themselves.

This proposal doesn't really buy you anything.  Either the output is
already nul-terminated (in which case you don't need an extra tr process
in the mix), or it is newline terminated (in which case you should just
use plain xargs instead of 'xargs -0', and you already have to worry about
the potential for filenames with embedded newlines).  In short, throwing
tr in the mix just to convert newlines to nul bytes does not buy you any
security.

> it would also be useful if tr did this automatically if invoked
> as 'print0'.

GNU Coding Standards discourage programs that change their behavior based
on how argv[0] was spelled.  But there is no need to change tr, when you
can easily do this yourself:

$ cat <<\EOF >>/usr/local/bin/print0
#!/bin/sh
exec tr '\n' '\0'
EOF
$ chmod +x /usr/local/bin/print0

- --
Don't work too hard, make some time for fun as well!

Eric Blake e...@byu.net
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkpG4tgACgkQ84KuGfSFAYCqigCfe0uj9ulITy+i+kcVxwxah2f3
wUMAnRRvagxC43sko/y3Lo4izEMIYxdf
=BuUY
-END PGP SIGNATURE-


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

Re: Savannah report new bug link not obvious

[jidanni]

EB> Actually, for coreutils, we are just as happy with email bug reports (as

Well do leave a path for those of us who have been toiled-trained by
e.g., Bugzilla that the only real report is a browser generated report,
and can't find the "Pavlov's dogs lever",
http://en.wikipedia.org/wiki/Classical_conditioning
(Do mention along the way that email reports are also fine.)


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

sort and multiple -k options

[Mike Frysinger]

i cant figure out if i'm doing something stupid here or sort is doing 
something wrong ...

consider this (reduced) input:
/path/._cfg_asciidoc.conf%/path/%._cfg_%asciidoc.conf
/path/._cfg_docbook.conf%/path/%._cfg_%docbook.conf
/path/._cfg0001_asciidoc.conf%/path/%._cfg0001_%asciidoc.conf

i want to have the files sorted by (1) path then (2) file name then (3) cfg 
order.  so i use this:
sort -t% -k2 -k4 -k3

but i keep getting the same output as my input:
$ cat f | sort -t% -k2 -k4 -k3
/path/._cfg_asciidoc.conf%/path/%._cfg_%asciidoc.conf
/path/._cfg_docbook.conf%/path/%._cfg_%docbook.conf
/path/._cfg0001_asciidoc.conf%/path/%._cfg0001_%asciidoc.conf

even if i try just (1) and (2), it still doesnt sort:
$ cat f | sort -t% -k2 -k4
/path/._cfg_asciidoc.conf%/path/%._cfg_%asciidoc.conf
/path/._cfg_docbook.conf%/path/%._cfg_%docbook.conf
/path/._cfg0001_asciidoc.conf%/path/%._cfg0001_%asciidoc.conf

if however i cut out field 3, then it seems to sort properly:
$ cat f | cut -d% -f1,2,4 | sort -t% -k2 -k3
/path/._cfg_asciidoc.conf%/path/%asciidoc.conf
/path/._cfg0001_asciidoc.conf%/path/%asciidoc.conf
/path/._cfg_docbook.conf%/path/%docbook.conf

using coreutils 7.4 here, and locale doesnt seem to matter (forcing to C gets 
same result).  there are no custom patches to the source in Gentoo.
-mike



___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils