[Top][All Lists]
[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
- Re: tail -c fails (coreutils 5.92),
Bob Proulx <=