bug#60989: [PATCH] rm: fail on duplicate input if force not enabled

[Philip Rowlands]

On Sat, 21 Jan 2023, at 13:05, Łukasz Sroka wrote:
> When the input files contain duplicates, then the rm fails. Because
> duplicates occur most often when the * is used and the shell unwraps it.
> There is a very common scenario when a user accidentally enters space
> after a filename, or enters space instead of forward slash.

To fail on duplicate FILE args, this bash function would do (lightly tested, 
doesn't attempt getopt processing):

function safe_rm {
  local -A seen
  local file
  for file in "$@"; do
if [[ -v ${seen[$file]} ]]; then
  echo "error: duplicate name '$file'" 1>&2
  return 1
fi
seen[$file]=1
  done

  # no dupes seen
  command rm "$@"
}

and could be used today, without waiting for the next coreutils release.

As an aside, I could be reading it wrong but the coreutils manual suggests the 
file arguments are optional
   rm [option]… [file]…


Cheers,
Phil

bug#72756: Potential Bug/Vuln in test.c

[Philip Rowlands]

On Wed, 21 Aug 2024, at 18:29, Nathan Hays via GNU coreutils Bug Reports wrote:
> Test:
> ~~~bash
> testvar=''
> [ -n $testvar ]
> echo -n unquote exit $?
> [ -n "$testvar" ]
> echo -n quote exit $?
> [ -z $testvar ]
> echo -z unquote exit $?
> [ -z "$testvar" ]
> echo -z quote exit $?
> ~~~

For this code snippet, the shellcheck linter reports

[ -n $testvar ]
 ^--^ SC2070: -n doesn't work with unquoted arguments. Quote or use [[ 
]].
 ^--^ SC2086: Double quote to prevent globbing and word splitting.

Did you mean:
[ -n "$testvar" ]

For more information:
  https://www.shellcheck.net/wiki/SC2070 -- -n doesn't work with unquoted arg...



Cheers,
Phil

Re: Error Encountered when updating

[Philip Rowlands]

On Wed, 10 Oct 2007, [EMAIL PROTECTED] wrote:


FYI
The following error was encountered when doing an update:

Setting up linux-image-2.6.15-29-386 (2.6.15-29.60) ...
/usr/share/initramfs-tools/scripts/functions: line 82: [: too many arguments
basename: extra operand `2007'
Try `basename --help' for more information.
Failed to create initrd image.
dpkg: error processing linux-image-2.6.15-29-386 (--configure):
subprocess post-installation script returned error exit status 2


The error message you're seeing from basename simply states that it has 
been called incorrectly. I'd suggest reporting the problem to whoever 
provided your Linux distro, or the maintainer of the "linux-image" 
package therein.


This is not a bug in basename.


Cheers,
Phil


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

Re: Undocumented cut feature

[Philip Rowlands]

On Thu, 25 Oct 2007, Gambs, David (CONT) wrote:

I have found a consistent "feature" in cut that is causing issues for 
what I am trying to accomplish.


I am pulling data from the system and trying to extract three pieces 
out of that data. What I am finding is that when the field of interest 
is the last field, cut is adding a ^M to the end of the line:


vgdisplay > file1
cat file1 | egrep -e Name -e "PE Size" -e Free > file2
cut -b23- file2 > file3
cut -f1 -d' ' > file1

It is only at the last step that the ^M is added to the end of the 
volume group name extracted.


How did you determine this? Can you give a (short) before-and-after 
example run which explicitly shows cut adding spurious CRs?



And we are at core utilities: coreutils-4.5.3-28.4


If there is a bug and it's fixed in the latest version of coreutils, the 
only recourse you'll have is to petition the vendor (RedHat in this 
case) to release an update, as there's nothing that the coreutils 
maintainers can directly do to RHEL's packages.


It would be helpful if you were able to test with the latest 
(non-snapshot) release, which can be found here: 
http://ftp.gnu.org/gnu/coreutils/coreutils-6.9.tar.bz2



Cheers,
Phil


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

Re: Trying to get sort keys to work

[Philip Rowlands]

On Fri, 26 Oct 2007, mario wrote:

One of the biggest frustrations with the "sort" utility is figuring out how to 
tell it where exactly the keys are on each line.  For example, I have a file 
which contains, in part,


MI#4617 ROM11  FAD_13 vss! vss! nmos  L=0.18U W=0.69U
MI#4765 ROM0N  FAD_11 vss! vss! nmos  L=0.18U W=0.69U
MI#4749 ROM8N  FAD_15 vss! vss! nmos  L=0.18U W=0.69U


I took the liberty of re-wrapping the lines where it seemed appropriate.

I really want to sort FIRST on column 3, and then on the numeric part of 
column 2.  I would think that the sort command would be something like


sort -s -k3 -k2.4n


-k3 means "from key 3 until the end of the line". -k3,3 will restrict 
just to the single field.


BUT this doesn't work.  It sorts OK on column 3, but then does nothing 
with the second sort key.


It would be incredibly useful if there were some mode in which sort 
would just report each line and the sort keys found on that line, so 
that I can make sure that I'm properly communicating how to find the 
darn keys!


I agree, a debug mode for sort would be very useful.


Cheers,
Phil


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

Re: groupadd man page

[Philip Rowlands]

The group* utilities provided with Fedora are not part of GNU coreutils.

Unfortunately the website mentioned in the package header 
(http://shadow.pld.org.pl/) seems to be down right now. Perhaps the 
Redhat bug tracking system would be a better place to report this?



Cheers,
Phil


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

Re: [bug #21455] date --date "" "+test" fails ONLY WITHIN CERTAIN TIME PERIOD #$%^%

[Philip Rowlands]

On Mon, 29 Oct 2007, Mischa Molhoek wrote:

ok, here is the text version, because the image is remove by accident 
:)


It's simpler to debug problems reported by text, not pictures.


[titan: mischa] ~> date --version
date (GNU coreutils) 5.97
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 David MacKenzie.
[titan: mischa] ~> date --date "" "+test"
test

[titan: mischa] ~> sudo date -s "Sun Oct 28 22:00:53 CET 2007"
Sun Oct 28 22:00:53 CET 2007

[titan: mischa] ~> date --date "" "+test"
date: invalid date `'


You don't need the "+test", it's invalid by itself :)


[titan: mischa] ~> sudo rdate -s ntp.xs4all.nl

[titan: mischa] ~> date
Mon Oct 29 12:08:41 CET 2007



[titan: mischa] ~> date --date "" "+test"
test


You don't give your timezone explicitly, so I'm going to guess you're in 
a region which follows Central European Time / Central European Summer 
Time.


I hacked up the following to avoid resetting my system clock all over 
the place:


- clock_gettime.c ---
#include 
#include 
#include 

int clock_gettime(clockid_t clk_id, struct timespec *tp) {
if (clk_id != CLOCK_REALTIME) {
errno = EINVAL;
return -1;
}
char *faketime = getenv("FAKETIME");
if (! faketime ) {
errno = EINVAL;
return -1;
}
if (tp) {
tp->tv_nsec = 0;
tp->tv_sec = atol(faketime);
}
return 0;
}
-

gcc -c -fPIC clock_gettime.c -D_GNU_SOURCE
gcc -shared -fPIC -o clock_gettime.so clock_gettime.o
for anyone following at home.

Firstly, let's see what date -d "" does?

$ date -d ""
Mon Oct 29 00:00:00 GMT 2007

This has shown my current time wound back to the previous midnight. (I 
can't find the documentation which describes this, but let's continue 
regardless.)


$ export TZ=Europe/Paris
$ export FAKETIME=1193605253; LD_PRELOAD=./clock_gettime.so date -d ""
date: invalid date `'

Smells like a DST issue, are we in a DST change?

$ zdump -v Europe/Paris
Europe/Paris  Sun Oct 28 00:59:59 2007 UTC = Sun Oct 28 02:59:59 2007 CEST 
isdst=1 gmtoff=7200
Europe/Paris  Sun Oct 28 01:00:00 2007 UTC = Sun Oct 28 02:00:00 2007 CET 
isdst=0 gmtoff=3600

In Europe/Paris, the boundaries of "invalid" times are 1193533200 -> 
1193612399 inclusive, or

Sun Oct 28 02:00:00 CET 2007 -> Sun Oct 28 23:59:59 CET 2007

If I try the same thing in Europe/Dublin, invalid times become
1193533200 - 1193615999 inclusive, or
Sun Oct 28 01:00:00 GMT 2007 -> Sun Oct 28 23:59:59 GMT 2007

This corresponds to the first second of winter time "isdst=0" and 
persists for the rest of the logical day. I'm wary about diving around 
in unfamiliar code - perhaps someone more familiar with date parsing 
knows how date -d "" is supposed to be treated, and what the problem is 
here?



Cheers,
Phil


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

Re: [bug #21455] date --date "" "+test" fails ONLY WITHIN CERTAIN TIME PERIOD #$%^%

[Philip Rowlands]

On Tue, 30 Oct 2007, Jim Meyering wrote:

I'm hardly the authority on such TZ things, but would have thought the 
invalid zones are those two intervals (one per line), which are 
nominally two and one hours long.  It looks like they're two different 
views of the same two-real-hour interval.  The first uses the DST 
(isdst=1) times, and the second non-DST times.


Date's -d option interprets an empty string just like "0", which is 
interpreted as 00:00 in the current day.


Ah, that makes the problem easier to present:

$ export TZ=Europe/Paris
$ export LD_PRELOAD=./clock_gettime.so
$ FAKETIME=1193533200 date -d ""
date: invalid date `'
$ FAKETIME=1193533200 date -d "0"
Sun Oct 28 00:00:00 CEST 2007

-d "" and -d "0" are not equivalent in this case.


Cheers,
Phil


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

RE: cp -p : timestamp NOT preserved (coreutils 6.9, Linux)

[Philip Rowlands]

On Wed, 31 Oct 2007, Graf, Peter wrote:


Additional info to my former mail:

1) My former mail contained a small inconsistency (after anonymizing the user 
name).  The following messages   show the problem in a consistent way 
(username, home-directory name):


...
prompt%  cp -p ~/.cshrc ~/tmp/.cshrc
prompt%  ls -l ~/.cshrc ~/tmp/.cshrc
-rwxr-x--- 1 pg mygroup 2180 Jan 19  2007 /home/pg/.cshrc
-rwxr-x--- 1 pg mygroup 2180 Oct 31 14:46 /home/pg/tmp/.cshrc
Timestamp was NOT preserved.


Does strace show the cause of the problem?

$ strace -e trace=file cp --preserve=timestamps a b
on my system gives:

[ snipped ld.so stuff ]
stat64("b", 0xd7f0) = -1 ENOENT (No such file or directory)
stat64("a", {st_mode=S_IFREG|0640, st_size=0, ...}) = 0
stat64("b", 0xd63c) = -1 ENOENT (No such file or directory)
open("a", O_RDONLY|O_LARGEFILE) = 3
open("b", O_WRONLY|O_CREAT|O_LARGEFILE, 0100640) = 5
utimes("/proc/self/fd/5", {1193849440, 0}) = 0

"utimes" is the relevent system call, which sets the timestamps on the 
inode.



Cheers,
Phil


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

Re: usb pen blocked after using dd

[Philip Rowlands]

On Sat, 3 Nov 2007, Emmanuel Wilhelm wrote:


sudo dd if=/dev/zero of=/dev/sdx (take a while and wipe everything)

sudo mkfs.vfat -F 32 /dev/sda

The key is on /dev/sdh, but when I did the first command, I receive the
message:


dd: writing to `/dev/sdh': no free space on the device
2+0 red recordings
1+0 written recordings
512 bytes (512 B) copied, 0,00164514 second, 311 kB/s

Is my key hs or have I a hope to solve this problem?


Given your example command, dd will simply write to the device until 
either the read filehandle returns EOF (which /dev/zero should not) or 
the write filehandle returns ENOSPC.


It's possible that your USB drive has a fault. Are you able to use it 
correctly on other systems? Does dd perform as expected when you try a 
different USB drive?



Cheers,
Phil


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

Range problem in expr regex

[Philip Rowlands]

$ export LC_ALL=en_US
$ ./expr --version
expr (GNU coreutils) 6.9-354-68c33a
$ ./expr "a" : "[A-Z]"
0
$ ./expr "b" : "[A-Z]"
1
$ ./expr "a" : "[EMAIL PROTECTED]"
1

Although I see that POSIX has left the implementation of non-POSIX 
locales undefined with respect to range expressions in regexes, this 
looks like a bug nonetheless.


I got as far as regexec.c before getting confused. Problem in expr, or 
problem in the locale definition files on my machine?



Cheers,
Phil


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

Re: Range problem in expr regex

[Philip Rowlands]

On Mon, 5 Nov 2007, Jim Meyering wrote:


In that locale [A-Z] looks like AbBcCdD...


Sneaky :) I will use [A-Za-z] in the future (and advise the person who 
reported the issue to me).



Thanks,
Phil


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

Re: bug swftools

[Philip Rowlands]

On Thu, 8 Nov 2007, Guto Barbosa wrote:


[EMAIL PROTECTED]:~/Desktop/swftools-0.8.1$ make install

[snip]

/bin/bash ../mkinstalldirs /usr/local/share/man/man1
mkdir /usr/local/share/man/man1
mkdir: cannot create directory `/usr/local/share/man/man1': Permission denied


You do not have permission to write to this directory, probably because 
you're running as an non-privileged user.



Im using Ubuntu 7.04
can u help me?


bug-coreutils is a mailing list for reporting problems with GNU 
coreutils only. swftools and Ubuntu have their own mailing lists where 
you can ask for assistance, but in this case it appears that all that's 
needed is to try again as root.



Cheers,
Phil


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

Re: date broken in coreutils-6.7 and new glibc-2.7

[Philip Rowlands]

On Wed, 7 Nov 2007, Clemens Koller wrote:

I have a problem setting the system date together with the time with 
date -s. This happens since I migrated my embedded powerpc system to 
the latest glibc-2.7. glibc-2.3.4 was working fine with same kernel. 
Since I did a full toolchain bootstrap while upgrading glibc, lots of 
stuff has changed.


Conclusion:
1) date -s can only set either the date or the time, but it's clearing the 
time or the date, then.


2) date -s cannot set both: date und time at once. -> resets to
Thu Jan  1 01:00:00 CET 1970


There's nothing special about setting "date only" from the system call's 
point of view - it's just a number of seconds (and microseconds).



[EMAIL PROTECTED]:~$ date
Thu Jan  1 01:00:00 CET 1970

[EMAIL PROTECTED]:~$ date -s 20071107
Wed Nov  7 00:00:00 CET 2007

[EMAIL PROTECTED]:~$ date -s 12:01
Thu Jan  1 12:01:00 CET 1970

[snip repeats]

The rest of the examples show date working correctly, so let's focus on 
the above problem.


date doesn't re-read the clock after it's been set, so you should be 
able to produce the error with just a query:


$ date -d '12:01'

Does this return today's date or Jan 1 1970? It would be useful to see 
the system calls with strace; could you run the mis-firing command and 
copy the system calls?



Cheers,
Phil


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

Re: Follow Up: Re: date broken in coreutils-6.7 and new glibc-2.7

[Philip Rowlands]

On Mon, 12 Nov 2007, Clemens Koller wrote:

As already mentioned, my problem is that I cannot set the date 
reliably, working on glibc-2.7 and coreutils-6.9 (including the 
futimens patch). I did some more tests (the commands have been entered 
one by one... only some second(s) in between):


Right after power-up, login:
[EMAIL PROTECTED]:~$ date
Thu Jan  1 01:00:00 CET 1970
[EMAIL PROTECTED]:~$ date -u 111214492007.00
Mon Nov 12 14:49:00 UTC 2007
[EMAIL PROTECTED]:~$ date
Thu Jan  1 01:00:00 CET 1970


This is wrong.

[snip repeats]


[EMAIL PROTECTED]:~$ date -u 111214492007.00
Mon Nov 12 14:49:00 UTC 2007
[EMAIL PROTECTED]:~$ date
Thu Jan  1 01:00:00 CET 1970
[EMAIL PROTECTED]:~$ date
Mon Nov 12 15:49:03 CET 2007<<< working from here!!


Well, that's odd.


An then another test-run after some minutes uptime, everything is fine:
[EMAIL PROTECTED]:~$ date
Mon Nov 12 16:04:11 CET 2007
[EMAIL PROTECTED]:~$ date -s 16:06
Mon Nov 12 16:06:00 CET 2007



I think I forgot to mention that the problem seems to appear only 
right after powerup of the embedded device (it has a RTC on it's I2C 
bus (DS1337U chip) but that's not used here or broken).


The interesting part of it is, that the date can indeed be set with -u 
(and with -s), but the actual update seems to be delayed by about one 
minute after a reboot. Once the system is up and the date has been set 
once, it can be set properly without any delay or problem.


It seems more kernel / glibc related to me, now. And I will have to 
first understand the expected behaviour of the kernel. (But note: the 
kernel didn't change in between my toolchain upgrade, so it was 
working before with the old glibc-2.3.5, same coreutils... )


It certainly sounds like a problem with the kernel/RTC interaction. I 
don't know the history of glibc changes with regard to time functions.



Below are some strace outputs... in case of interest.
-8<---

WORKING PROPERLY (I want to set it back 2 minutes):
$ date -s 16:12;date;strace date -s 16:10;date
Mon Nov 12 16:12:00 CET 2007
Mon Nov 12 16:12:00 CET 2007
execve("/bin/date", ["date", "-s", "16:10"], [/* 19 vars */]) = 0



clock_gettime(CLOCK_REALTIME, {1194880320, 18361000}) = 0



open("/etc/localtime", O_RDONLY)= 3
read(3, "\nCET-1CEST,M3.5.0,M10.5.0/3\n", 4096) = 28



clock_settime(CLOCK_REALTIME, {1194880200, 0}) = 0
write(1, "Mon Nov 12 16:10:00 CET 2007\n", 29) = 29


I removed the uninteresting strace lines, and what's left looks fine.



Just after a reboot - NOT WORKING:
(because I want to set it to 15:10 CET and not to 15:12 UTC)

[EMAIL PROTECTED]:~$ date -u 111215122007.00;date;strace date -s 
111215102007.00;date
Mon Nov 12 15:12:00 UTC 2007
Mon Nov 12 16:12:00 CET 2007
execve("/bin/date", ["date", "-s", "111215102007.00"], [/* 19 vars */]) = 0



write(2, "date: ", 6)   = 6
write(2, "invalid date `111215102007.00\'", 30) = 30
write(2, "\n", 1)   = 1
close(1)= 0
close(2)= 0


This fails for a different reason; the format is incorrect unless using 
the -u flag. This really isn't obvious from the documentation, and may 
be a bug; the only thing -u is supposed to do is provide an implicit 
TZ=UTC0 environment variable.


But back to the problem at hand. It's obvious something is wrong with 
setting the date on your system, but to conclusively show where the 
problem lies, could you provide strace output showing the set followed 
by get? Do not alter the arguments to the failing date command, just run 
something like:


# strace -e clock_gettime,clock_settime date -u 111214492007.00
# strace -e clock_gettime date

which was the failing example above. If the clock_gettime() does not 
return a value very close to the clock_settime() just called, you have a 
kernel bug (or a malicious process running separately).



Cheers,
Phil


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

Re: Follow Up: Re: date broken in coreutils-6.7 and new glibc-2.7

[Philip Rowlands]

On Mon, 12 Nov 2007, Philip Rowlands wrote:

This fails for a different reason; the format is incorrect unless 
using the -u flag. This really isn't obvious from the documentation, 
and may be a bug; the only thing -u is supposed to do is provide an 
implicit TZ=UTC0 environment variable.


Not a bug; I misunderstood the date-setting syntax, which is (from the 
manpage)


date MMDDhhmm[[CC]YY][.ss]]
or
date --set=DATESTR

Both of these can take a --utc flag, but the first syntax is much more 
rigid, whereas the second can utilize relative terms etc.



Cheers,
Phil


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

Re: inconsistent behavior of sort -z

[Philip Rowlands]

On Thu, 15 Nov 2007, Stanislav Brabec wrote:

Comparing coreutins with busybox I found following inconsistency in 
the GNU coreutils:


GNU sort -z documents:
use NUL instead of EOL on input


Right, more specifically:

"Treat the input as a set of lines, each terminated by a null character 
(ASCII NUL) instead of a line feed (ASCII LF)."



GNU sort -z does:
use NUL instead of EOL on input and output


Does this not follow as a corollary of the documentation? The way I read 
it, -z tells sort to "use NUL instead of LF".


Do you see the NUL/LF as a separator or end-marker? In other words, 
isn't the terminating character part of the line, to be carried through 
and printed to the output? That's my understanding, and considering the 
practical implications, if the user had a genuine need for 
NUL-terminated lines (awkward filenames, etc), surely the output must be 
similarly NUL-terminated, otherwise the concept of a "line" becomes 
confused.


Note that implementing it as documented would break GNU findutils 
updatedb, as happens with busybox.


Agreed, busybox appears to handle -z differently.


Cheers,
Phil


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

Re: inconsistent documentation of sort -z

[Philip Rowlands]

On Thu, 15 Nov 2007, Stanislav Brabec wrote:

"Treat the input as a set of lines, each terminated by a null 
character (ASCII NUL) instead of a line feed (ASCII LF)."


I mentioned this as a documentation problem. (I changed mail subject.)

More correct would be "Treat the input and generate the output...".


That would probably be clearer.


Agreed, busybox appears to handle -z differently.


...as probably were authors of busybox. Their implementation does 
exactly what GNU sort info page writes about -z.


No, busybox goes further; GNU sort's doc does not say "input using NUL 
and output using LF". But this is splitting hairs, and the spirit of 
your email is (I think) that coreutils' documentation could be clearer, 
and busybox should fix its behaviour.



Cheers,
Phil


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

Re: Zend Core 2.5 installation

[Philip Rowlands]

On Tue, 20 Nov 2007, Andre Augustus wrote:

I have followed the installation instructions for Zend Core 2.5 on 
Linux (RHEL 4). I successfully unzipped the files, but when I issue 
the commands in the guide "install -y" or "install -n" , I get an 
"invalid option" error and when I use "install -g", I get an error for 
too few arguments. Please tell me where to go to find proper 
installation instructions (preferably GUI, I'm a linux newbie).


This mailing list is for reporting problems in GNU coreutils only. It 
sounds like in this case the documentation for the product you're 
installing is incorrect.


The best course of action would be to seek help from the organisation 
which supplied you with Zend Core; I see that their website has a 
support forum.



Cheers,
Phil


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

Re: Bug in error when "mv" when you don't have access to source file

[Philip Rowlands]

On Mon, 26 Nov 2007, Quintin Beukes wrote:


This is a copy of the sequence of commands with which to reproduce this
problem.

[EMAIL PROTECTED] admin_scripts $ sudo mkdir /tmp/mvbug
[EMAIL PROTECTED] admin_scripts $ sudo touch /tmp/mvbug/file
[EMAIL PROTECTED] admin_scripts $ mv /tmp/mvbug/file /tmp/file1
mv: cannot move `/tmp/mvbug/file' to `/tmp/file1': Permission denied
[EMAIL PROTECTED] admin_scripts $ mv /tmp/mvbug/file .
mv: cannot remove `/tmp/mvbug/file': Not a directory
[EMAIL PROTECTED] admin_scripts $ mv /tmp/mvbug/file ./
mv: cannot remove `/tmp/mvbug/file': Not a directory



You don't specify whether "." is on a different filesystem; this affects 
whether mv can use a rename(2) syscall, or has to copy and delete. I 
suspect "." is not on the same filesystem as /tmp, in which case the 
strace output looks like this:

(boring lines hidden)

rename("/tmp/mvbug/file", "./file") = -1 EXDEV (Invalid cross-device link)
unlink("./file")= 0
open("/tmp/mvbug/file", O_RDONLY|O_LARGEFILE) = 3
open("./file", O_WRONLY|O_CREAT|O_EXCL|O_LARGEFILE, 0600) = 4
fchown32(4, 0, 0)   = -1 EPERM (Operation not permitted)
fchmod(4, 0100644)  = 0
close(4)= 0
close(3)= 0
unlinkat(AT_FDCWD, "/tmp/mvbug/file", 0) = -1 EACCES (Permission denied)
openat(AT_FDCWD, "/tmp/mvbug/file", 
O_RDONLY|O_NOCTTY|O_NONBLOCK|O_LARGEFILE|O_NOFOLLOW) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
close(3)= 0
unlinkat(AT_FDCWD, "/tmp/mvbug/file", AT_REMOVEDIR) = -1 EACCES (Permission 
denied)
write(2, "mv: ", 4mv: ) = 4
write(2, "cannot remove `/tmp/mvbug/file\'", 31) = 31
write(2, ": Not a directory", 17: Not a directory)   = 17
write(2, "\n", 1)


I agree that mv's diagnostic message doesn't correspond to the syscall 
return value. Will have to dig around the source and see if I can spot 
what causes this.



Cheers,
Phil


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

Re: coreutils-6.9.90 released

[Philip Rowlands]

On Sun, 2 Dec 2007, Jim Meyering wrote:

Actually, I *was* really impressed to see the size decrease from 5.6MB 
to 3.6MB, when going from bzip2 to lzma compression on the coreutils 
tarball.


The algorithm's clearly doing better, but I've not seen much use of lmza 
in the wild. On the distros I tried (Fedora, Ubuntu) it was easier to 
find 7zip packages than lmza. Is .7z a more widespread archive format?



Cheers,
Phil


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

Re: bug-coreutils date command

[Philip Rowlands]

On Mon, 3 Dec 2007, Richard Narum wrote:

I'm not sure if you would call this a bug or not but I'm wondering why 
the GNU date command doesn't have the correct time adjustment for 
daylight savings from years past on its output when using an input 
date string to generate its output.


I am currently running GNU coreutils 6.9 with Cygwin on Windows XP 
version "CYGWIN_NT-5.1 1.5.24(0.156/4/2) 2007-01-31 10:57".


What version of the tzcode package do you have, if any? 
/var/log/setup.log contains this info on my Cygwin installation - I 
don't know the "proper" way to check, which the installer uses.



The following commands shows dates when CST switches to CDT and back.

$ export TZ=CST6CDT


What does this mean? Specifically, without giving the full syntax (e.g. 
"EST5EDT4,116/2:00:00,298/2:00:00") how is the C library to know what 
rules are passed by Congress regarding the DST switchover date?


The usual way is to have a large collection of files giving the 
historical date patterns and gmt offsets. If your system has an old 
(pre-2005?) version of these files, or none at all, date and the 
localtime(3) function it calls can't help.


Could someone shed some light on why maybe additional rules are not 
applied?


I remember being told once that the "CST8CDT" pattern was now broken by 
the Energy Policy Act changes, but I can't find a reference. The best 
thing to do is avoid that syntax and use the location-based files 
instead; e.g. "America/Chicago" for Central Standard/Daylight Time.



Cheers,
Phil


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

Re: about df and lvm

[Philip Rowlands]

On Tue, 4 Dec 2007, tq01azk wrote:


test environment:
centos 4.4
Linux localhost.localdomain 2.6.9-55.0.12.ELsmp #1 SMP Fri Nov 2 11:19:08 EDT 
2007 i686 i686 i386 GNU/Linux
lvm> version
 LVM version: 2.02.21-RHEL4 (2007-03-26)
 Library version: 1.02.17-RHEL4 (2007-04-24)
 Driver version:  4.5.5

I creat  4G of size  lvm  partition.

#df -h
/dev/mapper/lvtest-lv4.0G  2.6G  1.3G  68% /mnt/lv

[snip]


then I use the command "lvextend" to add 800M capatity into the lvm.
but i also see the capatity is 4G by using df,lvdisplay show right information

#lvextend -L +800M /dev/lvtest/lv
Extending logical volume lv to 4.88 GB
Logical volume lv successfully resized
#df -h
/dev/mapper/lvtest-lv4.0G  2.6G  1.3G  68% /mnt/lv


Does lvextend affect the logical volume ("partition") size or the 
mounted filesystem? I think you'll need to run e2extend or other 
fs-specific tool to expand the filesystem structures, which is what df 
is reporting.



Cheers,
Phil


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

Re: Maybe a bug!

[Philip Rowlands]

On Fri, 21 Dec 2007, [EMAIL PROTECTED] wrote:

Why does head accept die option -1 and tail does not, in this same 
context?


Please see this FAQ entry regarding arguments to tail:
http://www.gnu.org/software/coreutils/faq/coreutils-faq.html#Old-tail-plus-N-syntax-now-fails

I'm not sure why head and tail are not behaving the same way, but 
generally that form of the syntax is not encouraged.



Cheers,
Phil


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

Re: rmdir fault

[Philip Rowlands]

On Sun, 23 Dec 2007, [EMAIL PROTECTED] wrote:


I am trying to remove a bad install of VMWare by using;

rmdir -v -p --ignore-fail-on-non-empty *

(--ignore-fail-on-non-empty was found in MAN)

The command line accepts the command without complaint,


It is a valid command line, but not an appropriate tool for the 
described purpose.



then fails to remove the directories.


It's likely that the directories specified are not empty. rmdir only 
works on empty directories, because the underlying rmdir(2) system call 
does likewise.


It also fails to remove 
directories when * is replaced by a directory name.


Because the shell replaces the wildcard "*" by matching directory 
entries, this is to be expected.


Assuming you have permission to remove the files, the following will do 
what you want:


rm -v -rf -- *


Cheers,
Phil


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

Re: Concern about --reply=no option of mv.

[Philip Rowlands]

On Mon, 7 Jan 2008, Dana Runge wrote:


I noticed that the --reply option is being deprecated in mv.

Perhaps I am overlooking something, but it appears as if key 
functionality is being removed from the command.


I regularly write scripts with --reply=no with the intent that if the 
target file exists, the mv command fails. Neither of the recommended 
replacements, -i, nor -f offer this functionality. Because these 
scripts may be run from a cron job, I don't want to ask for user 
input.


The only option left, if --reply=no is removed, is to use

   mv -i x y < /dev/null 2> /dev/null

You tell me, is this clearer than

   mv --reply=no x y

I don't think so.


I think the problem was that mv would prompt in other circumstances than 
the example above, and that the option was being misunderstood. This 
thread has the discussion:


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

If you insist on removing my beloved --reply=no, please replace it 
with a new option that provides the same functionality, and please 
provide several years, 3-4 at least, to allow the new command to 
propagate through all the various Linux distributions that are out 
there.


Will your cron-driven script have a terminal on stdin? The help text for 
--reply used to say at one point:


  --reply={yes,no,query}   specify how to handle the prompt about an
   existing destination file.  Note that
   --reply=no has an effect only when mv
   would prompt without -i or equivalent, i.e.,
   when a destination file exists and is not
   writable, standard input is a terminal, and
   no -f (or equivalent) option is specified

Other alternatives and examples are given in the abovementioned thread.


Cheers,
Phil


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

Re: ls produces spurious message elements during tab completion

[Philip Rowlands]

On Sat, 12 Jan 2008, Paul Coe wrote:

when using a partially completed path after ls and playing with tab 
completion to remind oneself of the next directory or file then the 
following message typically appears, as in this example...


prompt: ls -al /usr/lib/jvm/j
There are 4 There are %d %s, list them anyway? [n/y] , list them anyway?
[n/y] n

This text duplication bug with the C code style format specifiers 
showing up is obviously only a minor issue, but is certainly a symptom 
of incomplete coding and may lead you to notice other problems.


Are you sure it's ls which is printing that message? Some shell 
tab-completion setups include calls to other processes, but as you've 
described file and directory listing is usually performed by the shell 
itself.


I'd expect the same problem to appear if you try other commands than ls.


Cheers,
Phil


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

Re: RE Serious Boot Bug In Sayabon Linux (reboots reboot process after CORRECT PWD LOGIN ENTERED)

[Philip Rowlands]

On Tue, 15 Jan 2008, Dave Saunders wrote:


I purchased this in Adelaide, SA. It's been great up to now. The
password & login details work great on the Console Terminal. So I know
my 120gig data is intact. However, I can't access it via the desktop
at all. It just reboots the reboot sequence everytime.


bug-coreutils@gnu.org is for reports of problems with the GNU coreutils 
set of software. The problem you're seeing has nothing to do with 
coreutils, so I'm afraid this mailing list can't help you.



Cheers,
Phil


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

Re: PDT timezone bug in GNU coreutils "date" v6.9

[Philip Rowlands]

On Tue, 15 Jan 2008, [EMAIL PROTECTED] wrote:

I believe I have identified a bug in the GNU coreutils "date" utility 
when handling the PDT timezone.


I'm running Fedora 8 kernel 2.6.23.9-85.fc8, and the command "date - 
-version" reports:  date (GNU coreutils) 6.9

[snip]


$ date -d"Tue Jan 14 08:25:26 PDT 2008" +%s
date: invalid date `Tue Jan 14 08:25:26 PDT 2008'

Note that EST, EDT and PST work fine, however, PDT is listed as 
invalid.


Odd, this seems to depend on your current timezone setting:

$ export TZ=UTC
$ date -d"Tue Jan 14 08:25:26 PDT 2008" +%s
1200324326

$ export TZ=America/Los_Angeles
$ date -d"Tue Jan 14 08:25:26 PDT 2008" +%s
date: invalid date `Tue Jan 14 08:25:26 PDT 2008'

or put more simply:

$ TZ=America/Los_Angeles date -d '12:00 PDT'
date: invalid date `12:00 PDT'

This report can be generalised to "using the time_zone_table entry 
corresponding to the local DST state *not* currently in effect gives an 
error".


A few more examples (which depend on today's date):

$ TZ=Europe/London date -d '12:00 BST'
date: invalid date `12:00 BST'

TZ=America/Chicago date -d '12:00 CDT'
date: invalid date `12:00 CDT'

TZ=America/New_York date -d '12:00 PDT'
Tue Jan 15 14:00:00 EST 2008

TZ=Pacific/Auckland date -d '12:00 NZST'
date: invalid date `12:00 NZST'

Although the coreutils documentation cautions about using ambiguous 
timezone labels like this, I don't see any mention of (or reason for) 
the error message you've found.



Cheers,
Phil


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

Re: PDT timezone bug in GNU coreutils "date" v6.9

[Philip Rowlands]

On Thu, 17 Jan 2008, Bob Proulx wrote:

Let me state this in a slightly different way.  You are trying to use 
GNU date's --date=STRING date parsing extension to parse the 
historical default date format.  But the problem is that the 
historical default date format is not exact and has the problems 
mentioned by Paul and Phil.


I'm not quite following, sorry. Absolutely agree that strings like "EST" 
are present as the %Z "time zone abbreviation" in multiple timezones, 
and that robust software should use numerical offsets.


However, in the context of getdate's grammar, "EST" unambiguously means 
-0500, no? It's not particularly helpful to think about strings like 
"2007-07-01 EST", but it's not ambiguous to getdate. Currently, it 
seems to be invalid if the current TZ has a matching string.


If "2007-07-01 EST" is an invalid string, then a future improved date 
would need to learn the TZ mappings (EST -> US/Eastern) in order to 
consistently reject it?


I don't see the danger in allowing all possible values from 
time_zone_table for all dates, whatever the current TZ, but I suspect 
I'm missing something...



Cheers,
Phil


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

Re: PDT timezone bug in GNU coreutils "date" v6.9

[Philip Rowlands]

On Thu, 17 Jan 2008, Bob Proulx wrote:


But the case under discussion was PDT not EST.

 $ TZ=US/Pacific date -d"Tue Jan 14 08:25:26 PDT 2008"
 date: invalid date `Tue Jan 14 08:25:26 PDT 2008'

At this point I don't know if PDT is ambiguous or not


Not to getdate. There is one "PDT" entry in time_zone_table:
  { "PDT",  tDAYZONE, -HOUR ( 8) }, /* Pacific Daylight */

Consulting the tables with 'zdump -v US/Eastern | grep 2008' shows 
that indeed "Tue Jan 14 08:25:26 EDT 2008" is not a valid date in that 
timezone.  It should be flagged with an error regardless of local 
timezone setting.


Are we in the territory of documented error or opinion? Can you cite the 
docs which explain why "Tue Jan 14 08:25:26 EDT 2008" is not valid? I 
can't find any (otherwise I'd stop arguing :)), which is why I ask 
whether treating "EDT" as "-0400" is technically wrong or aesthetically 
wrong. getdate isn't confused, and with a non-conflicting TZ will handle 
the input unambiguously.



Cheers,
Phil


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

Re: date command

[Philip Rowlands]

On Fri, 1 Feb 2008, Felix Joussein wrote:


Basically I am aware of what you said, but as I am operating an NTP
Server which get it's timescale directly from an ATOM clock via the
serial interface, which makes it to a STRATUM 1 server, I have to set
the leap second manually by date command or similar to push forward the
ntp-server timescale for this one second when ever the IERS announces a
leap second.
The prior system was running on a Red Hat 7.2 where the date command was
able to set the 60th second... unfortunately the version of the
coreutils which is shipped in debian/etch does not.
I'm helping myself now by using the old date command from the Red Hat
distribution which seams to work for my needs but never then less:
Why has a 8 year old version of date a feature, which it's actual
version doesn't have? I cannot imagine, that the code which is necessary
to set the 60th second would blow up the code that much, that the date
project-team decides to blow out that code...


Hi Felix,

I simply don't think it's possible to use date for the stated goal. 
There is no built-in historical knowledge of leap seconds for the 
purposes of allowing the occasional ":60" setting - incidentally, the 
example given "01/31/2008 14:20:60" was not an official leap second.


These notes explain how the underlying timers are incremented through a 
leap second:

http://www.cis.udel.edu/~mills/leap.html

Once a leap second has passed, effectively the system forgets it ever 
happened. The following wall-clock timestamps were actually 11 seconds 
apart, but date shows only a 10 second gap.


$ date -u -d '2005-12-31 23:59:55' +%s
1136073595
$ date -u -d '2006-01-01 00:00:05' +%s
1136073605

The right way (I think) for what you're trying to do is obtain in 
advance a copy of the "leapseconds" file supported by ntpd; latest 
version here:


http://www.cis.udel.edu/~mills/leap-seconds.3331497600

Stratum-1 clocks need to be told when a leap second is approaching, to 
propagate this information through the leap "bits" to their configured 
slaves. If this is not done correctly the machines will not march in 
step, and the way the ntp protocol works doesn't allow for spot fixes at 
or after a discontinuity; the semi-random polling interval would almost 
guarantee your population of machines would learn of (and apply) the 
change at different times.



Cheers,
Phil


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

Re: bug in the command "du"

[Philip Rowlands]

On Mon, 18 Feb 2008, Jochen Röder wrote:


i've found a bug in the command "du"

When i list recursivly directories and i only want to see the binary 
count of all files. I become a wrong result. The command e.g. "du -ab" 
add the bytes from "." in every directory to the result.


This is not a bug. -a is documented to include "all files, not just 
directories"; its purpose is not to alter the reported totals, but to 
show more detail by including an output line for every "file" i.e. 
directory entry, which can be a regular file, directory, symlink etc.



Or did you have a parameterset to list the bytes only of the files?


Assuming you mean only regular files, there is no option to restrict 
du's output in this way.



Cheers,
Phil


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

Re: date command

[Philip Rowlands]

[ Re-adding bug-coreutils, so the mailing list archives get the benefit 
of the whole discussion ]


On Wed, 27 Feb 2008, Felix Joussein wrote:


thank your for your detailed answers.
since we're talking about time, and I was quiet busy the past 4 weeks and 
didn't have time to continue, I'm now about to resume my work. At this point I 
know everything about the leap-second that is written about on the ntpd 
homepage
So one precise information is still missing: Where do I have to install the 
leap-second.XX file? I'd copied it to /etc/ntp/leap-second..

Is this the right place?


The information is missing where? Did you check the ntpd documentation?
http://www.cis.udel.edu/~mills/ntp/html/miscopt.html

Please see the "leapfile" configuration option.


Cheers,
Phil


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

Re: date +%s ignores TZ

[Philip Rowlands]

On Fri, 29 Feb 2008, Bob Proulx wrote:


Jan Engelhardt wrote:


I wanted to get the number of seconds since the start of the day.

echo $[`date +%s` % 86400];

unfortunately does not do the right thing ÿÿ it would show
82800 instead of 0 when it is (local) midnight.


I can't think of any totally race free way to do this without invoking
date multiple times.


I might be misunderstanding the problem, but it seems easy enough to do 
this calling date only once:


$ date +%T | awk -F: '{ print $1 * 3600 + $2 * 60 + $3 }'
67652

(corresponding to 18:47:32)


Cheers,
Phil




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

Re: Bugreport 'sort'

[Philip Rowlands]

On Tue, 4 Mar 2008, Heijnen, Eugène (DID) wrote:


I want to report a bug in "sort" utility.


Please see the FAQ:
http://www.gnu.org/software/coreutils/faq/coreutils-faq.html#Sort-does-not-sort-in-normal-order_0021


Cheers,
Phil


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

Re: problem with command sort after uniq -c

[Philip Rowlands]

On Mon, 10 Mar 2008, Damien ANCELIN wrote:

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
  1320 51970
  1692 12345
 22681 8060
 26063 8649
  2668 33603
  3487 44496
  4350 23246
 47013 8000
 5447 2
81724 5000


You don't say which locale your environment is configured to use for 
sorting, but I'd bet it's one which treats whitespace differently to how 
you expect.


With only spaces between the 2 fields, sort -n read 1 number per line 
and use it to do the sort : 2668 33603 is read as 266833603. With this 
consideration, the result of sort is correct, but it's not what I 
expected (and I didn't see this behaviour in the documentation).


The command "sort -n" treats the whole line as the sort key. Specifying 
"sort -k1,1n" will use just the first field, in ascending numerical 
order.



Cheers,
Phil


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

Re: Error : Cannot create directory 'usr/local/nagios': permission denied

[Philip Rowlands]

On Mon, 31 Mar 2008, [EMAIL PROTECTED] wrote:


I am trying to Install nagios 3.0 in Ubuntu 7.10 Desktop edition.

After compliation , when i type " make install "  I get error messege 
saying that cannot create directory 'usr/local/nagios': permission 
denied.


Presumably your user account does not have permission to write to that 
directory. This is not a bug; it's how standard unix permissions work.


If you have access to run commands as root on your system, then "make 
install" should succeed. Otherwise you'll need to ask your system 
administrator.



Cheers,
Phil


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

Re: NotLoggingdetails when user changes system time with date command

[Philip Rowlands]

On Wed, 9 Apr 2008, Chinnakka K Batakurki wrote:

When I changed the Linux system time by using date -s  command, 
the info is not logged to /var/log/wtmp


wtmp is a file for recording user login/logout activity.

whereas when I change the Hardware clock with hwclock command, it is 
logged to : /etc/adjtime


Certain uses of hwclock will write /etc/adjtime to record clock drift 
statistics.


Could you please let me know is there any setting needs to be done to 
get the logs related to system date/time


I'm not sure what sort of logging you'd like to see. Small, 
single-purpose commands like coreutils don't generally write logs; 
perhaps the logger(1) command would suit your purposes?



Cheers,
Phil


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

Re: OO 2.2 freezes repeatedly on Freespire 2.0.8

[Philip Rowlands]

On Thu, 1 May 2008, Kenneth Koym wrote:


Attn: Bug-coreutils@gnu.org
 Repeatedly, OO 2.2 has froze while saving a document; often this happens 
just as I open and select a line or two for placing in another document or 
place it in an email for sending. Then, I have to spend hours and hours to 
resolve the glitch. Last night I said, "before going to bed, this is the 
latest response in the terminal
mv: cannot move `/root/.openoffice.org2' to a subdirectory of itself, 
`/root/.openoffice.org2_backup/.openoffice.org2'

what causes this?"


What version of coreutils to you have installed? The "bug" here is the 
misleading error message from mv as

/root/.openoffice.org2_backup/.openoffice.org2 is not a subdir of
/root/.openoffice.org2

As the Ubuntu bug you referenced points out, previous versions of mv 
would sometimes mistakenly fail with "cannot overwrite directory" (see

http://lists.gnu.org/archive/html/bug-coreutils/2006-05/msg00086.html).

Unfortunately, this "cannot overwrite" error message is disguising the 
real reason the mv command may be failing. Nonetheless, I'm confident 
that, even with a newer version of coreutils, your problems with 
OpenOffice freezing won't be resolved. As Bob points out in another 
reply the best people to ask about OpenOffice issues are OpenOffice 
support folks:

http://support.openoffice.org/


Cheers,
Phil


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

Re: BugReport about "ln" command worked in NTFS

[Philip Rowlands]

On Fri, 2 May 2008, [EMAIL PROTECTED] wrote:

When I use "ln" command to create a hard link in NTFS file system. If 
I delete one of the file, and use "ls -l" to list the files the link 
counter still the same.


Either ln is not working, or the underlying kernel is not responding 
correctly to the system calls which ln issues. Can you find out using 
strace whether ln's call to unlink(2) is returning successfully, and if 
the following stat/fstat shows the decremented link count?


If not, then the NTFS driver (NTFS-3G?) or filesystem is probably at 
fault.


And I suggest if users use "ln" in NTFS, it will create a junction 
point.


Perhaps a good idea, but something that should be handled in the NTFS 
driver rather than ln.



Cheers,
Phil


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

Re: BugReport about "ln" command worked in NTFS

[Philip Rowlands]

[ re-adding bug-coreutils@gnu.org ]

On Thu, 8 May 2008, [EMAIL PROTECTED] wrote:


The complete log about running "ln" is in the attachment.


The strace -c output you posted shows 1 successful call to link(2), as 
I'd expect. It then shows further expected output from stat(1) that the 
link count is 2 for both filenames.


Your initial report stated that rm was failing to remove one of the 
links, but your sample output doesn't show any use of rm, so it's 
impossible to see the problem being demonstrated.


Please try running the following commands on the affected filesystem and 
send back the output:


$ touch test1
$ ln test1 test2
$ ls -l
$ strace -e trace=unlink rm test1
$ ls -l


Cheers,
Phil


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

Re: BugReport about "ln" command worked in NTFS

[Philip Rowlands]

[ re-adding bug-coreutils again ]


Please try running the following commands on the affected filesystem
and send back the output:
$ touch test1
$ ln test1 test2
$ ls -l
$ strace -e trace=unlink rm test1
$ ls -l



I think I know where is the problem...
Previous commands work successful.
And the problem occur when I delete the file in nautilus...
I'll report it to who manages nautilus.


I've removed some of the output so that it's easier to read...

$ touch test1
$ ln test1 test2
$ ls -l
 0
-rwxrwx--- 2 root plugdev 0 2008-05-09 10:43 test1
-rwxrwx--- 2 root plugdev 0 2008-05-09 10:43 test2
$ strace -e trace=unlink nautilus . &
unlink("/tmp/orbit-daiyutsung/linc-4020-0-2550990e1816d") = 0
Process 16416 detached
$ ls -l
 0
-rwxrwx--- 2 root plugdev 0 2008-05-09 10:43 test2


This shows nautilus removing a different file entirely. I suspect, 
although I haven't looked, that some sort of safe-undelete functionality 
might be moving rather than removing files.



Cheers,
Phil


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

Re: bug in sha1sum

[Philip Rowlands]

On Mon, 12 May 2008, Dave Hines wrote:


I have just been looking at the man page for sha1sum, and saw the options:

  -b, --binary
 read in binary mode

  -t, --text
 read in text mode (default)

There is no further explanation of what these options mean.


Coreutils manpages tend to be short reference sheets listing the 
available options. Further documentation is provided in the "info" 
command, as should be mentioned as the end of each manpage.


 From the docs:
`-b'
`--binary'
 Treat each input file as binary, by reading it in binary mode and
 outputting a `*' flag.  This is the inverse of `--text'.  On
 systems like GNU that do not distinguish between binary and text
 files, this option merely flags each input file as binary: the MD5
 checksum is unaffected.  This option is the default on systems
 like MS-DOS that distinguish between binary and text files, except
 for reading standard input when standard input is a terminal.

`-t'
`--text'
 Treat each input file as text, by reading it in text mode and
 outputting a ` ' flag.  This is the inverse of `--binary'.  This
 option is the default on systems like GNU that do not distinguish
 between binary and text files.  On other systems, it is the
 default for reading standard input when standard input is a
 terminal.


Cheers,
Phil


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

Re: bug in sha1sum

[Philip Rowlands]

On Tue, 13 May 2008, Phillip Susi wrote:


Philip Rowlands wrote:

 Coreutils manpages tend to be short reference sheets listing the available
 options. Further documentation is provided in the "info" command, as should
 be mentioned as the end of each manpage.

 From the docs:
 `-b'
 `--binary'
  Treat each input file as binary, by reading it in binary mode and
  outputting a `*' flag.  This is the inverse of `--text'.  On
  systems like GNU that do not distinguish between binary and text
  files, this option merely flags each input file as binary: the MD5
  checksum is unaffected.  This option is the default on systems
  like MS-DOS that distinguish between binary and text files, except
  for reading standard input when standard input is a terminal.

 `-t'
 `--text'
  Treat each input file as text, by reading it in text mode and
  outputting a ` ' flag.  This is the inverse of `--binary'.  This
  option is the default on systems like GNU that do not distinguish
  between binary and text files.  On other systems, it is the
  default for reading standard input when standard input is a
  terminal.


I have to agree with Dave on this then.  It is a severe bug that text mode is 
the default since this means that you will get different results for the 
checksum on MS-DOS/Windows than on a GNU/Linux system.


Please re-read the option descriptions. On MS-DOS, the default is 
--binary unless reading from a terminal. You'd practically have to be 
typing text directly into sha1sum to provoke this behaviour; pipes and 
file redirection wouldn't do it. (This does make me wonder why the 
behaviour was provided in the first place, as typing into checksumming 
utilities seems unusual and error-prone.)



Cheers,
Phil


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

Re: Problem with Date Command

[Philip Rowlands]

On Wed, 4 Jun 2008, Dameon G. Rogers wrote:


Bug-coreutils,

  I would like to report a problem with the *date* command:

date +%C

   does not function properly.  It says it displays the current 
century but the/ definition /of century means that we are in the 21st 
not the 20th.


The documentation does not state that %C is the ordinal century; in the 
manpage/--help output, we see:


  %C   century; like %Y, except omit last two digits (e.g., 21)
  %Y   year

and from the info documentation:

`%C'
 century.  This is like `%Y', except the last two digits are
 omitted.  For example, it is `20' if `%Y' is `2000', and is `-0'
 if `%Y' is `-001'.  It is normally at least two characters, but it
 may be more.

Either the command needs to be changed or the man page needs to be 
changed to express what the command actually does.  Any assistance 
would be appreciated.


I agree that until 2100, it would be better if the manpage gave "20" as 
the example, or no example at all, but the wording is strictly correct.



Cheers,
Phil


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

Re: cp -u

[Philip Rowlands]

On Sat, 14 Jun 2008, Markku A. Mähönen wrote:

I noticed that if, for some reason, the copy of a file is interrupted 
(and so the destination file is not the same size as the source) and 
after that you do 'cp -u' again it does not update the interrupted 
file. So the 'cp -u' does not care about the file size mismatch and 
cares only about the timestamps.


So I would like to suggest that 'cp -u' should also check the size of 
the files and do a copy if source is newer, or if destination is 
missing, or if file sizes are different.


You might find rsync to be a better tool for this task. It's more robust 
against partial-copy failures, and has the nice property that copied 
files will all carry the same mtime, whereas cp -u will not attempt to 
replicate timestamps (from a cursory check).



Cheers,
Phil


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

Re: du: cache directory size

[Philip Rowlands]

On Wed, 2 Jul 2008, Mildred wrote:

I was thinking that perhaps caching the size of directories could bu 
useful. Perhaps, after du computes the size of a directory, it could 
write its size in its extended attributes (if the filesystem support 
it). Next time, du would only compare the directory atime (or mtime 
perhaps) with the time of the scan.


Unfortunately neither the atime nor mtime of a directory would 
necessarily show a change to the disk usage of the enclosed files. 
Consider a logfile, for example; the filesize grows continuously, but 
makes no change to the directory.



Cheers,
Phil


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

Re: ls missing in cygwin

[Philip Rowlands]

On Thu, 3 Jul 2008, Craig Naumann wrote:

hello, i cant use the "ls" command in cygwin, it says command not 
found.


It sounds like coreutils is not installed properly, or not installed at 
all in your cygwin environment. Unfortunately, this is not the right 
mailing list for cygwin installation problems; please read the advice on 
the following page about how to request Cygwin support.


http://cygwin.com/lists.html


Cheers,
Phil


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

Re: cd command issue

[Philip Rowlands]

On Thu, 10 Jul 2008, Janarthanan Palanichamy wrote:


Hi GNU coreutils,

Today I just tried "cd ~" .
After entering this in the terminal it became unable to delete the ~ symbol

and the user have to use the  to come out of that, to enter other
commands. Using a 2.6 Kinux kernel (RH 4)


This is not an issue with GNU coreutils; shell tab-completion is the 
responsibility of the shell, but you don't say which shell you're using 
so it's difficult to suggest an alternative mailing list / help forum.


http://www.catb.org/~esr/faqs/smart-questions.html

Perhaps try waiting a minute for the requested username completion. I 
suspect the shell is blocking while performing a network lookup for all 
valid usernames on your system.



Cheers,
Phil


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

Re: cp -v doesn't work correctly under file system mounted through FUSE

[Philip Rowlands]

(apologies if my mailreader mangles your name - I can't easily write 
in BIG-5)


On Thu, 10 Jul 2008, ¬x¥ô¿Ù wrote:


Normally, cp -rv files > log should list all the files copied in the file 'log'.
However, when cp -rv a directory under file system mounted via FUSE,
redirect of I/O doesn't work. The verbose output is gone and the log file
contains nothing. Also, if I try to read the verbose output of cp command
with another program via pipe, it works with local file systems, but not
with remote file systems mounted via FUSE, such as sshfs and curlftpfs.
However, if I use forkpty in the program, it seems to partially work.
Shouldn't --verbose always give output whether the stdout is a tty or not?


Yes, it should. I suspect the filesystem emulation in your FUSE mounts 
is somehow misbehaving. Perhaps you could perform the following tests 
both on local disk and FUSE mount, and spot the difference in system 
calls and responses?


$ mkdir a
$ touch a/{x,y,z}
$ strace -o /tmp/cp.trace -e trace=desc cp -rv a b

Hopefully it should be obvious where copying on a FUSE filesystem 
differs.



Cheers,
Phil


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

Re: filesizes/diskusage with ls, du, df only on xen-images

[Philip Rowlands]

On Wed, 16 Jul 2008, tstaps wrote:


I have a problem, that is testet only on one machine.


[ snip creating and mounting 5GB filesystem ]

Sorry, I have to delete some quoted text otherwise this reply will be 
unreadable.



# cp /var/lib/xen/images/xc51small.hda .
# df -k .
Dateisystem 1K-Blöcke Benutzt Verfügbar Ben% Eingehängt auf
/dev/mapper/vg_opt-lv_opt_image1
5160576 1087236 3811196 23% /opt/image1
^^^ ?


The figure highlighted is the total number of 1K blocks in the 
filesystem. The total has not changed, but the used and available 
figures have, as would be expected.


Perhaps I'm misreading the ascii-arrows; the change in filesystem usage 
is 945796 K, which is smaller than the 2GB you reported. The further 
examples given make the same point.


Please check whether the original xc51small.hda is a sparse file, which 
would explain the difference between size as reported by ls and du, and 
space occupied on disk as reported by du and df.



Cheers,
Phil


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

Re: [PATCH] Again, do not change the mode of all directories below $HOME.

[Philip Rowlands]

On Tue, 22 Jul 2008, Ralf Wildenhues wrote:


* tests/CuTmpdir.pm (chmod_tree): Do not run chmod on undefined
argument, can happen when the build path contains spaces.


That sounds wrong - there's no magic to unusual characters in filenames 
other than avoiding passing them unquoted through an IFS-splitting 
shell.



sub chmod_tree
{
-  if (chdir $dir)
+  if (defined $dir && chdir $dir)
{


Surely skipping the test is going to give a misleading impression to the 
tester? Tracing back up, why is $dir not defined?



Cheers,
Phil


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

Re: Fw: chroot: error...!!!

[Philip Rowlands]

[ other cc: recipients removed ]

On Sun, 3 Aug 2008, ~*~ Its Lucky ~*~ wrote:


 My name is Lucky, i am building the LFS, now i am at Section 6.4 of LFS-6.2,

When i am going to run the following command to change the root, i got the error

The Command is
===
chroot "$LFS" /tools/bin/env -i \
   HOME=/root TERM="$TERM" PS1='\u:\w\$ ' \
   PATH=/bin:/usr/bin:/sbin:/usr/sbin:/tools/bin \
   /tools/bin/bash --login +h==

The error i got is

===
Chroot: cannot run command /tools/bin/env

no such file or directory
===


The bug-coreutils mailing list is intended for reporting bugs in GNU 
coreutils software. However, what you're seeing here is not evidence of 
a bug, rather a problem with the Linux From Scratch documentation or the 
steps you've followed prior to running the above command.


I'd suggest asking folks who are more knowledgable about the details 
of LFS, perhaps on one of these lists:


http://www.linuxfromscratch.org/mail.html


Cheers,
Phil


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

Re: rm && opensolaris && ntfs-3g problem

[Philip Rowlands]

On Sun, 10 Aug 2008, Andras Barna wrote:


on opensolaris (update 94) can't remove recursively directories.

@osol /ntfs: /usr/gnu/bin/mkdir -p t/t/t/t/t/t/t/t/t/t//t/t///t//t/t/t/
@osol /ntfs: /usr/gnu/bin/rm --version|head -1
rm (GNU coreutils) 6.7
@osol /ntfs: rm -rf t
rm: cannot remove directory `t': Directory not empty
@osol /ntfs: rm -r t
@osol /ntfs: ls t
ls: cannot access t: No such file or directory


This example shows the default "rm" (PATH not shown) failing to remove a 
directory tree, but succeeding on the second attempt.




@osol /ntfs: /usr/gnu/bin/mkdir -p t/t/t/t/t/t/t/t/t/t//t/t///t//t/t/t/
@osol /ntfs: /data/a/bin/rm --version|head -1
rm (GNU coreutils) 6.12
@osol /ntfs: /data/a/bin/rm -rf t
@osol /ntfs: echo $?
0
@osol /ntfs: ls t
t
@osol /ntfs: /data/a/bin/rm -r t
@osol /ntfs: ls t
t
@osol /ntfs: /data/a/bin/rm -r t
@osol /ntfs: echo $?
0
@osol /ntfs: ls t
t
@osol /ntfs: /usr/bin/rm --version
/usr/bin/rm: illegal option -- version
usage: rm [-fiRr] file ...
@osol /ntfs: /usr/bin/rm -r t
@osol /ntfs: ls t
ls: cannot access t: No such file or directory


This example show GNU coreutils rm v6.12 failing to remove a directory 
tree; even though the exit status is 0, not all files are deleted. This 
is a bug.




@osol /ntfs: /usr/gnu/bin/mkdir -p t/t/t/t/t/t/t/t/t/t//t/t///t//t/t/t/
@osol /ntfs: /usr/bin/rm -rf t
@osol /ntfs: ls t
ls: cannot access t: No such file or directory


This example shows /usr/bin/rm successfully deleting a directory tree.

To determine whether this is a bug with GNU rm or interactions between 
your kernel and the NTFS filesystem, it's necessary to trace the system 
calls and their return values - hopefully your solaris system has truss 
installed, in which case you could try to repeat the failing commands 
given above like so:


$ truss -o rm-trace.txt /path/to/rm -r t

If you are able to interpret the output of truss, please try to identify 
where GNU rm and solaris rm differ in their system calls, specifically 
which files are removed with unlink(2). If not, then please just attach 
the truss output, ideally compressed.



Cheers,
Phil


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

Re: coreutils: bug in date --iso-8601={seconds,ns}?

[Philip Rowlands]

On Fri, 22 Aug 2008, Johannes Truschnigg wrote:

in thre process of writing an Atom-feed-generator in bash, I discovered 
what MIGHT be a bug/documentation misinterpretation in GNU date's 
--iso-8601 switch when invoked with "ns" or "seconds" as a parameter.


--iso-8601 is deprecated since coreutils 5.90.


RFC3339 and some documents regarding ISO 8601 I could find on the web quickly
seem to suggest that the time-offset component of the output should match the
regex /\d\d:\d\d/; date, however, matches /\d\d\d\d/.


I think --rfc-3339=seconds will do what you want.


Cheers,
Phil


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

Re: French accents

[Philip Rowlands]

On Thu, 28 Aug 2008, Dr. Aprahamian wrote:


I am having difficulty with file names that have French accents.
For example the file.-
AfficheJourn\351e\311tudeP\350reaveclogos-1.pdf
exists but because it has the French e accent in its title the programme is 
not recognizing it.


Which programme is not recognizing it? You've emailed bug-coreutils, 
which is a list for GNU coreutils discussion. If the problem lies with a 
different application, we probably won't be able to help.



What to do?


Please phrase the problem in a way that helps us to reproduce it. At a 
minumum, always consider the following questions when asking for 
support:

- What did you do?
- What happened?
- What did you expect to happen?


Cheers,
Phil


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

Re: Bug in command "test"

[Philip Rowlands]

On Thu, 18 Sep 2008, Abhishek Verma wrote:

I have been training UNIX for a few months, and have come across a bug 
(I guess so) With test command.


The problem is, with -f option it reports a symbolic link as a regular 
file. For ex: say there is a file "f1" of type symbolic link, then


   If [ -f f1 ]; then
   Echo reg file
   Else
   Echo Not reg file
   Fi

The above code should give output as : "Not reg file"
But it happens to print "reg file".


This is not a bug - the manpage for test states:
  "Except for -h and -L, all FILE-related tests dereference symbolic
   links.

If the filename passed to test is a symlink, the target of the link is 
tested as a file/directory/etc.



Cheers,
Phil


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

Re: shorttest crash

[Philip Rowlands]

On Tue, 23 Sep 2008, Konrad Mader wrote:


if I try a short test the HDD switched off until a new power off/on.



  [EMAIL PROTECTED] smartctl -t short /dev/sda -d ata
  smartctl version 5.38 [i686-pc-linux-gnu] Copyright (C) 2002-8 Bruce
  Allen
  Home page is http://smartmontools.sourceforge.net/


Sorry, you've reached the bug-coreutils mailing list, which covers GNU 
coreutils issues only. There are mailing lists which are much better 
targetted to your questions - the website mentioned in the output of the 
given smartcl command is a good place to start.



Cheers,
Phil


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

Re: FAIL: df/total-awk.log

[Philip Rowlands]

On Sat, 11 Oct 2008, Jim Meyering wrote:


Actually, that might be due to something else.
What version of awk are you using?

With the versions of gawk I've tried (3.1.5 and 3.1.6),
it doesn't use the offending format:

 $ awk 'BEGIN {print 2607560286}'
 2607560286

Ah ha!
But if i use mawk, it does:

 $ mawk 'BEGIN {print 2607560286}'
 2.60756e+09

This might be the last straw.  If my patch doesn't work for you,
then I'd welcome a rewrite of that test to make
it use perl (and to skip it if perl is not available).


I get the same results as Jim, even though on my system (Ubuntu Hardy) 
both gawk and mawk docs state OFMT defaults to "%.6g".


I can't tell why OFMT is being ignored here by gawk - although I found a 
bug-gnu-utils post suggesting a difference between printing integers vs 
floating-point, this can't be right:


$ gawk --version
GNU Awk 3.1.6
$ gawk 'BEGIN {print 2607560285.99}'
2.60756e+09
$ gawk 'BEGIN {print 2607560286.00}'
2607560286
$ gawk 'BEGIN {print 2607560286.01}'
2.60756e+09


Cheers,
Phil


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

Re: Why not enhance "sort" to handle floating point numbers?

[Philip Rowlands]

On Fri, 7 Nov 2008, Steve Wald wrote:


It would be real handy if sort had an option analogous to -n which would
properly handle columns of exponential notation numbers, e.g.
-9.575e-08, or even if the -n option itself would detect and sort them.
Much of my data is mixed exponential and decimal notation.


You're in luck - sort's -g option does exactly this.


Cheers,
Phil


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

Re: Bug in uname

[Philip Rowlands]

On Mon, 8 Dec 2008, Eric Blake wrote:


The information contained in this e-mail may be privileged and/or


Sending mail from an account that adds a disclaimer longer than the body
of your message is considered poor netiquette.  This disclaimer is
unenforceable on a publicly archived mailing list, but some people refuse
to reply on principle.


Hi Eric,

I agree these disclaimers can be annoying, but there's no clue to the 
sender that "bug-coreutils@gnu.org" represents a publically archived 
mailing list. I'm not sure there's even an implied license to copy and 
re-publish the text of this email, although _I_ know that's what MHonArc 
will do on http://lists.gnu.org/



Cheers,
Phil


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

Re: WebSphere UpdateInstaller 7.0

[Philip Rowlands]

On Wed, 10 Dec 2008, Duttera, Scott CIV DISA GS4B wrote:


We are trying to install the WebSphere UpdateInstaller 7.0 on a Linux
image under z/VM, and we have extracted the .tar files into a directory,
but when we run the install command we get this:

install: missing file operand
Try `install --help' for more information.


Hi Scott,

It sounds like you've typed "install" by itself, which isn't going to do 
what you expect.


install is a utility for copying files around, typically used in 
software compilation scripts. I'm afraid this mailing list doesn't know 
anything about WebSphere 7.0 - the address you emailed is for reporting 
bugs in the "install" utility itself.



None of this tells us ANYTHING about how to install this thing.  Is
there a manual somewhere that actually explains how to install this
thing?


Searching Google for [ webshpere updateinstaller 7.0 manual ] suggests a 
few pages which may be useful. Alternatively, consult the people who 
supplied the software.



Cheers,
Phil


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

Re: bug

[Philip Rowlands]

On Sat, 13 Dec 2008, punk wrote:


/dev/sda5  65G   43G   22G  67% /media/disk-1
p...@punk-desktop:~$ df -h --h
df: option '--h' is ambiguous


This is correct, not a bug. Both --help and --human-readable long 
options match the prefix you gave.



Cheers,
Phil


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

Re: ls -help not accurate

[Philip Rowlands]

On Mon, 29 Dec 2008, John Bowling wrote:


ls -d
returns only '.'
Per your faq this is the designed in operation

ls --help
does not reflect that operation:

 -d, --directorylist directory entries instead of contents,
  and do not dereference symbolic links


"." is the directory entry (not the contents) of ".", which is the 
default argument to ls.



For that result it should read
 -d, --directorylists base directory entry only instead of
contents,


"ls -d" is not a useful command on its own, without any arguments. 
Changing the --help text as suggested would mis-describe the intended 
purpose of -d, which is detailed in the referenced FAQ.



There is no way to get directory entries  (plural or multiple levels)
with just -d
making that description of -d very inaccurate.


 From the FAQ:
"If you are trying to find files in the directory hierarchy then you 
should look into using the find command."


--help output is intended to be more of a quick reference; the coreutils 
manual contains a longer description of -d.



Cheers,
Phil


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

Re: chown and bash trashed part of system

[Philip Rowlands]

On Wed, 31 Dec 2008, Vincent Chapman wrote:


I understand, but there are still incosistancies in the unix world of
shells.  Try this and you'll understand how one(I) could make this
mistake.

$ sudo bash echo .*
. .. .hidden_files

in zsh

$ sudo zsh echo .*
.hidden_files


This output is presumably fake, but I see your point.


zsh would not have accended into the parent directories.  Bash will.


zsh in a certain configuration will elide . and .. from the expansion of 
".*". bash will also, in a certain configuration, elide . and .. - 
please see the docs for "dotglob" and "GLOBIGNORE".


A shell behaving in accordance with POSIX will follow the spec as to the 
expansion of ".*" and "*".



Cheers,
Phil


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

Re: wc enhancement request: total option

[Philip Rowlands]

On Fri, 13 Feb 2009, Kevin Ivory wrote:


Hi coreutils team,

wc gives a grand total when analyzing several files.
It would be helpful to have a command line option that
returns only the total. It should be able to combine
with -c/-l/-w to return only the total characters /
total lines / total words.


It's usually preferable to combine the features of several coreutils 
rather than add new code. In this case the desired result can be 
obtained with:


$ wc *.txt | tail -n 1
  485  1861 13078 total

If required, this could be wrapped up in a shell script or alias to save 
typing if used frequently.



Cheers,
Phil


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

Re: seq -w floating point incorrect formating

[Philip Rowlands]

On Sat, 14 Feb 2009, Samuel Hap?k wrote:


I think that seq is not behaving correctly on this input:
seq -w 9 0.5 10

I obtain the output:
9.0
9.5
10.0

While I think I should obtain:
09.0
09.5
10.0



 From the info documentation:

`-w'
`--equal-width'
 Print all numbers with the same width, by padding with leading
 zeros.  FIRST, STEP, and LAST should all use a fixed point decimal
 representation.  (To have other kinds of padding, use `--format').

As your example doesn't use a fixed point representation (e.g. seq 9.0 
0.5 10.0) the result is undefined. However, the wording is confusing 
("should" use? why not "must"?). It would be helpful if seq assumed the 
".0" where needed.


Another curious output comes from:

$ seq -w 1 4.5 112
01.0
05.5
10.0
14.5
19.0
23.5
28.0
32.5
37.0
41.5
46.0
50.5
55.0
59.5
64.0
68.5
73.0
77.5
82.0
86.5
91.0
95.5
100.0
104.5
109.0



Cheers,
Phil


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

Re: ls (GNU coreutils) 6.12 bug: -d or --directory switch broken

[Philip Rowlands]

On Thu, 26 Feb 2009, gero...@bluewin.ch wrote:

I installed this version of coreutils to get proper accent support in 
french pathnames, but the ls command for

managing directories silently fails.


Could you give an example of the exact command you ran, what output was 
generated, and what output was expected? Without seeing a reproducible 
example of the bug it's hard to determine the cause of the problem.


Please also see this FAQ, which might be relevant:
http://www.gnu.org/software/coreutils/faq/coreutils-faq.html#ls-_002dd-does-not-list-directories_0021


Thanks,
Phil




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

Re: code retour de test -s incorrect.

[Philip Rowlands]

On Thu, 5 Mar 2009, Marc POIRIER wrote:


# ls

# NOM.htm <- En minuscules

# [ -s NOM.HTM ]

# echo $?

# 0  <- Devrait indiquer 1


What is the output of the following command (on Linux)?

# strace -e trace=file [ -s NOM.HTM ]


Cheers,
Phil


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

Re: code retour de test -s incorrect.

[Philip Rowlands]

[ re-adding bug-coreutils@gnu.org ]

On Thu, 5 Mar 2009, Marc POIRIER wrote:

this is the trace file with option "strace -o file" under cygwin for 
windows.


OK, the issue lies with the underlying filesystem. Under Cygwin 
filenames are (as for Windows generally) case-insensitive.


This isn't a coreutils bug, so these resources will be more appropriate 
for Cygwin-specific issues.


http://cygwin.com/lists.html
http://cygwin.com/faq.html


Cheers,
Phil


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

Re: Did I found a bug in "ls"?

[Philip Rowlands]

On Sun, 8 Mar 2009, Major Péter wrote:

I would like to list some folders with they block-sizes, but only specific 
folders am I interested.

So I would like to use find to list the correct folders for me:
ls `find . -type d -user foo -name "*"`
this is not working because ls can't find folders with spaces in there name,


find uses an implicit "-print" argument, but in this case please look at 
find's "-print0" option. This version of the above command should work:


$ find . -type d -user foo -print0 | xargs -0 ls
(-name "*" is redundant, as everything matches)

I'm still not sure what you're referring to by folders with block-sizes? 
Would the du command be helpful here?



Cheers,
Phil


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

Re: Did I found a bug in "ls"?

[Philip Rowlands]

On Sun, 8 Mar 2009, Major P?ter wrote:

The main problem with du is, that it doesn't care with users, so I need a 
"find" before (using the -user will solve the problem). But I can't use du 
`find ...` because it will contain the subfolders too, so it will duplicate, 
and the measure won't be correct. (Or if I'm use the --max-depth option it 
will still not care with the user filtering).

So by now I have this:
du `find . -type f -user foobar`
using sed, and a for cycle I can make a sum from this values.
But now, I don't have the sizes of the directories, so that's why I tried to 
use:
ls `find . -type d -user foo -name "*"` # -name "*" will be removed in the 
final version

but didn't worked, so I wrote here a mail.
If you know a better way, please just send me a command or parameter name, 
because this is my homework. :)


I don't expect this list will do your homework for you, however... you 
can get all the required information about users and filesizes from 
find's -printf action.



Cheers,
Phil


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

Re: Did I found a bug in "ls"?

[Philip Rowlands]

On Tue, 10 Mar 2009, Major Péter wrote:


But here is some list-related problems of mine:
ls:
If it has a null parameter e.g. in
"find blah -print0 | xargs -0 ls" find gives no hit,
the ls writes on the output (maybe on error output, I'm not sure) a message, 
that incorrect argumentum has camed, BUT it still writes out the content of a 
normal ls, and the exit status is 0. So that's why I need to check first, that 
the find output whether null is or not...


See the --no-run-if-empty argument to xargs.


Cheers,
Phil


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

Re: bug report

[Philip Rowlands]

On Fri, 27 Mar 2009, Mary wrote:


I just downloaded the new beta afor 9.04 and had the following experience.


For the benefit of the list, I've been trying to help to identify the 
source of Ubuntu queries by replying "helpfully" to address the question 
as well as asking where bug-coreutils@gnu.org was seen.


In this case, Mary wrote:
Well, I believe it was in the information about the beta release. 
Online. I believe there was a line that said you could report bug at 
this place.  I was lost wandering around, I am not sure where I saw it. 
Sorry.


I can't find any Ubuntu help page which mentions bug-coreutils@gnu.org; 
perhaps some Ubuntu script is inadvertently calling "util --help" and 
printing the bug reporting address?



Cheers,
Phil


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

Re: factor is too fast

[Philip Rowlands]

On Tue, 21 Apr 2009, Toralf F?rster wrote:


For a long time I used the command "factor" to test my system WRT the cpu
ondemand governor of the linux kernel, eg for issues like this :
http://bugzilla.kernel.org/show_bug.cgi?id=12385

However switching from coreutils-6.10 to 7.1 (stable Gentoo Linux) now the
factor command is too fast: it takes only 0.003 sec instead of 5.5 sec for
the same prime number.


That's probably due to this entry from NEWS:

* Noteworthy changes in release 7.0 (2008-10-05) [beta]

  If the GNU MP library is available at configure time, factor and
  expr support arbitrarily large numbers.  Pollard's rho algorithm is
  used to factor large numbers.


Therefore I'm wondering whether you have a hint for me which number I could
use nowadays ?


If the goal is simply drive the CPU usage to 100% for 5 seconds, this 
would work:


$ timeout 5 factor 20158916322613169725842061629370496430


Cheers,
Phil


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

Re: mv italian translation

[Philip Rowlands]

On Thu, 30 Apr 2009, Stefano Mersi wrote:


when trying to move a diretcory into itself the progam says in italian:
mv: impossibile spostare "myDir" in una sottodirectory di sé stessa, 
"myDir/myDir"


There is a grammar error:
"sé stessa" should become "se stessa"


Please report translations bugs here:
http://translationproject.org/team/it.html


Cheers,
Phil


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

New util suggestion: timeout

[Philip Rowlands]

What:
timeout, executes the sub-command a-la GNU time/nice, but takes
arguments to control the amount of wallclock time the process is
allowed.

Why:
- ulimit for real time
- No current util (GNU or otherwise) widely distributed (AFAIK)
- Useful in scripting, particularly with network apps

I was surprised to find lacking, when writing a shell script, that no
simple app exists for constraining how long apps will run, so this is a
proposal to write one for coreutils, although I'd be happy to learn if
there's something else already in common use.

Feedback is appreciated; I'll come up with some example invocations and
use cases if there's enough interest.


Cheers,
Phil


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

Re: New util suggestion: timeout

[Philip Rowlands]

On Mon, 28 Jun 2004, Paul Jarc wrote:

>>> How would you limit wall-clock time?  Schedule SIGALRM with
>>> setitimer and then exec the given command?
>>
>> I've long used a command of my own called 'alarm' that just does that.
>> However, this strategy doesn't always work well if the command has
>> subprocesses, since the signal is sent only to the exec'ed process.
>
>It also fails if the command uses setitimer itself.  That could be
>handled by forking and having the parent send SIGTERM to the child
>when it gets its own SIGALRM.  To handle the child processes, a new
>process group could be created, but that might interfere with other
>things.

Yes, keep the parent hanging around to handle the killing, particularly
because you might want a two-stage kill (SIGTERM, sleep(5), SIGKILL).

Process group helps when there might be sub-sub-processes, but as you
say that has the potential to interfere with things which don't expect
it, so perhaps make it a command-line parameter.

So far then, I've got as potential command line args:
- Seconds to sleep until first signal
- Which signal to deliver at timeout #1
- Seconds to sleep until second signal (KILL)
- Optionally create process group and kill all children
- Exit status for the timeout condition

The most common use I've got right now (and this is what prompted me to
suggest it in the first place) is:
$ timeout 10 ssh otherhost 'some random command'


Cheers,
Phil


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

Re: Bug with filenames starting with a hyphen

[Philip Rowlands]

On Thu, 15 Jul 2004, David [iso-8859-15] Gómez wrote:

>Several coreutils, like mv, cp, rm, ln, etc... fails when the file passed
>as first parameter starts with a hyphen:
>
>$ cp -old new cp: missing destination file Try `cp --help' for more
>information. thanks,

Please see this FAQ entry:

http://tinyurl.com/3p7ja
from
http://www.gnu.org/software/coreutils/faq/coreutils-faq.html


Cheers,
Phil


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

Re: Bugs

[Philip Rowlands]

On Wed, 4 Aug 2004 [EMAIL PROTECTED] wrote:

>should I send here (possible) bug requests  about linux utils?

You should if they are "GNU coreutils" utilities. You can tell whether
this is the case by running the util with the "--version" argument, e.g.

$ ls --version
ls (coreutils) 5.2.1
Written by Richard Stallman and David MacKenzie.

Certain other utils, e.g. fdisk, mount, are not part of coreutils.
Consult the util's documentation to see where bug reports should go.


Cheers,
Phil


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

Re: Bad cp -a behaviour

[Philip Rowlands]

On Tue, 3 Aug 2004, Tim Waugh wrote:

>When using 'cp -a' to copy a directory structure, it has some
>unexpected behaviour.  See the attached Makefile, which compares the
>behaviour between tar, cpio, and cp.

I might be missing something here; I can't reproduce this with a recent
cp (from FC2):

$ cp --version
cp (coreutils) 5.2.1
$ make -s cp
$

The source and dest appear identical, and strace shows cp unlinking
"1/d/2" and "1/d/3" as it goes.

>The original bug report is here:
>
>https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=128874

"You are not authorized to access bug #128874"


Cheers,
Phil


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

Re: Bad cp -a behaviour

[Philip Rowlands]

On Tue, 10 Aug 2004, Tim Waugh wrote:

>How odd.  Is that a patched 5.2.1?

Possibly; it's from an unadulterated Fedora Core 2.

>Here's what I get with unpatched 5.2.1, straight from the tarball:
>
>[EMAIL PROTECTED] ~/coreutils-5.2.1/src]$ ./cp --version
>cp (coreutils) 5.2.1
>Written by Torbjorn Granlund, David MacKenzie, and Jim Meyering.
>
>Copyright (C) 2004 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.
>[EMAIL PROTECTED] ~/coreutils-5.2.1/src]$ rm -fr 1 2
>[EMAIL PROTECTED] ~/coreutils-5.2.1/src]$ mkdir -p 1/d 2/d
>[EMAIL PROTECTED] ~/coreutils-5.2.1/src]$ echo foo > 1/d/1
>[EMAIL PROTECTED] ~/coreutils-5.2.1/src]$ ln 1/d/1 1/d/2
>[EMAIL PROTECTED] ~/coreutils-5.2.1/src]$ ln 1/d/1 1/d/3
>[EMAIL PROTECTED] ~/coreutils-5.2.1/src]$ echo foo > 2/d/1
>[EMAIL PROTECTED] ~/coreutils-5.2.1/src]$ echo bar > 2/d/2
>[EMAIL PROTECTED] ~/coreutils-5.2.1/src]$ ln 2/d/2 2/d/3
>[EMAIL PROTECTED] ~/coreutils-5.2.1/src]$ ln 2/d/2 2/d/4
>[EMAIL PROTECTED] ~/coreutils-5.2.1/src]$ ./cp -af 2/d 1
>[EMAIL PROTECTED] ~/coreutils-5.2.1/src]$ diff -upr 2 1
>diff -upr 2/d/1 1/d/1
>--- 2/d/1   2004-08-10 13:19:02.695163241 +0100
>+++ 1/d/1   2004-08-10 13:19:02.703161000 +0100
>@@ -1 +1 @@
>-foo
>+bar

I tried building from source, but I get the same as before (i.e. no
problem, no output from diff). Bizarre. Let's keep digging:

$ src/cp -afv 2/d 1
`2/d/4' -> `1/d/4'
`2/d/2' -> `1/d/2'
`2/d/1' -> `1/d/1'
`2/d/3' -> `1/d/3'
$ ls -U1 2/d
4
2
1
3
[ this is running on an ext3 filesystem ]

The bug might be order-specific; does your test produce the same output
as the above with "-v"?


Cheers,
Phil


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

Re: Bad cp -a behaviour

[Philip Rowlands]

On Wed, 11 Aug 2004, Tim Waugh wrote:

>Thinking about it, it must be order-specific.  But here's the output I
>get:
>
>`2/d/3' -> `1/d/3'
>`2/d/2' -> `1/d/2'
>`2/d/1' -> `1/d/1'
>`2/d/4' -> `1/d/4'

OK, so this is a filesystem-dependent issue when using --recursive on
source and destination directories which both contain hard links.

I don't know the specs to which GNU cp adheres well enough, but I'd be
surprised if they mandate a sort routine for recursive copying.

Conversely, it's particularly confusing of cp to throw up its hands and
claim "undefined" in this scenario. I'd think the cp_hash code probably
has a role to play here, but I'm not sure I'm qualified to start hacking
it around. Any AUTHORS in the list??


Cheers,
Phil


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

Re: Bad cp -a behaviour

[Philip Rowlands]

On Wed, 11 Aug 2004, Paul Eggert wrote:

>The GNU documentation says that "-a" implies "--preserve=links" and
>that "--preserve-links" means "Preserve in the destination files any
>links between corresponding source files."

It also implies -R; should this patch cover that flag in isolation, or
only when accompanied by -d/--preserve=link?

If -R alone doesn't trigger the unlink, then we're still at the mercy of
the filesystem and the order it stores directory entries.


Cheers,
Phil


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

Re: chmod drwxrwxrwT

[Philip Rowlands]

On Fri, 20 Aug 2004, Mario Lombardo wrote:

>In the last triplet, a capital "T" isn't discussed on the man page.  I know
>it's sticky, but it means something different from drwxrwxrwt.  Where can I
>get more info on this?  I'd like to learn.

$ info coreutils 'Mode Structure'

   In addition to the three sets of three permissions listed above, a
file's permissions have three special components, which affect only
executable files (programs) and, on some systems, directories:

  3. save the program's text image on the swap device so it will load
 more quickly when run (called the "sticky bit").



AIUI, this is more of a historical flag, used to indicate to the kernel
that the executable is frequently used, thus should be given
preferential retention to "stick" in memory, hence the "sticky bit". I
don't believe the VM layer of modern systems pay much attention to it.


Cheers,
Phil


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

Re: why "ls -d" does not work?

[Philip Rowlands]

On Tue, 14 Sep 2004, Joe wrote:

>I type "ls --help"
>it shows " -d, --directory  list directory entries instead of contents,
>and do not dereference symbolic links"
>
>then I type "ls -d" under my home directory, it display nothing , but
>actually there are some directories under my home directory.

By default, ls will list the files inside a given directory, e.g.

$ ls -l /tmp
-rw-r--r--1 prowlands users 406 Sep  7 14:58 114784.txt
-rw-r--r--1 prowlands users   0 Sep  6 10:59 Acro5QRJo3
-rw-r--r--1 prowlands users   11424 Sep  6 11:05 Acro5S37FS

If, instead, you wanted to list the directory itself, that's what -d is
for:

$ ls -l -d /tmp
drwxrwxrwt   13 root root 4096 Sep 14 04:02 /tmp


The "-d" option doesn't mean "list only directories" in the way you
suggest.


Cheers,
Phil


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

Re: weird echo behaviour...

[Philip Rowlands]

On Thu, 16 Sep 2004, Alfred M. Szmidt wrote:

>Could someone explain the following behaviour for me?  Because I sure
>do not understand it.
>
>[EMAIL PROTECTED]:/tmp/foo$ touch 1 2 3 4 5
>[EMAIL PROTECTED]:/tmp/foo$ foo=`ls`

Here, ls knows it is not outputting to a terminal, so implies the "-1"
option.

>[EMAIL PROTECTED]:/tmp/foo$ /bin/echo $foo
>1 2 3 4 5

Here the shell splits up the arguments and /bin/echo sees argc==5 (or it
it 6 to include argv[0]?).

>[EMAIL PROTECTED]:/tmp/foo$ /bin/echo "$foo"
>1
>2
>3
>4
>5

Here the shell passes the single argument and /bin/echo sees argc==1.


>[EMAIL PROTECTED]:/tmp/foo$ foo='1 2 3 4 5'
>[EMAIL PROTECTED]:/tmp/foo$ /bin/echo $foo
>1 2 3 4 5
>[EMAIL PROTECTED]:/tmp/foo$ /bin/echo "$foo"
>1 2 3 4 5

These shouldn't cause any surprises, I hope.


Cheers,
Phil


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

Re: CPU affinity patch for 'nice'

[Philip Rowlands]

On Tue, 21 Sep 2004, Paul Eggert wrote:

[snip]

>Last but not least, is there prior art for this sort of thing?

Recent RedHats come with the taskset(1) utility in the schedutils
package. Its usage:

taskset version 1.3.0
usage: taskset [options] [mask] [pid | cmd [args...]]
set or get the affinity of a process

  -p, --pid  operate on existing given pid
  -h, --help display this help
  -v, --version  output version information

$ taskset 03 nice -20 nohup doexec arg0 timeout 30 chroot /var/empty env -i 
(I made up "timeout", although I still plan to write it...)

Sure, an uber-launcher could know about multiple different modifications
to a process's world-view, but I don't think CPU affinity and scheduler
priority fit quite well enough together to share in a common app.


Cheers,
Phil


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

Re: rm -rf / protection

[Philip Rowlands]

On Tue, 5 Oct 2004 [EMAIL PROTECTED] wrote:

>I thought this was interesting...
>http://blogs.sun.com/roller/page/jbeck/20041001#rm_rf_protection

I'd struggle to find a justification for removing / (perhaps some
chroot'd scenario), but surely this kind of protection mechanism belongs
in the [interactive] shell, a la tcsh's "rmstar" builtin.


Cheers,
Phil


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

Re: wc can not count very large file

[Philip Rowlands]

On Thu, 7 Oct 2004 [EMAIL PROTECTED] wrote:

>find . -name '*.[ch]' -print0 |
>xargs -r0 wc -l |
>grep -Ev "^[ ]+ [0-9]+ total" |
>tr -s ' ' |
>cut -f2 -d' ' |
>(tr '\n' +; echo 0) |
>bc

I name that tune in 3:
find . -type f -name '*.[ch]' -print0 |
xargs -r0 -n1 wc -l |
awk '{total += $1} END {print total}'


Cheers,
Phil

P.S. Is there some slowdown/moderation on this list? My last email I
sent took 14 hours to make it back to my, whereas other threads are
fairly snappy. We'll see on this one, sent at 11:43 GMT...


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

Re: TERRIBLE sort performance in RedHat 9.0

[Philip Rowlands]

On Fri, 8 Oct 2004, Mike Westall wrote:

>The file fack.0-1.dif is an ASCII text file of 54,853 lines
>with 4 columns of numeric data.  I noticed very slow performance
>when trying to sort on a RH9.0 system:

Stop right there - Unicode problems. See:
http://rhn.redhat.com/errata/RHBA-2004-083.html

And the changelogs in:
ftp://updates.redhat.com/9/en/os/i386/grep-2.5.1-7.8.i386.rpm
ftp://download.fedora.redhat.com/pub/fedora/linux/core/development/SRPMS/grep-2.5.1-29.src.rpm


Cheers,
Phil

P.S. grep is not a coreutil, BTW


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

Re: TERRIBLE sort performance in RedHat 9.0

[Philip Rowlands]

On Fri, 8 Oct 2004, Mike Westall wrote:

>Thanks for replying, but I was complaining
>about the performance of
>
><>
>
>and not grep. Does the same disease afflict
>both

Sorry, my mistake; it is the same disease though, and I think this
describes the problem you're seeing:

http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=90279

Now that RHL9 is out of support, you'll have to hunt around for a
suitable update. Of course, you could always just build from the latest
source, but if you need a Redhat-provided drop-in package I'd try
looking in Fedora Core 1 or 2, or the development "rawhide"
repositories.


Cheers,
Phil


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

Re: missing --help information for command "rmdir"

[Philip Rowlands]

On Mon, 18 Oct 2004, Alex Powell wrote:

>i have noticed there is no -option character for
>"ignore-fail-on-non-empty",

Not all long options have corresponding short options; typically I see
this when an option is a GNU-extension, and would not be found in other
version of the utility.


Cheers,
Phil


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

Re: touch - cannot use options "backward"

[Philip Rowlands]

On Mon, 1 Nov 2004, Laurent Charpentier wrote:

>>   touch --date "$(date --date '1 hour ago')" /tmp/foo
>In fact I want the date '1 hour' younger than its current timestamp
>(not 1 hour ago from now).

It's getting messy, but I think this works:
$ touch -d "$(date -d "$(date -r foo) 1 hour ago")" foo


Cheers,
Phil


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

Re: touch - cannot use options "backward"

[Philip Rowlands]

For curiosity's sake, I've been trying to track down the pedigree of
this --backward option to touch, as although I think I've disproved its
necessity, it seems a useful idea.

To pick a random distro, Red Hat Enterprise Linux 3 took a
coreutils-4.5.3.tar.bz2 base, and patched it
("fileutils-4.1.1-FBoptions.patch" gives an idea when it was introduced)
to support --forward and --backward.

More recent (Fedora) RedHat distros have removed the option; these
comments from the package changelog:

* Mon Feb 16 2004 Tim Waugh <[EMAIL PROTECTED]> 5.1.3-0.1

- 5.1.3.
- Patches ported forward or removed.

* Sat Apr 05 2003 Tim Waugh <[EMAIL PROTECTED]> 5.0-1

- 5.0.

(I've not checked that precise "Patches ... removed" comment, it just
seems the most likely.)

To address the original requirement though, would it be useful for GNU
touch to support an "--offset" option, taking a signed [fractional?]
number of seconds to affect the target date?


Cheers,
Phil


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

Re: Patch for "mv -s" option

[Philip Rowlands]

On Fri, 5 Nov 2004, Brendan Byrd/SineSwiper wrote:

>Also, I have a question about how files are moved.  Currently, all files
>are copied to a new diskspace, and then the old diskspace is removed.

Only when the file is moving across filesystem boundaries.

Try this to see how mv usually behaves:
$ strace -e trace=file mv /tmp/foo /tmp/bar

>Why not just create a hardlink (ie: x->hard_link = 1;) and remove that
>link?

Because hard links cannot cross filesystem boundaries :)

$ ln /boot/message /tmp/message
ln: creating hard link `/tmp/message' to `/boot/message': Invalid cross-device link


Cheers,
Phil


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

Re: mv not safe - deletes moved file too soon

[Philip Rowlands]

On Mon, 8 Nov 2004, Ryan Duffy wrote:

>a large file to move (e.g. 700Meg ISO image).
>large amounts of RAM available for file caching.
>2 separate disks of significantly different speed (e.g. one fast
>internal HDD, one fairly slow external HDD).

I'm going to make some assumptions here. Please correct them if wrong:
- You have some USB or FireWire drive connected (to Linux?)
- You have moved a file onto it, and noticed that mv returns well before
the kernel buffers are flushed to disk
- You have mounted the filesystems (probably implicitly) with the
"async" mount option

This has nothing to do with GNU mv, and everything to do with the kernel
I/O caching and mount options. There are options (e.g. "sync") to mount
to trade off performance against data integrity, if that's your
preference.


Cheers,
Phil


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

Re: Improve on the Vi editor

[Philip Rowlands]

On Mon, 15 Nov 2004, Dimieari Macaulay wrote:

>'am happy to join the Linux family.As a programmer,I would wish to send
>in some few contributions:
[snip]

Glad that you've taken an interest in improving the tools which ship
with whichever Linux distribution you've found, but this mailing list
really isn't the place to discuss vim.

Perhaps the vim lists would be a better place to start; you may find
your questions have already been asked and answered there:

http://www.vim.org/maillist.php


Cheers,
Phil


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

Re: [PATCH][RFC] New 'true' program

[Philip Rowlands]

On Fri, 19 Nov 2004, Paul Eggert wrote:

>If small size is all you want, I can do a lot better than that:
>
>$ ls -l true
>-rwxr-xr-x  1  eggert  eggert  10  2004-11-19 22:18  true
>$ ./true; echo $?
>0

Can't beat this for size:

$ ls -l true
-rwxr-xr-x  1 prowlands users 0 Nov 20 12:59 true
$ ./true; echo $?
0

(The implementation is left to the reader.  :-)


Cheers,
Phil


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