bug-coreutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: tail -c fails (coreutils 5.92)


From: Bob Proulx
Subject: Re: tail -c fails (coreutils 5.92)
Date: Mon, 31 Oct 2005 23:25:10 -0700
User-agent: Mutt/1.5.9i

Vincent Lefevre wrote:
> Under Mac OS X, with tail 5.92 installed by DarwinPorts:
> 
> prunille:~> echo abcd > blah
> prunille:~> /opt/local/bin/gtail -c 2 blah
> /opt/local/bin/gtail: cannot open `2' for reading: No such file or directory
> ==> blah <==
> abcd
> zsh: exit 1     /opt/local/bin/gtail -c 2 blah
> prunille:~[1]> /opt/local/bin/gtail --version
> tail (GNU coreutils) 5.92
> [...]

Thanks for the report.  This works for me on my GNU/Linux machine.  I
am guessing that configure is somehow not configuring the getopt
routine properly.  It may be deducing that getopt_long is available
and functional when it is not.

What is the output of grep on getopt from the config.log file?  For
example I have the following output.

  grep getopt config.log
  configure:26757: checking getopt.h usability
  configure:26801: checking getopt.h presence
  configure:26872: checking for getopt.h
  configure:26901: checking for getopt_long_only
  | #include <getopt.h>
  configure:27066: checking for working GNU getopt function
  ac_cv_func_getopt_long_only=yes
  ac_cv_header_getopt_h=yes
  gl_cv_func_gnu_getopt=yes

What is the output of grep on the config.h file?  For example I have
the following output.

  grep GETOPT config.h
  #define HAVE_GETOPT_H 1
  #define HAVE_GETOPT_LONG_ONLY 1
  /* #undef __GETOPT_PREFIX */

Would it be possible for you to get in the debugger and determine
where this goes astray and why it is not parsing the -c option
correctly?

Bob




reply via email to

[Prev in Thread] Current Thread [Next in Thread]