bug#60989: [PATCH] rm: fail on duplicate input if force not enabled
On Sat, 21 Jan 2023, at 13:05, Łukasz Sroka wrote:
> When the input files contain duplicates, then the rm fails. Because
> duplicates occur most often when the * is used and the shell unwraps it.
> There is a very common scenario when a user accidentally enters space
> after a filename, or enters space instead of forward slash.
To fail on duplicate FILE args, this bash function would do (lightly tested,
doesn't attempt getopt processing):
function safe_rm {
local -A seen
local file
for file in "$@"; do
if [[ -v ${seen[$file]} ]]; then
echo "error: duplicate name '$file'" 1>&2
return 1
fi
seen[$file]=1
done
# no dupes seen
command rm "$@"
}
and could be used today, without waiting for the next coreutils release.
As an aside, I could be reading it wrong but the coreutils manual suggests the
file arguments are optional
rm [option]… [file]…
Cheers,
Phil
bug#45695: Date does not work for dates before 1970
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
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
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
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
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
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’
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
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
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]
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
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?
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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.
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?
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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.
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
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
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
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
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
[ 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
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
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
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
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
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?
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?
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?
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.
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
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
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
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
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
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
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
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?
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
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
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
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
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}?
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
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...!!!
[ 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.
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
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
(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
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
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
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
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
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
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
[ 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
[ 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
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
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
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
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
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
[ 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
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
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
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
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
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)
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
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.
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!
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
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
