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 _______________________________________________ Bug-coreutils mailing list [email protected] http://lists.gnu.org/mailman/listinfo/bug-coreutils
