date bug report: %G gives incorrect year

[matt smiglarski]

The following shows how the year is not rolled back.

# date
Wed Jan  2 12:12:23 GMT 2008
# date --date '2 days ago' +'%G-%m-%d %k:%M:%S'
2008-12-31 12:12:53

However,

# date --date '2 days ago'
Mon Dec 31 12:15:02 GMT 2007

...suggests it is the %G that is the problem. The problem is mentioned
in the archives here:

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

...but the post has no replies.


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

Re: date bug report: %G gives incorrect year

[Andreas Schwab]

"matt smiglarski" <[EMAIL PROTECTED]> writes:

> The following shows how the year is not rolled back.
>
> # date
> Wed Jan  2 12:12:23 GMT 2008
> # date --date '2 days ago' +'%G-%m-%d %k:%M:%S'
> 2008-12-31 12:12:53

RTFM.

`%G'
 year corresponding to the ISO week number.  This has the same
 format and value as `%Y', except that if the ISO week number (see
 `%V') belongs to the previous or next year, that year is used
 instead.  It is normally useful only if `%V' is also used; for
 example, the format `%G-%m-%d' is probably a mistake, since it
 combines the ISO week number year with the conventional month and
 day.  This is a GNU extension.

Andreas.

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


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

linecut (further refinement)

[Steven Schubiger]

Since a bit of time passed (a month) after I debated with Jim about the
overall performance of linecut compared to an "equivalent" script in an
interpreted language (perl, python, etc.), I wrote a small perl script
[attached] and ran it and linecut on an older machine against a
few-hundred lines textfile 'extracting' several slices of lines and
have them print the slices to the terminal.

The outcome was that linecut performed significantly faster; as observed,
the slower the machine is, the execution time difference increases (e.g.,
on a 400 Mhz CPU machine [specs attached] where the perl script and
linecut were run against a ~250 lines textfile with 20 iterations,
linecut performed a bit more than 3-times faster than the script).

autotools and gnulib support has meanwhile been added, whereas proper
documentation aside from manpage output generated by help2man is still
lacking.

Features/bugfixes that were added since last RFC include:

 * (internal): copy stdin to tempfile
 * (feature): range opts: + prefix (denoting advancement of lines)
 * (bugfix): abandon strlen() while buffering to tempfile

I'm writing in the hope that, if still considered worthwhile, someone will
take the time and point out some design flaws, subtle errors, and related
bugs that weren't obvious to me or have been overlooked.



1.
#!/usr/bin/perl

use strict;
use warnings;

my @sets = ([1,2],[20,24],[50,100],[-30,-1]);
my $file = $ARGV[0];

open(my $fh, '<', $file) or die "Can't open $file: $!\n";
my @lines = <$fh>;
close($fh);

foreach my $set (@sets) {
my ($start, $end) = @$set;
my $current = $start;
while ($current <= $end) {
print $lines[$current - 1];
$current++;
}
}

2.
processor : 0
vendor_id : GenuineIntel
cpu family: 6
model : 5
model name: Pentium II (Deschutes)
stepping  : 1
cpu MHz   : 400.913
cache size: 512 KB
fdiv_bug  : no
hlt_bug   : no
f00f_bug  : no
coma_bug  : no
fpu   : yes
fpu_exception : yes
cpuid level   : 2
wp: yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov 
pat pse36 mmx fxsr
bogomips  : 799.53

Steven Schubiger


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

Re: linecut (further refinement)

[Paul Eggert]

Steven Schubiger <[EMAIL PROTECTED]> writes:

> linecut performed a bit more than 3-times faster than the script).

Here's an Awk script that ran twice as fast as the script you used,
which suggests that scripting is still pretty competitive with C here,
if you choose a faster implementation.  I tested it using Mawk, on a
text file with 15,699,634 bytes and 514,573 lines.

#! /usr/bin/mawk

BEGIN { 
sets[1, 1] = 1
sets[1, 2] = 2
sets[2, 1] = 20
sets[2, 2] = 24
sets[3, 1] = 50
sets[3, 2] = 100
sets[4, 1] = -30
sets[4, 2] = -1
}

{ line[NR] = $0 }

END {
for (i=1; i<=4; i++) {
start = sets[i, 1]
end = sets[i, 2]
if (start < 0) start = NR + start 
if (end < 0) end = NR + end
for (current = start; current <= end; current++) print line[current]
}
}


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

Re: linecut (further refinement)

[Steven Schubiger]

Paul Eggert <[EMAIL PROTECTED]> wrote:
> Here's an Awk script that ran twice as fast as the script you used,
> which suggests that scripting is still pretty competitive with C here,
> if you choose a faster implementation.  I tested it using Mawk, on a
> text file with 15,699,634 bytes and 514,573 lines.

Thanks.

Interesting, albeit not really surprising (taking into the account the
features of Perl vs. Awk).

Did you run it against linecut? If not, would you bother to do so?

Still, do you think it's worth pursuing linecut implemented in C
(given the best possible implementation) ?

I do, but if you (i.e., this list) can't be convinced, I won't pursue
this any further.

Steven Schubiger


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

Re: linecut (further refinement)

[Paul Eggert]

Steven Schubiger <[EMAIL PROTECTED]> writes:

> Did you run it against linecut? If not, would you bother to do so?

No, I didn't have a copy easily available.  I'd guess linecut would
run about 50-75% faster than mawk.

> Still, do you think it's worth pursuing linecut implemented in C
> (given the best possible implementation) ?

I doubt it, if all one gets is a 50-75% performance improvement.  As
far as I can tell, the need for linecut isn't great enough to justify
the hassle of maintaining it.


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

Is this bug in "rm"?

[Oto Brglez]

Hi all!

I was deleting something today with rm and i found the folowing:

I create folder with name "folder" and i go inside of it.
# mkdir /var/folder; cd /var/folder

Then, i create some text inside of it.
# echo "test" > test.txt

And after that i use rm to delete folder inside whitch i'm in.
# rm -rf ../folder/

Now the fun part.
# pwd

It gives me the right path. But... Where am I realy? The output is:
/var/folder

And if i want to write something in this "imaginary" folder, like this:
# echo "test" > test.txt

I get this output.
bash: test.txt: No such file or directory

...
Now... Is this "bash problem", "rm problem" or "whatever problem"? :)
Have a nice day and if it's not a bug, i'm sorry for disturbing you
all...

Bye!
Zver






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

664 vs. touch -d now

[jidanni]

Gentlemen, what's the deal, or have we been through this before and
I'm just not using the current version or something here on Debian sid
GNU/Linux 2.6.22.

$ ls -al
drwxr-xr-x 2 jidanni jidanni 60 2008-01-03 08:40 .
drwxr-xr-x 3 jidanni jidanni 60 2008-01-03 08:23 ..
-rw-rw-r-- 1 rootjidanni  2 2008-01-03 08:35 a
$ touch -d now a
touch: setting times of `a': Operation not permitted
$ touch a
$ ls -l a
-rw-rw-r-- 1 root jidanni 2 2008-01-03 08:41 a
$ touch --version
touch (GNU coreutils) 5.97
$ uname -a

Also noticed with (which inspired me to send this bug):
$ touch b
$ cp -a b a
cp: preserving times for `a': Operation not permitted

Info says:
  If changing both the access and modification times to the current
  time, `touch' can change the timestamps for files that the user running
  it does not own but has write permission for.  Otherwise, the user must
  own the files.

Well at least: Ah ha, isn't "now" the current time? Bug! Muhahaha.

Wait, you will pull out the fine print, fully aware I don't know how
to change my screen resolution to read it (OK, can use xrandr),

 The strings `now' or `today' are relative items corresponding to
  zero-valued time displacement, these strings come from the fact a
  zero-valued time displacement represents the current time when not
  otherwise changed by previous items.  They may be used to stress other...

OK, OK, you win or whatever. As usual, I was... only trying to help.


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

Re: Is this bug in "rm"?

[Bob Proulx]

Oto Brglez wrote:
> # mkdir /var/folder; cd /var/folder
> # rm -rf ../folder/
> # pwd

Files (and directories which are simply special files) are reference
counted.  Effectively the filesystem garbage-collects when the
reference count is reduced to zero.

Because your current working directory was keeping the directory busy
it was not actually deleted.  The reference count was not zero.
Therefore the program still had a directory that existed.

The rm command did unlink it from the directory above it however.  The
directory no longer has a parent.  The ".." entry has been removed.
If you were to do a list of all of the files there you would no longer
find a "." or ".." entry.

This is rather like climing out on a limb of a tree and using a saw to
cut off the limb between you and the tree trunk.  Nothing stops you
from doing it.  In some cases it might even make sense to do it.  You
might really be on a boom-lift with a safety harness trimming a
particularly problem limb and it would be a shame if you were
prevented from doing it if that was what made sense at the time.

> It gives me the right path. But... Where am I realy? The output is:
> /var/folder

Remember that "pwd" is a shell builtin and the shell will report the
value that it has been tracking in $PWD.  It actually has stale data
there.  If you were to do /bin/pwd to force using the external one you
would see:

  /bin/pwd: couldn't find directory entry in `..' with matching i-node

The way that pwd determines the name of the current directory is by
walking upward through the ".." entries and matching i-nodes to
filenames.  Because there are no ".." entries there is effectively no
path to the current working directory.

The shell remembers where it was with $PWD and reports where it was
last known to be in order to report symlinks logically instead of
physically.

You can change directory from the orhaned directory to anywhere.  Or
you can exit the process.  Either way the reference count on the old
directory will be reduced to zero at which time the filesystem will
reclaim all of the space.

> And if i want to write something in this "imaginary" folder, like this:
> # echo "test" > test.txt
> 
> I get this output.
> bash: test.txt: No such file or directory

Yes.

> Now... Is this "bash problem", "rm problem" or "whatever problem"? :)

None of the above.  It is simply how Unix-like filesystems work.  It
does not dictate to you that you cannot do such a thing.

Think of this case as a contrived example of one way for this to be
useful.  A program can create a temporary directory in /tmp and change
directory to it.  It can create temporary files there.  When done the
program can remove the entire directory to clean up all of the
associated files.  Then the program can exit.  All clean.

Bob


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

coreutils-6.9.91: enable-no-install-program ignores 'groups'

[Bauke Jan Douma]

I noticed that, when running configure with:

--enable-no-install-program="groups,id,kill,su,uptime,hostname,arch"

which, by the way, causes these warnings (which are ok I suppose):

configure: WARNING: 'groups' is already not being installed
configure: WARNING: 'su' is already not being installed
configure: WARNING: 'hostname' is already not being installed
configure: WARNING: 'arch' is already not being installed

that `make install' still happily installs 'groups'...

bjd


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