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

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

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

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 t

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

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

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

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 . Filesyst

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

[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-co

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

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

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

[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

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

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

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

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,

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

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,

Re: Command touch and irregular file names

--- 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 wron

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

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 un

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

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 thi

security bug in cp(1)

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.

Re: security bug in cp(1)

-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 fi

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

-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)

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

-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 -e

Re: security bug in cp(1)

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

Re: Obsolete fileutils, shellutils, textutils web pages updated

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 fou