[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re2: coreutils v5.2.1 - stat.c
From: |
ThMO |
Subject: |
Re2: coreutils v5.2.1 - stat.c |
Date: |
Wed, 28 Sep 2005 21:37:19 +0200 |
Hello Bob and others listening,
> > the `stat' command doesn't return an errorcode in case a given file
> > couldn't be stated.
> > The bug seems to be in the first calling parameter to `error()', which
> > is always 0, so the global variable `G_fail' will never be set, in
> > order to return something different than EXIT_SUCCESS - which is wrong.
>
> Thank you for taking the time to dig into this and report the bug.
> This is greatly appreciated. This bug is fixed in the latest test
> release. A new test release is in the works right now. But there
> have been quite a few changes recently and so it will take some time
> before it can be called stable. The next stable release will contain
> this fix.
>
> You might want to try the latest test release:
> ftp://alpha.gnu.org/gnu/coreutils/coreutils-5.3.0.tar.gz
> ftp://alpha.gnu.org/gnu/coreutils/coreutils-5.3.0.tar.bz2
I took the time to test the above package - and I have to say several things
about this test-release:
· even though the C compiler might be able to deal with 64-bit integer values,
this must *not* be the case with the C pre-processor:
#define ULLONG_MAX 18446744073709551615ULL
the C compiler (gcc v2.7.2.1) *is* able to deal with that value, but the
cpp can't - instead I had to hand-fix this kind of stuff with:
#define LONGEST_MODIFIER "ll"
inside config.h and I had to modify lib/fts.c and src/system.h:
I had to enclose the definition of the symbol LONGEST_MODIFIER by
#ifndef LONGEST_MODIFIER ... #endif
constructs in order to compile correctly
but the question really is - is it necessary for a system, which works
with 32-bit integers *and* which is able to handle files up to 2GB only?
-> definitely no, as it just wastes both space and running time
· lib/getdate.y:
I'm using bison v1.28 - and for me it's unacceptable, that this grammar
can't be processed corrrectly with this older version, as there is abso=
lutely no need in it, that bison is working on this grammar - instead it
should also be processed by stock berkeley yacc, which it doesn't
interestingly there is even in v1.28 a method of setting parameters both
for yylex() and yyparse() - so this is very surprising
and it's even more surprising if I look at 1.7 meg big, fat configure
script, which could handle exactly such things...
just think about that - even other people are nowadays using beta-software
in order to handle their grammars and scanners - the lastest example is
libraptor v1.4.7, which uses flex v2.5.31, which is flagged beta *and*
uses a specially hacked debian-version of this lexer, while there is abso=
lutely no need to do so
-> this is a very bad practise - IMHO
BTW, is anyone able to guarantee me, that bison v2.0 has not even one
problem with processing older (and oldest - I'm using software packages
dated in the early 80's) grammar files?
· src/su.c:
it would be nice if there would be some configure flags for the 3 compile-
time symbols for setting up the logging activity for the su command
instead I had to, as usually, hand-fix this file, just to get some loggings
of some su activity, which is boring...
· --disable-nls:
IMHO there is no need, if I decide to configure *wihtout* NLS support,
which I usually do, to setup a specific locale, since the one and only
locale is the C locale in this case (and iso-8859-1 in my case)
- although YMMV at this point
· man/dd.1:
the man-page should *always* reflect the various options, for which a
command was configured for - only while removing *all* pre-processed
man-pages (as I always do for *all* kinds of things, which could be rege=
nerated), will reflect the man-page for the dd command the command itself.
since there are two flags, which aren't supported by my older system...
-> in that case would it be more elegant, if the help() for the dd command
would #ifdef out those unsupported printing calls instead of doing it
during running-time, right? ;-)
· invoking the various commands through info:
the correct way to invoke say the info-pages for dd is:
info coreutils dd
as there is absolutely no need to pollute the info/dir file with lengthy
sub-menu options just for looking up a specific command, as the primary
source for every *real* unix-user is the man-page - and only if the de=
scription within the man-page are not as clear as it should be, will the
info reader be started - the man-page only says: info dd
· factor:
it's increddible - your factor command is *not* able to factorize negative
values - folks, even my several years old factor command taken from some
very old BSD games-package *is* able to do that!
only this command knowns nothing about the --help switch - but then again,
this could easily be done using a very small shell wrapper script
· pinky:
what's the use of this command?
if someone would be so gentle to explain me that, please?
there is a command call `w', which already does this kind of stuff and
there is already a finger command installed...
and what about the following discrepancies:
· pinky -s <user>
· pinky -l <user>
=> two different kinds of output for one and the same command - is this
command *really* described in the POSIX specs and in that way?
I can hardly believe that - instead it looks like a wet dream to me - or
am I wrong?
maybe some programmers do have too much spare time by their hands... ;-)
· NEWS:
why is the above bug, which I reported, *not* listed within the NEWS file,
clearly stated as a fixed bug?
or do I have always slowfully have to download a big, fat package paying a
lot of money to my provider using an analog modem just for getting the news
by inspecting the lengthy Changelog file?
BTW, while reading the above NEWS file I really wonder why v5.2.1 is doing
it's job...
· fprintf, printf, fputs, fputc, putc, putchar:
I may be wrong, but I seem to remember me, that some time ago the GNU
conding style said something about *not* using each and every output
function... but maybe things have changed
· configure run:
I was really astonnished - my (and that's absolutely true) libc5 based linux
system is old, but it *works* and is running fast
and I heard RMS *several* times with my own ears about harrasing against
commercial software - and this 1.7 MB fat configure file is checking for
a M$windog system?
my old unix-like system is called deprecated and support has been cancelled
by e.g. the gdb package, even though all checking routines were present,
since it was supported sometime ago - and now M$, which kicks-ass each and
every standard just to enslave their users will be supported in the big style?
-> folks, that makes *me* think, really think...
· performance of the dd command:
the execution speed of dd sucks heavily, if the ibs and obs parameters are
*not* the same, which is true for *most* small jobs, for which a unix-user
uses this command
-> maybe you should think about integrating J.S. sdd command, which beats
dd by factors...
as an example - just think about extracting a mpeg-stream out of an AVI
container, where 3 dd executions are neccessary in order to extract the
top, middle and bottom part, so to be able to reproduce the original XA
format again -> time to play with my two female slaves as otherwise I had
to take a sleep in front of my computer screen
---
I'm *not* upgrading my v5.2.1 coreutils package - instead I quickly fix the
above bug myself - and I'm going to think in the future about writing those
things completely by myself, as it looks like the days are really over, where
GNU software stands for well-developed software tools.
Sorry for that, but I'm getting sick and tired lately, if I had to see folks
out there, which believe, that only if they have nothing better to do than
to recompile the fucking system day-in and day-out, everyone else have to do
the same things.
Please people, rethink about that - I do own two female slaves, which *always*
are capable to provide me with much more pleasure than "upgrading" each and
every tool, simply because some nerd think, that he has to use this one
fucking gimmick, which makes an alternative tool unusable.
(and I'm in the programming business for more than 20 years now...)
THX for listening.
CU Tom.
(Thomas M.Ott)
Germany
- coreutils v5.2.1 - stat.c, ThMO, 2005/09/26
- Re: coreutils v5.2.1 - stat.c, Bob Proulx, 2005/09/26
- Re: coreutils v5.2.1 - stat.c, Bob Proulx, 2005/09/26
- Re2: coreutils v5.2.1 - stat.c,
ThMO <=
- Re: Re2: coreutils v5.2.1 - stat.c, Paul Eggert, 2005/09/28
- Re: Re2: coreutils v5.2.1 - stat.c, Paul Eggert, 2005/09/28
- Re: Re2: coreutils v5.2.1 - stat.c, Bob Proulx, 2005/09/29
- Re: Re2: coreutils v5.2.1 - stat.c, Jim Meyering, 2005/09/29
- Re: Re2: coreutils v5.2.1 - stat.c, Bob Proulx, 2005/09/29
- Re3: coreutils v5.2.1 - stat.c, ThMO, 2005/09/29
- Re: Re3: coreutils v5.2.1 - stat.c, Paul Eggert, 2005/09/29
- Re4: coreutils v5.2.1 - stat.c, ThMO, 2005/09/29
- Re: Re4: coreutils v5.2.1 - stat.c, Paul Eggert, 2005/09/29
- coreutils man pages "info sort" -> "info coreutils sort", Paul Eggert, 2005/09/29