Re: Bug#469525: coreutils: [wc] RFC: Add option --no-filename

[Pádraig Brady]

Jari Aalto wrote:
> Package: coreutils
> Version: 6.10-3
> Severity: wishlist
> 
> 
> Description:
> 
>   $ wc -l README
>   200 README
> 
> This is fine for interactive use, but not convenient in shell scripts,

Options are bad because of the extra complexity presented to users.
Currently wc only suppresses the "total" if only one file is passed.
I wonder could we go one step further and suppress the filename
also like grep does when passed a single file?
Note existing scripts that do the following would continue to work:

lines=`wc -l file | cut -d ' ' -f1`

It's probably safer though to not change the current operation,
considering that the functionality can be satisfied using the above,
or the following:

lines=`wc -l http://lists.gnu.org/mailman/listinfo/bug-coreutils

Re: Bug#469525: coreutils: [wc] RFC: Add option --no-filename

[Andreas Schwab]

Pádraig Brady <[EMAIL PROTECTED]> writes:

> I wonder could we go one step further and suppress the filename
> also like grep does when passed a single file?

That would require adding an option to be comptible with POSIX.

Andreas.

-- 
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."


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

New colorls.sh doesn't work with DIR_COLORS.xterm

[Dr. J. Kubiak]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


Hello,

some problem with coreutils-6.9-13. The new shellscript
/etc/profile.d/colorls.sh now ignores the color settings in file
/etc/DIR_COLORS.xterm.

But reinstalling the old much smaller shellscript colorls.sh works fine
with /etc/DIR_COLORS.xterm:

- - 8< -
# color-ls initialization

alias ll='ls -l' 2>/dev/null
alias l.='ls -d .*' 2>/dev/null

COLORS=/etc/DIR_COLORS
[ -e "/etc/DIR_COLORS.$TERM" ] && COLORS="/etc/DIR_COLORS.$TERM"
[ -e "$HOME/.dircolors" ] && COLORS="$HOME/.dircolors"
[ -e "$HOME/.dircolors.$TERM" ] && COLORS="$HOME/.dircolors.$TERM"
[ -e "$HOME/.dir_colors" ] && COLORS="$HOME/.dir_colors"
[ -e "$HOME/.dir_colors.$TERM" ] && COLORS="$HOME/.dir_colors.$TERM"
[ -e "$COLORS" ] || return

eval `dircolors --sh "$COLORS"`
[ -z "$LS_COLORS" ] && return

if ! egrep -qi "^COLOR.*none" $COLORS >/dev/null 2>/dev/null ; then
alias ll='ls -l --color=tty' 2>/dev/null
alias l.='ls -d .* --color=tty' 2>/dev/null
alias ls='ls --color=tty' 2>/dev/null
fi

- - 8< -


- -cu at the bitstream,   Dr. Jürgen Kubiak



- --
To verify signature get the Public Key at
http://www.tfh-berlin.de/~kubiak/kubiak_at_tfh-berlin.de.asc

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (GNU/Linux)

iD8DBQFHz8AcjNKDU5n5PCARAus4AKC6H7EXqh58zj+38aD4lFolexHTzACePnvZ
SRIN5oUHBFtVEpH/BWbF9FA=
=VqP5
-END PGP SIGNATURE-



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

utimens.h:2: error: conflicting types for 'futimens'

[totido :)]

After doing:

tar xfvz coreutils-6.9.tar.gz
cd coreutils-6.9/
./configure
make

the result is:

gcc -std=gnu99  -I.  -g -O2 -MT utimecmp.o -MD -MP -MF
.deps/utimecmp.Tpo -c -o utimecmp.o utimecmp.c
In file included from utimecmp.c:33:
utimens.h:2: error: conflicting types for 'futimens'

need more details? just ask


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

Re: utimens.h:2: error: conflicting types for 'futimens'

[Eric Blake]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

According to totido :) on 3/6/2008 5:46 AM:
| gcc -std=gnu99  -I.  -g -O2 -MT utimecmp.o -MD -MP -MF
| .deps/utimecmp.Tpo -c -o utimecmp.o utimecmp.c
| In file included from utimecmp.c:33:
| utimens.h:2: error: conflicting types for 'futimens'

Thanks for the report.  However, this was previously reported, and fixed
for coreutils 6.10, which is the latest stable version.

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

Eric Blake [EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHz++084KuGfSFAYARAhhnAKC74pLYYoyNIwnB6OeLbEe9St/C6ACg04Mh
DwLjESr2edxJKV93VtqvEpw=
=RwZa
-END PGP SIGNATURE-


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

Re: New colorls.sh doesn't work with DIR_COLORS.xterm

[Eric Blake]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

According to Dr. J. Kubiak on 3/6/2008 2:57 AM:
| some problem with coreutils-6.9-13. The new shellscript
| /etc/profile.d/colorls.sh now ignores the color settings in file
| /etc/DIR_COLORS.xterm.

Thanks for the report.  The latest stable version of coreutils is 6.10,
but coreutils does not provide colorls.sh, so you will need to forward
this report on to the provider of the script.

|
| eval `dircolors --sh "$COLORS"`

At any rate, this is a bug in the script.  The output should be properly
quoted:

eval "`dircolors --sh "$COLORS"`"

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

Eric Blake [EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHz+9o84KuGfSFAYARAhy9AJ9+553F66iFJ0mhBvgWOojmuk8PKACgighZ
lhpve4pr1VhCzJX1fYjqR0s=
=g7AQ
-END PGP SIGNATURE-


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

Feature Request: du --dir-with-slash

[Thomas Guettler]

Hi,

I use "du -ax / | sort -rn > /var/tmp/du-`date --iso`" to get the sorted
total size of all
files and directories.

Unfortunately you can't see a difference between a directory and a file
in the output. It would be nice if the directories would be added by a
slash.

Example:

old:
307704984   /
291330280   /home

new:
307704984   /
291330280   /home/

This way you can see if a line is a directory or not. This is even more
important
if you want to use the output for a script.

I suggest 'du --dir-with-slash' or 'du --trailing-slash' as parameter.

 Thomas

-- 
Thomas Guettler, http://www.thomas-guettler.de/
E-Mail: guettli (*) thomas-guettler + de



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

Re: Feature Request: du --dir-with-slash

[Jim Meyering]

Thomas Guettler <[EMAIL PROTECTED]> wrote:
> I use "du -ax / | sort -rn > /var/tmp/du-`date --iso`" to get the sorted
> total size of all
> files and directories.
>
> Unfortunately you can't see a difference between a directory and a file
> in the output. It would be nice if the directories would be added by a
> slash.
>
> Example:
>
> old:
> 307704984   /
> 291330280   /home
>
> new:
> 307704984   /
> 291330280   /home/
>
> This way you can see if a line is a directory or not. This is even more
> important
> if you want to use the output for a script.
>
> I suggest 'du --dir-with-slash' or 'du --trailing-slash' as parameter.

Thanks for the suggestion, but rather than adding an option,
how about wrapping a small script around du?
Use du's --zero (-0) option to make it work even with
names containing newline:

mkdir j && cd j && touch a b && mkdir d d2 &&
  du -a -0|perl -0 -ne \
'chomp; /^\d+\t(.*)/ and print "$_", (-d $1 ? "/" : ""), "\n"'

0   ./d2/
0   ./d/
0   ./b
0   ./a
0   ./

Of course, that will convert "/" to "//", but it's just a one-liner, too.
I'm sure you can adapt.


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

Re: Feature Request: du --dir-with-slash

[Pádraig Brady]

Thomas Guettler wrote:
> Hi,
> 
> I use "du -ax / | sort -rn > /var/tmp/du-`date --iso`" to get the sorted
> 
> Unfortunately you can't see a difference between a directory and a file
> in the output. It would be nice if the directories would be added by a
> slash.
> 
> This way you can see if a line is a directory or not. This is even more
> important
> if you want to use the output for a script.
> 
> I suggest 'du --dir-with-slash' or 'du --trailing-slash' as parameter.

If we were going to do that we should do it unconditionally.
I can't see how it would break existing scripts.
POSIX can't disallow that can it!

As an alternative try:

find / -xdev -printf "%k\t%p%y\n" |
sed 's/d$/\//;t; s/.$//;' |
LC_ALL=C sort -rn -k1,1

Pádraig.


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

undocumented nl behavior with -bt

[paul]

re:  nl (GNU coreutils) 6.9  Fedora 7 Linux

Good morning--

I have not used nl for a long time but just found a use for it.  It does the 
numbering that I want but it does more than that.  The file I am numbering is 
many lines of text with interspersed blank lines.  (It is data exported from 
an accounting system that is input to a perl program.)  The blank lines would 
be more accurately be called empty or null lines as they do not contain any 
white space characters, simply consecutive new line characters in the data 
file.  The perl program recognizes these empty lines and handles them as 
required by its specifications.

After numbering the lines using:  nl  -s, -w1 -nln oldfile > newfile
the perl program now chokes on the once empty lines in newfile.  Upon 
examination I find that the empty lines are no longer empty.  They now 
contain a number of space characters equal to the setting of the -w option.  
They cannot be suppressed entirely by specifying -w0 as that is reported as 
an invalid value, which is reasonable considering the purpose of -w.

The man page (and info page) states that the t style is to "number only 
nonempty lines".  This it does but it also changes the nonempty lines into 
lines containing spaces.  I feel that this latter behavior should not be 
included in nl.

Since nl has been around for many years there may be some users taking 
advantage of this undocumented behavior.  Therefore I propose that an option 
be added to allow the user to suppress this historical behavior.  In other 
words the option would direct nl to leave empty lines empty.  I suggest the 
option be "-e".  An alternative would be to specify this with a new body 
numbering style instead of an option.

Thank you for your consideration of this matter.

paul

ps--Mac OS X version of nl has the same behavior and worse.  If the -s option 
is present it inserts the separator character into the empty line following 
the string of spaces.  I have no other Unix platforms available on which to 
try nl.

-- 
Paul Almquist
Eau Claire, WI  USA
[EMAIL PROTECTED]


___
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

[anonymous]

URL:
  

 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



___

Reply to this item at:

  

___
  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