Re2: coreutils v5.2.1 - stat.c

[ThMO]

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