bug#45695: Date does not work for dates before 1970

2021-01-06 Thread Philip Rowlands
On Wed, 6 Jan 2021, at 16:34, zed991 wrote:
> On linux, I can use  date +%s --date "31 Dec 1969"
> The result is -9
> A negative number
> 
> But when I try it on Windows (using GNUWin32) it gives me an error -
> "invalid date"
> 
> I downloaded date for windows from this link -
> http://gnuwin32.sourceforge.net/packages/coreutils.htm

That specific page refers to coreutils 5.3.0, which was published in 2005. The 
gnuwin32 website in general doesn't appear to have been updated in over 10 
years.

My personal recommendation to run coreutils on Windows is WSL2, but there are 
other options (cygwin etc.)

Cheers,
Phil





bug#45057: Date has issues with some months in Norwegian

2020-12-05 Thread Philip Rowlands
On Sat, 5 Dec 2020, at 15:00, Odne Hellebø wrote:

> But this doesn't work for months may, october, and desember
> export LANG=nn_NO.utf8
> for i in {01..12}
> do
> mnd=$(date -d "2020-$i-01" +%B)
> date -d "01-${mnd:0:3}-2020" +%B
> done

This is documented behaviour:
https://www.gnu.org/software/coreutils/manual/html_node/General-date-syntax.html

"""
In the current implementation, only English is supported for words and 
abbreviations like ‘AM’, ‘DST’, ‘EST’, ‘first’, ‘January’, ‘Sunday’, 
‘tomorrow’, and ‘year’. 
"""

The reason only mai / okt / des fail is that the other months match in English 
/ Norwegian when considering the first three letters.


Cheers,
Phil

januar
februar
mars
april
mai
juni
juli
august
september
oktober
november
desember





bug#44240: coreutils 8.30-3ubuntu2 "date" command doesn't like one specific date: 2020-09-06

2020-10-26 Thread Philip Rowlands
On Mon, 26 Oct 2020, at 15:14, Leo Wandersleb wrote:
> for some reason I get an error with one specific date but not with others:
> 
> $ for i in 08 09 10; do for j in 5 6 7; do d="2020-$i-0$j"; echo $d $( date
> -d"$d" ); done; done
> 2020-08-05 Wed 05 Aug 2020 12:00:00 AM -04
> 2020-08-06 Thu 06 Aug 2020 12:00:00 AM -04
> 2020-08-07 Fri 07 Aug 2020 12:00:00 AM -04
> 2020-09-05 Sat 05 Sep 2020 12:00:00 AM -04
> date: invalid date ‘2020-09-06’
> 2020-09-06
> 2020-09-07 Mon 07 Sep 2020 12:00:00 AM -03

The clue is the change in timezone offset from -04 to -03. The only location I 
could find which switched on 2020-09-06 was Chile, so we can reproduce the 
problem with:

$ TZ=Chile/Continental date --debug -d 2020-09-06
date: parsed date part: (Y-M-D) 2020-09-06
date: input timezone: TZ="Chile/Continental" environment value
date: warning: using midnight as starting time: 00:00:00
date: error: invalid date/time value:
date: user provided time: '(Y-M-D) 2020-09-06 00:00:00'
date:normalized time: '(Y-M-D) 2020-09-06 01:00:00'
date: --
date:  possible reasons:
date:non-existing due to daylight-saving time;
date:numeric values overflow;
date:missing timezone
date: invalid date ‘2020-09-06’

Notice that, in Chile's DST rules, the time jumps from 23:59:59 to 01:00:00:
$ zdump -v Chile/Continental | grep 2020
Chile/Continental  Sun Apr  5 02:59:59 2020 UT = Sat Apr  4 23:59:59 2020 -03 
isdst=1 gmtoff=-10800
Chile/Continental  Sun Apr  5 03:00:00 2020 UT = Sat Apr  4 23:00:00 2020 -04 
isdst=0 gmtoff=-14400
Chile/Continental  Sun Sep  6 03:59:59 2020 UT = Sat Sep  5 23:59:59 2020 -04 
isdst=0 gmtoff=-14400
Chile/Continental  Sun Sep  6 04:00:00 2020 UT = Sun Sep  6 01:00:00 2020 -03 
isdst=1 gmtoff=-10800

Therefore there is no valid time "00:00:00", and this is the "non-existing due 
to daylight-saving time" case which date --debug reports.

This is an FAQ, which often crops up twice per year:
https://www.gnu.org/software/coreutils/faq/coreutils-faq.html#The-date-command-is-not-working-right_002e


Cheers,
Phil





bug#43497: ls exit status on removed directory

2020-09-18 Thread Philip Rowlands
Steps to reproduce:

$ mkdir /tmp/abc
$ cd /tmp/abc
$ rmdir /tmp/abc
$ ls

What happened:
no output, successful exit status

What was expected:
no output, unsuccessful exit status

ls tried to list the contents of . but failed to do so, at least on Linux:
open(".", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 3
getdents(3, 0x55e10c419cf0, 32768)  = -1 ENOENT (No such file or directory)

Although "stat ." and "ls -ld ." still work on the removed directory, should 
"ls ." report success even though the getdents syscall fails?





bug#43235: Xeoma Docker Container Bug reporting to GNU.org

2020-09-06 Thread Philip Rowlands
On Sun, 6 Sep 2020, at 06:08, Scott Carter wrote:

> *tail: unrecognized file system type 0x794c7630 for ‘/var/log/syslog’.
> please report this to bug-coreutils@gnu.org .

Recent versions of tail now take this upstream source filesystem types from
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/plain/include/uapi/linux/magic.h

which I see includes
#define OVERLAYFS_SUPER_MAGIC   0x794c7630

Thanks for the report, but as it's already fixed, you should ask whoever 
provided that docker container to update it (currently 4 years old).

> *Current password for network access:
> 

Best not to post passwords like this to a public mailing list.


Cheers,
Phil





bug#33281: head does not consume input after '-c' is satisfied

2018-11-05 Thread Philip Rowlands
On Mon, 5 Nov 2018, at 20:30, Luiz Angelo Daros de Luca wrote:
> 
> Once head read enough bytes to satisfy -c option, it stops reading input
> and quit.
> This is different from what -n does and it is also different from both
> FreeBSD and busybox head implementation.
> 
> With GNU Coreutils head:
> 
> $ echo -e "123\n456\n789" | { head -n 1; while read a; do echo "-$a-";
> done; }
> 123

This is incomplete; head doesn't read everything, but more than one line. On my 
(rather aged Linux) system:
$ head --version
head (GNU coreutils) 8.25

$ seq 1864 | { head -n 1; while read a; do echo "-$a-"; done; }
1
--
-1861-
-1862-
-1863-
-1864-

What's special about 1860 lines of output? It's just over the amount of data 
which head reads from the pipe, 8192 bytes.

$ seq 1860 | wc -c
8193

> $ echo -e "123\n456\n789" | { head -c 4; while read a; do echo "-$a-";
> done; }
> 123
> -456-
> -789-

In this case head knows it only needs 4 bytes, so only reads 4 bytes.

> With all other head implementations I tested:
> 
> $ echo -e "123\n456\n789" | { head -c 4 ; while read a ; do echo "-$a-" ;
> done ; }
> 123
> $
> 
> It would make sense to both -n and -c have the same meaning, differing only
> whether to read bytes or lines.

Consistency would be good, but consider in the case of lines, head doesn't know 
up-front how much data to read. The only way to read exactly the right amount, 
not a byte more, would be to read one byte at a time, something of a 
performance killer. It's not possible to "un-read" data you've collected via 
the read syscall.

To achieve consistency in the other direction, head could ignore the 
optimization to reduce the number of bytes read, and always read 8192 bytes, 
knowing that some would be discarded. This seems to be more in line with the 
other implementations you've tried.

For consistency's sake, what would these do? For widely differing values, the 
only way to produce the same residual output would be to consume all input data.
$ cat file.txt | { head -n 100; wc -c; }
$ cat file.txt | { head -c 100KB; wc -c; }


Cheers,
Phil





bug#25567: unrecognized file system type 0x53464846 for ‘letsencrypt.log’

2017-01-29 Thread Philip Rowlands

On 29/01/2017 08:59, Bernhard Voelker wrote:


Thanks for the report, however, the fix is already available
in a newer release (v8.26).

P.S. This type of bug report is kind of getting boring:
http://lists.gnu.org/archive/cgi-bin/namazu.cgi?query=0x53464846=Search%21=bug-coreutils=100=short=date%3Alate


How about updating the warning to something like:
Please report this via http://gnu.org/missingfs?id=0x53464846

where the landing page has the "thanks, we already know" message?


Cheers,
Phil





bug#14963: The values for the same file-system differ depending on the file tested

2013-07-30 Thread Philip Rowlands

On 27/07/2013 00:24, Zahariev, Boris wrote:


  ~]$ sudo df -h /nfs/eq-fas3240-001a/vol/a0content1/rcuvb/
FilesystemSize  Used Avail Use% Mounted on
eq-fas3240-001a:/vol/a0content1
   549G  501M  549G   1% /nfs/eq-fas3240-001a/vol/a0content1

  ~]$ sudo df -h /nfs/eq-fas3240-001a/vol/a0content1/rcuniverse/
FilesystemSize  Used Avail Use% Mounted on
eq-fas3240-001a:/vol/a0content1
   380G  495M  380G   1% /nfs/eq-fas3240-001a/vol/a0content1


The values for the same file-system differ depending on the file tested?


I infer from the pathname that you're using Netapp ONTAP as an NFS server.

From the results you see from df I infer that you're using qtree 
quotas. Have a look at the /etc/quotas file on the filer, and this document:

https://library.netapp.com/ecmdocs/ECMP1196979/html/man5/na_quotas.5.html

Cheers,
Phil





bug#13391: dd silently ignores lseek error

2013-01-09 Thread Philip Rowlands

From ea524ab7388bb35e591dcdb0fc7f7989d61143ae Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?P=C3=A1draig=20Brady?= p...@draigbrady.com
Date: Wed, 9 Jan 2013 00:42:38 +
Subject: [PATCH] dd: add [io]flag=seekable to verify file support for lseek

* src/dd.c: Add the new O_SEEKABLE flag.
(main): Verify leek() works if O_SEEKABLE is set.


leek?


(usage): Describe the new flag.
* tests/dd/misc.sh: Augment the test for the new options.
* doc/coreutils.texi (dd invocation): Describe the new option.
* cfg.mk (sc_dd_O_FLAGS): Add O_SEEKABLE to the list of private
flags with a a single underscore.
* NEWS: Mention the new feature.








bug#10819: [BUG][RM]

2012-02-16 Thread Philip Rowlands

On 16/02/2012 18:58, Eric Blake wrote:


so that we could simplify a bunch of automake recipes); but a more extensive
probing is needed in this matter I guess.  And if you are right (as I hope),
then this 'rm' feature could be documented in the Autoconf manual.


Yep, I think that's appropriate, as it is unlikely that we will come up
with any counterexamples any time soon.


As the now-POSIX-infringing behaviour is simple to detect, couldn't 
automake detect it early and die with a helpful message, or is that 
contrary to its philosophy?


Cheers,
Phil





Re: bug about date

2010-03-08 Thread Philip Rowlands

On Mon, 8 Mar 2010, gaosh wrote:


I use the command: date +%Y%m%d%H -d 1990-04-13 12 36 hours
But I get the result: 1990041501 ! The correct one should be 1990041500.


The result depends on your system's local timezone, which I assume is 
set to Asia/Shanghai or equivalent Chinese location. 1990-04-14 was a 
day when daylight saving time began, so you're seeing the extra hour 
gained. This is more obvious if you use the %z display option to see 
the UTC offset:


$ TZ=Asia/Shanghai date '+%Y%m%d%H %z' -d '1990-04-13 12 35 hours'
1990041423 +0800
$ TZ=Asia/Shanghai date '+%Y%m%d%H %z' -d '1990-04-13 12 36 hours'
1990041501 +0900

So this is not a bug, but a hazard of making precise date calculations 
around DST boundaries. Please read the FAQ discussion here:

http://www.gnu.org/software/coreutils/faq/coreutils-faq.html#The-date-command-is-not-working-right_002e


Cheers,
Phil




Re: wc user error?

2010-02-21 Thread Philip Rowlands

On Sat, 20 Feb 2010, Faheem Mitha wrote:


I'm puzzled by this. What am I missing here?

   Regards, Faheem.

fah...@avicenna:/home/cj35$ wc -l snpdb/illumina_cj35.fg_40101.map
620902 snpdb/illumina_cj35.fg_40101.map
fah...@avicenna:/home/cj35$ wc -l /home/cj35/snpdb/illumina_cj35.fg_40101.map
wc:  /home/cj35/snpdb/illumina_cj35.fg_40101.map: No such file or directory


It's unlikely this has anything to do with wc, as it simply operates on 
the supplied filenames. To narrow down the cause of the problem I'd 
suggest examining the directory name itself (use /bin/pwd) and then 
try to identify which path component is non-existent (use ls -ld).



Cheers,
Phil




Re: please fix the output of du -h

2010-02-11 Thread Philip Rowlands

On Thu, 11 Feb 2010, dh-b...@online.de wrote:


using -h with du on a directory tree can produce results several
gigabytes *below* the actual value. this is quite annoying (and just
plain wrong), especially when trying to burn a cd/dvd.


du -h doesn't do what you expect. Quoting the manual:

`-h'
`--human-readable'
 Append a size letter to each size, such as `M' for mebibytes.
 Powers of 1024 are used, not 1000; `M' stands for 1,048,576 bytes.
 This option is equivalent to `--block-size=human-readable'.  Use
 the `--si' option if you prefer powers of 1000.


Cheers,
Phil




Re: BUG: date 7.1 - reading date string

2010-02-04 Thread Philip Rowlands

On Thu, 4 Feb 2010, Klaus Bramstedt wrote:


I used the command
date -d $DATE
for almost all dates between Aug 2002 end Jan 2010 in a script.
Date has a format like this
  2003-03-30 02:08:17
However, 7 of 42048 randomly distributed dates in the list failed:

date: ungültiges Datum „2003-03-30 02:08:17“
date: ungültiges Datum „2003-03-30 02:25:58“
date: ungültiges Datum „2005-03-27 02:08:41“
date: ungültiges Datum „2006-03-26 02:41:44“
date: ungültiges Datum „2008-03-30 02:08:09“
date: ungültiges Datum „2009-03-29 02:09:26“
date: ungültiges Datum „2007-03-25 02:03:47“

For me, this seems to be a bug in the date reading part. The critical 
combination seems to be end of March and '02' as hour.


You don't say which timezone you're using, but I'll guess Europe/Berlin, 
in which case this is a DST issue, but not a bug.


$ zdump -v Europe/Berlin  | grep 2003
Europe/Berlin  Sun Mar 30 00:59:59 2003 UTC = Sun Mar 30 01:59:59 2003 CET 
isdst=0 gmtoff=3600
Europe/Berlin  Sun Mar 30 01:00:00 2003 UTC = Sun Mar 30 03:00:00 2003 CEST 
isdst=1 gmtoff=7200
Europe/Berlin  Sun Oct 26 00:59:59 2003 UTC = Sun Oct 26 02:59:59 2003 CEST 
isdst=1 gmtoff=7200
Europe/Berlin  Sun Oct 26 01:00:00 2003 UTC = Sun Oct 26 02:00:00 2003 CET 
isdst=0 gmtoff=3600

According to the daylight saving rules there was a discontinuity from 
01:59:59 - 03:00:00 on the dates you gave above, at the start of DST.


Please see this entry in the coreutils FAQ:
http://www.gnu.org/software/coreutils/faq/coreutils-faq.html#The-date-command-is-not-working-right_002e


Cheers,
Phil




Re: coreutils 8.x causes installwatch to not track symlinks

2010-02-02 Thread Philip Rowlands

On Tue, 2 Feb 2010, Eric Sandall wrote:


With coreutils 8.x (8.0 through 8.4) using installwatch to track files
breaks on symlinks. See
http://bugs.sourcemage.org/show_bug.cgi?id=15559 for more details.
Reverting to coreutils 7.6 allows installwatch to again track symlinks.


Reading through that bug report and the homepage of CheckInstall it 
appears the breakage was caused by not supporting the various *at 
syscalls which coreutils now uses, and that a fixed version was released 
on 2009-12-26. Does this new version work for you?



Cheers,
Phil




Re: expr exit status

2010-01-20 Thread Philip Rowlands

On Wed, 20 Jan 2010, salih k wrote:


add_num=`expr $int_num + 1 1/dev/null 21`

   if [ $? -ne 0 ]

some case exit status is 1552 for expr even though the argument is integer


This cannot be true, as the exit status exposed through the $? shell 
variable is limited to the range 0-255. For example,


$ sh -c 'exit 255'; echo $?
255
$ sh -c 'exit 1552'; echo $?
16

As Eric has (patiently) explained there are better ways in shell to test 
for an integer, so I'd suggest using those.


For reference, this is what expr will do with various inputs:

$ expr 5 + 1 /dev/null; echo $?
0

$ expr -1 + 1 /dev/null; echo $?
1

$ expr fish + 1 /dev/null; echo $?
expr: non-numeric argument
2


Cheers,
Phil




Re: expr exit status

2010-01-20 Thread Philip Rowlands

On Wed, 20 Jan 2010, salih k wrote:


Now shall I explain again (sorry:))

actually the issue is rare and never happened in unix .So am curious on
this.


never happened in unix? Which OS and shell are you using?


Now my query is why these exit status (254 or 16) are coming during the
first run then it become correct value after rerun?and

*what does it mean by exit status 16 and 254?Whether this can do any thing
with expr or issue with *
*/dev/null etc?*


No it can't. The exit status you observe is a bug or a mistake in your 
code or analysis.



Thats why am asking *whether I can use if [ $? -eq 1 -o $? -eq 2 -o $? -eq 3 ]
instead of*

*if [ $? -ne 0 ].


No; the apparent exit status greater than 255 is a bug, or a mistake in 
your code or analysis.



If i should not use if [ $? -eq 1 -o $? -eq 2 -o $? -eq 3 ] then i will go
ahead with case.But the current expr is a running codew so my manager need
explanation.thats why.If expr is not stable i have to change all the places
in script which uses expr.


If it's important to explain your observed usage of expr then I'm not 
sure what to suggest; maybe run the whole script under strace and check 
what arguments for exit() expr is giving, which may hint at the cause of 
the problem.



Cheers,
Phil




Re: new snapshot available: coreutils-8.2.52-4db2f

2010-01-05 Thread Philip Rowlands

On Tue, 5 Jan 2010, Jim Meyering wrote:


Here's the NEWS, then shortlogs for coreutils and gnulib:

** Bug fixes

[snip]


 tail -F (inotify-enabled) would abort when a tailed file is repeated
 renamed-aside and then recreated.
 [bug introduced in coreutils-7.5]


Should that be repeatedly?


Cheers,
Phil




Re: a problem about -regen_schema_file

2009-11-16 Thread Philip Rowlands

On Mon, 16 Nov 2009, Feng Jin wrote:


I am a user of Teamcenter engineering V9.02. now I have a problem about
-regen_schema_file.

[snip]


c:\temp\tcenginstall -regen_schema_file -u=infodba -p=infodba -g=dba

install: invalid option -- r
Try `install --help' for more information.


You have found the wrong install binary. I'm not familiar with 
Teamcenter Engineering, but it appears to include an install program 
which you need to find and run. The reason you're seeing the error 
message above is that GNU coreutils install is also present on your 
system.




Cheers,
Phil




Re: FW: +N option in tail command

2009-11-11 Thread Philip Rowlands

On Wed, 11 Nov 2009, נחשון ישורון/Nachshon Yeshurun wrote:


Man pages for the tail command shows the ability to use the +N option.
Yet, attempting it on Ubuntu 9.10 results in an error.
Is this a bug?


Not a bug.


From man pages:

 -n, --lines=N
 output the last N lines, instead of the last 10; or  use  +N  to
 output lines starting with the Nth


Attempting the command:

nachs...@nachshon-ubuntu-vm:~/temp$ tail +5 /etc/passwd
tail: cannot open `+5' for reading: No such file or directory


The manpage syntax should be read as
$ tail -n +5
or
$ tail --lines=+5


Regarding the bare tail +5 and the issues surrounding this usage 
please see:

http://www.gnu.org/software/coreutils/faq/coreutils-faq.html#Old-tail-plus-N-syntax-now-fails


Cheers,
Phil




Re: date

2009-11-03 Thread Philip Rowlands

On Mon, 2 Nov 2009, Escarrilla, Harold wrote:


/u/hescarri 29$ date -d2009-10-30 + 3 days
Sun Nov  1 23:00:00 EST 2009

It should be Nov 2.


I can't reproduce this, but it can't be a coincidence that daylight 
saving rules switched last weekend in America/New_York, and the given 
query spans the transition.


By giving an explicit time-of-day can you narrow down where the 
problem occurs? e.g.


$ date -d01:00 2009-10-31 + 2 days


Cheers,
Phil




Re: Problem with sort command

2009-11-02 Thread Philip Rowlands

On Mon, 2 Nov 2009, Justin White wrote:


I have been using the sort command for years with a syntax as follows:

cat $file | sort -t, +1


This is addressed in the FAQ:
http://www.gnu.org/software/coreutils/faq/coreutils-faq.html#Old-tail-plus-N-syntax-now-fails

In short, sort is treating +1 as a filename. The behaviour changed due 
to conflicting versions of the relevant standard, and you should rewrite 
the sort command to use the unambiguous +kN format.



Cheers,
Phil




Re: please verify

2009-10-06 Thread Philip Rowlands

On Mon, 5 Oct 2009, Chandan Kumar wrote:


I am getting some faults while doing CAL command,


cal is not part of GNU coreutils.

i.e. i am getting some leap years in case of non-leap years i.e. the 
years like 1000,500,1500,1700 etc


1700 is a leap year, and leap years predating 1582 (the adoption of the 
Gregorian Calendar) depend which calendar you're talking about.



Cheers,
Phil




Re: Problem with Firefox closing abruptly

2009-09-28 Thread Philip Rowlands

On Mon, 28 Sep 2009, David Weeks wrote:


I'm new to Ubuntu and also can't seem to get other Flash content to
function properly.


[snip]


PS - found your email in the Konsole help area.


Bingo.





feature request: sleep --random

2009-09-18 Thread Philip Rowlands
This would help with some work I'm doing today, but is it of general 
interest?


$ sleep --random 4.0

sleeps for a random amount of time up to and including the requested 
value. The purpose is that on distributed systems it's disruptive to 
have synchronized scripts all starting up together. One option is to use 
the shell's $RANDOM if available, but it's lot of typing to get true (vs 
coarsely quantized) randomness.



Phil




Re: feature request: sleep --random

2009-09-18 Thread Philip Rowlands

On Fri, 18 Sep 2009, Pádraig Brady wrote:


Pádraig Brady wrote:

sleep $(seq .1 .1 4 | head -n $(($RANDOM%40 +1)) | tail -n1)


Or more concisely using just coreutils logic:

sleep $(seq .1 .1 4 | shuf | head -n1)


This still has the quantization effects which I'm trying to avoid. Jim's 
perl suggestion would work well to ensure an even spread over the window 
of time.


$ perl -e 'sleep rand 4'

is probably the cleanest / most efficient way to do this with existing 
tools.



Cheers,
Phil




Re: Seq Segment Fault.

2009-09-18 Thread Philip Rowlands

On Fri, 18 Sep 2009, Eric Blake wrote:


However, it seems to me that your problem is that bash tries to slurp all
of $() into memory, and seq generated so much data that bash ran out of
memory (or overflowed its stack).


It's certainly possible for bash to run out of stack and crash with 
SIGSEGV.


$ bash -c 'recurse() { recurse; }; recurse'
Segmentation fault


for i in $(seq -w $NUM1 $NUM2); do wget $URL${i}$EXT; done


This could be rewritten as

seq -w $NUM1 $NUM2 | while read i ; do wget $URL${i}$EXT; done

to prevent all of seq's output having to be buffered at once.


Cheers,
Phil






seq, why so slow?

2009-09-07 Thread Philip Rowlands
The conversion of everything to long doubles internally makes seq a lot 
slower than it needs to be in integer cases, I assume from the use of 
floating-point multiplication for every line of output:


seq.c:257  x = first + i * step;

$ time seq 100  /dev/null

real0m1.616s
user0m1.610s
sys 0m0.004s


$ time ./myseq 100  /dev/null

real0m0.280s
user0m0.275s
sys 0m0.005s


Would it be possible to detect arguments which require no 
floating-point, and handle them with integer addition?



Cheers,
Phil




Re: the unicode arrow

2009-09-07 Thread Philip Rowlands

On Mon, 7 Sep 2009, Eric Blake wrote:


This was discussed last month.  The verdict is no.
http://lists.gnu.org/archive/html/bug-coreutils/2009-08/msg00048.html


This list archive has done strange things with character encodings which 
make the discussion difficult to follow. Something along the way has 
converted all the non-ascii characters into 'Ã', e.g. Pádraig into 
PÃdraig.


Anyone know who maintains lists.gnu.org (or is this a mailman/mhonarc 
issue)?



Cheers,
Phil




Re: -T option help text

2009-08-31 Thread Philip Rowlands

On Sun, 30 Aug 2009, James R. Van Zandt wrote:


For the help text, here are some alternatives:

   if DEST is a directory, then delete it first


This isn't what -T does. If DEST is an empty directory then it's 
overwritten with the rename(2) system call. Otherwise mv will fail e.g. 
if SOURCE isn't a directory or DEST is non-empty.



This is short, but doesn't handle the case of DEST being a
symbolic link

   if DEST is a directory, or a symbolic link to a directory, then delete it 
first


This isn't what -T does either. If DEST is a symlink it isn't 
deleted, merely clobbered by mv. It's the difference between


rename(file, DEST/file)  = 0
and
rename(file, DEST)   = 0

For the short --help description I'd try something like

disable special directory handling for DEST


Cheers,
Phil




Re: broken link

2009-08-31 Thread Philip Rowlands

On Mon, 31 Aug 2009, Jim Meyering wrote:


Can anyone suggest a replacement?


This is the same content, and references the expita.com URL as the 
source:


http://stagecraft.theprices.net/nomime.html


Cheers,
Phil




Re: sort -R not working

2009-08-27 Thread Philip Rowlands

On Thu, 27 Aug 2009, Barty Pleydell-Bouverie wrote:


sort -R fails to randomly sort files. I am using fedora8 - any known reason for 
this?


Fedora 8 was declared end-of-life (i.e. unsupported) on January 7, 2009. 
Can you reproduce this problem either with a current Fedora release, or 
with the latest stable coreutils source?


Also, when filing bug reports please state with as much detail as 
possible:

- What you did
- What happened (this is lacking in detail above)
- What you expected to happen


Cheers,
Phil




Re: AW: AW: AW: AW: AW: new snapshot available: coreutils-7.4.125-eca6

2009-08-19 Thread Philip Rowlands

On Wed, 19 Aug 2009, Voelker, Bernhard wrote:


somehow, my shell (/bin/ksh) doesn't like the { ... } syntax here:

 $ cd src  { touch a b; mode3=2755; ./ginstall -Cv -m$mode3 a b }
 

it waits for the command to be continued ... I can't see why


That's not quite valid (POSIX) sh, which requires a ; following every 
command.



Replacing the { ... } by ( ... ), it prints this:

 $ cd src  ( ./touch a b; mode3=2755; ./ginstall -Cv -m$mode3 a b )
 removed `b'
 `a' - `b'


This does the same thing but uses a subshell, which makes no difference 
in this example.



Cheers,
Phil




Re: Enhacement request - 'date' util

2009-08-13 Thread Philip Rowlands

On Wed, 12 Aug 2009, Alejandro Redondo wrote:


Well, the first clock set, when ntpd starts, is made in just one step.
This can be a problem when the client host is several seconds different than 
the ntp server.


Stepping versus slewing can be configured in ntpd. By default small time 
offsets are slewed, and large offsets stepped.


In the example I suffered, I had to sync different flavors clients with the 
ntpd servers.
Unluckily some of them had the ntpd daemon stopped for a lot of time and they 
had differences, to have an example, about 100secs (ntpdate -d ntp_serve 
used to know it).
It was not a problem on solaris/hpux boxes to use the date -a 100.00 and 
then restart the ntpd daemon with the right config avoiding a 100secs jump in 
time.


How fast does the kernel slew? A 0.5ms/s drift rate will fix 100s error 
in around 2.3 days; slewing is inappropriate for large corrections. If 
software can't tolerate backward steps in time then perhaps it's better 
to halt it while the system clock is fixed. (BTW, leap seconds make 
this hard.)


These commands are better suited to altering the frequency of the system 
clock:

ntpdate -B
ntpd -g -q -x
adjtimex --singleshot


Cheers,
Phil




Re: no feedback on snapshot? coreutils-7.5 coming soon

2009-08-12 Thread Philip Rowlands

On Wed, 12 Aug 2009, Jim Meyering wrote:


AFAIK, I am the only one who has built the latest snapshot:

   http://thread.gmane.org/gmane.comp.gnu.coreutils.bugs/17604

Though it's been only two days.

Unless I hear of new bug reports or portability problems soon,
expect coreutils-7.5 to be released in the next few days.


./configure  make check

works for me, non-root, Ubuntu 8.04.
===
All 341 tests passed
(40 tests were not run)
===

and for completeness, the gnulib test results were
===
All 124 tests passed
(11 tests were not run)
===


Cheers,
Phil




Re: Report a bug in the ln command

2009-08-08 Thread Philip Rowlands

On Sat, 8 Aug 2009, Laemmerhirt, Kai wrote:


in the already existing directory /srv/backup/home I wanted to create a
link for the user eddi to eddis home directory for data backup
reasons. In order not to change into the target directory I used the
following command:

ln -sf /home/eddi /srv/backup/home/eddi


Do you observe that running this command created two symlinks?
/srv/backup/home/eddi - /home/eddi
/home/eddi/eddi - /home/eddi

That's unusual; please try re-running the command with the --verbose 
flag, and report the results here. The -f flag shouldn't have any 
effect unless the link(s) already exist.



Cheers,
Phil




Re: [PATCH] ls: Use pretty UTF-8 arrow when showing where symlinks point to

2009-08-06 Thread Philip Rowlands

On Thu, 6 Aug 2009, Lennart Poettering wrote:


Diego Petten? complained that ls -l doesn't use the UTF-8 arrow
character to show where symlinks point to. This tiny patch fixes that.
With this applied the character is used when the CODESET is UTF-8
otherwise we fall back to the traditional - arrow.

Ah, ls -l is so much prettier now with this oh-so-important patch!
For verification:

http://pastie.org/573270

This will of course break scripts that try to parse the output of ls
-l and look for -. But quite frankly those scripts are broken
anyway and should be using LC_MESSAGES=C or suchlike. One could
argue this breakage might even be desirable.


Why are scripts which look for - broken? It's explicitly stated in 
the standard:


http://www.opengroup.org/onlinepubs/95399/utilities/ls.html


Cheers,
Phil




Re: Bug report for date

2009-07-28 Thread Philip Rowlands

On Tue, 28 Jul 2009, Paul Grinberg wrote:


Gives me correct date:

[ctpsmg11-dcdhealth@/opt/app/dcdhealth] # TZ=EDT+150 date
Wed Jul 22 12:27:15 EDT 2009

Gives me incorrect date:
[ctpsmg11-dcdhealth@/opt/app/dcdhealth] # TZ=EDT+172 date
Tue Jul 28 18:27:09 GMT 2009

Basically I cannot go back more than 6 days...


According to the POSIX/glibc definition of TZ:
http://www.opengroup.org/onlinepubs/95399/basedefs/xbd_chap08.html
http://www.gnu.org/s/libc/manual/html_node/TZ-Variable.html

the hour offset must be between 0 and 24. In other words, the examples 
above are undefined by the standards. Why are you trying to use TZ to 
concoct multi-day offsets?



Cheers,
Phil


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


RE: Bug report for date

2009-07-28 Thread Philip Rowlands

On Tue, 28 Jul 2009, Paul Grinberg wrote:


Shell script for SolarisIt can go future as long as I want, but past
only 6 days

http://www.isrcomputing.com/index.php?option=com_contentview=articleid=125:unix-shell-script-to-calculate-date-in-the-future-and-in-the-pastcatid=38:technology-tipsItemid=82


That script is using (/abusing) TZ beyond its stated purpose. As Bob 
suggests, GNU date can perform date calculations with relative offsets, 
e.g.


$ date -d 'now + 12 days'
Mon Aug 10 00:55:32 BST 2009


Cheers,
Phil



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


Re: bug in cp -r command

2009-07-13 Thread Philip Rowlands

On Mon, 13 Jul 2009, Sourav Chakraborty wrote:


Cp -r does not work if wild card entries are specified. Basically, it copies
all files, and ignores the wildcard entries.


cp doesn't know about wildcards; they are a shell construct. Please see 
the FAQ at http://tinyurl.com/59ovg



cp -r /directory/you/want/to/copy/from/*.ext /new/destination copies all
files to destination instead of only *.ext files. I think this is a serious
bug and should be remedied immediately.


The -r flag isn't necessary here, assuming all *.ext filenames refer to 
actual files, not directories.



Cheers,
Phil


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


Re: date bug

2009-07-08 Thread Philip Rowlands

On Tue, 7 Jul 2009, David wrote:

whist using date in a bash script there seems to be a problem returning the 
hour for 09:20


t_hr=$(date +%l) (small L) does not return 9 from 09:20 or any time between 
09:00 and 09:30


t_hr=$(date +%-I) works fine

I needed the hour with out the padded zero


I can't reproduce this:

$ date -d 09:00
Wed Jul  8 09:00:00 IST 2009
p...@dietofworms:~$ date -d 09:00 +%l
 9


Please try the following commands and report the results:
date --version
date 08:50 +%l
date 09:00 +%l
date 09:15 +%l
date 09:30 %+l
date 09:40 +%l
env -i date -u -d 09:00 +%l


Cheers,
Phil


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


Re: bug found from ls command

2009-07-07 Thread Philip Rowlands

On Mon, 6 Jul 2009, PG wrote:


r...@system76-pc:/home/xinwei/bugreport# ls -l
total 4
d---r--r-- 2 root root 4096 2009-07-05 13:27 protected



xin...@system76-pc:~/bugreport$ ls -l protected/
ls: cannot access protected/canttouchthis: Permission denied
total 0
-? ? ? ? ?? canttouchthis


http://www.gnu.org/software/coreutils/manual/html_node/Mode-Structure.html
---
   There are three kinds of permissions that a user can have for a file:

  1. permission to read the file.  For directories, this means
 permission to list the contents of the directory.
---

A directory with read permission allows the directory to be listed. 
This is not a bug.




xin...@system76-pc:~/bugreport$ find ./ -name canttouchthis


Curiously I get a different error here:

$ find ./ -name canttouchthis
find: ./protected: Permission denied

In theory find could show the file, but it attempts to chdir into the 
directory before listing, which is not allowed by the directory 
permissions.



Cheers,
Phil


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


Re: Want to contribute to Open Source.

2009-06-30 Thread Philip Rowlands

On Tue, 30 Jun 2009, VIKAS wrote:


Myself Vikas from India, i'm working as SQA in one of the big brand company.
I want to contribute to open source by doing some work for GNU.
Could you please guide me how can i contribute to GNU ?


Hi Vikas,

This page is probably the best place to start:
http://www.gnu.org/help/help.html


Cheers,
Phil


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


Re: copyright years: mass-update every January 1

2009-06-25 Thread Philip Rowlands

On Thu, 25 Jun 2009, Jim Meyering wrote:


Karl Berry just mentioned that it's now considered fine (recommended,
even) to update all copyright lists to include the new year on January 1.


I realise this list may not be the right place for GNU policy 
discussion, but how will this affect the eventual migration of coreutils 
works into the public domain?



Cheers,
Phil


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


Re: copyright years: mass-update every January 1

2009-06-25 Thread Philip Rowlands

On Thu, 25 Jun 2009, Jim Meyering wrote:


  migration of coreutils works into the public domain

I know of no such plan.


I'm refering to the copyright term limits which apply to all works, not 
a specific plan for coreutils.



Cheers,
Phil


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


Re: copyright years: mass-update every January 1

2009-06-25 Thread Philip Rowlands

On Thu, 25 Jun 2009, Alfred M. Szmidt wrote:


It doesn't affect it at all, if you use a version of coreutils from
1980, then the copyright term will be from that date.  If you use a
version from 2100 then it will be from that date.


OK, but taken separately the files have/had dates to indicate the most 
recent amendment. I'm curious whether the slavish copying (to use a 
phrase from a relevant case) of old to new file, updating only the date, 
contributes sufficient originality to defend the change in public-domain 
date.


Just trying to illustrate the point here; I don't intend to start a long 
thread, merely taking an interest in clarity of copyright terms/expiry 
in general.



Cheers,
Phil


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


Re: MAJOR Putty bug

2009-06-15 Thread Philip Rowlands

On Mon, 15 Jun 2009, Derrick Manor wrote:


I am using, or trying to use Putty to change a file ownership on an Apache 
server.

However, the chown command does not work. Tells me there is no such directory 
or file


There's not enough information to tell what's causing the problem here.

Please let us know:
- What did you do/type?
- What happened?
- What did you expect to happen?

Feel free to copy and paste the commands and output into your email; 
it's easier to see what's happening from the exact record.



Cheers,
Phil


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


Re: MAJOR Putty bug

2009-06-15 Thread Philip Rowlands

[ re-adding bug-coreutils to keep discussion on-list ]

On Mon, 15 Jun 2009, Derrick Manor wrote:


sorry:

using this basic command:

chown username home/username/public_html/path_to_directory


You've used example usernames and file paths here. Please give the exact 
command as it's typed, and the exact reply from chown.



error message: can't find file/directory


This is not an error message that chown prints. Please do not rephrase 
the output; simply paste it as it appears from chown.


It's very likely that the file does not exist. Please check using ls 
that the filename and path are correct.



Cheers,
Phil


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


Re: wish: cp: output some sort of message if copying was interrupted

2009-06-05 Thread Philip Rowlands

On Fri, 5 Jun 2009, Elmar Stellnberger wrote:


 Yes that will be a good solution for the usage of cp within shell
scripts. However in most cases I invoke cp directly via the command line
so that it is somehow awkward and very easy to forget having to issue
always an extra command that tests for the return value (i.e. cp  echo
xx).


The scenario under discussion was a simultaneous (long-running) cp and 
killall -s SIGINT cp. Shouldn't the user expect the POSIX-defined 
default behaviour for the signal?



It is not possible to create a shell alias for this since testing for
the return value must take place right -after- executing cp.


Shell functions allow arguments and multiple commands.


What about nonetheless issuing a message on stderr as long as no
-q/--quiet option is given for the cases where the return value becomes
nonzero?



 Other coreutils as rm are even more verbose than that, so why just
solely not cp? Making a difference just on cp will be somehow
conterintuitive.
  rm hug
rm: remove write-protected regular empty file `hug'? y
rm: cannot remove `hug': Permission denied


cp does print diagnostic messages to stderr in many cases where the 
return value is nonzero, e.g. permission errors. It is not an error to 
terminate immediately on SIGINT however, so I'm unsure it's worthwhile 
adding such output to cp given that wrapper scripts and shell functions 
can provide the same feature if so desired.



P.S.: In what kind of situation will it not be adequate to resume
copying by issuing the same cp-command again?


cp is not always idempotent, e.g. when using --backup. It's also 
inefficient to overwrite destination files which already exist; rsync 
would be better for repeat copies.



Cheers,
Phil


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


Re: wish: cp: output some sort of message if copying was interrupted

2009-06-01 Thread Philip Rowlands

On Sun, 24 May 2009, Elmar Stellnberger wrote:


 If I issue a 'cp -a' on one konsole and a 'killall -s SIGINT cp' on
another konsole cp -a will terminate just as if it had finished copying.


Not quite; the exit status passed to the calling process will show the 
signal used to terminate cp. This can in turn be used to diagnose a 
display any desired message, for example in bash:


$ PROMPT_COMMAND='[ $? -ne 0 ]  echo Command exited abnormally'
$ true
$ false
Command exited abnormally

Alternatively it would be possible to construct a signal-aware wrapper 
around cp and other interactive processes.



My regard would be to let it print something like 'copying interrupted'
(... and may be continued by issuing the same command once more).


As the tools already exist to build this feature it's not a good fit 
for adding to cp. The specific message regarding resumed copies would be 
highly dependent on the arguments to cp.



Cheers,
Phil


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


Re: mv italian translation

2009-04-30 Thread 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


Re: factor is too fast

2009-04-21 Thread 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: bug report

2009-03-30 Thread 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: Did I found a bug in ls?

2009-03-10 Thread 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?

2009-03-10 Thread 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: Did I found a bug in ls?

2009-03-08 Thread 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: code retour de test -s incorrect.

2009-03-05 Thread 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: ls (GNU coreutils) 6.12 bug: -d or --directory switch broken

2009-02-26 Thread 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: wc enhancement request: total option

2009-02-13 Thread 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

2009-02-13 Thread 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 -help not accurate

2008-12-29 Thread 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: bug

2008-12-13 Thread 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: WebSphere UpdateInstaller 7.0

2008-12-11 Thread 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 in uname

2008-12-09 Thread 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: Why not enhance sort to handle floating point numbers?

2008-11-08 Thread 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: FAIL: df/total-awk.log

2008-10-11 Thread 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: shorttest crash

2008-09-23 Thread 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: Bug in command test

2008-09-18 Thread 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: French accents

2008-08-29 Thread 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: coreutils: bug in date --iso-8601={seconds,ns}?

2008-08-22 Thread 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: rm opensolaris ntfs-3g problem

2008-08-11 Thread 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: Fw: chroot: error...!!!

2008-08-03 Thread 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: [PATCH] Again, do not change the mode of all directories below $HOME.

2008-07-22 Thread 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: cd command issue

2008-07-11 Thread Philip Rowlands

On Thu, 10 Jul 2008, Janarthanan Palanichamy wrote:


Hi GNU coreutils,

Today I just tried cd ~tabspace .
After entering this in the terminal it became unable to delete the ~ symbol
meaning the backspace key, enter key , right arrow marks are not detected 
and the user have to use the ctrl-c 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

2008-07-11 Thread 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: ls missing in cygwin

2008-07-04 Thread 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: du: cache directory size

2008-07-03 Thread 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: cp -u

2008-06-14 Thread 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: Problem with Date Command

2008-06-05 Thread 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: bug in sha1sum

2008-05-13 Thread 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: bug in sha1sum

2008-05-12 Thread 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: BugReport about ln command worked in NTFS

2008-05-09 Thread 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: BugReport about ln command worked in NTFS

2008-05-08 Thread 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

2008-05-06 Thread 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: OO 2.2 freezes repeatedly on Freespire 2.0.8

2008-05-01 Thread 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: NotLoggingdetails when user changes system time with date command

2008-04-09 Thread Philip Rowlands

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

When I changed the Linux system time by using date -s time 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: problem with command sort after uniq -c

2008-03-10 Thread 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: date +%s ignores TZ

2008-03-01 Thread 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: date command

2008-02-28 Thread 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: bug in the command du

2008-02-19 Thread 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

2008-02-01 Thread 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: PDT timezone bug in GNU coreutils date v6.9

2008-01-18 Thread Philip Rowlands

On Thu, 17 Jan 2008, Bob Proulx wrote:


But the case under discussion was PDT not EST.

 $ TZ=US/Pacific date -dTue 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: PDT timezone bug in GNU coreutils date v6.9

2008-01-17 Thread 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

2008-01-15 Thread 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 -dTue 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 -dTue Jan 14 08:25:26 PDT 2008 +%s
1200324326

$ export TZ=America/Los_Angeles
$ date -dTue 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: RE Serious Boot Bug In Sayabon Linux (reboots reboot process after CORRECT PWD LOGIN ENTERED)

2008-01-14 Thread 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: ls produces spurious message elements during tab completion

2008-01-12 Thread 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: Concern about --reply=no option of mv.

2008-01-07 Thread 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: Maybe a bug!

2007-12-21 Thread 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: about df and lvm

2007-12-04 Thread 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: bug-coreutils date command

2007-12-03 Thread 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


  1   2   3   >