Re: Could we have a flag to tell us which directories were actually removed?

[Andreas Schwab]

Reuben Thomas <[EMAIL PROTECTED]> writes:

> In this case, I don't see a good way of getting the same information. The
> best way I could come up with that was short enough for command-line use
> was use find to find directories with only 2 symlinks to them, but of
> course that only works on some filing systems.

$ find -type d -empty

Andreas.

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


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

Re: Could we have a flag to tell us which directories were actually removed?

[Jim Meyering]

Andreas Schwab <[EMAIL PROTECTED]> wrote:
> Reuben Thomas <[EMAIL PROTECTED]> writes:
>
>> In this case, I don't see a good way of getting the same information. The
>> best way I could come up with that was short enough for command-line use
>> was use find to find directories with only 2 symlinks to them, but of
>> course that only works on some filing systems.
>
> $ find -type d -empty

Note that if you simply want to remove all empty directories
(including e.g., those rendered empty by removing leaf dirs),
you should also use -depth and -delete:

  find . -depth -type d -empty -delete

Though, the -delete predicate is provided by GNU find,
it is not specified by POSIX.


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

Re: Could we have a flag to tell us which directories were actually removed?

[Reuben Thomas]

On Thu, 16 Aug 2007, Jim Meyering wrote:


Andreas Schwab <[EMAIL PROTECTED]> wrote:

Reuben Thomas <[EMAIL PROTECTED]> writes:


In this case, I don't see a good way of getting the same information. The
best way I could come up with that was short enough for command-line use
was use find to find directories with only 2 symlinks to them, but of
course that only works on some filing systems.


$ find -type d -empty


Note that if you simply want to remove all empty directories
(including e.g., those rendered empty by removing leaf dirs),
you should also use -depth and -delete:

 find . -depth -type d -empty -delete


Thanks both of you, that's great.

--
http://rrt.sc3d.org/
Kleineken: refreshes the dimensions other beers cannot reach


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

Re: mv can't change filename case on case-insensitive file systems

[Matthew Woehlke]

Eric Blake wrote:

[snip] Mac HFS is the other biggest case-preserving
case-insensitive system out there; can anyone comment on
whether rename(2) is a no-op or changes case when given two
case-wise distinct spellings of the same file?


Adding to what Jonathan already posted...

$ df -T .
FilesystemType   1K-blocks  Used Available Use% Mounted on
/dev/disk0s3   hfs80287128  12435372  67595756  16% /
$ touch foo
$ mv foo Foo
mv: `foo' and `Foo' are the same file
$ mv --version
mv (GNU coreutils) 6.9
Copyright (C) 2007 Free Software Foundation, Inc.
This is free software.  You may redistribute copies of it under the 
terms of the GNU General Public License 
.

There is NO WARRANTY, to the extent permitted by law.

Written by Mike Parker, David MacKenzie, and Jim Meyering.
$ /bin/mv foo Foo # /bin/mv is not coreutils
$ ls ?oo
Foo
$ perl -e 'rename("Foo","foo")'
$ ls ?oo
foo
$ uname -srp
Darwin 8.8.0 powerpc
$

--
Matthew
"So long, and thanks for all the fish" -- the dolphins



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

Re: who(1) shows more than one user on the same terminal

[Paul Eggert]

[EMAIL PROTECTED] writes:

> Perhaps "stale utmp entries?"

Yes, that's what it most likely is.  Clearing out the utmp file should
work around the problem.


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

who(1) shows more than one user on the same terminal

[jidanni]

Is it normal to see two users on the same tty?
$ who
jidanni  pts/0 ...
ralphpts/0 ...
jim  pts/1 ...
$ ls -l /dev/pts/0
crw--w 1 jidanni tty 136, 0 2007-08-17 00:58 /dev/pts/0

The administrator (Dreamhost) says
> You could potentially see many more than that at any given time.
> There are other users with whom you share the hosting, as well as
> the admins. This is normal.

Yes, many users, but not on the same pts/0?!
ps -u anybody_other_than_me won't show anything, so I can't
investigate further. Perhaps "stale utmp entries?"


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

Re: who(1) shows more than one user on the same terminal

[Phillip Susi]

[EMAIL PROTECTED] wrote:

Is it normal to see two users on the same tty?
$ who
jidanni  pts/0 ...
ralphpts/0 ...
jim  pts/1 ...
$ ls -l /dev/pts/0
crw--w 1 jidanni tty 136, 0 2007-08-17 00:58 /dev/pts/0

The administrator (Dreamhost) says

You could potentially see many more than that at any given time.
There are other users with whom you share the hosting, as well as
the admins. This is normal.


Yes, many users, but not on the same pts/0?!
ps -u anybody_other_than_me won't show anything, so I can't
investigate further. Perhaps "stale utmp entries?"


Yes, stale utmp entry.



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

Re: coreutils-6.9 problem with --preserve-timestamps

[Paul Eggert]

Warren L Dodge <[EMAIL PROTECTED]> writes:

>For applications portability, the utime() function should be used to 
> set file access and modification times instead of utimes().

That's just portability advice.  We can ignore it.  utimes is supposed
to work and is preferable to utime in this situation.  For details
please see Ulrich Drepper's paper "Defensive Programming for Red Hat
Enterprise Linux" .

> To make sure I
> did the same operations in a true nfs directory also.

Since it occurs only with NFS, it appears to be a bug in the NFS
implementation you're using, either on the client or the server side.  See

and look for #183208 for an example of this sort of bug.  I'm not
expert in Red Hat 4 but I imagine someone else on this list is, and
may be able to pinpoint the bug more precisely.  Good luck.


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

Re: mv can't change filename case on case-insensitive file systems

[John Cowan]

Eric Blake scripsit:

> You missed my earlier remark - since POSIX requires case sensitivity,
> a case-insensitive file system is not specified by POSIX, therefore,
> a platform may do whatever it likes with rename(2), including change
> the case (rather than be a no-op).

Well and good.  In fact, however, both Cygwin and the Linux VFAT driver
do treat rename("Foo", "foo") as a no-op.

> And now that we have proven that current Linux behaves differently
> than current cygwin,

We have?

> which behavior should mv(1) promote?  I would argue that being able
> to change case is more useful, particularly based on the volume of
> complaints of people on case-insenstive systems who don't like the
> current solution of using an intermediate name.

+1

-- 
All Norstrilians knew what laughter was:John Cowan
it was "pleasurable corrigible malfunction".[EMAIL PROTECTED]
--Cordwainer Smith, Norstrilia


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

Re: mv can't change filename case on case-insensitive file systems

[Jonathan Lennox]

On Thursday, August 16 2007, "John Cowan" wrote to "Eric Blake, John Cowan, 
Jonathan Lennox, bug-coreutils@gnu.org" saying:

> Eric Blake scripsit:
> 
> > You missed my earlier remark - since POSIX requires case sensitivity,
> > a case-insensitive file system is not specified by POSIX, therefore,
> > a platform may do whatever it likes with rename(2), including change
> > the case (rather than be a no-op).
> 
> Well and good.  In fact, however, both Cygwin and the Linux VFAT driver
> do treat rename("Foo", "foo") as a no-op.

No, on Cygwin rename(2) will change file case:

$ touch foo
$ echo *oo
foo
$ perl -e 'rename "foo", "Foo" or die($!)'
$ echo *oo
Foo
$ uname -srvmo
CYGWIN_NT-5.1 1.5.24(0.156/4/2) 2007-01-31 10:57 i686 Cygwin


On Cygwin, rename(2) of regular files just wraps the Windows MoveFile API,
after the usual path transformations and the like.


-- 
Jonathan Lennox
lennox at cs dot columbia dot edu


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

Re: Command touch and irregular file names

[Tong Sun]

--- Brian Dessent <[EMAIL PROTECTED]> wrote:

> You can do:...

Thanks for the comprehensive solution. 

> > I think if the touch command uses the standard gnu getopt lib, then
> > the above code should work, shouldn't it?
> 
> I don't think it should...

My silly mistake, I put the -- at the wrong spot. :-)

cheers




  

Fussy? Opinionated? Impossible to please? Perfect.  Join Yahoo!'s user panel 
and lay it on us. http://surveylink.yahoo.com/gmrs/yahoo_panel_invite.asp?a=7 



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

Re: mv can't change filename case on case-insensitive file systems

[John Cowan]

Jonathan Lennox scripsit:

> No, on Cygwin rename(2) will change file case:

Ah, sorry.  I had mixed up what rename(2) does with what mv does.

-- 
First known example of political correctness:   John Cowan
After Nurhachi had united all the other http://www.ccil.org/~cowan
Jurchen tribes under the leadership of the  [EMAIL PROTECTED]
Manchus, his successor Abahai (1592-1643)
issued an order that the name Jurchen should   --S. Robert Ramsey,
be banned, and from then on, they were all   The Languages of China
to be called Manchus.


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

Re: coreutils-6.9 problem with --preserve-timestamps

[Andreas Schwab]

Paul Eggert <[EMAIL PROTECTED]> writes:

> Since it occurs only with NFS, it appears to be a bug in the NFS
> implementation you're using, either on the client or the server side.  See
> 
> and look for #183208 for an example of this sort of bug.

Probably the same issue as described in this thread:
.

Andreas.

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


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

security bug in cp(1)

[Soren Spies]

I just noticed that cp -p doesn't update the group on a file before
writing data into the target.  That means that during the copy, users
you didn't intend to be able to read the file can read the file.

Running running Debian GNU/Linux 4.0 (etch) on i686.

techhouse-0:/scratch/soren=> ls -l spool.16Aug07
-rw-r- 1 soren adm 43105807 2007-08-15 21:17 spool.16Aug07
techhouse-0:/scratch/soren=> cp -p spool.16Aug07 whenadm
[3] + Stopped  cp -p spool.16Aug07 whenadm
techhouse-0:/scratch/soren=> ls -l whenadm
-rw-r- 1 soren ssl-cert 16728064 2007-08-16 21:41 whenadm
[huh, why can ssl-cert users (26 of them) read my file?]
[oddly my primary GID is ssl-cert; I think that used to be 'users' ;p]
techhouse-0:/scratch/soren=> fg
cp -p spool.16Aug07 whenadm
`[now that it's finished]
techhouse-0:/scratch/soren=> ls -l whenadm
-rw-r- 1 soren adm 43105807 2007-08-15 21:17 whenadm
[and finally it's right]


cp(1) says that  is the place for cp bugs.
Is there a way to search the bug database? gnu.org's fileutils page
()
has a link to bugs but it leads to a file-not-found page.  :P

I can't believe that no one has noticed this bug before and yet if they
had, surely it would have been fixed before.  Cc'ing .


-Soren


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

Re: security bug in cp(1)

[Eric Blake]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

According to Soren Spies on 8/16/2007 8:16 PM:
> I just noticed that cp -p doesn't update the group on a file before
> writing data into the target.  That means that during the copy, users
> you didn't intend to be able to read the file can read the file.

This was already noticed and fixed in 6.9.  From the NEWS file:

 "cp --preserve=mode" would create directories that briefly had
  too-generous permissions in some cases.  For example, when copying a
  directory with permissions 777 the destination directory might
  temporarily be setgid on some file systems, which would allow other
  users to create subfiles with the same group as the directory.  Fix
  similar problems with 'install' and 'mv'.

Consider upgrading.

> cp(1) says that  is the place for cp bugs.
> Is there a way to search the bug database?

http://lists.gnu.org/archive/html/bug-coreutils/

> gnu.org's fileutils page
> ()
> has a link to bugs but it leads to a file-not-found page.  :P

fileutils is obsolete, ever since it was folded into coreutils.  We try to
correct those pages as people find and report them.

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

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

iD8DBQFGxRT684KuGfSFAYARAlYAAKDP3DaEpUoR1E/Km07t0K9hi1s+ngCePpdJ
bzkfDF1UWEdA+F6PvY3Xa64=
=2maz
-END PGP SIGNATURE-


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

Re: Bug in od with "-j" option?

[Eric Blake]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

According to Paul GHALEB on 8/13/2007 10:33 AM:
> 
> IOW, when one tries to skip exactly the size of the file, od acts as if
> it ignored the "-j size" option.

[This mail assumes your sed obeys POSIX on this sequence:

$ seq 3 > foo
$ (sed -n q; cat) < foo
2
3
$

If this is not the case, replace 'sed -n q' with 'head -n1 > /dev/null']

While we're at it, od has another POSIX-compliance bug, when stdin is
seekable and starts life in the middle of the file:

$ seq 3 > blah
$ (sed -n q; od -tx1z -j 7) http://enigmail.mozdev.org

iD8DBQFGxRxF84KuGfSFAYARAk3/AKCl9e4RI+EYpKjG1igIfAsXfLVAtQCgy1YN
Sww8fEBmLT7P1pfmh/L79Nc=
=Wi5b
-END PGP SIGNATURE-


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

Re: Could we have a flag to tell us which directories were actually removed?

[Eric Blake]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

According to Reuben Thomas on 8/16/2007 4:12 AM:
>> Note that if you simply want to remove all empty directories
>> (including e.g., those rendered empty by removing leaf dirs),
>> you should also use -depth and -delete:
>>
>>  find . -depth -type d -empty -delete

Furthermore, you can combine this with -print to get a list of which
directories were successfully deleted.

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

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

iD8DBQFGxR5a84KuGfSFAYARAvo5AJ9NhS8zKU1O8RWUXsg3nOO2w28ebACdEdAy
LqEH9XMlx/l7e35bFNdCauc=
=rFHK
-END PGP SIGNATURE-


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

Re: security bug in cp(1)

[Bob Proulx]

Eric Blake wrote:
> Soren Spies wrote:
> > gnu.org's fileutils page
> > ()
> > has a link to bugs but it leads to a file-not-found page.  :P
> 
> fileutils is obsolete, ever since it was folded into coreutils.

Note that the http://www.gnu.org/software/fileutils/ page says this:

  Fileutils, Shellutils, and Textutils have been combined into the GNU
  Coreutils package.  All further development and discussion is now
  taking place as Coreutils.  The last separate versions were
  fileutils-4.1.11, textutils-2.1, and sh-utils-2.0.15.  The first major
  release of coreutils-5.0 was announced on Fri, 4 April 2003.

  Please refer to the new coreutils home page at
  http://www.gnu.org/software/coreutils/ for more information.

Bob


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

Re: Obsolete fileutils, shellutils, textutils web pages updated

[Bob Proulx]

More cleanup...

I have removed all of the files in the obsolete *utils web page
subdirectories.  These were the old online versions of the texinfo
manual pages for fileutils and textutils no longer updated nor
relevant.  Since these were recently discovered to still be around and
wrong answers found there I think it best if they are removed to
prevent further future confusion.

Bob


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