Re: Problem with 'df' on RedHat Linux with multiple "namespaces"

[Bauke Jan Douma]

Bob Proulx wrote on 01/01/2010 03:18 AM:

Pádraig Brady wrote:

Lenga, Yair wrote:

Please let me know if you need additional information.

I'm not sure it's related but could you give the output from
df -P as the -P option should always be used from scripts.


Seeing the output from the 'mount' command would also be useful.

  $ mount

And perhaps the 'df -T' output.

  $ df -TP

Bob






Not really related, but...
Coreutils' df's header line says 'use%' (en_US.UTF-8 locale).  That column
then lists values such as '55%', etc. i.e. a number with a percentage tacked
to it.

To me, that's a mismatch. The answer to the question '55 out of 100 -- what's
the percentage?" is "55", not "55 percent".

I find it more logical for the header to have "use" instead of 'use%', while
the values retain their percentage-character.

bjd

Re: stable coreutils-8.1 today, fingers crossed

[Bauke Jan Douma]

Jim Meyering wrote on 11/19/2009 02:47 PM:


What I meant was this:

Can you provide a stand-alone set-up similar to the following, with
directories on your PATH (whose perms and ancestor perms are all ok)
that still fails:

  perl -Te '$ENV{PATH}=~/(.*)/;$ENV{PATH}="$1";`/bin/true`'



cd /usr/bin && PATH=/usr/bin/:. /usr/bin/perl -Te 
'$ENV{PATH}=~/(.*)/;$ENV{PATH}="$1";`/bin/true`'; echo $?
Insecure directory in $ENV{PATH} while running with -T switch at -e line 1.
255

Note dot in PATH.

bjd

Re: stable coreutils-8.1 today, fingers crossed

[Bauke Jan Douma]

Andreas Schwab wrote on 11/18/2009 11:57 PM:

FAIL: rm/fail-eperm (exit: 255)
===

fail-eperm: considering /tmp/.
fail-eperm: considering /tmp/.X11-unix
fail-eperm: considering /tmp/missings-glibc-devel
Insecure directory in $ENV{PATH} while running with -T switch at 
./rm/fail-eperm line 88.

FAIL: misc/pwd-long (exit: 255)
===

Insecure directory in $ENV{PATH} while running with -T switch at - line 73.


Andreas.




I also got exactly these two.
Mine are under Karmic x86_64 GNU/Linux.
PATH is /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:

bjd

Re: incorrectly sorted file with snow leopard sort

[Bauke Jan Douma]

Eric Blake wrote on 11/04/2009 02:59 AM:

>> $ cat list-of-groups-greetings.txt | tr -d "\r" | sort
>
> Useless use of cat.
>
> tr -d "\r" < list-of-groups-greetings.txt | sort

Useless maybe, but then again maybe the user won some time
by it. I often wind up with constructs like this.

Many times, you do 'less /path/to/file', then right after you
may want to run sed or grep on it, in which case I usually
find it quicker to edit the previous command-line as little
as I can, and just attach the grep or sed or whatever-command
to it: 'less /path/to/file | grep regex'.

And many times --this may be hurtful ;-) -- I wind up doing 'cat
file' on too large a file, followed by a quick command-
line edit that gives me: 'cat file | less'.

Basically, I think I (my fingers?, my eyes?) have trouble
getting to the '<'. I'm not a touch typist by any means.

bjd

Re: incorrectly sorted file with snow leopard sort

[Bauke Jan Douma]

Eric Blake wrote on 11/04/2009 02:59 AM:


$ cat list-of-groups-greetings.txt | tr -d "\r" | sort


Useless use of cat.

tr -d "\r" < list-of-groups-greetings.txt | sort


Useless maybe, but then again maybe the user won some time
by it. I often wind up with constructs like this.

Many times, you do 'less /path/to/file', then right after you
may want to run sed or grep on it, in which case I usually
find it quicker to edit the previous command-line as little
as I can, and just attach the grep or sed or whatever-command
to it: 'less /path/to/file | grep regex'.

An many times --this may be hurtful ;-)-- I wind up doing 'cat
file' on too large a file, followed by a quick command-
line edit that gives me: 'cat file | less'.

Basically, I think I (my fingers?, my eyes?) have trouble
getting to the '<'. I'm not a touch typist by any means.

bjd

Re: [RFC] {print,}env -0

[Bauke Jan Douma]

Jim Meyering wrote on 10/26/2009 08:43 PM:

Pádraig Brady wrote:


Eric Blake wrote:

Since environment variables may contain newlines, but env and printenv
currently separate output entries via newline, we have a case of ambiguous
output.  For example, "env | sed -n '/^a.*=/ s,=.*,,p'" does not necessarily
tell you the set of environment variables beginning with "a", because I could
have done "export b=$'\na=c'".  What do list readers think of the idea of
adding:

env -0/--null
printenv -0/--null

as a means of unambiguously representing the current contents of the
environment with NUL terminators instead of newlines?

It's consistent and makes sense.
I've not needed it myself (I think :)),
but I would say it's worth adding.


I'm on the fence, partly because you can simulate printenv -0 with this:

perl -e 'print map {"$_=$ENV{$_}\0"} keys %ENV'

You can simulate env -0 the same way.
Certainly, env -0 and printenv -0 are easier to type and use.
Not strongly for or against.






... ah, Jim, but this is /core/utils no?

Wouldn't you agree therefore that historically as well
as OS-constitutionally coreutils are more fundamental
than perl? And, perhaps, therefore --at least in this
case-- it has no business of referring to a youngster
like perl?   ;-)

In short, personally, my hand's up for the proposition,
given the example.

bjd

Re: echo "-e" produces no outputs

[Bauke Jan Douma]

Eric Blake wrote on 07/17/2009 09:09 PM:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

According to Huang Tao on 7/17/2009 9:46 AM:

I'm not sure whether it is a bug
how can i echo the text string "-e" barely ( or "-n", "-E")
i tried
$echo "-e"
$echo '-e'
and some other inputs, all of which produced no outputs.


Instead of using echo (which POSIX itself admits is fraught with
portability problems), use printf:

printf -- '-e\n'



or:
echo -n "-" ; echo "e"

bjd


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

Re: cp command potental problem

[Bauke Jan Douma]

Eric Blake wrote on 06/17/2009 08:43 PM:

According to Bob Proulx on 6/17/2009 11:12 AM:

If there are three program arguments then the last one must be a
directory or it is an error.  But with only two it isn't possible to
determine the caller's intention.


It is also possible to write shell functions or aliases so that you can
avoid some of these mistakes.  For example:

$ alias safe_copy='cp -n'
$ safe_copy file*.txt


~/tmp > touch foo bar
~/tmp > cp -n foo bar
cp: invalid option -- 'n'
Try `cp --help' for more information.
~/tmp > cp --version
cp (GNU coreutils) 6.10
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Written by Torbjorn Granlund, David MacKenzie, and Jim Meyering.


bjd


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

id confusion

[Bauke Jan Douma]

Hi,

I wonder if, in the following session, the responses as given by 'id'
are correct and as intended (not regarding the numbers -- 1001 and the
others are correct), and if they wash with the manpage, specifically the
invocations with -gG, -ugG and -r.

To me it would seen g and G are mutually exclusive. But then what is
meant by the comment for option '-r' in the manpage?
A bit confusing, as are the nonzero-exit responses. And why doesn't id -r
succeed?

bjd

here's the session:


pig...@skyscraper:~$ id --version
id (GNU coreutils) 6.10
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Written by Arnold Robbins and David MacKenzie.

pig...@skyscraper:~$ id
uid=1001(piglet) gid=1001(piglet) groups=4(adm),20(dialout),21(fax),24(cdrom),
25(floppy),26(tape),29(audio),30(dip),44(video),46(plugdev),105(scanner),
107(fuse),1001(piglet)

pig...@skyscraper:~$ id -g
1001

pig...@skyscraper:~$ id -G
1001 4 20 21 24 25 26 29 30 44 46 105 107

pig...@skyscraper:~$ id -gG
id: cannot print "only" of more than one choice

pig...@skyscraper:~$ id -ugG
id: cannot print "only" of more than one choice

pig...@skyscraper:~$ id -r
id: cannot print only names or real IDs in default format


from the manpage:

   -r, --real
  print the real ID instead of the effective ID, with -ugG




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

Re: [Bug 485507] RFE: add ext4 to "stat -f" output

[Bauke Jan Douma]

Eric Sandeen wrote on 02/16/2009 06:53 PM:

Jim Meyering wrote:

How much code (and how ugly) would be required to distinguish ext4
from ext[23]?

it'd need to be able to do some parsing of the ext2/3/4 feature flags,
so it'd need to know some ext2/3/4 details.

lib/blkid/probe.c in e2fsprogs is an example, see probe_ext2,
probe_ext3, etc.  It reads in the superblock and then checks some of the
feature fields, for example:

/* Ext4 has at least one feature which ext3 doesn't understand */
if (!(blkid_le32(es->s_feature_ro_compat) &
  EXT3_FEATURE_RO_COMPAT_UNSUPPORTED) &&
!(blkid_le32(es->s_feature_incompat) &
  EXT3_FEATURE_INCOMPAT_UNSUPPORTED))
return -BLKID_ERR_PARAM;

so it'd not be rocket science but it might be a lot more fs details than
you'd really want in coreutils, I'm not sure...

Would you mind writing some proof-of-concept code for that?
If it's not too big or ugly, I'd like to teach stat -f
to distinguish ext4 from ext2/3.


Ok, I'll put it on the TODO list.  :)

Thanks,
-Eric


Might the linux klibc code for fstype be a source for this?
I'm not sure myself, I just looked in those for klibc-1.5.tar.gz,
(dated 2007, the latest?) and there doesn't to be code for ext4...

bjd



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

Re: date --date "4:59:54 1 hour 53 min 46 sec ago"

[Bauke Jan Douma]

Tom Rodman wrote on 01/28/2009 04:35 PM:

Not sure if this is cygwin specific, but it seems like a problem
in gnu date:

  ~ $ date;uname -a; cygcheck -c cygwin
  Wed Jan 28 09:30:54 CST 2009
  CYGWIN_NT-5.1 neon 1.5.25(0.156/4/2) 2008-06-12 19:34 i686 Cygwin
  Cygwin Package Information
  Package  VersionStatus
  cygwin   1.5.25-15  OK
  ~ $ cygcheck -f /usr/bin/date
  coreutils-6.10-2
  ~ $ date --date "4:59:54 1 hour 53 min 46 sec ago"
  Wed Jan 28 06:52:08 CST 2009


Seems like the 1 hour is added, the 53 minutes is added, and
then the 46 seconds is ... subtracted.

bjd



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

credo

[Bauke Jan Douma]

Hi Jim and all you coreutils maintainers,

I've a feeling a tremendous amount of work has been done over
the past year. The coreutils are being perfected by the minute.
Might I take a moment to say: Thanks!

At the risk of sounding corny:

   Who's cute and cool in cure and chore?
   Why it's the cast of the coreutils corps!
   The crew who code because they char...


;-)
Bauke Jan Douma




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

Re: problem

[Bauke Jan Douma]

P.S. I come from Germany


You mail arrived in Colorado!


And a hearty welcome to you, Colorado, to this
great big thing, the internet.  ;-)

bjd
Holland (Europe that is)



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

Re: if you use ptx, please let us know [Re: ptx bug (invalid read)

[Bauke Jan Douma]

Jim Meyering wrote on 16-07-08 12:47:


The trouble is that global state is reused
when processing the second and subsequent
file argument.  Fixing that will require a more
invasive change, and I'm not convinced it's even
worth my time.  Does anyone even use ptx these day?


Me, sometimes.


Does anyone rely on the GNU extension of accepting more
than one input file?  Since it appears that feature has never
worked properly, I seriously doubt it.  So I'm considering


Not me.


whether to add ptx to the list of programs that are not
installed by default.


Hmmm...


bjd


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

Re: solaris 8 fails to build due to `tr'

[Bauke Jan Douma]

Denis Excoffier wrote on 11-06-08 15:33:

The information in this e-mail is confidential. The contents may not be 
disclosed or used by anyone other then the addressee. Access to this e-mail by 
anyone else is unauthorised.
If you are not the intended recipient, please notify Airbus immediately and 
delete this e-mail.
Airbus cannot accept any responsibility for the accuracy or completeness of 
this e-mail as it has been sent over public networks. If you have any concerns 
over the content of this message or its Accuracy or Integrity, please contact 
Airbus immediately.
All outgoing e-mails from Airbus are checked using regularly updated virus 
scanning software but you should take whatever measures you deem to be 
appropriate to ensure that this message and any attachments are virus free.


Are you aware of the fact that the addressee in this case effectively
is that part of the world's population that has access to the internet?

bjd



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

Re: HELP

[Bauke Jan Douma]

Bauke Jan Douma wrote on 11-04-08 00:04:

dharini sutharsan wrote on 10-04-08 21:37:

hello sir

am running SLEUTH code in cygwin unix emulator and i want to use the 
chmod

option for write permission


can u suggest how to change the write permissions


I certainly can, by giving you read permission
of output from ls(1), 'info ls' or 'ls --help'.

bjd


Sorry, make that 'chmod(1), 'info chmod' or 'chmod --help'.

bjd



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

Re: HELP

[Bauke Jan Douma]

dharini sutharsan wrote on 10-04-08 21:37:

hello sir

am running SLEUTH code in cygwin unix emulator and i want to use the chmod
option for write permission


can u suggest how to change the write permissions


I certainly can, by giving you read permission
of output from ls(1), 'info ls' or 'ls --help'.

bjd




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

Re: problem with command sort after uniq -c

[Bauke Jan Douma]

Andreas Schwab wrote on 10-03-08 19:54:

Damien ANCELIN <[EMAIL PROTECTED]> writes:


I met a problem with the sort command : I've used the uniq command with
the -c option to count some numbers, and then applying sort -n don't sort
lines by numeric order of the first field.
Here is an example (my sort version is 5.97) :
$ cat bug_sort | sort -n


This is a useless use of cat, you can just redirect sort's standard
input from the file.


True, but such constructs do happen.

What might have been the case here, and which is a
situation that I find myself in sometimes, is this:
you want to do 'filter1 FILE | filter2'
(or 'filter1 http://lists.gnu.org/mailman/listinfo/bug-coreutils

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

[Bauke Jan Douma]

Pádraig Brady wrote on 07-03-08 18:01:


I think adding a / to all dirs is therefore more consistent
as well as providing more info to the user.
I understand the need to comply with POSIX where possible,
but one needs to use common sense to move forward.
POSIX is not the be all and end all.


That's why they have meetings.

bjd




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

Re: du reports different results for "."

[Bauke Jan Douma]

Mike Frysinger wrote on 20-02-08 23:18:

On Wednesday 20 February 2008, Bauke Jan Douma wrote:

Mike Frysinger wrote on 20-02-08 21:56:

On Wednesday 20 February 2008, Richard Ems wrote:

If I do a "du -s * ." and right afterwards "du -s ." I get different
values for the actual directory ".".

the * globa does not match the . directory.  it matches all the files as
expanded by the shell (which does not include the . directory nor any
file that starts with a .)

This can hardly be the answer, can it?
This is with * .  and  . * respectively:


sorry, i thought he was comparing "*" and ".", not "." and "* ."
-mike


That's what I guessed, no biggie.

Still, I cannot still quite fathom the difference
I am getting with * . and . * , even given that
there's a hard link in one of the subdirectries.

bjd


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

Re: du reports different results for "."

[Bauke Jan Douma]

Bauke Jan Douma wrote on 20-02-08 22:53:

Mike Frysinger wrote on 20-02-08 21:56:

On Wednesday 20 February 2008, Richard Ems wrote:

If I do a "du -s * ." and right afterwards "du -s ." I get different
values for the actual directory ".".


the * globa does not match the . directory.  it matches all the files 
as expanded by the shell (which does not include the . directory nor 
any file that starts with a .)

-mike


This can hardly be the answer, can it?
This is with * .  and  . * respectively:

/usr/src/linux >  du -s * .
20COPYING
92CREDITS
10892Documentation
4Kbuild
92MAINTAINERS
52Makefile
292Module.symvers
20README
4REPORTING-BUGS
984System.map
75136arch
844block
4484crypto
169076drivers
53780fs
43948include
424init
428ipc
5412kernel
2588lib
0make.res
3124make.res.3621
4make.res.4036
2584mm
39624net
2672scripts
1160security
23508sound
3692usr
5404vmlinux
6500vmlinux.o
471956.<--

/usr/src/linux > du -s . *
474044.<--
20COPYING
92CREDITS
10892Documentation
4Kbuild
92MAINTAINERS
52Makefile
292Module.symvers
20README
4REPORTING-BUGS
984System.map
73048arch<-- ?
844block
4484crypto
169076drivers
53780fs
43948include
424init
428ipc
5412kernel
2588lib
0make.res
3124make.res.3621
4make.res.4036
2584mm
39624net
2672scripts
1160security
23508sound
3692usr
5404vmlinux
6500vmlinux.o

/usr/src/linux > du -s arch
75136arch



Ah, the diff must be bzImage:
/usr/src/linux >  find . -type f -links 2 -ls
104974149 2088 -rw---   2 root root  2135928 Dec 24 18:32 
./arch/i386/boot/bzImage
104974149 2088 -rw---   2 root root  2135928 Dec 24 18:32 ./bzImage

bjd


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

Re: du reports different results for "."

[Bauke Jan Douma]

Mike Frysinger wrote on 20-02-08 21:56:

On Wednesday 20 February 2008, Richard Ems wrote:

If I do a "du -s * ." and right afterwards "du -s ." I get different
values for the actual directory ".".


the * globa does not match the . directory.  it matches all the files as 
expanded by the shell (which does not include the . directory nor any file 
that starts with a .)

-mike


This can hardly be the answer, can it?
This is with * .  and  . * respectively:

/usr/src/linux >  du -s * .
20  COPYING
92  CREDITS
10892   Documentation
4   Kbuild
92  MAINTAINERS
52  Makefile
292 Module.symvers
20  README
4   REPORTING-BUGS
984 System.map
75136   arch
844 block
4484crypto
169076  drivers
53780   fs
43948   include
424 init
428 ipc
5412kernel
2588lib
0   make.res
3124make.res.3621
4   make.res.4036
2584mm
39624   net
2672scripts
1160security
23508   sound
3692usr
5404vmlinux
6500vmlinux.o
471956  .   <--

/usr/src/linux > du -s . *
474044  .   <--
20  COPYING
92  CREDITS
10892   Documentation
4   Kbuild
92  MAINTAINERS
52  Makefile
292 Module.symvers
20  README
4   REPORTING-BUGS
984 System.map
73048   arch<-- ?
844 block
4484crypto
169076  drivers
53780   fs
43948   include
424 init
428 ipc
5412kernel
2588lib
0   make.res
3124make.res.3621
4   make.res.4036
2584mm
39624   net
2672scripts
1160security
23508   sound
3692usr
5404vmlinux
6500vmlinux.o

/usr/src/linux > du -s arch
75136   arch



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

Re: Feature Request: add wildcards and recursive to ln

[Bauke Jan Douma]

Vincent J. Schiavoni wrote on 20-02-08 17:21:

Hello:

Please consider adding features to ln to allow recursive linking of 
files in a directory and the use of wildcards to support that feature.


At present, there appears to be no way to link large numbers of files in 
a "batch"-type mode - each file must be linked individually, or a 
work-around used such as for example "for i in /usr/local/lib/*; do ln 
-s $i /usr/lib/ ; done".  It would be nice to have that functionality 
integrated into ln.


Methinks it would not.

Why is that a 'workaround?'.
Btw, that is just an example, isn't it?

Take a look at lndir, which comes with Xorg.

bjd


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

Re: UNDELETION EXT3 workaround

[Bauke Jan Douma]

Vincent wrote on 18-02-08 02:11:

The Linux EXT3 file system zero's the file pointers when you delete a
file.  The EXT2-Undeletion command does not exist with-in EXT3.  The
following is a more modern solution to the problem.

alias rm="mv --force --target-directory=$HOME/.Trash/"
alias rmdir="mv --force --target-directory=$HOME/.Trash/"

Removed files go into GNOME trash, and the icon even show papers in the
trash.  You can click on the trash icon anytime you want to delete or
un-delete a file or directory from the Trash.

I installed the following aliases in the aliases section of ~/.bashrc
for each user, except /root, where I specified

--target-directory=/home/myaccount/.Trash/ 


as root should never login into GNOME.

Now even if one has an accidental deletion of a file or entire directory
of files, one can simply copy the files back into place in the future,
from either the console or the trash icon on the task bar.

In a world with 500 GIG hard drives, these aliases should probably be
installed in all new ubuntu installations automatically, and advanced
users can remove them if they so desire.  The OS is not user friendly
with-out an undeletion or recovery method.


As has been pointed out here more than once, this runs the risk,
in a different place and time, of the user not being OS-friendly.

bjd


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

Re: [RFC]: --format=FORMAT option for ls

[Bauke Jan Douma]

Jim Meyering wrote on 12-02-08 15:50:

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

I can't think of any reason I would use `ls --format` over `find -printf`


Ha!  Good point.  Nor can I.  I'll remove the TODO item.



Actually, from the perspective of modularity that is (justifiably)
hammered on so often, wouldn't a format/printf option have been
somewhat more at home with 'ls' than with 'find'?

bjd





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

Re: shred -f -u should ignore nonexistent files (like rm -f does)

[Bauke Jan Douma]

Markus Kuhn wrote on 11-02-08 19:58:

Feature suggestion:

Given that "shred -u" and "rm" fulfill very similar functions (make a
file "go away"), it would make sense if their user interface were very
similar.

In particular, it would be nice if

  $ shred -u -f abc
  shred: abc: failed to open for writing: No such file or directory

would not output an error message if no file "abc" exists, just
like "rm -f abc" does not complain about nonexistent files.

Then one could use "shred -u -f" simply as a drop-in replacement for
"rm -f", e.g. change in a Makefile

  clean:
rm -f *~

to

  clean:
shred -u -f *~

Alternatively, it would be nice if the "rm" command had a shred-like
option to overwrite a file before unlinking it.


I disagree -- that would not be nice.

Some people what rm to just mv a file, others want it to
shred a file as well.  Personally, I would have liked rm
to run md5sum on the file before deciding whether or not
to delete it -- just for the fun of it.
But guess what.. you guessed it.

bjd



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

Re: Feature request: rm option that supports trash (plain text)

[Bauke Jan Douma]

Wilfred wrote on 10-02-08 23:17:

On 08/02/2008, Bob Proulx <[EMAIL PROTECTED]> wrote:

Wilfred wrote:

[EMAIL PROTECTED] ~ $ mkdir testdel
[EMAIL PROTECTED] ~ $ alias del='mv --verbose --backup=simple
--suffix=$(date +".(%F_%T)") --target-directory=$HOME/.Trash/'
[EMAIL PROTECTED] ~ $ del testdel
mv: accessing `/home/wilfred/.Trash/': No such file or directory

Right.  You would need to make the directory first.


This isn't a solution. I then have two trash directories, and the new
one isn't recognised by any trash handling applications. Moving files


There's nothing keeping you from subsituting it for the one you
want, in accordance with that spec (btw., how universal is that
spec...?), and further embellish that script even to the point
where it loses its simplicty and becomes simple and modular and
elegant.


to this new directory also does not record where the file came from
which makes restoring complex folder structures infeasible.

Trash is a solved problem and it would be nice not to reinvent the
wheel with simplistic scripts.


You're asking to reinvent the wheel using a binary executable?
Removing --that which rm MUST do-- simply isn't trashing.

bjd



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

Re: sort --compare-version

[Bauke Jan Douma]

Andreas Schwab wrote on 06-02-08 19:59:

Bruce Korb <[EMAIL PROTECTED]> writes:


Yep.  That's the reason for the "compare-" prefix.  I didn't like
``--compare-version-sort'' for some sort of reason, too.  Ultimately,
someone pick another name if "compare-version" is aesthetically bad.


How about making it --sort=KEYWORD, with KEYWORD in
{general-numeric,month,numeric,random,version}?

Andreas.



That's what I thought.  But I suppose the single-letter
options that are valid now will have to be kept also?

bjd



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

Re: Coreutils binary sizes over time

[Bauke Jan Douma]

Dr. David Alan Gilbert wrote on 27-01-08 01:29:

Hi,

  Out of a bit of boredom (and avoiding trying to fix a VHDL problem)
I decided to graph the sizes of a few of the binaries from coreutils,
as packaged by debian over time (I've included fileutils/shellutils).

At:

http://www.treblig.org/pics/debianbinarysizes.png

you can see a graph showing ls, du, df, true, and chmod
over about 10 years.

The raw data is here: http://www.treblig.org/data/debiansizes.csv
All of these are the Linux/x86 binary packages and all binaries
are ELF, stripped, with shared libs.

I've not made much attempt to analyse why things are growing;
although the fun one is the size of 'true' that used to be a tiny
shell script.

It's a bit scary that 'true' has gone from a 395 byte script to
a 22k binary in 10 years (even the first binary version I have is
under 5k); I can imagine that some of the other binaries probably
have more to do with system interaction (e.g. ls gaining selinux
support).

Dave



Interesting.  It would be even more interesting if you'd mark the timestamps
for breakthrough chipset and harddrive technology and anything that's driven
by that (major POSIX changes, new filesystem types, threading [which in turn
drive GCC for example] -- any more any one?) on that graph.

bjd


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

Re: [bug #22109] Enhancement request: tr should be able to take multiple consecutive actions

[Bauke Jan Douma]

Richard Neill wrote on 25-01-08 14:57:

Only that multiple instances of tr, piped together is rather ugly, and 


I, personally, strongly disagree.

bjd


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

Re: coreutils-6.10 released (stable)

[Bauke Jan Douma]

Jim Meyering wrote on 22-01-08 22:18:

Coreutils version 6.10 has been released.  This is a stable release.


I just for once would like to take this opportunity and, for your
unrelenting dedication, give a big THANKS to the coreutils core
developers and maintainers.
You know who you are.

bjd


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

coreutils-6.9.91: enable-no-install-program ignores 'groups'

[Bauke Jan Douma]

I noticed that, when running configure with:

--enable-no-install-program="groups,id,kill,su,uptime,hostname,arch"

which, by the way, causes these warnings (which are ok I suppose):

configure: WARNING: 'groups' is already not being installed
configure: WARNING: 'su' is already not being installed
configure: WARNING: 'hostname' is already not being installed
configure: WARNING: 'arch' is already not being installed

that `make install' still happily installs 'groups'...

bjd


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

Re: when executing mkdir command ...... ??

[Bauke Jan Douma]

Satyanarayana Ponugoti wrote on 28-12-07 11:49:

Hi,

when $mkdir isis\is 

command is executed, 


it creates a directory by name isisis,

and the same result is shown when $mkdir isisis

is executed,

IS IT a BUG in mkdir command...???

LET ME KNOW 


Consult the manual page for your shell,
subject 'Quoting'.

bjd



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

Re: coreutils-6.9.91 released (bug-fix-only)

[Bauke Jan Douma]

I just got around to building this yesterday. Without having much time
to devote to testing, I noted a few minor things.

$> uname -a
Linux skyscraper 2.6.23.11 #1 SMP Sun Dec 16 11:54:12 CET 2007 i686 GNU/Linux

./configure \
--disable-assert \
--enable-no-install-program="groups id kill su uptime hostname arch"

configure --help sez:
#   --enable-no-install-program=PROG_LIST
#   do NOT install the programs in PROG_LIST
#   (comma-separated, default: arch hostname su)

I think the latter should be changed into:
(comma-separated, default: arch,hostname,su)
I initially built having spaces instead of comma's.

$> RUN_EXPENSIVE_TESTS=1 make -k check

First time around I got two fails running this:

FAIL: groups-version.log
FAIL: preserve-gid.log

Hmm, I'm not even installing groups, as specified in the configure
option...

$> cat groups-version.log
FAIL: groups-version.log (exit: 1)
==

--- out 2007-12-20 11:58:58.400905662 +0100
+++ exp 2007-12-20 11:58:58.401905617 +0100
@@ -1,6 +1,6 @@
-id (GNU coreutils) 6.9.91
+id (GNU coreutils) 6.9+
 Copyright (C) 2007 Free Software Foundation, Inc.
-License GPLv3+: GNU GPL version 3 or later 
+License GPLv2+: GNU GPL version 2 or later 
 This is free software: you are free to change and redistribute it.
 There is NO WARRANTY, to the extent permitted by law.

$> cat preserve-gid.log
FAIL: preserve-gid.log (exit: 1)


cp: cannot open `a0' for reading: Permission denied


After I noticed the --enable-no-install-program list needed to be comma
separated, I did a make distclean, followed by:
./configure \
--disable-assert \
--enable-no-install-program="groups,id,kill,su,uptime,hostname,arch"

After the build, then once again did the make check:

Hmm, now I have three fails:
FAIL: groups-version.log
FAIL: preserve-gid.log
FAIL: test-getaddrinfo

I think this latter run must have been while being offline.

Anyway, I did some other rebuilds, always after make distclean, and one
time I also noted a fail on one of the infloop tests, either
./tests/ls/infloop.log or ./tests/tail-2/infloop-1.  I didn't jot that
down, so I can't tell which one it was.  I couldn't reproduce that very
quickly after that (doing make distclean, configure, make, make check).

After that, wiped out the entire coreutils directory, did a fresh
build, and got only the two fails as noted above.

bjd



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

Re: new snapshot

[Bauke Jan Douma]

Bauke Jan Douma wrote on 29-10-07 00:30:

Bauke Jan Douma wrote on 29-10-07 00:09:


But I have one difference in make-check results; I am getting:

SKIP: fail-eperm.log


SKIP: fail-eperm.log (exit: 77)
===

./../../../coreutils-6.9-354-68c33a/tests/rm/fail-eperm: 
/sources/build-coreutils/tests/rm: not writable by user `nobody'

./../../../coreutils-6.9-354-68c33a/tests/rm/fail-eperm: skipping this test

grep nobody /etc/passwd:
nobody:x:65534:65534:nobody:/:/bin/false

Whereas it just succeeded when building from $(srcdir).
(And I do have /tmp, with mode 1777...).


Ah, I see, the untarred sources' directories all have 777,
whereas the build directory has 755 throughout.  That explains.
Sorry for that noise.

bjd


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

Re: new snapshot

[Bauke Jan Douma]

Bauke Jan Douma wrote on 29-10-07 00:09:


But I have one difference in make-check results; I am getting:

SKIP: fail-eperm.log


SKIP: fail-eperm.log (exit: 77)
===

./../../../coreutils-6.9-354-68c33a/tests/rm/fail-eperm: 
/sources/build-coreutils/tests/rm: not writable by user `nobody'
./../../../coreutils-6.9-354-68c33a/tests/rm/fail-eperm: skipping this test

grep nobody /etc/passwd:
nobody:x:65534:65534:nobody:/:/bin/false

Whereas it just succeeded when building from $(srcdir).
(And I do have /tmp, with mode 1777...).

bjd




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

Re: new snapshot

[Bauke Jan Douma]

Jim Meyering wrote on 28-10-07 17:00:

Here are tarballs and signatures.
If I don't hear about problems (feedback about successes would be nice),
I'll make a coreutils-6.9.90 test release soon.


On x86_64, as root:
make bootstrap
configure
make


--- date:
Sun Oct 28 23:31:08 CET 2007

--- system:
Linux skyscraper64 2.6.22.6core2-4 #2 SMP Sun Sep 23 02:37:40 CEST 2007 x86_64 
Intel(R) Core(TM)2 Quad CPU

--- libc version:
GNU C Library stable release version 2.6.1, by Roland McGrath et al.
Copyright (C) 2007 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
Compiled by GNU CC version 4.2.1.
Compiled on a Linux 2.6.22 system on 2007-09-20.
Available extensions:
crypt add-on version 2.1 by Michael Glad and others
Native POSIX Threads Library by Ulrich Drepper et al
BIND-8.2.3-T5B
For bug reporting instructions, please see:
.

--- gcc version:
gcc (GCC) 4.2.1
Copyright (C) 2007 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.


--- binutils version:
GNU ld (GNU Binutils) 2.18
Copyright 2007 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or (at your option) a later version.
This program has absolutely no warranty.

--- coreutils version:
coreutils-6.9-354-68c33a

--- RUN_EXPENSIVE_TESTS=yes make -k check 2>&1 | tee make-check.res
...
...
grep FAIL make-check.res

I.e.: no failures.
Note the different system, toolchain, etc.
Same positive results with configure --disable-assert --disable-nls.


As for Andreas Schwab's report on building outside of source dir:
I didn't get the error he got (as root).
But I have one difference in make-check results; I am getting:

SKIP: fail-eperm.log

when running, as root, make check from a build directory (that has the same
parent as the coreutils source directory).
Haven't looked into this.  Expected?

bjd



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

Re: new snapshot

[Bauke Jan Douma]

Jim Meyering wrote on 28-10-07 17:00:

Here are tarballs and signatures.
If I don't hear about problems (feedback about successes would be nice),


The following (build and tests) as root:

make bootstrap
configure
make

and, again as root:

make bootstrap
configure --disable-assert --disable-nls
make

Output for make test was the same (see below).
System specifics:

--- date:
Sun Oct 28 21:46:30 CET 2007

--- system:
Linux skyscraper 2.6.22.5 #7 SMP PREEMPT Sun Sep 2 12:12:25 CEST 2007 i686 
GNU/Linux

--- libc version:
GNU C Library stable release version 2.5, by Roland McGrath et al.
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
Compiled by GNU CC version 4.1.1.
Compiled on a Linux >>2.6.19.1<< system on 2006-12-25.
Available extensions:
crypt add-on version 2.1 by Michael Glad and others
GNU Libidn by Simon Josefsson
GNU libio by Per Bothner
NIS(YP)/NIS+ NSS modules 0.19 by Thorsten Kukuk
Native POSIX Threads Library by Ulrich Drepper et al
BIND-8.2.3-T5B
Thread-local storage support included.
For bug reporting instructions, please see:
.

--- gcc version:
gcc (GCC) 4.1.1
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.


--- binutils version:
GNU ld version 2.17
Copyright 2005 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License.  This program has absolutely no warranty.

--- coreutils version:
coreutils-6.9-354-68c33a

--- RUN_EXPENSIVE_TESTS=yes make -k check 2>&1 | tee make-check.res
...
...

grep FAIL make-check.res
FAIL: printf-surprise.log


I will also test on an x86_64 tonight.

bjd




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

Re: new snapshot (rm fixes and new program: mktemp)

[Bauke Jan Douma]

Jim Meyering wrote on 08-10-07 11:05:

In addition to adding mktemp, I've fixed a few low-probability bugs in rm.
This also includes a lot of new code from gnulib, by virtue of coreutils
now requiring the vasprintf-posix module (mostly for non-POSIX systems),
so please give this a work-out if you haven't built a snapshot recently:

http://meyering.net/cu/coreutils-6.9-ss.tar.gz


Here's my verbose run of make check TESTS=chcon VERBOSE=yes

make  check-TESTS
make[1]: Entering directory `/sources/coreutils-6.9-316-e6f4b/tests/misc'
make[2]: Entering directory `/sources/coreutils-6.9-316-e6f4b/tests/misc'
FAIL: chcon

===
 1 of 1 tests failed
 See tests/misc/test-suite.log
 Please report it to bug-coreutils@gnu.org
===


   GNU coreutils 6.9-316-e6f4b: tests/misc/test-suite.log


1 of 1 tests failed.

.. contents:: :depth: 2


FAIL: chcon (exit: 1)
=

+ chcon --version
chcon (GNU coreutils) 6.9-316-e6f4b
Copyright (C) 2007 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Written by Russell Coker and Jim Meyering.
+ . ./../lang-default
++ LC_ALL=C
++ export LC_ALL
++ unset LANGUAGE NLSPATH
++ unset LANG LC_COLLATE LC_CTYPE LC_MESSAGES LC_MONETARY LC_NUMERIC LC_TIME
+ PRIV_CHECK_ARG=require-root
+ . ./../priv-check
++ case "$PRIV_CHECK_ARG" in
++ who='as root'
+++ id -u
++ my_uid=0
++ test 0 = 0
++ case $my_uid in
++ test 0 = 0
++ : nobody
+++ id -u nobody
++ coreutils_non_root_uid=65534
++ test 0 = 0
++ test 65534 = 0
++ give_msg=no
++ case $PRIV_CHECK_ARG:$my_uid in
++ test no = yes
+ . ./../test-lib.sh
++ unset function_test
++ eval 'function_test() { return 11; }; function_test'
+++ function_test
+++ return 11
++ test 11 '!=' 11
+++ pwd
++ test_dir_=/sources/coreutils-6.9-316-e6f4b/tests/misc
+++ this_test_
+++ echo ././chcon
+++ sed 's,.*/,,'
++ this_test=chcon
++ . ./../envvar-check
+++ as_unset=unset
+++ envvar_check_failed=0
+++ vars='
  _POSIX2_VERSION
  BLOCKSIZE
  BLOCK_SIZE
  CDPATH
  COLUMNS
  DF_BLOCK_SIZE
  DU_BLOCK_SIZE
  LS_BLOCK_SIZE
  LS_COLORS
  POSIXLY_CORRECT
  QUOTING_STYLE
  SIMPLE_BACKUP_SUFFIX
  TABSIZE
  TERM
  TIME_STYLE
  TMPDIR
  VERSION_CONTROL
'
+++ for var in '$vars'
+++ unset _POSIX2_VERSION
+++ eval test '"${_POSIX2_VERSION+set}"' = set
 test '' = set
+++ for var in '$vars'
+++ unset BLOCKSIZE
+++ eval test '"${BLOCKSIZE+set}"' = set
 test '' = set
+++ for var in '$vars'
+++ unset BLOCK_SIZE
+++ eval test '"${BLOCK_SIZE+set}"' = set
 test '' = set
+++ for var in '$vars'
+++ unset CDPATH
+++ eval test '"${CDPATH+set}"' = set
 test '' = set
+++ for var in '$vars'
+++ unset COLUMNS
+++ eval test '"${COLUMNS+set}"' = set
 test '' = set
+++ for var in '$vars'
+++ unset DF_BLOCK_SIZE
+++ eval test '"${DF_BLOCK_SIZE+set}"' = set
 test '' = set
+++ for var in '$vars'
+++ unset DU_BLOCK_SIZE
+++ eval test '"${DU_BLOCK_SIZE+set}"' = set
 test '' = set
+++ for var in '$vars'
+++ unset LS_BLOCK_SIZE
+++ eval test '"${LS_BLOCK_SIZE+set}"' = set
 test '' = set
+++ for var in '$vars'
+++ unset LS_COLORS
+++ eval test '"${LS_COLORS+set}"' = set
 test '' = set
+++ for var in '$vars'
+++ unset POSIXLY_CORRECT
+++ eval test '"${POSIXLY_CORRECT+set}"' = set
 test '' = set
+++ for var in '$vars'
+++ unset QUOTING_STYLE
+++ eval test '"${QUOTING_STYLE+set}"' = set
 test '' = set
+++ for var in '$vars'
+++ unset SIMPLE_BACKUP_SUFFIX
+++ eval test '"${SIMPLE_BACKUP_SUFFIX+set}"' = set
 test '' = set
+++ for var in '$vars'
+++ unset TABSIZE
+++ eval test '"${TABSIZE+set}"' = set
 test '' = set
+++ for var in '$vars'
+++ unset TERM
+++ eval test '"${TERM+set}"' = set
 test '' = set
+++ for var in '$vars'
+++ unset TIME_STYLE
+++ eval test '"${TIME_STYLE+set}"' = set
 test '' = set
+++ for var in '$vars'
+++ unset TMPDIR
+++ eval test '"${TMPDIR+set}"' = set
 test '' = set
+++ for var in '$vars'
+++ unset VERSION_CONTROL
+++ eval test '"${VERSION_CONTROL+set}"' = set
 test '' = set
+++ test '' = 1
+++ /sources/coreutils-6.9-316-e6f4b/tests/mkdtemp 
/sources/coreutils-6.9-316-e6f4b/tests/misc cu-chcon.XX
++ t_=/sources/coreutils-6.9-316-e6f4b/tests/misc/cu-chcon.aOKg37Xwyv
++ trap 'st=$?; cleanup_; 
d=/sources/coreutils-6.9-316-e6f4b/tests/misc/cu-chcon.aOKg37Xwyv;
cd /sources/coreutils-6.9-316-e6f4b/tests/misc && chmod -R u+rwx "$d" && rm -rf 
"$d" && exit $st' 0
++ trap '(exit $?); exit $?' 1 2 13 15
++ cd /sources/coreutils-6.9-316-e6f4b/tests/misc/cu-chcon.aOKg37Xwyv
++ diff --version
++ grep GNU
+ mkdir -p d/sub/s2
+ touch f g d/sub/1 d/sub/2
+ fail=0
+ u1=root
+ r1=object_r
+ t1=tmp_t
+ ctx=root:object_r:tmp_t
+ chcon ro

Re: new snapshot (rm fixes and new program: mktemp)

[Bauke Jan Douma]

Jim Meyering wrote on 08-10-07 11:05:

In addition to adding mktemp, I've fixed a few low-probability bugs in rm.
This also includes a lot of new code from gnulib, by virtue of coreutils
now requiring the vasprintf-posix module (mostly for non-POSIX systems),
so please give this a work-out if you haven't built a snapshot recently:

http://meyering.net/cu/coreutils-6.9-ss.tar.gz
http://meyering.net/cu/coreutils-6.9-ss.tar.gz.sig

aka

http://meyering.net/cu/coreutils-6.9-316-e6f4b.tar.gz
http://meyering.net/cu/coreutils-6.9-316-e6f4b.tar.gz.sig

In addition, note that the next snapshot will probably be compressed
with lzma, rather than with gzip.  The resulting file is less than half
the size of the .gz one and it is even 2MB smaller than the .bz2 one:


Never heard of it!
Is this it: http://tukaani.org/lzma/ ?
Is it considered mature/stable??

bjd



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

Re: new snapshot (rm fixes and new program: mktemp)

[Bauke Jan Douma]

Jim Meyering wrote on 08-10-07 11:05:

In addition to adding mktemp, I've fixed a few low-probability bugs in rm.
This also includes a lot of new code from gnulib, by virtue of coreutils
now requiring the vasprintf-posix module (mostly for non-POSIX systems),
so please give this a work-out if you haven't built a snapshot recently:

http://meyering.net/cu/coreutils-6.9-ss.tar.gz


$> uname -a
Linux skyscraper64 2.6.22.6core2-4 #2 SMP Sun Sep 23 02:37:40 CEST 2007 x86_64 
AMD Athlon(tm) 64 Processor 3800+ AuthenticAMD GNU/Linux

$> ./configure --prefix=/usr

I don't have selinux.

I'm getting:
FAIL: chcon

$> grep PASS make-check-root.res
PASS: basic
PASS: special-bits
PASS: no-give-up
PASS: fail-2eperm
PASS: append-only
PASS: nameless-uid

$> grep FAIL make-check-root.res
FAIL: chcon

$> grep SKIP make-check-root.res
SKIP: one-file-system
SKIP: cp-a-selinux
SKIP: writable-under-readonly
SKIP: sticky-to-xpart

$> cat tests/misc/test-suite.log

   GNU coreutils 6.9-316-e6f4b: tests/misc/test-suite.log


1 of 82 tests failed.  (11 tests were not run).

.. contents:: :depth: 2


FAIL: chcon (exit: 1)
=

chcon: invalid context: root:object_r:tmp_t
stat: failed to get security context of `f': Operation not supported
chcon: failed to get security context of `f': Operation not supported
stat: failed to get security context of `g': Operation not supported
chcon: failed to get security context of `f': Operation not supported
stat: failed to get security context of `f': Operation not supported
chcon: failed to get security context of `f': Operation not supported
stat: failed to get security context of `f': Operation not supported
chcon: failed to get security context of `f': Operation not supported
stat: failed to get security context of `f': Operation not supported
chcon: failed to get security context of `f': Operation not supported
stat: failed to get security context of `f': Operation not supported
chcon: failed to get security context of `f': Operation not supported
stat: failed to get security context of `f': Operation not supported
chcon: failed to get security context of `f': Operation not supported
stat: failed to get security context of `f': Operation not supported
chcon: failed to get security context of `f': Operation not supported
stat: failed to get security context of `f': Operation not supported
--- out 2007-10-08 22:02:59.008724413 +0200
+++ exp 2007-10-08 22:02:59.010724108 +0200
@@ -1,9 +1,9 @@
-f|?
-g|?
-f|--user=user_u|?
-f|--role=object_r|?
-f|--type=file_t|?
-f|--range=SystemLow-SystemHigh|?
-f|-uroot|?
-f|-robject_r|?
-f|-ttmp_t|?
+f|root:object_r:tmp_t
+g|root:object_r:tmp_t
+f|--user=user_u|user_u:object_r:tmp_t
+f|--role=object_r|user_u:object_r:tmp_t
+f|--type=file_t|user_u:object_r:file_t
+f|--range=SystemLow-SystemHigh|user_u:object_r:file_t:SystemLow-SystemHigh
+f|-uroot|root:object_r:file_t:SystemLow-SystemHigh
+f|-robject_r|root:object_r:file_t:SystemLow-SystemHigh
+f|-ttmp_t|root:object_r:tmp_t:SystemLow-SystemHigh



bjd


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

Re: Rm performance issue

[Bauke Jan Douma]

Ken Naim wrote on 26-09-07 19:19:

We are using ext3 on top of LVM on IBM SAN. I don't know the SAN hardware
specifics, although I have been trying to squeeze this info out of the
client for a while. 


As for bad io experiences, our core production system use raw devices for
our databases so we don't have the same issue(s), this is our production
reporting system that gets cloned over nightly. So the process removes all
the existing files and then writes new versions of them from a backup onto a
file system. I have noticed the poor io performance since I came onsite but
the unix team keeps saying everything is fine. This rm issue is causing the
database clone process to exceed its allocated downtime window so I thought
I'd start there.

If anyone can point me to any specific information on tuning ext3 file
system I'd appreciate it. I am googling it now.

Thanks much for the help,
Ken


Why remove them in the first place?
And, although I'm not that familiar with it, isn't /rsync/
better tuned to this kind of process?

bjd


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

Re: strange DF (disk full) output

[Bauke Jan Douma]

James Youngman wrote on 20-09-07 12:02:

On 9/19/07, Roberto Spadim <[EMAIL PROTECTED]> wrote:

hello guys, i'm using archlinux current under XFS
see what's happen with my /dev/sda2 (/ root partition)
DF output: (88% Usage)

[EMAIL PROTECTED] /]# df
Sist. Arq.   1K-blocos  Usad Dispon.   Uso% Montado em
/dev/sda2  9765312   8567884   1197428  88% /


So, 1197428 KB is free.

$ bc
bc 1.06
Copyright 1991-1994, 1997, 1998, 2000 Free Software Foundation, Inc.
This is free software with ABSOLUTELY NO WARRANTY.
For details type `warranty'.
scale=6
k=1197428
k/(1024*1024)
1.141956
k/100
1.197428

So you have about 1.2GB (1.14GiB) free.  About 8.6GB has been used.



[EMAIL PROTECTED] /]# du -s -x /
2031605 /


A different figure.   2GB; a significant disparity.



i think that DF is understanding /mnt/smb (smbfs mount point) as / disk
usage
but if i umount it and get again df and du -s /*, df still with 88%


OK, so you had a hypothesis, tested it and found it was wrong.  But
that's a good way to proceed.


what could i do? i think that DU is right, but DF is the main problem


They are both right but they do different things.   df asks the
filesystem how much space is free.   du examines all the files you
told it to look at and adds up the space occupied by them.  These
figures are always different.   I'll comment on this again, below.



since, if i do:
dd if=/dev/zero of=/test bs=1024 count=very big count
i get:

[EMAIL PROTECTED] /]# dd if=/dev/zero of=/test bs=1024 count=50
rm /testdd: escrevendo `/test': Não há espaço disponível no dispositivo
1194693+0 records in
1194692+0 records out
1223364608 bytes (1,2 GB) copied, 37,6201 s, 32,5 MB/s


So you tried to create a really large file, and created one that was
only 1.2GB because you ran out of space.   This confirms that the
output from df is correct.


so, df is my problem since i have "only" 1.2 gb,


Well, dd is telling you the same thing as df.   I'd assume that df is
correct, then.

There are many things that will normally result in the output of df
being different to the output of du.   Here are some examples:

  * filesystem overhead (e.g. partly-ful blocks)
  * journal files
  * unlinked files which are still open (they are not actually deleted
until they are closed, but du cannot see them because they have no
name)
  * inaccessible files

You can eliminate unlinked files as a problem by stopping (and if
needed, restartring) all the processes on your system which have large
open files.


To get a list of all the deleted files which are still open and the
processes which have them open, you can use this command (which
probably works only on GNU/Linux systems):

 find /proc -mindepth 3 -path '/proc/*/fd/*' -type l -lname
'*deleted*' -printf '%l %p\n'

That's a lower case L after the % sign there.   The output of this
command is a list of deleted files (the left hand column) and the
processes that have them open (for each /proc/NNN/fd/XX item in the
right hand column, the NNN is the PID of the process which has the
file open).

As for inaccessible files, one way for that to happen is if you create
a whole bunch fo stuff (say under /home) and then add a new filesystem
and mount it over the existing stuff.   The existing stuff is still
there (you didn't delete it) but it is not accessible to du because a
filesystem got mounted over it.

Hope this helps,

James.


This explanation (well done!) should make it into the FAQ, if only for
its clarity, that's what I think.

bjd



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

Re: Ubuntu V 6.06 LTS for your PC

[Bauke Jan Douma]

Robert Ryding wrote on 04-08-07 11:05:

This is in regards to the Freeware Copy of Ubuntu V6.06.
For reasons still unknown at this time, I cannot install,update or erase Ubuntu 
off my hard drive.

   ^^^

You cannot install. So what's with the attorney?

 > R C Ryding

Cheers,

bjd



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

Re: Feature request for cut and/or sort

[Bauke Jan Douma]

Andreas Schwab wrote on 24-07-07 02:26:

Matthew Woehlke <[EMAIL PROTECTED]> writes:


The Wanderer wrote:

Bob Proulx wrote:

The problem is the same as always, filenames with embedded newlines in
them.

I've never seen a filename with an embedded newline, and AFAICT standard
command-line tools cannot produce such.

Oh? ;-)
echo 'bar' > "`echo -e 'foo\nbar'`"


What a waste of resources.

$ touch 'foo
bar'

Andreas.



And there's the user's own limited resources.
What a waste indeed:
$ > 'foo
> bar'

bjd



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

Re: Bug in echo when trying to print "******************************************************************************************"

[Bauke Jan Douma]

Eric Blake wrote on 27-06-07 14:22:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Please keep replies on the list, so that others may benefit from the answers.

According to Robert Thompson on 6/26/2007 10:27 AM:

That said, it seems like you aren't pasting the exact command you
actually
tried.  echo "*" echoes a single asterisk, "echo *" is a glob character,
interpreted by your shell as all files in the current directory,
passed as
multiple arguments to echo, each of which are then echoed, giving the
output you demonstrated.  This is not a bug in echo, but probably a
misunderstanding on your part about shell quoting rules.




Thanks. Can you suggest a reference to shell quoting rules?  --  Bob T.


You can start out with the shell itself - 'man bash' tries to do a good
job.  Or you could refer directly to POSIX,
http://www.opengroup.org/onlinepubs/009695399/utilities/xcu_chap02.html#tag_02_02.
 But both of these options are a bit harsh if you are learning shell for
the first time.

A friendlier option is a good reference manual, such as O'Reilly's:
http://www.oreilly.com/catalog/bash3.  There is also plenty to be learned
from google.


There's also the Advanced Bash Scripting guide, to be found at
http://tldp.org/LDP/abs/abs-guide.pdf
which has many example scripts and scriptlets, and which would
in my view not be too advanced for even a beginner (lest bad
habits creep in).

bjd



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

Re: How to find character special files dependencies for a program or library?

[Bauke Jan Douma]

Martijn Ras wrote on 14-06-07 23:18:

Heya Folks,

Is there any way to find the character special files for a program or 
library? Similar to using ldd to find the libraries for a program ...


Mazzel,

Martijn.


At runtime: lsof.

Ja, de mazzel!

bjd


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

Re: Problem with wc

[Bauke Jan Douma]

Pat Robinson wrote on 13-06-07 22:04:
cat foo | wc -l 

 


works the first time but will hang on subsequent attempts (foo is a
ordinary text file).


"First time" after what?

Is foo any one particular file which display the behaviour
exclusively to any other ordinary text files?  Or is it the
proverbial 'fill in your own name here' kind of oridinary
text file, i.e. /all/ ordinary text files that display this
behaviour?

If not, is bisecting foo an option, and running the parts
through the command to see which and when the behavior occurs?

bjd



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

Re: [PATCH] arch: new program

[Bauke Jan Douma]

Jim Meyering wrote on 13-06-07 16:05:

Karel Zak <[EMAIL PROTECTED]> wrote:

On Wed, Jun 06, 2007 at 09:45:09PM +0200, Jim Meyering wrote:

I hate to say it, after Karel has done most of the work, but I suppose
simply not adding it to coreutils should be considered an option, too.

Opinions?

On Wed, Jun 06, 2007 at 04:17:32PM -0700, Paul Eggert wrote:

Jim Meyering <[EMAIL PROTECTED]> writes:


What do you think of a new configure-time option that
would list extra programs like arch that you'd like to install?
I would probably add "su" to the list, since most installers don't
want the version from coreutils.

 Also.. I can prepare this patch if you want this configure option.


Hi Karel,

I began work on it over the weekend and haven't gotten back to it.
Should find time to finish by Monday.


Sounds good to me.  There is the question of what the default set of
programs would be; one possibility would be omitting 'arch', 'su', and
whatever coreutils already decides by default to omit.

 is there any final decision? I'd like to freeze util-linux-ng code in
 next few weeks.

 We can also postpone this issue ;-( There is no problem to keep the old
 arch command in util-linux for the next release.


I'm planning something like this:

Programs *not* to install by default:

su
arch

Here's a minimum list of programs that you may choose not to install:

chroot
df
hostid
hostname
nice
pinky
stty
su
uname
uptime
users
who

I may extend that to include the full list of all 100 program names.

If you want to install one of the default-not-installed ones,
you'd use e.g., ./configure --enable-install-program=su

To add to the list of not-installed programs, you'd use
--enable-no-install-program=hostname

The option syntax is awkward due to autoconf's pseudo-requirement
that such options look like --enable-REMAINDER_OF_NAME=VAL .
I'd welcome a better name.


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



Oh, and I'm overlooking these:

groupsis in the shadow package too
idis in the shadow package too

bjd






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

Re: [PATCH] arch: new program

[Bauke Jan Douma]

Jim Meyering wrote on 13-06-07 16:05:


Jim Meyering <[EMAIL PROTECTED]> writes:


What do you think of a new configure-time option that
would list extra programs like arch that you'd like to install?
I would probably add "su" to the list, since most installers don't
want the version from coreutils.

 Also.. I can prepare this patch if you want this configure option.


[deletia]


I'm planning something like this:

Programs *not* to install by default:

su
arch

Here's a minimum list of programs that you may choose not to install:

chroot
df
hostid
hostname
nice
pinky
stty
su
uname
uptime
users
who


I think 'kill' should be in here as well, since under Linux it's
in the procps package too.


bjd




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

Re: Minor bug in df

[Bauke Jan Douma]

Jim Meyering wrote on 10-06-07 21:08:

Luke Kendall <[EMAIL PROTECTED]> wrote:

The column formatting of the plain "df" output is misaligned, making it
hard to read.  Same is true for -P option.  For example:

...

: /home/data/audio; df --version
df (GNU coreutils) 5.96


Thanks for the report.
That's probably fixed in the latest stable release: coreutils-6.9.
If not, please let us know.


This reminds me of something I noticed the other day.

I was briefly experimenting with i18n, specifically nl_NL, and
noticed some formatting irregularities of the translated header
of df (translated to Dutch):

(root[21:59:15] ~/emacs> LC_ALL= LANG=nl_NL df
Bestandssysteem  1K-blokken Gebruikt Beschikbaar Gebruikt% Aangekoppeld 
op
/dev/hda2 64429328  28321052  36108276  44% /
/dev/hdb1244992000 128022008 116969992  53% /usr

This hadn't occurred to me before, prob. because I always use
LC_ALL=C.

Rather than an issue with df itself, I suppose that either
this is the way to go, or else it's a matter for the translator,
who needs to do some truncation.
Correct?

bjd



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

Re: [PATCH] arch: new program

[Bauke Jan Douma]

Jim Meyering wrote on 06-06-07 21:45:

Ouch.  This makes it look like coreutils should not install arch
by default.  What do you think of a new configure-time option that
would list extra programs like arch that you'd like to install?
I would probably add "su" to the list, since most installers don't
want the version from coreutils.


On Linux/GNU, there are a couple more candidates for an
exclude-list:

groupsis in the shadow package too
idis in the shadow package too
suis in the shadow package too
kill  is in the procps package too
uptimeis in the procps package too
hostname  is in the net-tools package too

There may well be more for which a system administrator
might prefer another package.

bjd



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

Re: command cp

[Bauke Jan Douma]

gri grigri wrote on 17-05-07 19:17:

I have no bug, but an missing feature:
cp -p ... ...
like 
mkdir -p ...

for the case, that I want to copy a file in a yet not existing directory.


You might as well say mkdir has a missing feature, namely
that it doesn't copy files over.
Ergo...

bjd



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

Re: A bug -maybe or just some odd feature

[Bauke Jan Douma]

James Youngman wrote on 02-05-07 11:17:

On 5/2/07, James Youngman <[EMAIL PROTECTED]> wrote:


Well, here there is something of a problem; you have to tell the C
library yourself by setting environment variables.  Your terminator
does not automatically set up your shell's environment.


Yes, the T1000 is not yet so advanced.  I meant, of course, _terminal
emulator_.   What an odd mistake to have made.  Sorry.  I wonder what
it means...


The terminator is where day turns into night.
I suppose it was just getting late...  ;-)

bjd



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

Re: Don't you think there are too many *sum utilities?

[Bauke Jan Douma]

[EMAIL PROTECTED] wrote on 09-04-07 13:18:


One more comparison. Why do we have the only one 'mknod' utility and
why don't we have separate 'bmknod' (for block devices) and 'cmknod'
(for character devices)?


Because mknod was first and did it all.

> Do you fill the difference now?!

I personally don't.
Your proposal added confusion, if anything, because
it proposed a bundle-up for only a few of these
utilities.

bj





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

Re: mv

[Bauke Jan Douma]

[EMAIL PROTECTED] wrote on 22-03-07 17:58:

Hello maintainers of the mv command,
I have a problem with the "mv" command.
I cannot rename a file to lower case.
I used mv because Konqueror also fails.
Is there an explanation to this issue?
Greetings, Fabian.


Yes! -- in fact there are many possible explanations.
That might be a problem right there... ;-)

Why don't you for starters do:
`strace -o /tmp/mv.log /bin/mv FOO foo'
and see if /tmp/mv.log can make you any the wiser.

bj



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

Re: new coreutils snapshot; are they useful?

[Bauke Jan Douma]

Jim Meyering wrote on 14-02-07 14:48:

Last night I made another coreutils snapshot:

  http://meyering.net/cu/coreutils-6.7-dirty.tar.gz
  http://meyering.net/cu/coreutils-6.7-dirty.tar.gz.sig

  aka
http://meyering.net/cu/coreutils-6.7-ss-2007-02-14.00:04:10+0.tar.gz
http://meyering.net/cu/coreutils-6.7-ss-2007-02-14.00:04:10+0.tar.gz.sig

If you take the time to build/test, it'd be nice to let me or the list
know, even if it's just to say that everything went fine.  


Builds fine here (bootstrap, configure w/o any arguments, make) on:

Linux skyscraper 2.6.20 #2 PREEMPT Fri Feb 9 01:37:06 CET 2007 i686 GNU/Linux

including 'make check' -- apart from the following, which is prob. to be
expected, since I'm building as root:

make[2]: Entering directory `/sw/coreutils/coreutils-6.7-dirty/tests/rm'
make  check-TESTS
make[3]: Entering directory `/sw/coreutils/coreutils-6.7-dirty/tests/rm'
PASS: i-never
cmp: EOF on out
0a1
> rm: cannot remove `d/f': Permission denied
FAIL: fail-eacces

Also did a -Wall build, and for completeness, here are the warnings I'm
getting -- no surprises here I take it:

test.c:326: warning: 'lt.tv_nsec' may be used uninitialized in this function
test.c:326: warning: 'lt.tv_sec' may be used uninitialized in this function
test.c:326: warning: 'rt.tv_nsec' may be used uninitialized in this function
test.c:326: warning: 'rt.tv_sec' may be used uninitialized in this function
test.c:355: warning: 'lt.tv_nsec' may be used uninitialized in this function
test.c:355: warning: 'lt.tv_sec' may be used uninitialized in this function
chmod.c:186: warning: 'new_mode' may be used uninitialized in this function
chmod.c:185: warning: 'old_mode' may be used uninitialized in this function
copy.c:1007: warning: 'dst_mode' may be used uninitialized in this function
ls.c:3604: warning: 'displayed_width' may be used uninitialized in this function
shred.c:364: warning: 'thresh' may be used uninitialized in this function
cat.c:534: warning: 'out_ino' may be used uninitialized in this function
cat.c:531: warning: 'out_dev' may be used uninitialized in this function
cut.c:750: warning: 'spec_list_string' may be used uninitialized in this 
function
expand.c:155: warning: 'num_start' may be used uninitialized in this function
expand.c:154: warning: 'tabval' may be used uninitialized in this function
md5sum.c:454: warning: 'hex_digest' may be used uninitialized in this function
od.c:1562: warning: 'desired_width' may be used uninitialized in this function
od.c:1569: warning: 'pseudo_start' may be used uninitialized in this function
pr.c:2450: warning: 'chars' may be used uninitialized in this function
md5sum.c:454: warning: 'hex_digest' may be used uninitialized in this function
md5sum.c:454: warning: 'hex_digest' may be used uninitialized in this function
md5sum.c:454: warning: 'hex_digest' may be used uninitialized in this function
md5sum.c:454: warning: 'hex_digest' may be used uninitialized in this function
md5sum.c:454: warning: 'hex_digest' may be used uninitialized in this function
sort.c:783: warning: 'pid' may be used uninitialized in this function
unexpand.c:460: warning: 'tabval' may be used uninitialized in this function
unexpand.c:174: warning: 'num_start' may be used uninitialized in this function
unexpand.c:173: warning: 'tabval' may be used uninitialized in this function
uniq.c:297: warning: 'prevlen' may be used uninitialized in this function
uniq.c:296: warning: 'prevfield' may be used uninitialized in this function
expr.c:420: warning: 'v' may be used uninitialized in this function
test.c:326: warning: 'lt.tv_nsec' may be used uninitialized in this function
test.c:326: warning: 'lt.tv_sec' may be used uninitialized in this function
test.c:326: warning: 'rt.tv_nsec' may be used uninitialized in this function
test.c:326: warning: 'rt.tv_sec' may be used uninitialized in this function
test.c:355: warning: 'lt.tv_nsec' may be used uninitialized in this function
test.c:355: warning: 'lt.tv_sec' may be used uninitialized in this function
who.c:559: warning: 'ttyname_b' may be used uninitialized in this function
df.c:784: warning: 'stats' may be used uninitialized in this function


bjd




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

Re: stty -g

[Bauke Jan Douma]

Mike Frysinger wrote on 02-02-07 23:13:

On Friday 02 February 2007, Bauke Jan Douma wrote:

What is it actually that all gets output by `stty -a'?
Stty(1) wasn't much of a help.


your subject says '-g', not '-a' ...

but the description of '-a' sounds correct to me:
-a: print all current settings in human-readable form

which part is confusing ?


Sorry, meant -g.

bjd




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

dd conv=none

[Bauke Jan Douma]

conv=none might be handy when you're building
a dd command-line in a shell script.
Any thoughts?

bjd



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

stty -g

[Bauke Jan Douma]

What is it actually that all gets output by `stty -a'?
Stty(1) wasn't much of a help.

bjd




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

Re: basename sucks (OT)

[Bauke Jan Douma]

Philip Rowlands wrote on 02-02-07 18:52:

On Fri, 2 Feb 2007, Bauke Jan Douma wrote:

Reminds me of something.  This is largely off-topic, but does anyone 
know of a utility FOO that takes a path or file as input an outputs a 
full, absolute, rooted path?


readlink -f sounds close to what you want.


Well I'll be... -- yes!
Who'd have known.  I'd been implementing this as a shell-
script some time ago, and recall that it took more effort
to get it right than I had suspected.

Thank you!


Cheers,
Phil


Likewise.

bjd




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

Re: basename sucks (OT)

[Bauke Jan Douma]

Andreas Schwab wrote on 02-02-07 18:18:

[EMAIL PROTECTED] (Bob Proulx) writes:


Then Mike's suggestion of using the shell directly is the best choice
for efficiency.  No process forks and everything is done internally to
the shell.  It should be quite fast.

  dirname - ${foo%/*}


Note that this is not a full replacement.  It doesn't correctly handle
names without a directory component.


Reminds me of something.  This is largely off-topic, but
does anyone know of a utility FOO that takes a path or file
as input an outputs a full, absolute, rooted path?

E.g.

$> cd / && FOO /etc/termcap
/etc/termcap

$> cd /etc && FOO termcap
/etc/termcap

$> cd /etc && FOO ../etc/./termcap
/etc/termcap


bjd



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

Re: sort behavior - Ubuntu problem?

[Bauke Jan Douma]

Kevin Scannell wrote on 24-01-07 02:50:

I suspect that the behavior I describe below is caused by broken
locale definition files, but I wanted to get an expert opinion on this
before I go trying to find who maintains those upstream.

I know about the "sort does not sort" FAQ, and I don't think that I've
fallen into that trap, so please keep reading!

Anyway, here's a sample file, utf-8 encoded text.
http://borel.slu.edu/obair/test.txt

$ uname -a
Linux borel 2.6.17-10-generic #2 SMP Fri Oct 13 18:45:35 UTC 2006 i686 
GNU/Linux


$ sort --version
sort (GNU coreutils) 5.96
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software.  You may redistribute copies of it under the 
terms of

the GNU General Public License .
There is NO WARRANTY, to the extent permitted by law.

Written by Mike Haertel and Paul Eggert.

$ locale
LANG=
LC_CTYPE="en_US.utf8"
LC_NUMERIC="en_US.utf8"
LC_TIME="en_US.utf8"
LC_COLLATE="en_US.utf8"
LC_MONETARY="en_US.utf8"
LC_MESSAGES="en_US.utf8"
LC_PAPER="en_US.utf8"
LC_NAME="en_US.utf8"
LC_ADDRESS="en_US.utf8"
LC_TELEPHONE="en_US.utf8"
LC_MEASUREMENT="en_US.utf8"
LC_IDENTIFICATION="en_US.utf8"
LC_ALL=en_US.utf8

$ sort test.txt
a
á
áa
aá
az
áz
áa
aá

The acute-a collates after the "a" (correctly) except when there are
additional non-ASCII characters on the same line.   I see this also
with ga_IE.utf8 which is the locale I usually use, and the one I care
about.  This sort order is definitely wrong there.

The thing that leads me to believe that the problem lies with the
locale definition file is that on a different machine, running Gentoo,
same conditions as above, this file sorts as I want it to, in
dictionary order:

$ uname -a
Linux turing 2.6.17-gentoo-r4 #2 SMP Mon Aug 28 12:53:48 CDT 2006
x86_64 AMD Opteron(tm) Processor 246 AuthenticAMD GNU/Linux

$ sort test.txt
a
á
aá
áa
az
áz
aá
áa

Any advice would be appreciated.
Kevin



My advice is to first also do sort --version on the latter machine.
That might be a lead.

bjd



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

Re: feature request: gzip/bzip support for sort

[Bauke Jan Douma]

Dan Hipschman wrote on 22-01-07 05:55:


sort can now compresses


Small typo here.


bjd





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

Re: feature request: gzip/bzip support for sort

[Bauke Jan Douma]

Paul Eggert wrote on 16-01-07 18:35:

Jim Meyering <[EMAIL PROTECTED]> writes:


So, with just one trial each, I see a 19% speed-up.


Yaayyy!  That's good news.  Thanks for timing it.  I read your email
just after talking with Dan (in person) about how we'd time it.  I
just bought 1 TB worth of disk for my home computer and hadn't hooked
it up yet, so was going to volunteer that, but you beat me to it.

At this point to my mind the only question is how to put this change
in, and whether to make it the default (with gzip, say).  Clearly it
can lead to a big performance improvement with large sorts on modern
machines.


How about files of 'average' size?

Someone said:

>  sort: Compress temporary files when doing large external sort/merges.
> This improves performance when you can compress/uncompress faster than
> you can read/write, which is common in these days of fast CPUs.

If this statement is true, you get the best of both worlds.
In that case I'd just make it the default (which is just that,
the default, and implies an option to choose the 'old' behavior).

bjd




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

Re: include dos2unix/unix2dos in coreutils ?

[Bauke Jan Douma]

Pádraig Brady wrote on 20-12-06 18:52:


Perhaps we could use the retired shellutils name?
Would that be too confusing?


Yes too confusing.
Like I said, just this time with some added seriousness:
odd-utils.

What's the english name again for a box (not a toolbox)
where you keep all kinds of unassorted odds and ends?

Motley-utils.

Div-utils (diverse).  Hmm, that sounds good.

Orphan-utils (not at home in any other package).

Sundry-utils.

Various-utils. Or var-utils -- that sounds great.
How about that: var-utils? <--

bjd



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

Re: What is the opposite of 'printf'?

[Bauke Jan Douma]

Matthew Woehlke wrote on 12-12-06 17:06:
 > Thanks Eric and Bob for the replies. Unfortunately, as stated, the
problem is that I am looking to generate an editor-friendly script (i.e. 
makeself is out) that can be run on arbitrary platforms (i.e. codegroup 
is out). And apparently uudecode is also out; my computer has man pages 
for it but no programs(?!). Conversely, I can't say I've run into a 
system yet that lacks printf.


Uuencode/uudecode are in GNU sharutils.

bjd



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

Re: echo and -n versus \c

[Bauke Jan Douma]

Raymond DeGennaro II wrote on 06-12-06 20:06:

Howdy,

I was just working on a new server supposedly running the latest version 
of GNU/Linux and encounted a problem with 'echo'.


On every other *nix system I've used, both the built-in echo in 'sh' (I 
know there's variations and that's why the scripts I'm using use 
/bin/echo) and /bin/echo work like this:


RayD$ /bin/echo -n "blah"
blahRayD$

RayD$ /bin/echo "blah\c"
blahRayD$

On this "brand-new" linux box, they behave like this:

:/bin/echo -n "blah"
blah:

:/bin/echo "blah\c"
blah\c
:

Also, the man pages state that the '-e' option is default:

Without -E, the following sequences are recognized and interpolated:

Not sure if this is a behavior change, error in the documentation, 
legitimate bug, or system admin error.



Here's what system info I have:



[snip]


:/bin/echo --version
echo (GNU coreutils) 5.2.1
Written by FIXME unknown.


I'd say the behaviour is correct and in line with current coreutils
(mine is 6.4); quoting echo(1):



ECHO(1)  User Commands ECHO(1)

NAME
   echo - display a line of text

SYNOPSIS
   echo [OPTION]... [STRING]...

DESCRIPTION
   Echo the STRING(s) to standard output.

   -n do not output the trailing newline

   -e enable interpretation of backslash escapes

   -E disable interpretation of backslash escapes (default)  <--

   --help display this help and exit

   --version
  output version information and exit

   If -e is in effect, the following sequences are recognized:

   \0NNN  the character whose ASCII code is NNN (octal)

   \\ backslash

   \a alert (BEL)

   \b backspace

   \c suppress trailing newline

   \f form feed

   \n new line

   \r carriage return

   \t horizontal tab

   \v vertical tab

   NOTE: your shell may have its own version of echo, which usually super-
   sedes the version described here.  Please refer to your  shell's  docu-
   mentation for details about the options it supports.

AUTHOR
   Written by FIXME unknown.



bjd


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

Re: shred command. Autodetect file type

[Bauke Jan Douma]

John Darrington wrote on 05-12-06 01:41:

Why not use the stat system call to find out what type of file
we're dealing with, and then remove or not remove accordingly ?
 
 That might cause a suprise in some cases.  It is better to have a

 consitent behaviour than have different behaviours for different types
 of files. 


Why?  Other core GNU commands modify their behaviour based upon the
file type.  For example tar and ls treat their arguments differently
depending upon whether they are names of directories or names of
files.


Maybe that's justified by the fact that they're a tad less destructive?

bjd



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

Re: [coreutils] "cut" from last column

[Bauke Jan Douma]

Philip Ganchev wrote on 02-12-06 23:33:

Hi

I have a suggestion to allow the "cut" command to understand column
(field) numbers relative to the last column.  I find I need this
functionality very often when working with tabular data.  Currently,
the expression to achieve this is clumsy:

cut -f 3,5-$(echo $(head -1 myfile | wc -w) - 3 | bc) myfile

The new syntax could use +1 to specify the last column, +2 to specify
the second-last, etc.  This syntax is the same as for the "tail"
command.  Then you can achieve the same as the above expression by
writing:

cut -f 3,5-+3 myfile


Couldn't you use rev(1).  If you're using Linux, it's in
the util-linux package.
rev < myfile | cut -something | rev

bjd



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

[Fwd: Re: man jobs, does it do what is expected to be done?]

[Bauke Jan Douma]

j j wrote on 01-12-06 13:14:

If I do man jobs, then the page showed is:


Do 'help jobs' instead; then take a look at 'help'.
This is all bash builtins.

bjd




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

Re: Feature request: "df -c" - Totals at the base of each collumn

[Bauke Jan Douma]

[EMAIL PROTECTED] wrote on 28-11-06 16:20:

With the GNU implementation of df, it'd be really, really nice to be
able to see a total amount of free diskspace.

/dev/hdb1  70G   54G   17G  77% /mnt/hdb1
/dev/hdb2  70G   63G  7.5G  90% /mnt/hdb2
/dev/hdb3  95G   91G  3.2G  97% /mnt/hdb3
TOTAL 235G 208G   28G  83%

Yes, this could be scripted.


I vote against it, for this very reason, plus it's feature creep.
Plus it might require a name change: df -> sf ...

bjd


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

Re: include dos2unix/unix2dos in coreutils ?

[Bauke Jan Douma]

Mike Frysinger wrote on 15-11-06 00:42:

On Tuesday 14 November 2006 18:16, Pádraig Brady wrote:

Alfred M. Szmidt wrote:

Would anyone like to take care of the miscutils project?

I would like to maintain miscutils.


cant we have a more unixish name ?  frillutils / not-so-coreutils / 
coreutils-extra / coreishutils ...

-mike


How about odd-utils.  The tarball will be named oddball then ;-)

bjd




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

Re: include dos2unix/unix2dos in coreutils ?

[Bauke Jan Douma]

Matthew Woehlke wrote on 13-11-06 17:56:

Actually, dos2unix (the one I have, anyway) *does* do a few things that 
aren't so trivially done with sed. For one, it is in-place (unless told 
otherwise), and has --keepdate. In-place is awkward to do with sed.


At present I have my own shell script (using sed) that does exactly that,
keep the date, using two small home-written binary utilities to preserve
the time.  To me, this prerequisite is a argument /pro/ having coreutils
provide dos2unix/unix2dos (fromdos/todos, d2u/u2d, whatever).

Also, I find myself sometimes converting whole directories full of DOS-like
files, and a binary executable might be just a little more efficient here.

My current script btw. also handles possible multiple consecutive DOS
newlines.

Wow, that was a TERRIBLE example! ;-) I've used dos2unix enough to be 
annoyed by its lack of pervasiveness, but I don't know that I've *ever* 
used dirname (maybe 'basename', and only in scripts). To use your 
argument, dirname (and basename) is a simple hack that can be written as 
a trivial bash substitution. :-) Does that mean dirname should not be in 
coreutils?


Also, I find myself sometimes converting whole directories full of DOS-files,
and a binary executable might be just a little more efficient here.

In short, I agree with Woehlke here.


bjd




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

Re: include dos2unix/unix2dos in coreutils ?

[Bauke Jan Douma]

Alfred M. Szmidt wrote on 13-11-06 18:12:


What next? HTML to text, and text to HTML conversion programs in
coreutils?  This would probobly be more useful than dos2unix...


The argument doesn't wash - it's a wrong analogy, html and text are
different mime-types.
A DOS text file and a Unix text file are the same mime-type, plain
text, they just differ in line-endings, features of the OS.

bjd



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

Re: du feature request

[Bauke Jan Douma]

Logan Hansen wrote:

Sirs,

I would like to request a feature to be added to the 'du' command:

a command line switch to sort output by directory name or by size of 
directory


How about adding a gui to du?

Maybe you should read up on the de-facto UNIX philosophy
in documents such as http://www.faqs.org/docs/artu/ch01s06.html

Once having grasped this 'philosophy', you'll learn to appreciate
the aesthetics (if I may) of it.  The UNIX world will become clear
to you.  With it will come a hunbled attitude towards 'featuritis'.

bj


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

Re: coreutils-6.3: install: basic-1 fails

[Bauke Jan Douma]

Jim Meyering wrote:

Bauke Jan Douma <[EMAIL PROTECTED]> wrote:

Paul Eggert wrote:

Bauke Jan Douma <[EMAIL PROTECTED]> writes:


cp: cannot open
`/sw/coreutils/coreutils-6.3/tests/install/../../src/dd' for reading:

What are the permissions of that file?  That is, what is the output
of
this command:
ls -l /sw/coreutils/coreutils-6.3/tests/install/../../src/dd

$> ls -l /sw/coreutils/coreutils-6.3/tests/install/../../src/dd
-rwx--x--x 1 root staff 45532 Oct  3 18:06 
/sw/coreutils/coreutils-6.3/tests/install/../../src/dd


That file is readable only by root.
So if you're running tests as some other user, that would
explain the failure you saw.


Yes, I am running the tests as root, but apparently the basic-1
test re-runs itself as user nobody (65534), which explains the
failure.

Presently though that doesn't explain, to me at least, why
'require-non-root' is a show-stopper when I'm running the
make check as root initially.

bj


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

Re: coreutils-6.3: install: basic-1 fails

[Bauke Jan Douma]

Paul Eggert wrote:

Bauke Jan Douma <[EMAIL PROTECTED]> writes:


cp: cannot open
`/sw/coreutils/coreutils-6.3/tests/install/../../src/dd' for reading:


What are the permissions of that file?  That is, what is the output of
this command:

ls -l /sw/coreutils/coreutils-6.3/tests/install/../../src/dd


$> ls -l /sw/coreutils/coreutils-6.3/tests/install/../../src/dd
-rwx--x--x 1 root staff 45532 Oct  3 18:06 
/sw/coreutils/coreutils-6.3/tests/install/../../src/dd

$> /sw/coreutils/coreutils-6.3/tests/install/../../src/dd if=/dev/zero of=out 
bs=1c count=32
32+0 records in
32+0 records out
32 bytes (32 B) copied, 0.000135955 s, 235 kB/s

I was wanting to investigate this further but when I came across
some old note about `strip' (mine is binutils GNU strip 2.17) in
the basic-1 script at that point my phone rang...
I'll look into it tomorrow.

bj


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

coreutils-6.3: install: basic-1 fails

[Bauke Jan Douma]

$> who am i
root pts/3Oct  3 17:38 (:0.0)

$> uname -a
Linux skyscraper 2.6.18 #3 PREEMPT Wed Sep 27 21:02:18 CEST 2006 i686 GNU/Linux

$> RUN_VERY_EXPENSIVE_TESTS=yes make check
...
Making check in install
make[2]: Entering directory `/sw/coreutils/coreutils-6.3/tests/install'
make  check-TESTS
make[3]: Entering directory `/sw/coreutils/coreutils-6.3/tests/install'
PASS: trap
cp: cannot open `/sw/coreutils/coreutils-6.3/tests/install/../../src/dd' for reading: 
Permission denied

cp: cannot stat `dd': No such file or directory
strip: 'dd2': No such file
ginstall: cannot stat `dd': No such file or directory
ls: cannot access dir/dd: No such file or directory
FAIL: basic-1
PASS: create-leading
PASS: d-slashdot
==
1 of 4 tests failed
Please report to bug-coreutils@gnu.org
==
make[3]: *** [check-TESTS] Error 1
make[3]: Leaving directory `/sw/coreutils/coreutils-6.3/tests/install'
make[2]: *** [check-am] Error 2
make[2]: Leaving directory `/sw/coreutils/coreutils-6.3/tests/install'
make[1]: *** [check-recursive] Error 1
make[1]: Leaving directory `/sw/coreutils/coreutils-6.3/tests'
make: *** [check-recursive] Error 1



bj


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

Re: bug in date command

[Bauke Jan Douma]

On Fri, May 14, 2004 at 11:27:53AM +0200, Andreas Schwab wrote:
> Bauke Jan Douma <[EMAIL PROTECTED]> writes:
> 
> > On Fri, May 14, 2004 at 12:51:20AM +0200, Andreas Schwab wrote:
> >> "duncan brown" <[EMAIL PROTECTED]> writes:
> >> 
> >> > date +%C reports the 20th century, but we've been in the 21st since jan 01, 
> >> > 00:00:00
> >> 
> >>   %C   century (year divided by 100 and truncated to an integer) [00-99]
> >
> > Surely this must be a Y2K-ism in the standard, no?
> 
> Why?
> 
> $ date +%C%y
> 2004

I am sorry, I answered under the assumption that you wrote
'truncated to the closest integer'.

Still, there is discrepancy in one common meaning of the word
'century' and the meaning it has here, as the original
poster noted.  Here it apparently means something like 'the
century part of the full year-number.'

BJ


___
Bug-coreutils mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-coreutils

Re: how to create errors on floppy disks

[Bauke Jan Douma]

On Thu, May 13, 2004 at 07:12:46PM +0300, Buciuman Adrian wrote:
> 
> 
>   Can fdutils be used to make some sectors  ( but not all  ) on a floppydisk
> unreadable ( i.e. give an I/O error when read from /dev/fd0 ) ?
>   This can be used  to test and debug dd  and maybe other utilities ( for
> data recovery etc )

Use a magnet or a hairpin.

BJ


___
Bug-coreutils mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-coreutils

Re: bug in date command

[Bauke Jan Douma]

On Fri, May 14, 2004 at 12:51:20AM +0200, Andreas Schwab wrote:
> "duncan brown" <[EMAIL PROTECTED]> writes:
> 
> > date +%C reports the 20th century, but we've been in the 21st since jan 01, 
> > 00:00:00
> 
>   %C   century (year divided by 100 and truncated to an integer) [00-99]

Surely this must be a Y2K-ism in the standard, no?

BJ


___
Bug-coreutils mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-coreutils

Re: right-justification of uid's/gid's is a mistake.

[Bauke Jan Douma]

On Thu, Apr 15, 2004 at 12:32:56AM -0700, Paul Eggert wrote:
> > I think there's no justification (pun intended) for the current
> > right-justification of uid's/gid's -- it really looks ugly.
> 
> In some cases it looks better, in some cases it looks worse.
> Here's an example where it looks better:
> 
>$ old-ls -l a b c
>-rw-r--r--  1 99   109 0 Apr 15 00:20 a
>-rw-r--r--  1 100  999 0 Apr 15 00:20 b
>-rw-r--r--  1  10000 Apr 15 00:20 c
>$ new-ls -l a b c
>-rw-r--r--  1   99  109 0 Apr 15 00:20 a
>-rw-r--r--  1  100  999 0 Apr 15 00:20 b
>-rw-r--r--  1  1000 0 Apr 15 00:20 c
> 
> as integers are usually printed right-adjusted, not left-adjusted.

I agree with you here, but then again these are all numeric.

> I agree that your example looks a bit outre, but then the data were
> pretty outre too.
> 
> One possible change would be to right-adjust the numbers, but to have
> their right margin be at a minimal location.  That would cause the
> output to have the "clean formatting" that you suggested, while still
> preserving the right-adjustedness of numbers in the example above.

I'm not sure I follow you here -- what format string would that
be in C?

Anyway, I saw some talk the other day about having a --format
option for 'ls' and others.  I don't know if that idea is gonna
fly, but I wouldn't be against it -- would enable you to please
100% of the people 100% of the time.

-BJ


___
Bug-coreutils mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-coreutils

[RFC] ls: new option --full-path

[Bauke Jan Douma]

Good morning,

At the risk of being diagnosed with featuritis, I would like
propose here a new option to 'ls', namely --full-path / -P,
which would enable you to get an unambiguous fully qualified
path for the files listed.

Example:

$ cd / && ls -l --full-path /usr/X11R6/bin | head -n 5
total 17328
lrwxrwxrwx1 root staff   7 May 18 11:55 /usr/X11R6/bin/X -> 
/usr/X11R6/bin/XFree86
-rws--x--x1 root staff 1621548 May 20 00:03 /usr/X11R6/bin/XFree86
-rwxr-xr-x1 root staff2764 Sep 30  2002 /usr/X11R6/bin/XWindows
-rwx--x--x1 root staff   27494 Mar  6 14:41 /usr/X11R6/bin/Xmark

Full path output would be useful for instance when making file
system 'ls-laR' dumps that you would expect people to grep for
file locations.

Before this is implemented -- I'm not sure if it should be
the full path relative to / or relative from cwd.

I seem to recall I was trying to implement this about two
years ago with the aid of 'find' and 'xargs', but had a hard
time -- something with quotes and whitespace iirc.  Now that I
think of it, I believe I had a working diff for ls.c at the
time.

Any thoughts?

-BJ


___
Bug-coreutils mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-coreutils

right-justification of uid's/gid's is a mistake.

[Bauke Jan Douma]

Hi,

It's unclear to me if this has been addressed definitively yet,
so here goes nothing:

I think there's no justification (pun intended) for the current
right-justification of uid's/gid's -- it really looks ugly.

Sure it stands out, but I don't think ls should be in the business
of doing special formatting by default based on someone's arbitrary
definition of what needs a user's special attention -- it's contrary
to UNIX philosophy btw.

Ls should basically just list files, and their associated data, by
default in a clean format -- nothing more.

BJ


ridiculous formatting that I don't care for:
total 16
drwx--x--x   3 root  staff 4096 Apr 10 23:27 .
drwxrwxrwt  17 root  staff 8192 Apr 10 23:23 ..
-rw---   1   666 staff0 Apr 10 23:27 foo
dr-xr-xr-x   8 ftp   admin 4096 Mar 20  2002 ftp
-rw---   1 aliceinwonderland staff0 Apr 10 23:27 humpty-dumpty

clean formatting:
total 16
drwx--x--x   3 root  staff 4096 Apr 10 23:27 .
drwxrwxrwt  17 root  staff 8192 Apr 10 23:29 ..
-rw---   1 666   staff0 Apr 10 23:27 foo
dr-xr-xr-x   8 ftp   admin 4096 Mar 20  2002 ftp
-rw---   1 aliceinwonderland staff0 Apr 10 23:27 humpty-dumpty


___
Bug-coreutils mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-coreutils